I am using Ecowitt Integration (Gateway and RF Sensor Drivers) I guess, this is latest version:
driver v1.34.6
which was installed fresh through HPM.
Before migrating to the C8 the Ecowitt Integration was running on C7 for more than a year without any problems (I think). After migrating to C8 I started to use two hubs (C8 and C7) with Hum Mesh enabled. I moved all LAN-based integrations to the C7 and exposed all Devices to the C8 via Hub Mesh. C8 immediately started to report Elevated (or even Severe) HUB Load pointing to one pf my RM Rule which is using many parameters from Ecowitt Sensors.
Here is a RM Rule in question:
The original rule had a Trigger for every (7 of them) value changed. @kahn-hubitat pointed me to change multiple trigger to a single trigger "lastUpdate" since all Ecowitt Sensor's attributes will change all at once when "lastUpdate" event is changed.
Plus he recommended to delay evaluating Attributes for change to let them be updated.
This make perfect sense. Somehow I missed this point.
This change reduced but did not eliminate Elevated Hub Load warnings.
And here are my few questions:
When "lastUpdate" change actually happens:
before Attribute's updated started or after update is complete?
I am asking this question to figure out if delay is required in a first place and if "yes" what is
a reasonable value for this delay?
I enabled a Debug login for the Ecowitt Gateway Driver.
All what I am getting every 2min (Gateway Reporting Interval is 2min) is this:
However all values from WS90 Multi sensor are updating correctly.
If I change Ecowitt Gateway reporting interval to 1min C8 immediately reports
"Severe Hub Load". I am surprised why this is happening and why 1min reporting interval
becomes a disaster for the C8 load?
C7 (this is where driver is running) is absolutely happy with any Gateway Reporting interval.
I have found the sweet spot (for my system) is having the Ecowitt report every 90 seconds and adjust the "Too many events alert" threshold on the Device page for the RF sensor to 450. You can see the actual resources being used in the other logs - the "too many events alert" is strictly based off that number that is entered on device page - if you aren't seeing any performance degradation with your devices or in the other logs showing actual resource consumption - I don't believe you have anything to worry about.
I didn't thoroughly read your post - you are running it on a C-8. I have mine on a C-7. I was getting the alerts before adjusting the Ecowitt's send interval and the alert threshold.
C7 was running flawlessly without complaining anything.
Now Ecowitt Integration is still hosted on C7 and there is no problems with C7.
However now all my rules are running on C8 and unfortunately C8 is not happy with many my rules reporting Elevated or even Severe load. All these rules are very old.
I do not believe all problems i am seeing related to the C8 hardware (but who knows).
To my eyes something is not quite right with the latest platform updates.
Running stand-alone on the C-7 mine would always generate those warnings if I had the Ecowitt sending every 60 seconds and did not modify the warning threshold. If you are carrying the same entries across the mesh to the C-8, it makes sense it might throw the same error. Have you looked at actual resource consumption?
Right now the refresh interval is 120sec.
C& is happy (running actual drivers).
C8 is still complains but C8 runs only RM Rules.
BTW, C8 is not happy with many other rules as well. But this one is first in line.
And I am really surprised to see 1min refresh interval immediately create
near a disaster condition on C8.
At this time I cannot say anything what is the reason for this phenomena and
how stable C7 could be with this latest platform updates.
Unfortunately there are too many changes in my setup in order to come up
with reasonable conclusion(s).
The lastUpdate is the last attribute that is updated as part of parsing the data feed from the EcoWitt Gateway. An appropriate delay is a hard one to advise on, it probably depends on the performance of your hub and other factors. You may just have to "play with it" to see what gives you the outcome you are after.
I would suggest looking at the Device and Apps stats, if you haven't already. Aside from the severe load warning from the hub, are there any other details that you have looked at? This may help identify where to spend time working out what is happening.
It's hard to know for sure why the 1 minute interval would be such a problem. I would turn logging on in the rule to see how often it is being triggered and how long it takes to run. If you can do without it for a period of time, you could try and reconstruct the rule, to try and see what part may be causing issues and if the issue is actually the rule.
As an alternative to your current trigger for the rule, given it is a fixed timing for updates coming through from the EcoWitt Gateway, you could setup a simple time-based schedule for your rule, e.g. every two minutes, simply reading the sensor values at the time the rule runs. I would expect the difference in readings across a 2-4 minutes timeframe would not be significant.
Those debug logs look fine, just some tidy-up I should do in the driver to more elegantly cover the various data points coming through.
If the "lastUpdate" attribute is an indicator for the end of parsing I don't need any delays at all.
So, if rule trigger is a "lastUpdate" change by this time all sensor's attributes already updated
to the new reported values. Is this correct?
This is a place where I was looking for the problematic app.
I am very confused how do I interpret a presented/logged values and which one is actual
indicator for the Elevated/Severe Load warning. The same rules ran without any problems
(I think) on the C7 before I migrated to C8. Unfortunately C8 is not happy with many of my
old rules. I think this is something to do with 2.3.5,xyz platform versions.
There is a 100% correlation between how often Gateway send a data with hub
complaining a Elevated/Severe Load warning. I am surprised to see this correlation.
There is effectively a periodic trigger but based on time reporting interval from the Gateway.
The rule in question is very simple. All what it does - is updating hub attributes with
sensors attributes and send all this data to the Display Controller.
It cannot be simpler.
Seeing this rule creating a load problem is a BIG surprise for my eyes.
I expect it should work, my only suspicion for why @kahn-hubitat may have suggested the delay would be in case there was any delay in the changes to other attributes actually being saved. I don't know for sure if that would be a possibility... So I think it would be a safe enough starting point to just look for a change in the lastUpdate.
I can't claim to be an expert on these stats.... You may want to click on the elevated load warning when it comes up, as I believe that gives an indication of the device(s) / app(s) that triggered the warning. To @Eric.C.Miller 's point, have you looked at the alert threshold for the EcoWitt Gateway?
I was getting these with zero indications of actual severe load on the hub. This is just a warning based on a device generating a certain number of events (this was when it was set at the default of 300).
But I have no idea how this sensor may generate that many events if gateway reporting
interval is 1 or 2 min.
@sburke781 Do you have an idea what is this about?
Right now the Ecowitt Integration is hosted on C7 but the RM Rule is on C8.
And the above log is from C8.
Also I am not sure if this is orrelated with Elevated Load warnings.
I feel like some of this may be a red herring... Or at least a secondary cause of your load issues. Not to say it isn't worth discussing at some point, but from your more general topic about hub performance, with other symptoms like general slowness in the GUI and other rules having issues, I suspect something more fundamental like the Network Settings Robert mentioned may be contributing more to your issues.
In terms of the "spammy devices", that is likely a result of the number of attributes and the relatively frequent updates. I'm not sure what the timeframe is that the number of Events are measured in, but if it was an hour that would certainly make sense. Don't forget that an update to a single attribute is an Event. So if 10-15 attributes are updated in each data feed from the EcoWitt Gateway, then you will have 10-15 Events every 1 or 2 minutes.
I think it's totally a red herring. While the number of events processed is likely correct, the load on hub is negligible (at least in the case of my hub it is).
Air Quality and Multi sensors have 20+ attributes. All others no more than 7.
All together this will be far less than 300 events.
I have no idea what is a timeframe was when hub reported over 300 events.
