node-red-snmp - "RequestTimedOutError: Request timed out"

[triDcontrols]

Got node-red-snmp working, but on every 2-3 snmp writes, I get a "RequestTimedOutError: Request timed out" in the debug window. I have set the interval from 5 seconds to 5 minutes and same thing, the above error filling up the debug log. Is there a way to disable the debug output? or identify the root issue? I have tried setting version from 1 to v2c and changing the community name, bunch of combos, and still get the same error.

[triDcontrols]

My Flow.

[{"id":"d8012983.7137a8","type":"tab","label":"CyberPowerUPS SNMP","disabled":false,"info":""},{"id":"d9b1bb28.05aab8","type":"http request","z":"d8012983.7137a8","name":"","method":"GET","ret":"txt","url":"http://192.168.1.8:5002/pwrstat","tls":"","x":112,"y":268,"wires":[["d0bd94c7.477b98"]]},{"id":"d0bd94c7.477b98","type":"json","z":"d8012983.7137a8","name":"","pretty":false,"x":263,"y":272,"wires":[["d63d344b.fa9c18"]]},{"id":"fef2748d.59a768","type":"snmp set","z":"d8012983.7137a8","host":"192.168.1.250","community":"public","version":"2c","varbinds":"","name":"","x":842.5,"y":310,"wires":[]},{"id":"d63d344b.fa9c18","type":"function","z":"d8012983.7137a8","name":"Separate_JoinOID","func":"var batt_cap = msg.payload[\"Battery Capacity\"];\nvar firm = msg.payload[\"Firmware Number\"];\nvar lpe = msg.payload[\"Last Power Event\"];\nvar line_inter = msg.payload[\"Line Interaction\"];\nvar load = msg.payload.Load;\nvar model = msg.payload[\"Model Name\"];\nvar out_volt = msg.payload[\"Output Voltage\"];\nvar psw_by = msg.payload[\"Power Supply by\"];\nvar rated_pwr = msg.payload[\"Rating Power\"];\nvar rated_volt = msg.payload[\"Rating Voltage\"];\nvar rem_runtime = msg.payload[\"Remaining Runtime\"];\nvar state = msg.payload.State;\nvar test_result = msg.payload[\"Test Result\"];\nvar util_volt = msg.payload[\"Utility Voltage\"];\n\nmsg.varbinds = (\n[\n {\n \"host\": \"192.168.1.250\",\n \"version\": \"v2c\", \n \"oid\": \"1.3.6.1.4.1.4131.1.4.1.3.1\",\n \"type\": \"OctetString\",\n \"value\": batt_cap\n },\n { \n \"host\": \"192.168.1.250\",\n \"version\": \"v2c\",\n \"oid\": \"1.3.6.1.4.1.4131.1.4.1.3.2\",\n \"type\": \"OctetString\",\n \"value\": firm \n\t},\n\t{\n\t \"host\": \"192.168.1.250\",\n \"version\": \"v2c\",\n \"oid\": \"1.3.6.1.4.1.4131.1.4.1.3.3\",\n \"type\": \"OctetString\",\n \"value\": lpe\n },\n { \"oid\": \"1.3.6.1.4.1.4131.1.4.1.3.4\",\n \"type\": \"OctetString\",\n \"value\": line_inter\n\t},\n\t{\n\t\t\"host\": \"192.168.1.250\",\n \"version\": \"v2c\",\n \"oid\": \"1.3.6.1.4.1.4131.1.4.1.3.5\",\n \"type\": \"OctetString\",\n \"value\": load\n },\n { \n \"host\": \"192.168.1.250\",\n \"version\": \"v2c\",\n \"oid\": \"1.3.6.1.4.1.4131.1.4.1.3.6\",\n \"type\": \"OctetString\",\n \"value\": model \n\t},\n\t{\n\t \"host\": \"192.168.1.250\",\n \"version\": \"v2c\",\n \"oid\": \"1.3.6.1.4.1.4131.1.4.1.3.7\",\n \"type\": \"OctetString\",\n \"value\": out_volt\n },\n { \"host\": \"192.168.1.250\",\n \"version\": \"v2c\",\n \"oid\": \"1.3.6.1.4.1.4131.1.4.1.3.8\",\n \"type\": \"OctetString\",\n \"value\": psw_by\n\t},\n\t{\n\t \"host\": \"192.168.1.250\",\n \"version\": \"v2c\",\n \"oid\": \"1.3.6.1.4.1.4131.1.4.1.3.9\",\n \"type\": \"OctetString\",\n \"value\": rated_pwr\n },\n { \"host\": \"192.168.1.250\",\n \"version\": \"v2c\",\n \"oid\": \"1.3.6.1.4.1.4131.1.4.1.3.10\",\n \"type\": \"OctetString\",\n \"value\": rated_volt\n\t},\n\t{\n\t \"host\": \"192.168.1.250\",\n \"version\": \"v2c\",\n \"oid\": \"1.3.6.1.4.1.4131.1.4.1.3.11\",\n \"type\": \"OctetString\",\n \"value\": rem_runtime\n },\n { \n \"host\": \"192.168.1.250\",\n \"version\": \"v2c\",\n \"oid\": \"1.3.6.1.4.1.4131.1.4.1.3.12\",\n \"type\": \"OctetString\",\n \"value\": state\n\t},\n\t{\n\t \"host\": \"192.168.1.250\",\n \"version\": \"v2c\",\n \"oid\": \"1.3.6.1.4.1.4131.1.4.1.3.13\",\n \"type\": \"OctetString\",\n \"value\": test_result\n },\n { \n \"host\": \"192.168.1.250\",\n \"version\": \"v2c\",\n \"oid\": \"1.3.6.1.4.1.4131.1.4.1.3.14\",\n \"type\": \"OctetString\",\n \"value\": util_volt \n\t}\n]);\n\nreturn msg;\n\n\n","outputs":1,"noerr":0,"x":447.5,"y":282,"wires":[["fef2748d.59a768"]]},{"id":"91a4817f.68b56","type":"inject","z":"d8012983.7137a8","name":"","topic":"","payload":"true","payloadType":"bool","repeat":"1800","crontab":"","once":false,"x":88,"y":187,"wires":[["d9b1bb28.05aab8"]]},{"id":"e5f3c855.b57ca8","type":"function","z":"d8012983.7137a8","name":"TimeStamp","func":"var currentdate = new Date();\nvar currenthour = currentdate.getHours();\nvar currentmin = currentdate.getMinutes();\nvar currentsec = currentdate.getSeconds();\n\nmsg.varbinds = \n[\n {\n \"host\": \"192.168.1.250\",\n \"version\": \"v2c\",\n \"oid\": \"1.3.6.1.4.1.4131.1.4.1.3.15\",\n \"type\": \"OctetString\",\n \"value\": \"\"+currentdate+\"\"\n },\n\t{\n \"host\": \"192.168.1.250\",\n \"version\": \"v2c\",\t \n \"oid\": \"1.3.6.1.4.1.4131.1.4.1.3.16\",\n \"type\": \"OctetString\",\n \"value\": \"\"+currenthour+\"\"\n },\n\t{\n \"host\": \"192.168.1.250\",\n \"version\": \"v2c\",\n \"oid\": \"1.3.6.1.4.1.4131.1.4.1.3.17\",\n \"type\": \"OctetString\",\n \"value\": \"\"+currentmin+\"\"\n },\n\t{\n \"host\": \"192.168.1.250\",\n \"version\": \"v2c\",\n \"oid\": \"1.3.6.1.4.1.4131.1.4.1.3.18\",\n \"type\": \"OctetString\",\n \"value\": \"\"+currentsec+\"\"\n }\n];\n\t\nreturn msg;\n","outputs":1,"noerr":0,"x":473,"y":341,"wires":[["fef2748d.59a768"]]},{"id":"efcbc1a6.4add7","type":"inject","z":"d8012983.7137a8","name":"","topic":"","payload":"true","payloadType":"bool","repeat":"15","crontab":"","once":false,"x":228,"y":341,"wires":[["e5f3c855.b57ca8"]]},{"id":"8fadd92c.8545c8","type":"exec","z":"d8012983.7137a8","command":"sudo","addpay":false,"append":"python /home/mdimov/pwrpanelapi/pwrstat-api/pwrstat-api.py","useSpawn":"false","timer":"","oldrc":false,"name":"CyberPower UPS","x":378,"y":105,"wires":[["827bfd73.6738a"],["827bfd73.6738a"],["827bfd73.6738a"]]},{"id":"b01c12a9.5221e","type":"inject","z":"d8012983.7137a8","name":"","topic":"","payload":"true","payloadType":"bool","repeat":"","crontab":"","once":true,"x":152.5,"y":111,"wires":[["8fadd92c.8545c8"]]},{"id":"827bfd73.6738a","type":"debug","z":"d8012983.7137a8","name":"","active":false,"console":"false","complete":"true","x":586,"y":84,"wires":[]}]

[dceejay]

I have added a timeout option to the snmp nodes (default is 5 seconds). Pushed to npm as version 0.0.16

Please let us know if this help address the problem.

[triDcontrols]

thanks for the update, I upgraded and do see the timeout option, but when I edit the node, and set it to 10 seconds or anything else, the settings are not being commited, I can enter a value, but when I set it to done, the node config dialog exits, and the deploy button is not lit for changes, when I doubleclick on the snmp-set node the timeout option is empty and even with 5 seconds as you set it to default timeout error is triggered, granted not as often, but is triggered from time to time. I Also tried deleted snmp and reinstalling snmp node and same result.

[dceejay]

Apologies - one missing line, is the one you needed... now sorted and pushed as version 0.0.17

[DeanCording]

I'm having this problem now since the update the other day. Today's update hasn't fixed it. Even tried deleting the node and recreating it. The RequestTimeOutError occurs every 10-20 seconds, irrespective of what I set the timeout value to, and it happens even when the device has responded.

I've had a bit of a look at what is going on and not much is making sense. Sniffing the packets, I can see the request and the immediate response from the devices. However, I actually see the request being sent twice each time with different request ids, which is odd.

Even though the device is responding, the responses don't seem to be processed.

Looking at net-snmp, there has been a new version released recently and there has been an issued raised about it breaking things. Maybe you need to downgrade to version 1.1.19

[triDcontrols]

Thanks for the update, can confirm here, with 0.0.17 update, same issue. Changing the timeout does not affect the errors. continues to fill up the debug log. Tried also re-installing the node, no change.

[dceejay]

Then may I suggest that the other end is actually not responding correctly ?

[DeanCording]

Possible, but it has been working for over a year previously. I'll try reverting net-snmp to see if it fixes it.

[dceejay]

ok - thanks

[DeanCording]

Yep, downgrading to net-snmp@1.1.9 solves the problem, including the doubled up requests.

[dceejay]

ok - will pin it back - Thanks for debugging it ! pushed as 0.0.18

[triDcontrols]

yep, confirmed working on 0.0.18, Thanks @dceejay and @DeanCording