But I think what rossko57 and I are trying to push you towards is if you actually go down that path now, it will work for all of your devices, battery powered or not. You are stuck trying to solve this one way when there are other more appropriate ways to accomplish the exact same thing in a more scalable manner.
You seem bound and determined to go down this path of using the Thing status and we are happy to help you with that. But, at the risk of speaking for rossko57, we both think that’s the wrong approach. The Thing’s ONLINE status is a poor proxy for the device’s actual status. Working with Thing status is awkward at best and inefficient (from the user’s perspective).
I wrote up a pretty comprehensive tutorial with examples in Python and Rules DSL. [Deprecated] Design Patterns: Generic Is Alive
And don’t fall into the sunk costs fallacy. It doesn’t matter how much time you’ve spent on the current approach. If it’s the wrong approach investing more time into it isn’t going to make it the right approach.
Here’s the thing about openHAB. Any reasonable approach is going to be technology independent. It is going to depend on Items and it doesn’t matter what those Items are linked to. Don’t restrict your searching and example to only those that deal with Zwave. You likely won’t actually find anything that actually talks about Zwave. Almost all the examples and tutorials you will find will talk about Items, not technologies. And they will work for all technologies.
In the code linked to above (the first approach is basically what rossko57 suggested except with a whole lot more explanation and if you don’t like that there are two additional approaches presented), I can use the exact same rule to detect when my Zwave Power meter goes offline, my connection the OpenWeatherMap’s API goes offline (or is blocked for some reason), MQTT devices (though the LWT is a better approach for that), or anything else that reports periodically.
For the Expire binding code all you have is a Group, Items configured with Expire, and a two-three line rule to generate an alert when the device changes to UNDEF.
The second approach uses separate Switch Items which get updated when any Item linked to a Channel on a given Thing updates. This is a good approach for when you have lots of Items representing the same device as it lets you use updates on all of those Items to reset the timer before it gets marked offline. Again the code is presented in Rules DSL and Python.
Don’t worry about the complex example as it has a bunch of extra stuff in it to limit how often a device can be reported as offline and such. I don’t even use that rule any more and have greatly simplified it.