Compare heartbeat time against current time to check if device is alive in jython

See [Deprecated] Design Patterns: Generic Is Alive.

If you use Expire, or Jython Drop-in Replacement for Expire 1.x Binding if you don’t want to install a binding you will notice that all that needs to be done in the rule is to generate the alert. No looping through all the Items every five minutes, no complicated time comparisons, just some metadata on the Item and a Rule triggered when the Item changes to UNDEF. The rule itself will tell you what Item went offline so there is no looping required. Everything is already done for you. And you get the bonus that when OH loses the connection to the MQTT broker, it will set the Items to UNDEF too which should also generate alerts and will do so immediately instead of an hour after the fact.

You can also tune it per device/Item based on how often it reports (e.g. I’ve some battery powered Zwave smoke alarms that report only once every couple of days).

Why not just compare the times directly?

if item.state.toZonedDateTime().isAfter( DateTimeType.toZonedDateTime().minusMinutes(update_interval):
    action_sensor_status.log.info(raw_item_name + " is online")
else
    action_sensor_status.log.info(raw_item_name + " is offline")

NOTE: I just typed in the above from my phone, there may be typos.

This line is a noop. item.name is already a string.

Then you probably will be happier using HAPApp which runs outside of openHAB and interacts with openHAB through it’s REST API. It’s Python 3 to boot, though it is limited to only work with what’s exposed through the REST API (e.g. no Actions). The whole point of openHAB Rules is to interact with openHAB stuff (Items, Things, etc). Why tie your hands behind your back out of some sense of purity? As soon as you start working with Item Objects you are outside of pure Python and working with Java Objects anyway. So take advantage of all the hard work done by the developers to make writing rules like this as easy as possible. You are already not going to be using pure Python anyway.

You do realize that this is exactly what is happening with a Time cron triggered rule too, right? In OH 2.5, the timers and cron triggered rules are scheduled using the same scheduler. And in general, it’s always way better to react to an event rather than polling for an event. It takes fewer resources, is more responsive, and is much easier to implement compared to polling.