Okay, I’ll look into it… thanks!
Another thing is that all values in HA are displayed as unavailable when deconz is updated/restarted and has not received any messages from the sensors:
In the phoscon app it also shows up as unavailable:
However, shouldn’t these values be ignored in Home Assistant and the last available valid value be displayed?
Is there a way to debug why there are inconsistencies between deconz and HA?
(“nicht verfügbar” = unavailable, “offen”/“geöffnet” = open, “geschlossen” = closed)
I’m seeing this in HA:
whereas deconz has
Names are different, but the order is the same…
I have the suspicion that maybe the first events after the “unavailable” state are not pushed out maybe or mishandled in HA.
I think if the item is marked as unavailable in deconz the preferable choice is to have the HA component also mark the device as unavailable so that the true state of the device is known to the user in HA.
You should enable debug logging for the deconz component and watch to see what the websocket data for that sensor says - if it is marked available and sending values, but HA marks it unavailable, then there is a problem that @Robban should look into. If deconz still reports as unavailable over WS or hasn’t sent an updated value, you should raise this as an issue in the deconz rest API GitHub.
I did another reboot and see the same thing. When I trigger updates again then this is also reflected in HA.
So it seems to be just a bootstrapping thing…
Does the component pick up the current values from the deconz REST interface when it starts ? Or does it rely on websockets alone?
@marthocoo , What is the correct string to enable the logger for the component?
Is there maybe an issue with deconz regarding timestamps?
Edit:
I rebooted at around 5pm but there is a value in deconz that has timestamp of 2pm. Is this possible or did maybe the rpi not finish syncing the time when deconz received that value?
@jo-me sorry I didn’t see this message earlier; enable debug logging by adding the following to your configuration.yaml:
logger:
default: info
logs:
homeassistant.components.deconz: debug
pydeconz: debug
In other news, I took your docker image idea from above and built images that can be deployed from Docker Hub: https://hub.docker.com/r/marthoc/home-assistant-deconz/.
Just substitute marthoc/home-assistant-deconz for the normal image name in your docker run command. If on a raspberry pi, add the :rpi tag: marthoc/home-assistant-deconz:rpi.
@jo-me by enabling logger as @marthocoo we will be able to see if deconz get the information or not. I print everything in debug. So expect a lot of data.
Regarding unavailable, the logic between hass and deconz might differ in how certain data is presented. But hass only presents the information sent from deconz.
But of course there might be some dial-in to get stuff 100%. Suggestions are appreciated 
The component doesn’t care about time stamps, it acts on all messages from deconz.
I’m throwing this out here because of @jo-me recent issues with unavailable devices.
Sensors don’t update when a non-state change has happened. deCONZ reports two different events; state and config. State contains the usual things with its state and other attributes. Config reports stuff such as reachable and battery. Config comes when unreachable happens or scheduled every 5-ish minutes.
At the moment the component doesn’t update the entities if event=config, since this gave “ghost” triggers of automations for previous testers and the solution was to not trigger sensor updates when a config event is received.
Interesting - so this explains why sensors don’t seem to get marked as unavailable in HA if they are unavailable in deconz, unless they are unavailable in deconz when HA starts. Do I have that right? My preference would be to know when a sensor is unreachable so that I could figure out why, rather than assume it’s available. Maybe we could look into why the automationa get ghost triggered?
Well the ghost thing is that config triggers an update to the entity without the state actually changing. So we know what the ghost is. You can check higher up in this thread about the thoughts to fix it.
Its an easy change.
In binary_sensor/deconz.py and sensor/deconz.py in the method def async_update_callback(self, reason): remove the line if reason['state']:
Try it out and say
I’m not sure I understand completely, but I would expect that, for example. the temperature value remains the same if the sensor becomes unavailable. The timestamp shows whether the value might be stale or not. Otherwise, when the sensor returns to the network and sends the same value as before, it would be a entity value change for home assistant (20° => unavailable => 20°). That does not sound right, also in regards to automation triggers.
I have not seen battery status messages yet, but couldn’t these become separate entities just like _temperature, _humidity, e.g. _battery?
For Zwave devices, they have solved the availability question by showing a separate Zwave group that populates automatically with the detected devices and their status:
This is in addition to the values of the individual zwave devices.
So in order to find out why there is no value update for a certain device, you can look in that group to see whether the device is just sleeping or marked as dead.
That way real sensor values are not mixed with availability states and other meta information.
Makes the sensor values more type safe as well 
I have not looked at your suggestion yet, but I just noticed that since my reboot yesterday, the sensor values have swapped. While temperature was reported from entity {sensor} and humidity from {sensor}_2, this is now the other way around thus making my entity name customization wrong and all other places where the enitity name was used like in the history graph:
Are you aware of this behavior?
Yes, there is no specific order that entities are loaded in and if they have the same name this will happen. Thats why I asked you to try out this
Modify this to match your device and device type.
{ “field”: “/lights/1”, “data”: {“name”: “light2”} }
For more details check the documentation here: https://raw.githubusercontent.com/Kane610/home-assistant.github.io/a49c08adb98d5333c09b84d95312116b9dab3f22/source/_components/deconz.markdown
If device is unavailable it is hass who changes state value to unavailable, the component just informs that the device is unavailable.
Yeah, depending on how it works to rename your devices I might need to add a suffix, please test this first. Might also have a discussion with deconz team about allowing renaming specific sensors of device in deconz. I’d prefer to not keep work arounds in the component for stuff that can be manually set.
Regarding battery; for devices reporting battery there is a attribute with the battery level available. On switches that doesn’t get exposed as entities there will be an additional battery entity created. This is how its expected to be.
Understood… I renamed them and its fine now. 
Was easy to forget that they are in fact 2 sensors as this is not shown in the Phoscon app but only in the rest api. My other sensors were already named correctly because I added them before phoscon became available.
Allright! You could add _temperature suffix to your sensor? Great!
I might update the documentation to mention this and also add a request to deconz team to add support for renaming multisensor devices in gui
Yeah, well I used the deconz rest api directly. Had this set up in a postman collection already.
A friendly reminder in your docs would be very helpful so that all sensor have to have unique names.
Does the component have a service call to update the device list? Right now, new sensors only show up after a HA restart.
I’m still not decided on how I’d prefer this to be handled. I agree it would be best if the individual sensors could be renamed in deconz/Phoscon, but if that’s not forthcoming then my vote would be for your component to add suffixes, I think it’s less confusing and better for end users rather than having to call a HA service or figure out using Postman to rename sensors. That’s just my thought though, I always think making it easy for people is preferable (and then, if they don’t like the suffix, they are free to rename, but the component has done the right thing in the first place, which is give each sensor a unique entity Id).
Well if I where to add the suffix that wouldn’t be possible to override with personal preference from deconz. I’d prefer to keep it as straightforward as possible.
On a second note, did you try to remove those checks to see if you got a better behavior with unavailable attribute?