Since thing status of the network binding is not reliable (always shows “Online”, even though device is switched off), I would like to use a workaround with ping…
The latency value in ms from the network binding seems to be a much better indicator for the thing status.
Idea: after successful ping -> “ONLINE”, else “OFFLINE”
e.g. if ping value is greater or equal 0, then “ONLINE” else “OFFLINE”.
Unfortunately, the following rule doesn’t work:
rule "Mesh2 Status"
when
Time cron "0 * * ? * * *"
then
if (network_pingdevice_726a2714_latency >= 0)
mesh2_status.postUpdate("ONLINE")
else
mesh2_status.postUpdate("OFFLINE")
end
Item:
String mesh2_status
Sitemap:
Text item=mesh2_status label="Mesh 2 [%s]" icon="none" valuecolor=[=="OFFLINE"="red", =="ONLINE"="green"]
I had thought that the …_online switch item from the network binding is as unreliable as the thing status from it. But it is as reliable as the _latency item.
I use the following rule which is working - even after system startup:
rule "Mesh2 Status"
when
System started or Item network_pingdevice_726a2714_online changed
then
if (network_pingdevice_726a2714_online.state == ON) {
mesh2_status.postUpdate("ONLINE")
mesh2_statusdetail.postUpdate("PING_SUCCESS")
}
else {
mesh2_status.postUpdate("OFFLINE")
mesh2_statusdetail.postUpdate("PING_FAILED")
}
end
The switch channel is provided to indicate the target’s status.
The status of a Thing is internal openHAB business. Are the resources available that are needed to attempt to ping that target? It’s not a results holder. That’s what channels and Items are for.
Not sure I understand your question. WHat do you mean by “resources” in this contaxt? Computing resources?
My main target was to get a reliable thing status.
This is highly unreliable for things via network binding. e.g. showing “Online” even if the device (thing) is switched off. I don’t think that the thing status is purely openHAB business. There are several threads about this indicating issues with thing status with the network binding - at least a relation seems to exist.
Therefore I was trying to find a workaround for it.
The _online switch items from things via network binding work for me to achieve this.
You misunderstand what the Thing tepresents here. It’s not a model of a target device. It’s something the netwrk binding can use to query the device.
Hence my rhetorical. Am I (openHAB) able to ping that target? Yes. Then the Thing is available. Whether the target eventually responds or not isn’t really important to the binding to carry out the task.
The results of that ping are of course made available to you to make your own model of the target. Usually a switch for a go/nogo indicator.
@rossko57 Thanks for your help. It sounds like it is finally time to upgrade. Fingers crossed that nothing breaks to bad. Any pointers on making a smooth upgrade? I’m running on Windows.
I’ve no idea - haven’t you watched it? If it doesn’t actually change then of course your rule will not trigger. It could take forever, see below.
Well, yes.
An openHAB MQTT Thing just sits there waiting for incoming messages from the broker. It has absolutely no way tell if any remote device even exists.
The broker is the one with the direct connection that could find out, but the broker doesn’t know if anyone wants to hear about it.
There’s a special mechanism in MQTT called “LWT”. The remote device has to initiates this when it signs on to the broker. “Hi, can you tell people if I die”. That means your Garage Opener needs to support and be configured with a LWT.
Then you need to configure the openHAB Thing to subscribe for that LWT message. Some about that here
I do not think any of this works at openHAB version 2.5.0 and you should move up to 2.5.11
There might be another approach -does your garage thingy send regular status updates? We might be able to check for a missed report.
Here is my not so elegant attempt (with device heartbeat), it works however to do this to each device seems like a lot of repetitive work, any idea’s on how to do this properly ?.
rule “Check Garage Door Opener for Heartbeat”
when
Item Heartbeat_Garage_Door2 received update //heart beat sent every 'x' minutes, coded inside device
then
Status_Garage_Door2_Expire.sendCommand(ON)
end
rule “Garage Door Opener Timer Expired”
when
Item Status_Garage_Door2_Expire received command OFF
then
logInfo("notifications", "Garage Door Opener Offline")
sendNotification("rkurek@telus.net", "Garage Door Opener Offline")
end
rule “Repeat Garage Door Opener Offline Notification”
when
Time cron "0 0/1 * * * ?"
then
if(Status_Garage_Door2_Expire.state == OFF) {
logInfo("notifications", "Garage Door Opener Offline")
sendNotification("rkurek@telus.net", "Garage Door Opener Offline")
}
‘expire’ feature applied to an existing Item allows you to update the state to some value if there’s no update within a fixed time.
If you update to UNDEF you can stop your ‘ordinary’ rules working with stale values.
If you put a number of such Items into a Group, one rule can detect if any of them change to UNDEF, and ring bells.