This solved the issue. Thank you.
Will continue to work on the rule to actually show the Thing status with a cron job…
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"]
What is wrong?
Seems pointless triggering on cron when you are offered triggers for Item changing. If it hasn’t changed, what use is running the rule again …
I’m guessing that is an Item. An Item is a complex object with name, label, etc. I expect what you’re interested in is its state.
But - if you are using the network binding to a ping, why not just use the switch type channel conveniently provided?
You’re right! Thank you!
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.
getThingStatusInfo() always generates an error:
var thingStatusInfo = getThingStatusInfo(“zwave:device:512:node5”)
An error occured during the script execution: The name ‘getThingStatusInfo()’ cannot be resolved to an item or type.
It doesn’t matter if the thing exists or not. It generates the same error every time.
Any ideas?
You need to have Thing Actions installed, but I thought they were part of core and always in. Your OH version?
In some versions, this was needed
ThingAction.getThingStatusInfo( xxx )
ThingAction.getThingStatusInfo gives me the same error.
My version shows 2.0.0.b5 when it starts up.
Ah right, I don’t think these features arrived until 2.4 (the current stable version)
@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.
2.0 to 2.4 is quite a step. I think I’d backup everything, start a fresh install, and restore my items/rules/things etc. Personal choice.
It is possible a 2.5 stable will be out for a Christmas project.
All,
I gave the below a try based on suggestions above and all I get reported back is NULL, any idea’s ?
rule “Garage Opener Status”
when
Thing 'mqtt:topic:7c9c3b77' changed
then
var thingStatusInfo = getThingStatusInfo("mqtt:topic:7c9c3b77")
if ((thingStatusInfo !== null) && (thingStatusInfo.getStatus().toString() == "ONLINE")){
logInfo("ThingStatus", "Garage Opener Online")
Garage_Door2_status.postUpdate(ON)
}
else {
logError("ThingStatus", "Garage Opener Offline")
Garage_Door2_status.postUpdate(OFF)
}
end
Item
Switch Garage_Door2_status “Garage Sensor On/Offline [%s]” (gOn_Offline)
What version of OH are you using?
Does the rule run, you will get evidence of that in your openhab.log or events.log ?
I remember some unlikely stories that trigger should have double quotes around uid, not single, worth a try.
ver 2.5.0, the log does not show up, used both double quotes (") and single (’) with no luck.
What is the time frame for the device to go “offline” after it has been unplugged ?.
As these are MQTT devices do I have to set something up in the broker to check it the thing is on/offline ?
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")
}
end
‘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.
Do you have an example of putting them in a group ?