Ok Rob, thanks. One thing I noticed and will explore further; the reaction times of my LIFX lights gets noticeably longer the closer I get to that 7th day I referred to, when they no longer react. I am wondering if logging a whole bunch of those UDP warning messages somehow bogs down the system. I am going to start clearing the log files to see if that keeps me from having to do a soft reset every seven days. I’ll let you know what it looks like after a few weeks. Thanks again for your time!
I have done soft resets and I recognize now that this does not clear PAST LOGS. "Clear" only clears the current live logging view. I will try to PAUSE and see if that makes any changes to my issue.
Plenty! But concentrating on one device, I noticed all of the warnings on this device occurred with a time stamp that had 32 seconds as a common theme.
Each of the warning messages has a specific time in seconds. This color bulb log shows a few warnings through today and when it occurred, 18 seconds was the common time.
My bulbs have indeed been extremely sluggish today. I wasn't getting this flood a couple days ago. I'll keep watching it over the next few days to see what happens.
I've been fooling around all day today with Hubitat and RM4.0, so everything's gone through a lot of changes. I did however reboot my router at 11:24pm, right after the last UDP error occurred here, and I haven't gotten a single new one since.
I should also mention that the reason I rebooted my router was because I upgraded the firmware. I also went in and gave all my LIFX bulbs highest bandwidth priority in the router settings in an effort to help 'em out - don't know if that'll make any difference.
I updated. Imported the code for each. Did not delete anything and did not press "clear caches". Rebooted Hub and checked the logs - flooded with the same message, "Error occured with UDP message: SocketTimeoutException: Receive timed out".
That is definitely the poll() method which runs every minute, I would always expect that to run at the same second of the minute (+/- 1) unless the hub is really busy.
Running the 2.1.3.128 Hubitat firmware,
I downloaded the latest of your LifxMaster.
I just rebooted my Netgear WNDR3700v3 with firmware V1.0.0.42_1.0.33
Didn't occur to me to reboot the router. Thanks for that idea, Kilowatts! I set the device that I showed in the first set of logs to the HIGHEST QoS priority.
So we'll let that run for a while and then look at the log later today.
More hints to the problem here:
I did the reboot of the Netgear router and I reexamined the HE log to hone in on the devices throwing the most warnings (two Z-strip devices, Coffee light, Stove light). I prioritized them to the highest QoS on my router.
Then I went back to one of my Rule Machine 3.0 triggered rules and realized I called those two Z-strips to turn RED in the event of a break-in. Then I remembered, Rob, that the Z-strips can only be turned on and off, no colors. I edited that triggered rule accordingly.
Been running the log a couple hours now and have substantially reduced (but not eliminated) the warnings on the system in general. I'll evaluate in a few more hours.
Next step?:I thought about saving this set-up, then doing another HE soft reset, add just one Lifx light to HE, add just one contact device (Pantry door), add just one lighting rule (Turn on overhead light when pantry door contact opens) and then let HE run and log for a while. See what happens. I've got time...
Thanks for that Darrall - as I just posted in my earlier message, there are 3 device types that send more than one message when polling, It's possible that I'm not waiting long enough between those, I guess that may cause a problem since you're supposed to wait around 50ms before sending a new packet to a given address.
I probably won't be able to work on this until Tuesday though.
Correctamundo, they're strips. However, all of the rest (a19, d&d) throw the errors eventually as well - looks like most happened in the wee hours overnight.
I was wondering whether there was a time dependency on this, although I would have thought that it would be more likely to be when the WiFi was being used heavily. It doesn't coincide with the hub's backup time (around 3AM) by any chance does it?
