Page 1 of 1
Zigbee device: no reliable lastupdate
Posted: Monday 06 January 2025 15:07
by manjh
I am building a script to check if a Zigbee device (a temperature sensor, in this case) is still "alive".
But unfortunately the value that is returned does not match what I can see in the log.
The value that is returned to me with "otherdevices_lastupdate[device]" does not match, in the log of the device I can see it is being updated frequently, in fact every 5 minutes.
Am I missing something?
update: a bit more info. I have three domoticz devices for the hardware temp&hum sensor: one with both temp&hum, one with just temp, the third with only hum.
I found out that the lastupdate value for the combined temp&hum device is very different from the single temp and hum devices...
So the workaround in my LUA script is to check all three lastupdate values for the devices, and if at least one of them is in the allowed age limit, assume the device is still alive.
Not a very elegant solution, but I guess it will have to do for now.
Re: Zigbee device: no reliable lastupdate
Posted: Tuesday 07 January 2025 16:20
by manjh
Not only is this solution not very elegant, it does not work.
I have installed the device in the boot of my car, the LUA script can keep track of the fact that the car is in the driveway.
This afternoon I have been away with my car for several hours, but the device looked "present" during those hours!
When I look at the log of the three devices, then I can see entries without a pause. So it looks like the device was in range, while I am very sure that it wasn't. And yes, I am sure I took the right device...
Any clues?
Re: Zigbee device: no reliable lastupdate
Posted: Tuesday 07 January 2025 18:04
by manjh
Some more info. I looked at the log info for the device (Zigbee hum&temp sensor) and see in the graph that there is a value entry every 5 minutes.
But the output value from the lastupdate table does not match... I have been printing this value for a while now, and it runs up, it ran up to 1124 seconds with 60 seconds increment, then it dropped to 24. Does this make sense?
I am looking for a battery operated device that will give me some sort of signal every minute, so I can use it as a presence indicator for the car.
A temp&hum sensor seems like a good candidate, but....
I have considered using a simple ESP device and have that transmit a "heartbeat", but have not been able to find a battery-operated solution here.
Any ideas, anyone?
Re: Zigbee device: no reliable lastupdate
Posted: Tuesday 07 January 2025 18:47
by waltervl
manjh wrote: ↑Tuesday 07 January 2025 18:04
Some more info. I looked at the log info for the device (Zigbee hum&temp sensor) and see in the graph that there is a value entry every 5 minutes.
The 5min value is a Domoticz setting. By default Domoticz will copy the value of there was no real update. There is a setting that prevents that copying, menu Setup - Settings, tab log history.
What zigbee integration do you use?
Re: Zigbee device: no reliable lastupdate
Posted: Wednesday 08 January 2025 17:46
by manjh
waltervl wrote: ↑Tuesday 07 January 2025 18:47
manjh wrote: ↑Tuesday 07 January 2025 18:04
Some more info. I looked at the log info for the device (Zigbee hum&temp sensor) and see in the graph that there is a value entry every 5 minutes.
The 5min value is a Domoticz setting. By default Domoticz will copy the value of there was no real update. There is a setting that prevents that copying, menu Setup - Settings, tab log history.
What zigbee integration do you use?
I use plugin Zigbee-for-Domoticz. Old version, but cannot upgrade. I am still on Buster... haven't found the time and courage to upgrade to the latest Pi-OS...
Back to the sensor: from looking at the log info, I get the strong feeling that the sensor only sends a signal when a value (temp or hum) changes.
Makes sense, I suppose this extends battery life...
Re: Zigbee device: no reliable lastupdate
Posted: Wednesday 08 January 2025 17:52
by manjh
waltervl wrote: ↑Tuesday 07 January 2025 18:47
The 5min value is a Domoticz setting. By default Domoticz will copy the value of there was no real update. There is a setting that prevents that copying, menu Setup - Settings, tab log history.
Got it. Makes me wonder why it should copy values, even when they are not "new"?
Re: Zigbee device: no reliable lastupdate
Posted: Thursday 09 January 2025 12:17
by Dave21w
I would avoid using a zigbee device of any sort for this as once moved out of range they do not always reconnect when brought back. Why not use a simple BLE temp/hum sensor and then use the OpenMQTTGateway project installed on an ESP32. This will pickup BLE devices and add them to your MQTT broker and they can then be viewed in Domoticz. I use this for 3 temp/hum sensors that I have in my Fridge and 2 Freezers to monitor the temp, I chose this method as these sensors were designed for very low temps and use AA batteries instead of CR2032 coin cells. The bonus of this is it also detects the cheap BLE LCD sensor I have in my car, this sensor when not paired simply broacasts its values every minute so I use the last seen value as presence detection. When I leave home in the morning I turn on my drive lights and they go off automatically 5 mins later according to the last seen value.
Re: Zigbee device: no reliable lastupdate
Posted: Thursday 09 January 2025 12:25
by waltervl
I have no issues with all of my 7 zigbee battery powerd temperature meters...No need to go to BLE
You by the way could also this dzvents script, supplied by the Zigbee4Domoticz plugin author
https://zigbeefordomoticz.github.io/wik ... evices.lua
Re: Zigbee device: no reliable lastupdate
Posted: Thursday 09 January 2025 13:36
by Dave21w
@waltervl
I didn't say I had an issue with my zigbee battery temp sensors, I only said when a sensor is moved too far from the network when brought back they don't always rejoin.
Yes I use BLE ones for very cold environments as lithium coin cells don't last very long at minus 20 c !!
Re: Zigbee device: no reliable lastupdate
Posted: Thursday 09 January 2025 16:38
by Stepdes
Dave21w wrote: ↑Thursday 09 January 2025 13:36
@waltervl
I didn't say I had an issue with my zigbee battery temp sensors, I only said when a sensor is moved too far from the network when brought back they don't always rejoin.
Yes I use BLE ones for very cold environments as lithium coin cells don't last very long at minus 20 c !!
I have a zigbee sensor with a cr2032 in my freezer(-19) for 1 year now and still alive.
If you use different zigbee sensors together with mains powered zigbee devices like smart switches or shutterswitches, then they create a strong network.
And i don’t think that moving sensors is very common with zigbee.
Re: Zigbee device: no reliable lastupdate
Posted: Thursday 09 January 2025 17:24
by lost
Stepdes wrote: ↑
And i don’t think that moving sensors is very common with zigbee.
Right. Moving this kind of meshed devices breaks their network topology.
Issue quite clear for those buying remotes: I have one in zwave that only worked in the aera of inclusion. IMO this would be same in zigbee.
=>never buy remotes built on mesh network radios...
Anyway devices that loose their associations is weird. I have a PIR zwave sensor in my car that also reports vibration that works nicely when back.
Also have heaters control devices in zwave that have all mains switched off from april to october. Would be a hassle to need reinclusion each winter after 7 months down!
But looks this is mostly Xiaomi zigbee devices issue?
Re: Zigbee device: no reliable lastupdate
Posted: Thursday 09 January 2025 18:27
by manjh
Meanwhile I have looked a little deeper into car tracking devices. There is a very good ST-901L tracker for sale at Ali for only about €23, I've ordered it already.
Add a simple SIM (€6) with a data-only prepaid bundle (€2/year), and the car is not only visible on the driveway but wherever the thieves decide to take it...
I've installed the freeware traccar server on my Pi, it's fun to play with.
Total cost: about €30 one time investment, plus about €2 for the prepaid bundle every year. Add to that this is a new area and lots of fun to play with!