Device time out

[knasson]

hi,
WHen a device has not been updated from a certain time it appears with a red Bar on the widget or in Red on the plan
I have some devices upadted once a day so they appears with the red bar most of the time.
what is the time elapsed before red bar? is this time adustable ? and how?
thank you for your help

[pfloryann]

Agree, i have couple text sensors which receive updates every few hours and appear offline for this reason.
Another aspect is related to sensors in zigbee2mqtt via Mqtt auto discovery which very rarely transmit their status and the same problem occurs.
I have proposed this in the past... for zigbee2mqtt to take over the status from zigbee2mqtt to have a real status in domoticz as well.

[RonkA]

See Tab "Setup"-> "settings"-> "other" and find "Sensor timeout", here is the value in minutes. mine is at 1440 so that's 1 day..

Read https://wiki.domoticz.com/Application_Settings

Sensor Timeout
If the device is not seen for a long time (timed out), the highlight color will be Red. Set timeout time it in minutes

This setting only checks Sensors (temperature, humidity, lux etc), not Switches/Lights.

Also a notification can be set on sensors through the device notification button.

[pfloryann]

See Tab "Setup"-> "settings"-> "other" and find "Sensor timeout", here is the value in minutes. mine is at 1440 so that's 1 day..

Read https://wiki.domoticz.com/Application_Settings

I know but for zigbee It is not good if you don't take over the real status(Availability) of the device because for certain sensors, if the value does not change, Domoticz will display offline, even though the last seen in Zigbee2MQT was checked a few minutes before.

I will give a example... a smoke sensor if it is not triggered will be displayed offline in domoticz because it has not changed its status for a while, but in zigbee2mqtt dashbord the device is online and displays last seen(last check). This problem can be for several types of sensors.

[NomadIoT]

Hey,
Sensor Timeout (Setup > Settings > Other) is the option available and it is global. There is no way to set it per device.
It is worth mentioning: Domoticz only updates "LastUpdate" when the value changes, not just because data is received. So a sensor that is stable (, like a smoke detector that keeps saying "nothing") turns red even if it is working properly. That is probably what is happening with the zigbee2mqtt devices.The real solution would be for Domoticz to use z2ms Availability" status instead as pfloryann said.

[lost]

It is worth mentioning: Domoticz only updates "LastUpdate" when the value changes, not just because data is received.

Are you sure of this, I'm still on 2025.1 (as a consequence of libssl3 that did prevent upgrading raspian before Domoticz being compatible, I skipped 2 debian major versions and this needed a full reinstall or a double upgrade, so not so easy as usual) and LastUpdate change even if unchanged stuff may not go to DB.

This would be quite bad as I use LastUpdate quite a lot in scripts, even for unchanged values... An unchanged value IS an update from a device, even if unchanged state. There is many use-cases for using it just as it's name suggest.

On the time-out, no data from a device is not really a timeout. This would be a device that don't answer (due to a communication issue typically). On "real" timeouts, domoticz don't show any color change on devices for this, unfortunately. Just reverts back old state on the webUI. A way to notice true timeouts from webUI and in scripts would be nice: May allow handling retries only when needed instead of sending twice on devices subject to this kind of issue...

[imautohuttraeger]

I'm still on 2025.1 (as a consequence of libssl3 that did prevent upgrading raspian before Domoticz being compatible, I skipped 2 debian major versions and this needed a full reinstall or a double upgrade, so not so easy as usual) and LastUpdate change even if unchanged stuff may not go to DB.

OFFTOPIC: I had the same challenge. The following might be a platitude, but I thought sharing this consideration is not harmful:

I made a backup image of the whole SD card and then I installed rasbian with latest debian (Trixie) and alle the other stuff from scratch on a new SD card and restored the domoticz database. It worked flawlessly and after two hours downtime, domoticz was running again. If you are scared of having a longer downtime, you could take a new raspberry and make the new installation there, so the old system keeps on running. Later, you can give the old raspberry away or sell it or re-use it.

[NomadIoT]

It is worth mentioning: Domoticz only updates "LastUpdate" when the value changes, not just because data is received.

Are you sure of this, I'm still on 2025.1 (as a consequence of libssl3 that did prevent upgrading raspian before Domoticz being compatible, I skipped 2 debian major versions and this needed a full reinstall or a double upgrade, so not so easy as usual) and LastUpdate change even if unchanged stuff may not go to DB.

This would be quite bad as I use LastUpdate quite a lot in scripts, even for unchanged values... An unchanged value IS an update from a device, even if unchanged state. There is many use-cases for using it just as it's name suggest.

On the time-out, no data from a device is not really a timeout. This would be a device that don't answer (due to a communication issue typically). On "real" timeouts, domoticz don't show any color change on devices for this, unfortunately. Just reverts back old state on the webUI. A way to notice true timeouts from webUI and in scripts would be nice: May allow handling retries only when needed instead of sending twice on devices subject to this kind of issue...

Yes you are right. I think I was too vague, about LastUpdate. The method I discovered works with MQTT Auto Discovery and follows the pattern of Home Assistant. In that setup a flag called force_update exists. This flag lets a device send an update even if the value has not changed. Therefore the whole process depends on whether the zigbee2mqtt device has that flag set. LastUpdate will not trigger a message unless force_update is true. When using the hardware configuration the system likely behaves differently.

[lost]

OFFTOPIC

This was just contextual info to explain why still on a (so) old version.... not experiencing the issue. FYI, I did several migration attempts but until recently, had abrupt crashes without any stored logs for post-mortem debug. Without any clues on a headless PI3B, I was a bit in the dark.

This looked related to python plugins and the need to now use venv and IMO something changed on Domoticz and/or python integration as this now works. Issue was nailed down to a zigbee controller serial-usb interface that was configured using HW flow-control from latest update attempt, with the difference this now no-more cause such brutal kernel hang so this was possible to understand what's happening.

Now only have to finish migration when I have time as I now have working zwave and zigbee. The latest was the blocker to go ahead. But that's stuff I did years ago (like my let's encrypt certificate, my own IP cameras handling linked to domoticz using HTTP/Json API and custom pages...) and this is a bit more than restoring scripts and DB!

[imautohuttraeger]

I see. Indeed I can feel with you that adjustments having made years ago are considered to "don't touch a running system".

I am a non-coding guy who has to act like "copy - paste - hoping that it runs", so I fully understand you point.