Try this
4 Likes
Magic 
2 Likes
I wish I was graphing the Home Assistant DB size over time so I could say for sure if it got worse with the FW update but the following day HA alerted me to the disk being full and when I went in and looked at the DB, my Blues were pumping in roughly 2.5MB/min each of state updates and filled up the disk.
I’ve since excluded most of the related entities in the recorder settings but even just the standard light and energy sensor entities are spamming orders of magnitude more state updates than anything else I have.
Using Z2M
Anyone else experience this with recent firmware?
2 Likes
Can you post proof (logs)? I’m not doubting you but posting proof would help them figure out what’s wrong.
I haven’t noticed any issues here with 18 Blue’s installed but I use Postgres as a db engine rather than the sqlite version.
Also, you can exclude entities from being recorded to the db via the exclude parameter which may help if you aren’t interested in long term stats of particular items: Recorder - Home Assistant
I expect I’ll be gently guided to ask this question over at the HA forums, but what the hell…
Is there any way to restrict the HA (zha) automatic firmware updates to only run during certain hours?
I’m out of town this week and just got an earful from my wife asking why our bedroom switch was flashing bright green and woke her up sometime last night.
Any advice?
Currently, no. Your best bet would be to go into your configuration.yaml and then set “inovelli_provider: false” while you don’t want it running automatically.
I know there’s work being done to overhaul the way it works, but there isn’t any kind of timeline to expect new behaviors with it yet unfortunately.
I had problems with my database size too. It grew to over 25 GB in a mater of days. I went and disabled 67 entities and hid 34 for each switch. I also, went into the recorder and excluded pretty much all of the entities from it.
Each switch has over 100 entities. Inside of each entities attributes each a duplicate of 75 other entities. One of those entities is the current power. So every time the power usage changes, which can happen very often, then all the entities update.
I think the attributes should be removed from all the entities except for maybe the main light entity.
1 Like
That’s exactly my story, even the 25GB part. I’ve disabled a ton of stuff in the recorder exclusions since to slow the bleed.
As far as logs, I just used this SQLite query to sort by biggest offender and it’s all the Inovelli stuff crushing everything else.
SELECT
COUNT(*) AS cnt,
COUNT(*) * 100 / (SELECT COUNT(*) FROM states) AS cnt_pct,
SUM(LENGTH(attributes)) AS bytes,
SUM(LENGTH(attributes)) * 100 / (SELECT SUM(LENGTH(attributes)) FROM states) AS bytes_pct,
entity_id
FROM states
GROUP BY entity_id
ORDER BY cnt DESC
Here is a sample of the DB size growth where you can see where I’ve excluded most entities from the recorder. I’ve left just the main light and power sensor entities and they are what is causing the continued growth. I only have 2 of them so far but want to get more 
Definitely agree on the notion of deduping all those attributes.
I just created a new topic. I didn’t realize this thread existed. I put data in the thread I created.
What is the mapping for the new LED notifications? What number correlates to which notification animation?
- Added LED notifications: “falling”, “rising”, “aurora single”, and others. (2.02)
The new notifications are not listed in the Blue Series manual.
1=Solid, 2=Fast Blink, 3=Slow Blink, 4=Pulse, 5=Chase, 6=Open/Close, 7=Small-to-Big, 8=Aurora, 9=Slow Falling, 10=Medium Falling, 11=Fast Falling, 12=Slow Rising, 13=Medium Rising, 14=Fast Rising, 15=Medium Blink, 16=Slow Chase, 17=Fast Chase, 18=Fast Siren, 19=Slow Siren, 0=LEDs off, 255=Clear Notification"
3 Likes
Also currently for individual LED notifications -
0- Off
1- Solid
2- Fast Blink
3- Slow Blink
4- Pulse
5- Chase
6- Falling
7- Rising
8- Aurora
255- Clear
2 Likes
Also note the distinction between an “Off” notification and the “Clear” notification:
‘Off’ is an actual ‘effect’ to force the LED off when it might otherwise be on. It’s still considered to be an active notification. If it has a duration, the LED will turn off for the duration and then turn back on. IF it has an indefinite duration then that LED stays off until the notification is cleared
‘Clear’ is not an ‘effect’ but rather, it is the action to stop the notification. Typically this is used to stop (clear) a notification that was set with indefinte duration
9 Likes
Has anyone had any problems in Z2M where the update doesn’t show for some 2-in-1 dimmers? I was able to update 3 of my dimmers to 2.08, but one dimmer only updated to 2.07 and another didn’t find an update and is stuck at 2.00
3 Likes
Maybe it’s already updated? There is a z2m bug where it may not show the correct firmware version on the ota page.
Here is a workaround:
1 Like
Thanks for that pointer, looks like it was the same bug and the workaround fixed it for me.
1 Like
Hoping for some help from the friendly community. Smarthings user here who recently purchased a Sonoff Zigbee dongle to update firmware on my Blues. Ventured into HA (what a learning curve…) for the first time and managed to get a blue switch paired and controlable through the zigbee stick on HA running on a virtual machine.
I am not clear on steps to update firmware though. I added code to the configuration.yaml following these intructions: Zigbee Home Automation - Home Assistant , and saved the latest Inovelli OTA file in it’s own folder on the HA. Am I missing something? Are there any easy to follow instructions for someone new to HA… thanks in advance.
Once you have added the update code to your config yaml file and you have restarted HA you simply wait for the update to happen. In my experience it starts very quickly within a few minutes of connecting the new switch.
You might not even notice it updating unless you’re watching the LED on the strip. Occasionally I have had one update and I only knew because the firmware version changed on the device page.
