Same here…
Ah nice find. That makes more sense. I was making an assumption based on previous work.
I can confirm…no more yeelight on 0.116.1
1 Like
Neither do I, I’d have to google what that means.
Used this guide previously, worked well for me.
Interesting is, that netatmo stopped working for me at 3.00 am and I made the update to 116.1 at 8.00 am
the fix isn’t in 116.1, There are plenty of responses above that explain how to skirt around the issue until the fix is deployed. 2 posts up from this explain that.
I know, but it‘s strange, that netatmo works with 0.116.0 at first and than stopped working this morning, 5 hours BEFORE I updated to 0.116.1
A few sensors working previously and defined by groups.yaml are now appearing as “unknown”. Anyone else running into this?
verify a duplicate group with the same name + _2 wasn’t created
it would show up in your developer tools -> states page as group.blah_2, not whatever that screenshot is.
Sorry, should have elaborated, already confirmed that there is no duplicate in both Entities or in States. Each sensor that feeds into the group is a template sensor, extracting information from Z-Wave devices, i.e. Door/Window and Smoke sensors.
are they all binary_sensors? If the answer is no, then you’ll need to change them to binary sensors. Technically, sensors don’t resolve a state on groups. You can make an automation to update the group after startup if you don’t want to move them from the sensor domain to binary sensor. But seeing that they are all on/off sensors, they probably should be in the binary_sensor domain. It worked in the past (a fluke) because the startup procedure was slower.
Just take a look at the group state calculation docs, you’ll notice that sensor is not listed as something that will update the state of a group.
1 Like
Is that based on documentation somewhere or an educated guess?
Before System Metrics was released, I think if you were to ask a user what is the meaning of the System Monitor integration’s processor_use they would say “Surely it’s the percentage of the CPU’s total capacity.” (Good guess but we now know it’s incorrect.)
In supervisor -> system, you see the metrics that docker reports from the respective containers.
“System Monitor integration” can only report from inside the core container.
None of these will show total host usage, for that you need something like glances
1 Like
I’m getting a weird inconsistency between the barchart and the values I’m getting inside core today, I’m sure they were in sync before, but today my barchart is showing the cpu usage around double the system monitor, and the ram use around half of the system monitor.
I don’t know if this means anything to anyone 
That’s somewhat expected.
The calls that are being used to get the metrics are somewhat “expensive”, and it will some times show a slight inflated value.
I think a ‘slight’ variation I probably wouldn’t have noticed, but currently my system monitor is reporting 4% cpu and 33% ram, but the bar charts are showing 10% cpu and 12% ram.
I’m not ‘worried’ about it, just thought that the gap was a bit too big between the numbers for it to be easily explained so I thought I’d mention it.