-
-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Working out what sensors belong to what devices #279
Comments
If it's just for your personal use, you can give them custom names and select them on name or maybe on Type? If you really need to find it through the IDs, I would suggest using the V2 APIs. Support for the V2 APIs is available in the HueApi package: |
I haven't migrated to V2 yet but it sounds like it will be worth looking into. The reason I've blanked out some details is that I'm using this for home security as we had almost £100k of vehicles stolen from our house in a 3 week period so I'm now taking action to prevent any further thefts. |
There are a few missing fields in some of the classes such as HueApi.Models.LightLevel, so if I then parse the ExtensionData to get the information I need I'll have to rewrite the code at some point to make use of the LightLevel model. I appreciate that not everything is implemented yet, but it is also mentioned that an issue or PR should be created if something is needed that is not supported yet. Are you happy with me creating a PR to ensure LightLevel is populated with the data that is retrieved from the bridge? |
Yes, a PR that adds missing fields is more than welcome! Thanks. |
I written the following code:
But obviously the Light class already exists, so should I use the namespace HueApi.Models.LightLevel to resolve the conflict or is there a preferred way to resolve the clashing naming convention? Also, how are you determining whether something can be nullable? |
If the Light here contains the same properties, you can reuse the existing Light class. If it's specific for the LightLevel (what it looks like here), you can create something called |
It is specific for LightLevel, and using the naming you suggested will look like so:
I was thinking of breaking from the naming convention and using Lux like so:
Or if we used a different namespace we could do:
Which I think is only marginally better than the first. It is almost like the guys who write the API have overlooked this so I might point it out to them too. |
LuxLevel also sounds good! |
Sorry I did more digging and found that the light level is not the lux, to get the lux you have to do the following:
So to call it lux could be misleading. As a result I've gone back to my suggestion of using namespaces, the code looks like so when being called:
This means the sensors are all in their own HueApi.Models.Sensors namespace now. I've created a PR for the change, #281 |
When I call GetSensorsAsync I get a list of sensors in what appears to be an ordered result but I can't tell if this is guaranteed or not.
The reason this is important is because I have an outdoor motion sensor that returns 3 Sensor classes in the IReadOnlyCollection returned from the GetSensorsAsync call.
The first contains the device name, the second and third contain the sensors in the device.
Is there a way to relate all 3 so that I know that the two sensors belong to the device named X?
The reason for asking is I would like to be able to create rules based on specific devices so knowing which light sensor belongs to which device is important in order to be able to set up the rules in a GUI.
The text was updated successfully, but these errors were encountered: