sometimes , the response from ping command does not include the "statistics" line , see below:
dev:267 2021-03-15 17:40:16.299 debugPING 192.168.254.20 (192.168.254.20) 1250(1278) bytes of data.
1258 bytes from 192.168.254.20: icmp_seq=1 ttl=128 time=1.24 ms
1258 bytes from 192.168.254.20: icmp_seq=2 ttl=128 time=1.25 ms
1258 bytes from 192.168.254.20: icmp_seq=3 ttl=128 time=1.20 ms
1258 bytes from 192.168.254.20: icmp_seq=4 ttl=128 time=1.27 ms
dev:2672021-03-15 17:40:12.176 debug[uri:http://192.168.254.240:8080, path:/hub/networkTest/ping/192.168.254.20, headers:[Cookie:null]]
normally it includes as :
dev:267 2021-03-15 17:39:16.314 debugPING 192.168.254.20 (192.168.254.20) 1250(1278) bytes of data.
1258 bytes from 192.168.254.20: icmp_seq=1 ttl=128 time=1.32 ms
1258 bytes from 192.168.254.20: icmp_seq=2 ttl=128 time=1.28 ms
1258 bytes from 192.168.254.20: icmp_seq=3 ttl=128 time=1.28 ms
1258 bytes from 192.168.254.20: icmp_seq=4 ttl=128 time=1.27 ms
1258 bytes from 192.168.254.20: icmp_seq=5 ttl=128 time=1.29 ms
--- 192.168.254.20 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 1.271/1.291/1.320/0.027 ms
dev:2672021-03-15 17:39:12.182 debug[uri:http://192.168.254.240:8080, path:/hub/networkTest/ping/192.168.254.20, headers:[Cookie:null]]
and when there is no statistics line, there is no "%", as a result it is marked as a failure.
why does this happen ?
how can we address it ?
I’ve never seen a successful response not have a stats line, probably something I can design a work around for, but without being able to duplicate.....
I think I've found the problem.
Because of my wrong implementation , sometimes 2 ping requests fire at the same time and this caused a cut response.
I changed the schedule and now it's good.
2 Likes
This has been very helpful confirming that my IoT firewall rules are working as I expect. Thank you.
1 Like
Thank you for this tool. This is awesome!
2 Likes
V2.0.0 is out utilizing the new direct hub ICMP ping call, if the hub is on 2.2.7.x or greater. Response seems to be quicker, and doesn't require an HTTP call.
Tried the new code - I wrote a wrapper child device list to ping around it. ie ping 10 hosts and have it show status present or not present as a device. CPU wise it was a occasional 30 sec ping to a single host in the list (round robin).
I found that the new code that calls the "hubitat.helper.NetworkUtils.PingData". If the host does not respond it fails to get the packet data timely (otherwise it comes back too early). I could not detect a loss using it. I also ran into the divide by zero in the pctLoss calculation. Instead I tested for pTran\pRec as long as pTran was => 1.
In the end it's more controllable using the old method, I could schedule a wait of 15 secs to read the values from the method handler. The new method fails when the host does not respond.
I did make a small error on the presence indicator (fixed in 2.0.1), otherwise the code was/is acting similar to the prior method - error resulted in reporting packet loss of 3333.33% (for the default 3 attempts) when the host wasn’t found - but packets transmitted is never zero if you wait for the responseReady to read true (while pinging it is set to false). Only way I can see you getting a divide by zero is if you set the number of attempts to zero (now checking for a range of 1..5)
I am getting some strange behavior and results with the latest update. If I ping something that exists and is detected I get normal behavior.
But if I ping something that I know does not exist the latest version reports that no packets were transmitted, none received, and none lost. This is not correct of course.
This broke any rule that's using the device. I am debating how to fix it myself within the rules or code but thought I'd post to see if you've experienced this too?
Edit: I also see errors in the logs now…
In addition, trying to ping an address that is not a valid address throws an error and blocks the device for some time. For example, ping 10.1.1.11111 will throw an error and the device will take some time to recover before becoming usable again.
What firmware version are you on? Didn’t see this on 2.2.7.119, but seeing it on 2.2.7.121. Fix is up (v 2.0.3)
Note that you need to wait for the responseReady flag to be true before sending another ping or your results for the first may be overwritten before you can process them.
1 Like
I just wanted to ask incase my experience is a little bit different. I have this setup to do a ping test against my Home NAS (Unraid) server. What i have noticed is that it appears that action takes about 2.3 seconds with the latest code. Is that what others are seeing and is expected for each ping test.
I added a little bit of trace logging to see what part of the ping method was holding it up and it is clearly the call to the new Hubitat command in 2.2.7.x to submit the ping.
This also execution time also correlates with the Runtime stats for the device as well.
That seems to be about right, old method if I recall was 1-1.5 seconds longer for a positive test; negative tests run longer as it has to timeout between packet sends. New method gives you the option of sending 1-5 packets (default 3) vs. the old method which is always 5 packets; so you can only request 1 packet to speed up the result but you increase the risk of a false negative.
As I have dabbled with this I just wanted to post two things. First your comment about being careful about how low of a number to use is no joke. I created two devices with this driver and then setup RM to hit them every 5 seconds. Lets just say initially there was no problem, but eventually this brought my hub to it's knees. To the point that it was taking about a min to just load screen on the hub through UI. My guess is I got the hub into a race condition of some kind even though it looked like the ping processes were completing. Fortunately I was able to end the RM jobs and the hub did recover. I did a reboot for good measure. This exercise was intended to test a worst case scenario, If anything i am just reiterating your initial statement for folks to hear that setting the refresh value to low is no joke and will cause impact to Your HA environment.
I also noticed that the drivers value for Ping repeat doesn't appear to be working in my case. I don't see it schedule the next run. For my test I had to use RM to submit the send ping command on the device.
I'll take a look at that, I may have broken something adding the new method.
Edit: Found it, I have the reschedule event embedded in the response handler for the old method (i.e. not called in the new method) Should be able to get out a fix later tonight. Fix is available now.
@thebearmay - thanks for creating this! It's exactly what I'm looking for. Unfortunately, I can't seem to get it to work when using just an IP address... like: 1.1.1.1 or 8.8.8.8 or 9.9.9.9; it does work if I turn on the HTTP endpoint and enter a domain name though. Here's an error message I keep getting:
dev:13992021-06-21 02:26:49.029 pm errororg.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_thebearmay_Hubitat_Ping_1169.refresh() is applicable for argument types: () values: [] Possible solutions: every(), every(groovy.lang.Closure), grep() (refresh)
Current States
- avg : 0.0
- lastIpAddress : 1.1.1.1
- max : 0.0
- mdev : N/A
- min : 0.0
- percentLoss : 100
- pingReturn : PingData(rttAvg: 0.0, rttMin: 0.0, rttMax: 0.0, packetsTransmitted: 3, packetsReceived: 0, packetLoss: 100)
- pingStats : Transmitted: 3, Received: 0, %Lost: 100
- presence : not present
- responseReady : true
You’re the second person I’ve seen with a scheduled refresh in a driver that didn’t have that code. Please delete the device, do a repair from HPM and then recreate the device. That should get rid of the error.
2 Likes
I deleted the device and did a repair from HPM and the error is gone; however, I still can't ping with an IP address... but pinging a domain name does work.
Current States
- avg : 0.0
- lastIpAddress : 1.1.1.1
- max : 0.0
- mdev : N/A
- min : 0.0
- percentLoss : 100
- pingReturn : PingData(rttAvg: 0.0, rttMin: 0.0, rttMax: 0.0, packetsTransmitted: 3, packetsReceived: 0, packetLoss: 100)
- pingStats : Transmitted: 3, Received: 0, %Lost: 100
- presence : not present
- responseReady : true
Looks like it did 3 pings but didn’t get a response. Could be being blocked by your firewall; try pinging an address on your local LAN and see what you get.
I just tried pinging several addresses including the hub on my local LAN and same results.
