Network:pingdevice detects sometimes incorrectly offline state

Add-ons Bindings
1

I want to fire an event (logError(), playSound()) when my system goes online and offline. The problem is that there are many false alarms: the system detects offline state, when there is in fact no offline state (internet is working fine). This implies false announcements, not only when the system goes offline, but as result also when it goes online (even if it was online all the time). But when there is a real offline state, then the logic is correct: there is a trigger for going offline, and a trigger for going online.

In particular, when I do apt-get update the system load increases, and this can results false alarm with higher probability. openhab.log contains:

2026-07-09 19:07:09.197 [WARN ] [.network.internal.utils.NetworkUtils] - Timed out while waiting for the ping process to execute
2026-07-09 19:07:59.278 [WARN ] [.network.internal.utils.NetworkUtils] - Timed out while waiting for the ping process to execute
2026-07-09 19:07:59.295 [ERROR] [org.openhab.core.model.script.rele1 ] - internet item changed OFF
2026-07-09 19:08:49.304 [ERROR] [org.openhab.core.model.script.rele1 ] - internet item changed ON

I am using openHAB 5.2.0.

  • What should I change, so that the events are triggered reliably: the internet/ping item in openHAB goes offline, when there is indeed no internet connection.

Moreover this does not have to happen instantly, as apparently it cannot be instant: one minute delay for going online and offline is OK.

I have a Thing, where 1.2.3.4 is the IP address of my internet provider, as reported by tcptrace:

Thing network:pingdevice:internet "Internet" [hostname="1.2.3.4", refreshInterval=50000, retry=4, timeout=7, useArpPing="false", useIOSWakeUp="false"]

two items

Switch internet "Internet [MAP(internet.map):%s]" <network> [Status, OpenState] {channel="network:pingdevice:internet:online"}
DateTime internet_last_change "No Internet since [%1$tY-%1$tm-%1$td %tRh]" <none>

and a rule

val play = [String s|
  playSound("webaudio", s + '.mp3')
  playSound("enhancedjavasound", s + '.mp3')
  executeCommandLine('/usr/local/bin/announce', s + '.mp3')  // this is the same as the next line
  // /usr/bin/ffmpeg -re -i /etc/openhab/sounds/$1 -filter_complex 'aresample=8000,asetnsamples=n=160' -acodec pcm_mulaw -ac 1 -f rtp udp://239.239.239.239:4444
]

rule "Internet"
when
  Item internet changed
then
  internet_last_change.postUpdate(new DateTimeType)
  if (previousState == NULL) return;
  logError('rele1', 'internet item changed ' + internet.state)
  play.apply(switch newState {
    case OFF: "internet-off"
    case ON: "internet-on"
  })
end
2

Increase the ping timeout on the Thing.

Set the timeout for 60000 for a one minute delay.

Note the refresh interval should be the same or longer than the timeout so change that as well.

Instead you could use the Debounce State profile from Basic Profiles - Transformation Services | openHAB so that the Item must remain OFF for a minute before the Item becomes OFF but immediately or very quickly becomes ON when the Channel reports it’s ON.

Alternatiively you can set a timer in your rule to wait a minute once it goes offline and only report offline if it remains OFF for the full minute. When it comes online cancel the timer. See Design Pattern: Motion Sensor Timer for different ways to implement this.

It would be way overkill, but Threshold Alert and Open Reminder [4.0.0.0;5.9.9.9] is another option, though I think this is currently broken on OH 5.2 and am working to fix that so stay tuned. If this is your only use for the template though, it’s probably not worth the extra complications.

There is also a Debounce rule template, but that’s really only needed for Items that are not linked to Channels. The Debounce profile above is a better choice when the Item is linked to a Channel.

3

I think changing the timeout to something sensible will “solve” the whole issue without the need for further complication. The description of the parameter is:

States how long to wait for a response (in ms) before a device is stated as offline.

So, this is a millisecond value, 7 milliseconds is a very short time, and by the slightest sign of contention of your Internet connection, the ping time is likely to exceed that. Setting it to 1000 would probably get rid of 99.9% of “false alarms”.

4

Thanks for the hints. The problem is that I set timeout= assuming it means seconds, while in reality it is milliseconds. Ouch!