OH2 Network Binding - Device always online

So the network binding on windows is just no good then? For me it sees devices and updates their last seen long after they are gone.

It works for me on Windows 10 it was perfectly stable before I updated to the latest version of OH but I do have problems with it’s reliability using the latest version

It randomly shows devices as online when there is no chance of the device being online as its unplugged

It also randomly shows devices as offline when I’m using the Internet on them so they are online

some of my rules revolve around the network binding and this behavior seriously upsets them

Do we have another option? IFTTT trigger a switch when the phone leaves/enters an area?

I use IFTTT for my prescence detection

Ifft moniters my mobile phones location and sends a command too openhab if I leave or enter an area

But ifttt can’t replace the whole network binding I still have too deal with it being unstable for devices in my house

The network binding seems more reliable running on windows 10 since updating to 2.3

I’m getting a weird pattern with the network binding on certain devices - especially one device (a mobile phone which is taken physically away from the network): apart from cases where the network binding appears to start up believing that every pingable device is online (such situations seem to occur randomly on startup, and are resolved by quitting and relaunching OH2), there’s one that has been persistent for a few days now: after the phone in question has been present on the network, then for a random chunk of time afterwards, it is intermittently detected as present just as it would be if it were physically here (off and on again every minute or so), even though it is definitely not here and CLI pings consistently show it as unreachable. Essentially, the pattern of reachability from the device genuinely being present appears to be replicated when it isn’t. And yet, at other times, when the device is taken away from the network, it genuinely detects it as offline (and staying offline), so the presence-off timer trigger works correctly (I have it set to turn presence on when it becomes pingable, and turn presence off when it has been unreachable for at least 15 minutes).

Something is definitely fishy about the functioning of the Network binding. Does anyone have any ideas about what logging to enable to trace it more thoroughly?

You said it yourself…

Sorry I wasn’t clear in my question:

log:set TRACE something.goes.here.but.i.dont.know.what

?

I need to be able to trace whatever component of OpenHAB is actually carrying out the ping and receiving the response - because I can sit with a shell side by side on the same server, manually ping the IP addresses listed in my network.things file, and the responses are correct (timed out, no route to host, etc, or good ping responses when the device is online). Meanwhile, the OH2 network binding is returning… complete bollocks. It doesn’t seem to give false negatives (when a device is online, it is returning pings), but it is giving a massive range of false positives. I suspect a failure to parse ping responses correctly (e.g. interpreting “no route to host” as a positive response), but need the correct log process identifier to find that out.

1 Like

Thanks for that - I’d looked at that page numerous times recently, just missed the one line which would have answered my question! So now I have some log output, and I suspect I’m closer to the solution. Here are some extracts from the log, for a device which is physically not present (it’s in another suburb, and has no connection virtual or otherwise to our network when it’s not physically here).

11:53:49.931 [TRACE] [ng.network.internal.PresenceDetection] - Perform native ping presence detection for 192.168.11.105
11:53:49.930 [TRACE] [ng.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.11.105 on interface: en0
11:53:49.930 [TRACE] [ng.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.11.105 on interface: utun0
11:53:54.946 [INFO ] [smarthome.event.ItemStateChangedEvent] - pingGillianPhone changed from OFF to ON

11:57:04.969 [TRACE] [ng.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.11.105 on interface: utun0
11:57:04.969 [TRACE] [ng.network.internal.PresenceDetection] - Perform native ping presence detection for 192.168.11.105
11:57:04.969 [TRACE] [ng.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.11.105 on interface: en0
11:57:10.075 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'network:pingdevice:gillianphone' has been updated.
11:57:10.078 [INFO ] [smarthome.event.ItemStateChangedEvent] - pingGillianPhone changed from ON to OFF

11:58:10.077 [TRACE] [ng.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.11.105 on interface: en0
11:58:10.078 [TRACE] [ng.network.internal.PresenceDetection] - Perform native ping presence detection for 192.168.11.105
11:58:10.077 [TRACE] [ng.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.11.105 on interface: utun0
11:58:15.097 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'network:pingdevice:gillianphone' has been updated.
11:58:15.098 [INFO ] [smarthome.event.ItemStateChangedEvent] - pingGillianPhone changed from OFF to ON

I’ve tried arping from the command line, and I get the following output:

arping -i en0 192.168.11.105
ARPING 192.168.11.105
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
^C
--- 192.168.11.105 statistics ---
8 packets transmitted, 0 packets received, 100% unanswered (0 extra)

SpaceWhale:jsondb robin$ arping -i utun0 192.168.11.105
arping: Unable to get the IPv4 address of interface utun0:
arping: libnet_get_ipaddr4(): ioctl(): Can't assign requested address
arping: Use -S to specify address manually.

Now, based on the log output, I suspect I’ve got a race condition between the interface it should be using (en0) and one it really shouldn’t be using (utun0), and that the network binding is taking the failure response of the latter as a “device is online” response, rather than a failure.

Does anyone have an idea how I might force the network binding ONLY to make arping requests on en0, but never on any other interface? Unfortunately, it doesn’t appear to handle multiple -i flags, so including “-i en0” in the arping command in the binding configuration probably won’t work, as “arping -i en0 -i utun0 …” gives the same failure as “arping -i utun0 …”, so convincing the network binding not even to try arping using utun0 seems to be the only solution.

Would you please rerun the last arping call?
And just after its exit, please do a echo $? to print out the last exit code.

Regarding forcing the binding to choose an interface: This is not implemented yet. Unfortunately it is not easy to archive automatically, because Java doesn’t help us here (it doesn’t provide us the kernel routing table which determines the interface priorities).

Cheers,
David

Hmm - all the exit codes seem to be the same.

SpaceWhale:jsondb robin$ arping -i en0 192.168.11.105
ARPING 192.168.11.105
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
^C
--- 192.168.11.105 statistics ---
8 packets transmitted, 0 packets received, 100% unanswered (0 extra)

SpaceWhale:jsondb robin$ echo $?
1
SpaceWhale:jsondb robin$ arping -i utun0 192.168.11.105
arping: Unable to get the IPv4 address of interface utun0:
arping: libnet_get_ipaddr4(): ioctl(): Can't assign requested address
arping: Use -S to specify address manually.
SpaceWhale:jsondb robin$ echo $?
1
SpaceWhale:jsondb robin$ arping -i utun1 192.168.11.105
arping: Unable to get the IPv4 address of interface utun1:
arping: libnet_get_ipaddr4(): ioctl(): Can't assign requested address
arping: Use -S to specify address manually.
SpaceWhale:jsondb robin$ echo $?
1

Perhaps I’m barking up the wrong tree… or in the wrong forest altogether…

The binding interprets “0” as a success. So “1” is fine for both unsuccessful calls.

Yes - that’s why I’m even more confused now as to why the binding is detecting the device as online. I’m going to run a few more cycles of tests. Certainly turning off arping seemed to stop the false positives. I might also see if I can custom-build a version of the binding that will behave differently, or one that will delay between different tests to make very clear when it’s getting the false positive results.

You can look up the thing in the paperUI and check the listed properties. One of them will tell you what the last successful method was. Maybe it is not even the arping part.

Here are the properties of the thing in paperUI (taken when the thing was reporting online):

uses_dhcp_listen no
dhcp_state off
presence_detection_type ARP_PING, ICMP_PING
arp_state THOMAS_HABERT_ARPING_WITHOUT_TIMEOUT
uses_ios_wakeup On
icmp_state MAC_OS_PING
uses_arp_pings no

For the time being, I’m going to have difficulty tracing this further, because having sorted out the problem that I created earlier with a duplicate network binding (but which happened after the bug was already evident), and subsequent to a couple of restarts and changes to network.cfg, it now appears to be working properly again - including with arping configured.

So that’s good, except that it puts my troubleshooting on hold for now.

Hi,
i found this thread, because i have the same problems with devices always shown as online.

I hope it is ok to revive this thread. Please be patient, it’s my first post in this forum and i am pretty new to OH. :sweat_smile:

My OH (2.4 stable) is currently running on a Windows Server 2016 directly. (I think it behaves similar to current Windows 10 regarding system ping).
I dont have arping, I use system ping only.
I disabled dhcp functionality of the binding.

Problem:
When my device (mobile phone) leaves the network, the item still shows “online”. It never switches to “offline”

I have items for online-state and latency. When i look into the logs i see:

Device present:

[vent.ItemStateChangedEvent] - I_NetDevJanPhone_Latency changed from 95.0 to 73.0

Device not present:

[vent.ItemStateChangedEvent] - I_NetDevJanPhone_Latency changed from 1373.0 to 1378.0

So the binding still thinks that the device is pingable only a bit slower.
I think a possible reason could be that the binding missinterpretes the system ping answers.

Thoughts about a possible reason:
When i do a ping in windows cmd:
On an up to date windows 10 with device present:

C:\>ping 192.168.178.44
Ping wird ausgeführt für 192.168.178.44 mit 32 Bytes Daten:
Antwort von 192.168.178.44: Bytes=32 Zeit=1ms TTL=255
...

On an up to date windows 10 with device NOT present:

C:\>ping 192.168.178.44
Ping wird ausgeführt für 192.168.178.44 mit 32 Bytes Daten:
Antwort von 192.168.178.2: Zielhost nicht erreichbar.
...

with 192.168.178.2 beeing localhost and needing more time for the answer to come. Approximately a bit more than a second (would match the 1378ms from my item for latency).
But unfortunately there IS an “answer” from localhost??
That would also explain why it works for some users when timeout is switched from 5000 to 500ms like anybody wrote above.

On a Windows 7 machine the answer looks different:

C:\>ping 192.168.178.44
Ping wird ausgeführt für 192.168.178.44 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.

So here it says NO ANSWER.

On my Windows 7 machine the binding worked. On up to date Windows 10 (and Windows Server) it doesnt.

May there be a bug in the binding, missinterpreting the response from system ping on newer windows machines?

Greetings
Jan

It’s technical not a bug, but it hasn’t been adapted for windows 10 that is correct. What we do is indeed reading the user-visible response string because the return value of ping is always the same (on Win7 at least afaik).

Open a bug report or fix the file on github :slight_smile:

Cheers, David