Iām mainly suggesting that perhaps there are HE optimisations that could be made under the hood so that events donāt get missed when cpu loads hit certain levels. That could be via changes to process prioritisation for critical HE services (eg radios and core OS) or some other strategy.
I wish I wasnāt being vague, but HE is a black box to us, and we donāt know what we donāt know. All I know is that I can create the circumstances that lead to my C8 Pro being unreliable - I think that there are likely ways to increase reliability without throwing more hardware at the āproblemā.
Yeah, but there is zero evidence that this happens, let alone that cpu loads have anything to do with it. Your post is pure speculation, wrong speculation at that.
I was pretty up front that I donāt have the data to prove the underlying cause behind my observations. I donāt care if Iām right or wrong.
Can you please be constructive rather than simply insult me?
You have the engineering tools, I donāt. I would be willing to give Hubitat access to my hub and setup the conditions Iāve described for you to get the data and find the actual root cause.
Nice. Just post anyway, right? Your initial post is just wrong.
Why would we put energy into this? On the strength of what evidence? I'm sorry, but this post/thread doesn't pass any test of raising a real issue, only anecdotal stories that you can't or won't back up. Not chasing your ghosts without more than you've provided.
Wow Bruce, way to treat a loyal customer who just wanted to discuss his observations and gain a better understanding of HE.
I didnāt make any demands and made it very clear I lacked information. But instead of being constructive and offering some information to educate me, you insult me instead. I didnāt even tag you in the thread, but you pop in anyway with your hostile attitude.
No, not at all, Iām a professional IT Problem Manager amongst other roles. Solving problems requires one to put their ego aside and not be afraid to ask the āstupid questionsā or pose theories that are āwrongā.
Iāve lost count of the number of difficult problems my teams have solved over the years by myself and others posing āhereās what I think is happening, am I wrong?ā type questions and ppl digging through the data to confirm or deny the veracity of the theory has ultimately found the root cause.
There is a certain arrogance to your post. You admit that you know nothing about the hub internals, but nevertheless inform us what should be done to address the problem you describe. You won't provide any details about these problems, just the answer, inclusive of your diagnosis of cause and effect. I've called out the nonsense this represents -- if you find that insulting, I'm sorry.
Bruce, I was very clear I didnāt have knowledge of the inner workings.
If I were intending to be arrogant, I would not use phrases like āI proposeā and I would not admit upfront my lack of knowledge. Instead I would make demands, I tried very hard not to do this as Iām very aware of what I donāt know.
I was hoping that Hubitat staff would share some knowledge and engage in a constructive discussion as other community members have done. Frankly itās quite disappointing that this has not been the case.
OK, but when the information is not what you want to hear, you reject it. There is no link between cpu load and possibly 'missed' z-wave motion inactive events. The premise you put forth is wrong, as I stated in my first post above. Have you considered that the fact you removed Maker API and saw no change in CPU behavior might counter your assumption your experience has something to do with CPU load? Maker API is extremely light weight, so it's not surprising to me that removing it has no visible impact on CPU load.
What information? All I got from you was my theory is nonsense. As previously stated, I have no objection to being wrong, but educate me as to why Iām wrong instead of dismissing me outright. No one can learn from their mistakes without being provided the information they lacked when making the error.
I'll admit my ārecommendationā was a touch presumptuous, but I donāt know the HE architecture and figured a discussion around CPU process prioritisation would be at the very least, interesting (and it mainly has been).
Your entire thesis is that CPU load is the reason for your problem, and you rejected my relatively well informed understanding of the situation out of hand, continuing to beat on the horse of cpu load. Maybe you're right, and everything you've seen is entirely explained by cpu load.
What can I say? You posted this as a seemingly 'to be taken seriously' statement about a need for 'Hubitat crew' to address how the quad core cpu is utilized, complete with your recommendations. That's what I responded to, that, no, cpu optimization is not a relevant consideration for the problem you described, and that cpu load is not related to that problem. Had you posted this asking for information about how the cpu's are utilized, or what might have been going on with the situation you described, you would have gotten a different response, including possibly a discussion about how cpus are utilized and what role, if any, they might play in missing events. Instead, you plowed directly into telling us what to do.
The hub already has this design, and has had from its inception.
Your statements donāt explain anything, In fact you conflated speculation from others with mine. I never said there was an issue with the Maker API, only that I used to reproduce the issue. If you actually read my comments above your first post youāll see I said I doubted there was an issue in the Maker API.
Iām open to valid criticism, but throwing about terms like red herring and ridiculous isnāt constructive.
How about telling us how HE operates? I know it isnāt open source, and thatās fine, but educating us on how HE prioritises different tasks is surely not going to give away trade secrets.
The reason I couldnāt provide data is because I couldnāt find anything in the logs. I would see the motion detected light on the sensor turn on, but the automation never saw the event trigger and thus didnāt turn on the light - this happened randomly for about a week.
Following standard problem solving 101, I backed out the last major change I made, which was pulling the plug on HA and moving it to my second hub where I should have put it in the first place.
I wasnāt able to spot any other patterns, aside from the several motion sensors randomly not triggering their automatons - Itās very obvious when lights donāt turn on in dark rooms.
Absent active troubleshooting of this issue, there is no way to know what caused it. It would have been nice to know this while troubleshooting was still possible. Now, after the fact, it's pointless to pursue it or speculate about causes.
Iām more than happy to setup the conditions again and let you know if it reoccurs. I probably didnāt have enough logging turned on which Iām happy to revisit.
