Here is the thing. I believe, you believe there is nothing going on. You probably have good reason to believe so. But something is happening that is causing load.
My talk about polling is simply that any type of repetative scheduled activity can cause impact if it happens frequently enough. I am just trying to zero in on anything that has even the slightest chance of causing a issue. Sometimes thing we shouldn't have a impact can unexpectedly.
Maker API is one of those things that it is very easy to create issues using. I have brought my dev hub to it's knees multiple times with very simple tasks i didn't think would be impactful.
Maker API has a option to post events to a external system. In this case it would be your Teensy that would be that external system. In the screen shot below it is the field for "URL to Post Device Events to". By populating that with your Teensy you can post events to it for activities.
Reguardless of how good the code is on HE it will need to be restarted occasionally. It runs in a JVM and those just tend to need to be restarted occasionall for memory reasons and such. If it has been up for months then it may not be bad to restart it.
I went through all the devices, and found that they all had an event history of either 11 or 20, and a state history of 30. I set both of those on all devices to 5. So I wasn't storing a lot to begin with, but as you very correctly point out, that's just not something I need a lot of for normal operation. If I really cared (which I don't ) I'd just turn on the debug flag for the device or app on the Teensy, and keep it all logged there.
Also is the problem still occuring. Can you help provide clairity as to what is the issue. Is it heavy load, or those messages that were logged, or something else?
Missed that - thanks for the heads up. Updating the Z-Wave radio now.
So far I haven't seen it since the reboot. As for what the issue is, you know about as much as I do. Something broke in the Z-Wave stack during an event from the thermostat, that caused all events generated by Z-Wave devices to generate an exception, and the event was then lost. Thus the reason that the lights stopped working.
Again as I repeat, I can't see this being heavy load, not when you see how lightly loaded the HE is, as shown by the App and Device lists shown upthread.
It is very likely the Zwave firmware update and the hub firmware update probably got this in a much better state. There were some very big things that have come since the version you were on.
I think what through me off was terming it as a performance issue. In most cases that means someone is calling out getting heavy load warning and such and that was kind of the verbiage from the log errors.
One last housekeeping step you could do to make sure it is as good of a state as it can be would be to shut down the hub from the menu and then pull the power from the wall and leave it unplugged for about a min. This just ensures that the Zwave radio fully restarts. It doesn't restart with a simple hub reboot unfortunately. This is probably a dot your i's and cross your t's step, but probably not bad to do with what you have delt with.
Did not see this mentioned anywhere so I will put this out there.
For the near future I would monitor app / device stats at Logs > Device Stats / App Stats
Turn on all the checkboxes.
Sort by Total ms high to low (should be default sorting).
Look at the % of total
Most apps / devices will be below 1.0, anything above 1.0 I would take a deeper look at.
Also, sort by Hub Actions
High Hub Actions can be an indication of problems stirring, but not always. For some apps/devices it is normal.
) I'd just turn on the debug flag for the device or app on the Teensy, and keep it all logged there.
