Network binding takes 1 minute to update item status

So basically you’ve got a similiar issue. Its not fast enough if you use it in a rule, because to change the input on the TV, it needs for the presense of this item to be ON. At least in my scenario.

except my Samsung binding response is almost instant so I could use that in a rule if I wanted to.

I am just wondering if it’s not OH that’s at fault but your TV.
I have the network binding too to detect ON/OFF via ping.
It’s ALLWAYS very quick to detect OFF but rather long to detect ON and I found the root cause.
It’s the TV. It takes a while to boot up and enable the network interface
The TV OS is optimised to give you a picture ASAP because it’s a TV after all
But the initialisation of the network interface come later in the game and can take up tp a minute for me.

Just a thought. If for rule purposes couldn’t you use some logic to execute a ping since then you know you’ll get a correct state?

He did say that manual pings show instant changes though.

The simplest way to tell if it’s an openHAB issue or not is to physically pull the plug on the TV - even with it on the wall, surely you must have access to the other end of either the network cable or power cable?

I think it’s probably the TV holding the network active for a random period of time, but it could also be the underlying OS of your openHAB box caching the result, or, it could very well be a logic error in the Network binding, especially if you’re still using very short timings.

As Ramz has said, the Pings are instant. Its not the TV, because the pings would continue to respond after the TV has gone off if this was causing me grief. When it switches off, pings stop. When its on, they respond as soon as its switches on.

Getting to the plug isnt possible Garry, its a 75" TV that requires two to lift it off the wall.

I changed the timings in the binding.

Is there another way to detect the presense of the TV being on/off quickly?

I think Garry meant locating the other end of the lan cable (router side) and unplugging that.

Another thought. What if you used a script (outside OH but maybe on the same server) that actually pings and then based on the result uses the OH REST api to flip a virtual switch?

Oh. Did that too - just disabled the port on the switch.

Confirming this is the right syntax for the switch, right? Doesnt make much sense to me because the thing is always online

Switch TVStatus { channel="network:pingdevice:TV:online" }

Yes, I meant unplug the network cable from the router end, or even switch the main power off to the ring main that feeds the TV (assuming your openHAB machine is powered from a different circuit)

Are you pinging from a different machine, or your openHAB machine? What have you now set your timeout and refreshInterval to?

Pinging from both a different machine, and the OH2 machine. Same result.

According to the last log snippet, the cache is still set to 2000ms.

Try to set the refreshInterval higher than 2000ms.

OK done.


17:57:42.539 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'network:pingdevice:192_168_0_200' has been updated.
17:57:42.596 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'network:pingdevice:192_168_0_200' has been updated.
17:57:42.607 [TRACE] [ng.network.internal.PresenceDetection] - Perform native ping presence detection for 192.168.0.200

issued an on command, you can see how long it takes

17:58:42.757 [TRACE] [ng.network.internal.PresenceDetection] - Perform native ping presence detection for 192.168.0.200
17:59:11.896 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'TV' received command TVOnOff
17:59:17.338 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'yamahareceiver:zone:dce3432d:Zone_2' has been updated.
17:59:17.380 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'yamahareceiver:zone:dce3432d:Zone_4' has been updated.
17:59:17.389 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'yamahareceiver:zone:dce3432d:Zone_3' has been updated.
17:59:17.410 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'yamahareceiver:zone:dce3432d:Main_Zone' has been updated.
17:59:25.290 [INFO ] [smarthome.event.ItemStateChangedEvent] - OpenHAB_Cpu_Load5 changed from 0.1 to 0.0
17:59:25.294 [INFO ] [smarthome.event.ItemStateChangedEvent] - OpenHAB_Cpu_LoadAverage changed from 0.1 to 0.0
17:59:25.295 [INFO ] [smarthome.event.ItemStateChangedEvent] - OpenHAB_Cpu_SystemUptime changed from 1177.1 to 1178.1
17:59:25.298 [INFO ] [smarthome.event.ItemStateChangedEvent] - OpenHAB_Storage_Available changed from 19492 to 60.3
17:59:25.304 [INFO ] [smarthome.event.ItemStateChangedEvent] - OpenHAB_Network_PacketsRecevied changed from 1894666 to 1895434
17:59:25.307 [INFO ] [smarthome.event.ItemStateChangedEvent] - OpenHAB_Storage_Used changed from 12845 to 39.7
17:59:25.309 [INFO ] [smarthome.event.ItemStateChangedEvent] - OpenHAB_Cpu_Load changed from 1.6 to 1.3
17:59:25.314 [INFO ] [smarthome.event.ItemStateChangedEvent] - OpenHAB_Network_PacketsSent changed from 1493884 to 1494517
17:59:25.316 [INFO ] [smarthome.event.ItemStateChangedEvent] - OpenHAB_Cpu_Load1 changed from 0.2 to 0.1
17:59:26.134 [INFO ] [smarthome.event.ItemStateChangedEvent] - OpenHAB_Storage_Available changed from 60.3 to 19492
17:59:26.137 [INFO ] [smarthome.event.ItemStateChangedEvent] - OpenHAB_Storage_Used changed from 39.7 to 12845
17:59:42.908 [TRACE] [ng.network.internal.PresenceDetection] - Perform native ping presence detection for 192.168.0.200
17:59:42.914 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'network:pingdevice:192_168_0_200' has been updated.
17:59:42.915 [INFO ] [smarthome.event.ItemStateChangedEvent] - TVStatus changed from OFF to ON


kris@OpenHAB:/etc/openhab2/items$ ping 192.168.0.200
PING 192.168.0.200 (192.168.0.200) 56(84) bytes of data.
From 192.168.0.3 icmp_seq=1 Destination Host Unreachable
From 192.168.0.3 icmp_seq=2 Destination Host Unreachable
From 192.168.0.3 icmp_seq=3 Destination Host Unreachable
From 192.168.0.3 icmp_seq=4 Destination Host Unreachable
From 192.168.0.3 icmp_seq=5 Destination Host Unreachable
From 192.168.0.3 icmp_seq=6 Destination Host Unreachable
From 192.168.0.3 icmp_seq=7 Destination Host Unreachable
From 192.168.0.3 icmp_seq=8 Destination Host Unreachable
From 192.168.0.3 icmp_seq=9 Destination Host Unreachable
From 192.168.0.3 icmp_seq=10 Destination Host Unreachable
From 192.168.0.3 icmp_seq=11 Destination Host Unreachable
From 192.168.0.3 icmp_seq=12 Destination Host Unreachable
64 bytes from 192.168.0.200: icmp_seq=13 ttl=64 time=423 ms
64 bytes from 192.168.0.200: icmp_seq=14 ttl=64 time=0.200 ms
64 bytes from 192.168.0.200: icmp_seq=15 ttl=64 time=0.239 ms
64 bytes from 192.168.0.200: icmp_seq=16 ttl=64 time=0.258 ms
64 bytes from 192.168.0.200: icmp_seq=17 ttl=64 time=0.293 ms
64 bytes from 192.168.0.200: icmp_seq=18 ttl=64 time=0.208 ms
64 bytes from 192.168.0.200: icmp_seq=19 ttl=64 time=0.298 ms
64 bytes from 192.168.0.200: icmp_seq=20 ttl=64 time=0.234 ms
64 bytes from 192.168.0.200: icmp_seq=21 ttl=64 time=0.259 ms
64 bytes from 192.168.0.200: icmp_seq=22 ttl=64 time=0.239 ms
64 bytes from 192.168.0.200: icmp_seq=23 ttl=64 time=0.219 ms
64 bytes from 192.168.0.200: icmp_seq=24 ttl=64 time=0.233 ms
64 bytes from 192.168.0.200: icmp_seq=25 ttl=64 time=0.206 ms
64 bytes from 192.168.0.200: icmp_seq=26 ttl=64 time=0.227 ms
64 bytes from 192.168.0.200: icmp_seq=27 ttl=64 time=0.222 ms
64 bytes from 192.168.0.200: icmp_seq=28 ttl=64 time=0.239 ms
64 bytes from 192.168.0.200: icmp_seq=29 ttl=64 time=0.331 ms
64 bytes from 192.168.0.200: icmp_seq=30 ttl=64 time=0.218 ms
64 bytes from 192.168.0.200: icmp_seq=31 ttl=64 time=0.215 ms
64 bytes from 192.168.0.200: icmp_seq=32 ttl=64 time=0.192 ms
64 bytes from 192.168.0.200: icmp_seq=33 ttl=64 time=0.222 ms
64 bytes from 192.168.0.200: icmp_seq=34 ttl=64 time=0.216 ms
64 bytes from 192.168.0.200: icmp_seq=35 ttl=64 time=0.211 ms
64 bytes from 192.168.0.200: icmp_seq=36 ttl=64 time=0.211 ms
64 bytes from 192.168.0.200: icmp_seq=37 ttl=64 time=0.228 ms
64 bytes from 192.168.0.200: icmp_seq=38 ttl=64 time=0.194 ms
64 bytes from 192.168.0.200: icmp_seq=39 ttl=64 time=0.239 ms
64 bytes from 192.168.0.200: icmp_seq=40 ttl=64 time=0.248 ms
64 bytes from 192.168.0.200: icmp_seq=41 ttl=64 time=0.241 ms
64 bytes from 192.168.0.200: icmp_seq=42 ttl=64 time=0.279 ms
64 bytes from 192.168.0.200: icmp_seq=43 ttl=64 time=0.277 ms

That’s picked up the change in status bang on xx:xx:42 seconds - which is when the Thing was updated - so the refreshInterval is being picked up by the Binding to operate every 60 seconds (the default)…

Why is it using default when its configured otherwise?

Clearly theres an issue with the binding if the pings respond and fail immediately.

I wonder if monitoring the open TCP ports for presense is worthwhile

kris@OpenHAB:/etc/openhab2/rules$ nmap -p- 192.168.0.200

Starting Nmap 7.60 ( https://nmap.org ) at 2018-08-01 14:24 AEST
Nmap scan report for HisenseTV.lan (192.168.0.200)
Host is up (0.00088s latency).
Not shown: 65527 closed ports
PORT STATE SERVICE
1969/tcp open lipsinc1
9080/tcp open glrpc
9223/tcp open unknown
9224/tcp open unknown
38400/tcp open unknown
39500/tcp open unknown
56789/tcp open unknown
56790/tcp open unknown

Nmap done: 1 IP address (1 host up) scanned in 3.56 seconds
kris@OpenHAB:/etc/openhab2/rules$

what about what I suggested above? write an ever running script using ping https://stackoverflow.com/questions/6118948/bash-loop-ping-successful

that then uses the oh http api to switch your tv online virtual switch?

1 Like

I think ill have to. I’ve received a Juniper SRX 550 with a 24 port Gig POE module, I’m going to move all my devices over to this and try it again. If this fails, ill try the script idea.

So just revisiting this.

Changed all my hardware, same issue :frowning: Hopefully David can help on this issue or suggest ways to improve the speed