New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SNMP Sensor #71368
Comments
snmp documentation |
I am also having this issue. |
Logger: homeassistant.components.sensor Setup of platform snmp is taking longer than 60 seconds. Startup will proceed without waiting any longer. |
Seeing the same issues here after upgrading to 2022.5, logs are flooded with the following, and not getting any SNMP data. It will work for a few polls after a restart but then fails. Running within a container setup. 2022-05-06 08:42:45 WARNING (MainThread) [homeassistant.components.sensor] Updating snmp sensor took longer than the scheduled update interval 0:00:10 Rolling back to 2022.4.x and it works instantly again. As an example of the YAML code, have tested with and without the scan_interval set, and confirmed same L2 network segment, no firewall in between, and obviously that it works after rolling back to 2022.4.x
|
Of course, the change was tested on Python 3.9 and 3.10 with sensors from my printer. I tested it again this morning and have no warnings. Add this to your logger:
default: warning
logs:
homeassistant.components.snmp: debug
pysnmp: debug |
Added those debug options and here is the full log after restarting, still 2022.5, will pull 2022.5.1 shortly.
This is my full SNMP config
|
Same thing under 2022.5.1, which makes sense as none of this was really changed. For reference the system it's running on is an Intel i7-12700, 64GB of RAM, and a NVMe SSD. |
I flipped debug on for everything and filtered for "snmp"
|
Assuming you used grep to filter, try adding Your log will be quite large with that additional context, so consider pastebin or trimming your log entries to just things that look interesting, rather than dozens of the same messages repeated. |
Nah just a simple snmp filter on the log output from portainer as I was remote, and mainly enabling debug on everything as above with the snmp component didn't really seem to show anything additional. Having a look with -C2 and full debug is still very very noisy given all the other devices (lots of MQTT, and UPNP being picked up on). |
Understood. I find it weird that there are no significant error messages - feels like maybe the debug log level isn't respected by pysnmp/pysnmplib given that there's no messages recorded from that source component. |
Yeah that's the same point I reached, it seemed weird that it didn't respect the debug, or didn't really give me much more that made sense. If anyone can come up with another way to pull more detailed logs of the SNMP component, happy to grab more info. |
Having given it 24 hours it does seem to be intermittent. Can't rule out something on the network side at the moment. Will keep monitoring. |
I just installed Core version 2022.5.2 and the problem is still present. |
Seeing this as well with Core 2022.5.2 |
Core 2022.5.2, these error logs are output at startup
|
SNMP also broken here in core 2022.5.2; nothing beyond this in logs even with debug set for pysnmp and snmp component.
Worked fine before, now doesn't. No config changes between versions. |
Just to see what would happen, I started removing SNMP sensors and it magically started working when I had only 8 SNMP sensors configured. Adding a 9th caused it to break again. So the magic number seems to be no more than 8 SNMP sensors. 9 sensors breaks it. |
Can you try removing all but 8 of your SNMP sensors and see if you get the same results I had? |
Might be a race condition rather than a (hard) limit, so dependant on what other integrations are installed and the performance of the hardware running HA, people's experiences may vary from that magic #8. Just something to keep in mind. I've been putting off upgrading to 2022.5.x until this got sorted but as I only have 2 SNMP sensors it now sounds like I'm unlikely to be affected. |
For me it seemed to be 10, once I went past 9 it seemed to get unhappy again and you'd see delays on startup. This aligns with what I was seeing earlier, that sometimes after restarting the container I'd be missing a random set of SNMP sensors, then another restart and it would be a different set that were missing. At least this gets my energy monitors back for now, the other data is nice to have, but still a regression over 2022.4.x |
I think I fixed the problem. Please test this as a custom component. If you're using |
Running your fix as a custom component fixed the Log flooding. |
I was testing the fix for 17 hours on about 30 sensors and everything seems to be OK. |
Hi, |
This fix definitely fixes the issues on my side. Nice work! |
Hi @AbeltjeNL , |
Wauw, that's awkward. Changed it, thanks! |
@bieniu, i was to optimistic:
|
How many SNMP sensors/switches do you have configured? |
Same problem here. I've a total of 53 snmp sensors (on 3 devices), running HA on a i3-6100T CPU @ 3.20GHz and no Brother integration. On 2022.4.7 it is all working fine, but with the 2022.5.x versions I get the same errors as mentioned above. |
Those who still have warnings with the custom component, can you check the
And uninstall old
I think this is only possible if you're using HA on core or supervised installation. |
@claymen Please reinstall
|
The fix worked for me :) |
Not sure this is going to work inside the container, throws a new set of errors. Am I right in thinking this is all related to simply being container based, as what I am doing isn't really what you should be doing to a container? |
I have 12 sensors and 5 switches handled with SNMP. They were extremely unreliable on 2022.5.x. Similar logs to what others posted. I installed the custom component and the problem has not reoccurred. RPi4 running HAOS 7.6. Thanks for the help resolving this issue, at least for a portion of us. |
My installation running in VB doesn't like al the above (uninstall, install, reinstall). Sorry, can't test what you are suggesting. |
Totally missed this. Throws some red lines but does seem to fix the issue on my test machine. Just updated my main instance to 2022.5.4 and ran this line. Will keep you posted with my findings this weekend 👍🏻 |
What kind of install are you using though? Are you using a container install, or the HassOS/Supervised install? |
OVA, VirtualBox. |
the problem still exists for me using the custom component. This is what it says in the logs:
|
No joy:
|
This means you're not using |
Correction - error returned after a couple of days of uptime |
@bieniu, is there something else we can test that can possibly fix this issue? :) |
Just wanted to add that if you want to run this inside the HASS docker container, you first need to install
|
This fixed the issue for me as well. Core 2022.5.4. |
2022.5.5 just released, which includes a revert to the PR that caused these issues. |
The problem
Hello,
with the Core 2022.5 version I'm having problems with sensors on the snmp platform.
Entities are not generated and I cannot view their status. With version 2022.4.7 everything works fine.
I state that I used the same configuration and same yaml
Below is an example of a sensor:
platform: snmp
name: "Port1"
host: 192.168.0.10
community: #######
baseoid: .1.3.6.1.2.1.2.2.1.8.1
accept_errors: true
default_value: 2
platform: snmp
name: "Port2"
host: 192.168.0.10
community: #######
baseoid: .1.3.6.1.2.1.2.2.1.8.2
accept_errors: true
default_value: 2
platform: snmp
name: "Port3"
host: 192.168.0.10
community: #######
baseoid: .1.3.6.1.2.1.2.2.1.8.3
accept_errors: true
default_value: 2
What version of Home Assistant Core has the issue?
2022.5.0
What was the last working version of Home Assistant Core?
2022.4.7
What type of installation are you running?
Home Assistant OS
Integration causing the issue
No response
Link to integration documentation on our website
No response
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: