Detecting offline Things in a less stupid way

@rossko57 OK, back on this. This is the log entry I get when a device drops.

2021-05-10 15:41:11.368 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:device:Z-Wave_Serial_Controller:node4' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Node is not communicating with controller

I’m not sure if flagging an error alert doesn’t work because this is an info alert? How would you use Log Reader to trigger from something in this log?

No idea. How have you configured your log reader?

I wouldn’t. Personal choice, I would trigger a rule from Thing xxx:xxx changed

Thank you for this piece of code. I was looking for a way to check the status of things in HABApp because Homematic stuff needs some time after booting to initialize. HABApp is to fast. Is there also a way to come from an OpenHAB item to the linked thing to get the status?

What do you mean by that? The startup of HABApp?
It should work non the less!

You can read the item definition from OpenHAB and then get the link and use that to get the thing.
However, the thing uuid is static, so I would just copy paste that from the gui.
Is there any reason this does not work for you?

I have created a complex class for controling the rollershutters for a room. The constructor gets as parameter the room name and then collects the objects for the rollershutters, the alarm contacts, light,… in the room.
Then, base on a rule engine, actions are triggered on events. I use the same class for all the rooms in my house. So I can’t hard code the gui’s per room.
When booting up my Raspberry Pi OpenHAB and HabAPP starts. HabAPP has the config option wait_for_openhab. This works quite well. So HabAPP wait until OpenHAB comes up. Then the HabAPP engine starts loading the Python scripts. I can see in the log the rules are started. At the same time I see in OpenHAB the Homematic bridge thing (the CCU) is initializing. All the other things are in state “error bridge”. After the bridge is online, the other Homematic things start initializing and then became online.
At that point the rollershutter in HabAPP is already running the rule engine and the objects are in strange states. For now I fixed this by checking every item value if it’s None, then I wait until it becames a number.
But I hope there is a more elegant way to do this. My idea is to lookup the things of the items and then check the status of this thing and wait until they become online.

Can you use the -wos switch to wait a little longer after a reboot?
Imho that would be the most simple solution.

Yes, this would be an option. I will try this. Thank you.
But for the future it would be nice to include this in the object model of HabAPP. Somethink like a method get_all_items() in HABApp.openhab.items.Thing class or get_thing() in the OpenhabItem class.

The whole idea of Items is to abstract and hide implementation machinery.
Having said that, of course they usually have links.
Note that there may be multiple links - so you cannot have “a parent Thing”, you must have a list, and it may be empty.
An actual implementation is more likely to give you a list of channels, and leave you to work out what Things they belong to.

There is the get_item function on the oh interface that will return the whole item definition from openhab. The links are always named after the thing so it should be pretty easy to get it.

However I strongly agree with @rossko57 .
Items are there to hide the underlaying technical implementation and all you seem to be trying is to fix an initialization issue.
I’d rather tackle the issue through one of these different mechanisms:

  • mapdb that restores item states on startup
  • post update to the used items when the rule is loaded with sensible defaults
  • create the item listener only when the thing is online
    (just pass the thing uuid to the rule as an additional parameter)
  • use the wos switch and wait until all items have a proper state

I just use a timer if a response isnt received from the item then shows as offline.
Use ping for wifi
Updates from motion sensors/thermometers relies on the device providing an update - if it doesnt timer runs out and it shows as off line.
Im sure there are other ways but I have found that sufficient.