Hi @thebearmay
Just updated my spare hub and have the latest version of your driver.
Should the cpu5min reading give this many decimal points.
- cpu5Min : 57.99999999999999
Hi @thebearmay
Just updated my spare hub and have the latest version of your driver.
Should the cpu5min reading give this many decimal points.
Only for you LOL. I should be able to round that off fairly easy.
Edit: v1.8.2 - rounds CPU to max of 2 decimals
I hope the value isn’t really 57, that would be extremely high.. unless the driver is multiplying by 100 to represent a percentage?
Unless something has changed the value returned is a Linux load average and not a percentage. Unless the hub is under extreme load, it should always be under 4.
It would have come from the hub as a 5 minute average of 0.579999999... I multiplied it by 100 to report it as a percentage
I guess that is the question... Is the variable from the hub fractional % or LOAD?
If LOAD, you can't multiply by 100...
I assumed it was LOAD (so 0-4=normal, 4+ is overload), but didn't ask.
Easy enough to fix if load...
I’m pretty sure it’s load, the value matches the cpu5min url, which is load (or at least that’s how it was originally described).
Is not doing much?
Eh, subjective. That's a higher load than all 5 of my hubs have.
But yes - that is a good, low loading overall.
If you do a repair, I’ve reverted the code to Load
Can you run round the house flicking switches for 5 minutes to see if you can get it higher!
If 0-4 is normal 0.5 is bottom of normal?
Edit, yea soz for banter
Edit @JasonJoel so what is a theoretical max? Could it be converted to a percentage for layman's?
I've gotten my dev hubs up to 6 before. That is a BAD thing though.
EDIT: Sorry @thebearmay I'll quit posting off topic crap on your thread.. lol
LOL, no worries I enjoy the banter...
Not really / kind of. For load you get 1 for each core. So 4 would = 100%-ish (if the scheduler is doing a perfect job). BUT the process queue can go higher than what can be executed, which is why LOAD can go >4. Numbers >4 just mean not all processes can run when they want and are getting slowed down/have to wait.
A much more correct explanation than my butchered version:
This is the best paragraph, in my opinion though:
The figure I quoted was just after an update to the latest 2.2.6 fix.
The hub is a C3 that isn't actually doing anything.
0.12 with no one moving around
I'm looking at 0.08 or about 2% with some light activity - mainly 3-4 motion and a couple of dimmers and doors.
Just spotted this
Last time I saw that error I was using the Beta of 1.8.0; just pushed 1.8.3 about an hour ago, can you pull it down and see if that makes this go away?