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.
Logging
a vendor and technology agnostic open source automation software for your home
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.
but need the correct log process identifier to find that out.
a vendor and technology agnostic open source automation software for your home
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.
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
May there be a bug in the binding, missinterpreting the response from system ping on newer windows machines?
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
Cheers, David