- I think the temperature is only in Celsius so when users from US uses this you need a setting for the module to report in either C or F then you do the conversion. This is just a guess, i tried to find if the unit can be changed. Doesn’t look like it.
- See my attached json, i think
lightlevelis what comes from HUE motion sensor, deConz converts toluxtherefore i did the conversion.
4.2 I take it back, you are right, that information has to be somewhere. I had a look at thedevicetrackerand it takes same approach. Here is how my iPhone Battery Level shows upsensor.XXXXs_iphone_battery_levelso maybe just change it tosensor.XXXX_battery_levelbut it’s not important, it’s only if you want to follow the naming they use. - The only question is that users will ask, if you choose to use events for
ZHASwitchwhy not forZHAOpenCloseandZHAPresence? I mean they are very close, one sends a code and the the two others sends true/false. I am just saying
You have a good feeling and i have a feeling you are Swedish 
Indeed that is the case
- Hmm, yeah, might need some investigation just to be sure. I will look at you’re code to solve this I guess.
- Aah, excellent, great reference material.
- Well the difference (as I see it) compared to a switch is that it is momentary, where as you keep the state for ZHAOpenClose and ZHAPresence.
If you want to you can run the pydeconz without hass if you want to try it out and verify the different sensors before adding it to your hass instance.
So regarding lights i have seen following thing.
- When you turn the light on you set it to full brightness everything ok
- I change the brightness.
- Turn off the light
- Turn on the light
=> brightness of light is on the changed value but HASS shows full brightness
You need to save the bri on the entity when the user sets it to off.
I don’t give HASS fake values, all values for the lights comes over the web socket, you’re just not seeing the delay? Should I rethink that part perhaps?
- Yes do investigate further, most likely it’s best to ask on deconz github and i am sure you will get a good answer there how to handle units from temp sensors. You won’t find a good handle of this in my code since i only did the implementation for Celsius but that’s not enough for all users. One way is that you could just make it for Celsius then let users of Fahrenheit deal with the problem to make a template sensor where they convert to Fahrenheit.
- Well ZHAPresence state changes when there is no motion so it doesn’t keep it’s state if that’s what you mean.
- Yes but it is also interesting to keep it in that way, as you said with regards to history, so in this case there is no reason to also allow events.
I spent some time to get this working and it works in my case but i can’t put my finger on what i exactly did because i forgot. The point here is that when i turn the light on the state of the brightness in HASS need to match the lights.
I surrender…at least for the time beeing 
1 Like
I remember seeing that you specifically set the state in your setter. So will have to see if thats what necessary.
I take it back, the problem is on a group and not on a light.
Yeah, I haven’t mirrored all lights stuff to group now that you mention it 
, thanks for the reminder!
The group issue is still different between our implementations right? Will look in to it.
If you do this again and then go to the entity list, does the state correctly reflect the devices? I think that they should.
So i tried again your newest version.
Most of the things we discussed are resolved. One thing i found is that the HUE Motion sensor’s battery level is not created as a separete sensor. I guess the same goes for my IKEA Motion sensor but i can’t validate that since it’s not reachable at the moment for some reason.
When you add the battery level for instance for the HUE motion sensor do notice the HUE Motion sensor has 3 sensors in the JSON file that i sent you so you probably have to check the uniqueid and do some compare that it’s the same physical device so you don’t have to add 3 battery sensors for same physical device
One thing which i noticed while moving my groups to the new entities. Having a prefix before the name in the entity is MUCH more readable. This is against what i said before to follow same guideline with the battery sensor so for example sensor.battery_level.XXX is more readable than sensor.XXX.battery_level where XXX is dynamic. I found this out when i had a list of these below each other.
So the light group work as intended now? No issue with getting the three entities from the hue device and all parts working as expected?
Right now the implementation only supports creating a battery sensor when creating the deconz event for switches.
Ill check with upstream for naming conventions
Haven’t tested all of it, i am doing it now but i have problems. Many of my lights doesn’t show up as entities for some reason. They are reachable but has not been added to HASS, did a restart of HASS but still not there. However i did upgrade to deConz 2.04.89 today. It does work in my module without changes. I wonder what the problem might be.
Right now the implementation only supports creating a battery sensor when creating the deconz event for switches.
Yes i was afraid that would be the case 
The only thing i can thing of is that the group i can’t see is called “Køkken spots” so maybe because of the danish Ø letter ? On the other side i have lights with danish letters that gets into hass fine.
Here is the group :
"8": {
"action": {
"bri": 255,
"colormode": "ct",
"ct": 500,
"effect": "none",
"hue": 0,
"on": true,
"sat": 127,
"xy": [
0,
0
]
},
"class": "Other",
"devicemembership": [],
"etag": "2ccae63b72b7261e548ae513607b62bf",
"hidden": false,
"id": "8",
"lights": [
"17",
"21",
"13",
"19",
"12",
"20",
"14",
"15",
"18",
"16"
],
"lightsequence": [
"12",
"13",
"14",
"15",
"16",
"17",
"20",
"18",
"19",
"21"
],
"multideviceids": [],
"name": "Køkken spots",
"scenes": [],
"state": {
"any_on": true
},
"type": "LightGroup"
},
Here is a light which doesn’t show up :
{
"ctmax": 454,
"ctmin": 250,
"etag": "733ce87b0f0f23c36b115a11953c6457",
"hascolor": true,
"manufacturername": "IKEA of Sweden",
"modelid": "TRADFRI bulb GU10 WS 400lm",
"name": "Køkken Spot 6",
"state": {
"alert": "none",
"bri": 254,
"colormode": "ct",
"ct": 454,
"on": true,
"reachable": true
},
"swversion": "1.2.217",
"type": "Color temperature light",
"uniqueid": "00:0b:57:ff:fe:37:d5:9c-01"
}
```Language specific signs shouldn’t matter. Enable debug, you should see what happens and more data to understand