I have installed the marthocoo deconz addon in HassOs and connected a bunch of tradfri lights (7) and aqara temperature sensors (6). At the moment I’m testing the reliability of the setup but notice that refreshes of (at least) the aqara sensors in phoscon are not always synced to hassio. The refresh time stated in phoscon is sometimes newer than the sensor shows in hassio, up to a few hours. It is not a specific sensor, it seems to be random.
Is it possible to force the update? I use the refresh time of the sensor to check if they are alive. I would like to use the sensors for a thermostat function thus reliability and the alive check is quite important. Do you maybe have other suggestion how to check if sensors are still working properly?
I have tried to use the unavailable option by removing the battery from 1 sensor. Unfortunately sensors seems not to go ‘unavailable’ in phoscon. It will just show refreshed X hours ago ( now already more than 9 hours). For the lights it will show when unavailable.
I got some feedback from deconz and it seems that ‘unavailable’ state is not that easy to achieve for all zigbee items. IT seems for me that the update time is the only option to check.
To force an update of the sensors even when the state did not change ( in this case temperature) is probably not desired as it could trigger automations etc. For this case it would however be usefull. Any (other) options that I could try?
I use presence detection by checking the deconz websocket port in node red. All sensors report whenever they do in Phoscon. So that’s probably an easy solution if you use node red.
@wrenchse : thanx for that solution. The direct link to deconz would be a solution but I am not using node red (yet)… @Robban : this would be great and for me i think the easiest solution without setting up additional things like node red. How can this be achieved? Can I do something to help?
when adding a new aqara sensor it is created in Hassio but it seems that sensor.py is not called. I added some “_LOGGER” in class DeconzSensor(DeconzDevice): _init_ and as shown below in class Temperature but none are shown in the log
My question is as I am still trying to learn home assitant and coding: is it something easy to fix or will it take a lot of work and better to wait until it is added in the standard code?
Hereunder the temperature class modification.
class Temperature(DeconzSensor):
"""Temperature sensor.
State parameter is a string named 'temperature'.
"""
def __init__(self, device_id, device):
"""Initalize temperature sensor."""
self._temperature = device['state'].get('temperature')
self._lastupdated = device['state'].get('lastupdated')
_LOGGER.error( "temp init {}".format(self._lastupdated))
super().__init__(device_id, device)
self._sensor_class = 'temperature'
self._sensor_icon = 'mdi:thermometer'
self._sensor_unit = '°C'
@property
def state(self):
"""Main state of sensor."""
_LOGGER.error( "temp state")
if self.temperature is None:
return None
celsius = round(float(self.temperature) / 100, 1)
return celsius
@property
def temperature(self):
"""Temperature."""
_LOGGER.error( "temp_temp")
return self._temperature
@property
def lastupdated(self):
"""last updated."""
_LOGGER.error( "temp_update")
return self._lastupdated
Thanx. I’m doubting if I want to modify the original hass files and logging into docker. This will interfere with updates of hassos, I think? Maybe it it is wise to just accept the senosr udate limitation…
I’m struggling with this problem too: I have no idea is my water leak sensor alive or not. Is there a PR created for adding last updated information to sensor attributes? This way everyone - depending on the use case - can determine when a sensor is considered to be unavailable.
What means “truly”? I removed the battery of the sensor and after 9 hours it is still available. This is not acceptable for sensor that should alert a water leak. Acceptable would be something like 5-30 minutes. Even then unavailability wouldn’t always tell wether the sensor is out of coverage from time to time. Note that water sensor is often in difficult places from radio point of view; under machines, closets, etc.