Closed mikesalz closed 10 months ago
That looks like your omnologic controller failed to respond in time to the request to pull the configuration data, are you by chance on a slightly flaky wireless connection or something?
That is a good question. I don't THINK I am on a weak wireless connection. I have an Orbi Mesh system. The Omnilogic unit is pretty far away from the main house, but I have a satellite nearby and I seem to have a strong connection when I go out there and test it. I supposed it is intermittently bad, and I'm just not catching that when I test it. I restarted the router and each satellite, but I am still getting that error repeatedly. Any other thoughts?
Can you enable debug logging for the integration, replicate the issue, and then upload those logs?
Attaching here. home-assistant_2023-06-23T17-45-37.373Z.log
Unfortunately, it looks like it's just a matter of the Omni not responding to the requests. I can see in the logs that the integration is sending a request to get the MSP config, then not receiving back an "ACK" packet as expected, so it re-sends the request for the MSP config 4 additional times, still not receiving the "ACK" packet, and finally gives up.
I would recommend looking into the antenna placement for the wireless connection on your controller. There isn't much I can do if I send a request, get no response, and re-attempt multiple times and still receive no response.
One thing you may want to try is power cycling your Omni controller, I have seen them get into a somewhat "laggy" state where they occasionally just don't like to respond, and a power cycle can fix that, but chances are, this is just a bad wifi connection (probably on the Omni controller end) based on the logs that I'm seeing.
I just power cycled. Thanks for the suggestion. If that doesn't help, I'll try to run an ethernet cable to it. That'll be fun.
Is there any chance that pinging every 5 seconds could be mucking up the controller?
According to the logs that you uploaded, it appears to be polling every 10 seconds. I wouldn't try and push it any faster if you are already having issues.
For what it's worth, it does appear that it works fine most of the time, but there's a spot in the logs where it fails to update three times in a row, and then another shortly later where it failed to update about 10 or 12 times in a row... And then it goes right back to working fine again
OK, I thought the default was 5 seconds. I wasn't suggesting to make it poll more often, so I'll leave it at 10.
It is still happening after my power cycle. And seems to be happening more frequently now. I don't get it. I do think it is on the Omnilogic side rather than the router. I have other devices in HA that I know are connected to that satellite and none of them are getting timeout issues. I guess I need to pick up a really long ethernet cable. In the meantime, do you know of an easy way to disable that particular message so it stops blowing up my logs?
Unfortunately no, it's correctly logging that it was unable to run the polling cycle. As far as I know, the only way to inform home assistant that the polling cycle failed is to raise an exception.
You could also look into the Wi-Fi antenna placement on the Omni controller and see if it could be relocated to somewhere that gives it a better signal. Especially if the antenna is located inside the Omni case, or on the other side of the case from the Wi-Fi access point, that case can really attenuate the signal quite a bit.
There is a separate update failed exception that I can raise, that might quiet the logs a little bit... I'll look into it
@mikesalz I just released 0.5.3 that catches that OmniTimeoutException and re-raises as an UpdateFailed, which should hopefully stop some of the log destruction, can you test that out and let me know?
Thanks! I'll try it right now.
@mikesalz any improvement on the log noise?
I guess I'm not entirely sure what to expect with the recent change. This one is a little different, but I'm still getting it a bunch of times. Hopefully all of this goes away when my new long ethernet cable arrives Sunday!
Logger: custom_components.omnilogic_local.coordinator Source: helpers/update_coordinator.py:229 Integration: OmniLogic Local (documentation, issues) First occurred: 3:15:49 PM (31 occurrences) Last logged: 8:08:36 PM
Error fetching OmniLogic data: Error communicating with Omni controller
The goal with the recent change is just to not have your logs full of gigantic stack traces
OK, got it. So I'm still getting just as many errors in the log; they are just less verbose. I appreciate your help!
@cryptk what MSP firmware version are you using? Ever since upgrading from 3.2.2 to 4.8.1 I get a lot of dropped packets when pinging my omnilogic controller, e.g.
64 bytes from 192.168.1.228: icmp_seq=54 ttl=64 time=3.824 ms
64 bytes from 192.168.1.228: icmp_seq=55 ttl=64 time=3.863 ms
64 bytes from 192.168.1.228: icmp_seq=56 ttl=64 time=19.724 ms
64 bytes from 192.168.1.228: icmp_seq=57 ttl=64 time=4.117 ms
64 bytes from 192.168.1.228: icmp_seq=58 ttl=64 time=4.051 ms
64 bytes from 192.168.1.228: icmp_seq=59 ttl=64 time=3.886 ms
Request timeout for icmp_seq 62
Request timeout for icmp_seq 63
Request timeout for icmp_seq 64
Request timeout for icmp_seq 65
Request timeout for icmp_seq 66
Request timeout for icmp_seq 67
64 bytes from 192.168.1.228: icmp_seq=68 ttl=64 time=7.031 ms
64 bytes from 192.168.1.228: icmp_seq=69 ttl=64 time=3.729 ms
64 bytes from 192.168.1.228: icmp_seq=70 ttl=64 time=4.466 ms
64 bytes from 192.168.1.228: icmp_seq=71 ttl=64 time=15.330 ms
64 bytes from 192.168.1.228: icmp_seq=72 ttl=64 time=27.200 ms
64 bytes from 192.168.1.228: icmp_seq=73 ttl=64 time=3.848 ms
64 bytes from 192.168.1.228: icmp_seq=74 ttl=64 time=409.549 ms
Request timeout for icmp_seq 75
64 bytes from 192.168.1.228: icmp_seq=75 ttl=64 time=1016.496 ms
Request timeout for icmp_seq 77
64 bytes from 192.168.1.228: icmp_seq=77 ttl=64 time=1158.683 ms
Request timeout for icmp_seq 79
Request timeout for icmp_seq 80
64 bytes from 192.168.1.228: icmp_seq=79 ttl=64 time=2035.183 ms
64 bytes from 192.168.1.228: icmp_seq=80 ttl=64 time=1034.179 ms
Request timeout for icmp_seq 83
Request timeout for icmp_seq 84
64 bytes from 192.168.1.228: icmp_seq=81 ttl=64 time=4027.471 ms
64 bytes from 192.168.1.228: icmp_seq=82 ttl=64 time=3028.658 ms
64 bytes from 192.168.1.228: icmp_seq=84 ttl=64 time=3112.413 ms
64 bytes from 192.168.1.228: icmp_seq=85 ttl=64 time=2106.394 ms
64 bytes from 192.168.1.228: icmp_seq=86 ttl=64 time=1102.971 ms
64 bytes from 192.168.1.228: icmp_seq=87 ttl=64 time=98.555 ms
64 bytes from 192.168.1.228: icmp_seq=88 ttl=64 time=4.384 ms
64 bytes from 192.168.1.228: icmp_seq=90 ttl=64 time=5.074 ms
64 bytes from 192.168.1.228: icmp_seq=91 ttl=64 time=5.188 ms
64 bytes from 192.168.1.228: icmp_seq=92 ttl=64 time=44.822 ms
64 bytes from 192.168.1.228: icmp_seq=94 ttl=64 time=4.717 ms
64 bytes from 192.168.1.228: icmp_seq=95 ttl=64 time=6.355 ms
Request timeout for icmp_seq 97
I'm on a WiFi connection as well. I thought the signal would be very strong but upon further inspection it's not as good as I thought:
I'll try with an ethernet cable later.
Actually, simply moving the remote as close as I could to the AP was sufficient to resolve this. Zero dropped packets and sub 5ms ping. I anticipate ethernet will work even better.
@mmun I run mine hardwired, the wifi connections to Omni devices seems to be flakey at best
I think this can be closed as it was caused by a bad WiFi connection rather than by the integration
I installed the new local integration last night. Version 0.5.0. It seems to be working very well. But I noticed this in my logs. Just wanted to share it in case it is something that you can address. Please let me know if I can help test any changes. Thanks!