Network Binding Port Service Always On

Using OpenHab 2.2.0 and configure Network Biding to check a specific Sony HiFi port. I have tested this port with telnet and nmap. When I put the device on standby, Telnet and nmap shows me the port is not available anymore BUT the Item still shows OnLine:

default.things
Thing network:servicedevice:sonyhifist [ hostname=“192.168.2.199”, port=41824 ]

default.items
Switch swSonyHifi { channel=“network:servicedevice:sonyhifist:online” }

Even if I change the port number to any random port, the status always shows Online/ON. Seems the status is just looking at the IP and ignoring the port.

At a minimum you will need to test this with OH 2.3, even better 2.4 MY. There have been some number of bugs fixed in this binding in the more than a year since the 2.2 release.

If you are on Windows then this is definitely a known bug that has been fixed.

Great! I will do the upgrade and check again. Thanks!

Did this help to fix your problem?
I am actually running 2.4 and my network:servicedevice is always OFF (external webservice on port 80).
If I access the service by a browser it works perfectly…
:frowning:

Just bumping this old thread - I have the same problem with 2.5.0.M1 - my network:servicedevices are always ON

Dan

All,

Raspi on OH 2.4 stable.
my network binding on port 80 of an external website (IP camera) usually works.
every now and then it’s shown as disconnected (and does not come back online).
However, I can see the video stream at the very same adress so it’s obviously connected.

When I open the thing in Paper UI, change the settings slightly (e.g. refresh interval), the item comes up to normal / online.

My current settings are:
repeats: 11
time limit 70.000 ms
300.000 ms

Any idea?

70 ms is not a very long time to wait for a response from the server you are pinging. And hitting it every 300 ms is really really fast and likely adding a load to both your network and your server.

Increase the time limit to something 500 msec or over and increase your refresh interval to one 1000 msec or more.

Thanks Rich.
But actually I am using a time limit of 70000 ms - so 70 seconds. and 300 seconds for the refresh interval respectively
Sorry the thousands separator was probably misleading :slight_smile:

At least if the description in PaperUI is correct.

EDIT:
Default values are 5000 and 60000 ms

That makes much more sense. Commas, periods, it’s all good. :wink:

OK, when OH sees that the camera has gone offline but you are still able to see the stream, can you ping the camera? Especially, can you ping the camera from the same machine that OH is running on?

:joy:

Yes, the ping works fine, when the stream is available and the item is OFF

OK, that narrows down the problem quite a bit. There is something going wrong in the binding. Unfortunately I don’t know what else to try. Perhaps put the binding into debug or trace logging and see if there is something informative logged out when it goes to OFF.

I will, Rich.
Thanks for your support.
I will report back.

I have the same issues with this binding since upgrading to 2.5.0.

If you remove the ARP entry on the Openhab machinefor the specific device you are monitoring with the network binding, it behaves normal for some time. But it goes bad again mostly within 24 hours.

Alright, so it went offline again.
As always: video Stream is available and the host is pingable.

event.log shows:

    2019-06-08 04:24:52.806 [vent.ItemStateChangedEvent] - Amis_Dome changed from ON to OFF
    2019-06-08 04:24:52.814 [GroupItemStateChangedEvent] - G_Net changed from 14 to 13 through 

openhab.log:

2019-06-08 04:24:51.386 [TRACE] [g.network.internal.PresenceDetection] - Perform native ping presence detection for www.google.com
2019-06-08 04:24:52.741 [TRACE] [g.network.internal.PresenceDetection] - Perform TCP presence detection for xxx on port: 80
2019-06-08 04:24:52.852 [INFO ] [arthome.model.script.network.rules: ] - Amis_Dome disconnected
2019-06-08 04:24:55.508 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for yyy on interface: tun0
2019-06-08 04:24:55.509 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for yyy on interface: eth0
2019-06-08 04:24:55.514 [TRACE] [g.network.internal.PresenceDetection] - Perform native ping presence detection for yyy
2019-06-08 04:24:57.134 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.178.50 on interface: tun0
2019-06-08 04:24:57.135 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.178.50 on interface: eth0
2019-06-08 04:24:57.140 [TRACE] [g.network.internal.PresenceDetection] - Perform native ping presence detection for 192.168.178.50
2019-06-08 04:25:28.060 [TRACE] [g.network.internal.PresenceDetection] - Perform TCP presence detection for xxx on port: 22

After changing the thing parameters:
event:

2019-06-08 08:28:07.110 [me.event.ThingUpdatedEvent] - Thing 'network:servicedevice:dome' has been updated.
2019-06-08 08:28:07.230 [vent.ItemStateChangedEvent] - Amis_Dome changed from OFF to ON

openhab:
Here it is performing the presence detection as usual:
2019-06-08 08:28:07.131 [TRACE] [g.network.internal.PresenceDetection] - Perform TCP presence detection for xxx on port: 80

Actually I don’t see anything.
The only “special” is, that the host on port 80 is an external device through the internet.
So I assume it might be related to DynDNS changes!?

So to be clear, this is not a local device at all, it’s a roundabout pathway using a dynamic DNS?

This can involve your ISP. as well. I once used one that simply blocked all attempts to “loopback” i.e.call your dynamic address. Most seem to allow it, but I wonder if it glitches if IP changed, as you say.

Yes, it’s actually a fritz box with an external domain (xxx.myfritz.net).
Hmmm… you mean, that the ISP of the target domain is responsible?

I will check whether the IP-address of this service changed at the specific time.

In my case, my ISP (or perhaps the router they supplied) blocked any attempt to “loopback”. That’s to say, you could not access or ping my.dynamic.dns from any box onsite, although everything worked fine from the rest of the world. I do not know how this mechanism actually worked.

My point was just to be careful about laying blame where a self-reference dyndns is involved. Yours obviously works sometimes, so its not quite the same.

Thanks for pointing this out.
I never had the intention to blame something or someone (except myself not getting the point) :wink:

I am far to much appreciative for openHAB and all its contributors, so that I would not even think about blaming others.

Usually it’s pure curiosity about the reason of my issues.
Again, thanks for your help.