I have secrets used in multiple yaml files (in my packages directory).
I was hoping that my Zemismart Blinds Motor [M515EGBZTN] would work in ZHA in this release. Whereas prior to 2021.14 there were no controls (even though pairing would occur), now the controls appear but don’t seem to do anything. I’ve upgraded to 14.1 and that made no difference.
Below is the ZHA signature if that’s of assistance.
{
"node_descriptor": "NodeDescriptor(byte1=2, byte2=64, mac_capability_flags=128, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=0, *allocate_address=True, *complex_descriptor_available=False, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False, *is_valid=True, *logical_type=<LogicalType.EndDevice: 2>, *user_descriptor_available=False)",
"endpoints": {
"1": {
"profile_id": 260,
"device_type": "0x0202",
"in_clusters": [
"0x0000",
"0x0004",
"0x0005",
"0x0102",
"0xef00"
],
"out_clusters": [
"0x000a",
"0x0019"
]
}
},
"manufacturer": "_TZE200_xuzcvlku",
"model": "TS0601",
"class": "zhaquirks.tuya.ts0601.TuyaMoesCover0601"
}
I’ve been holding out for this release for it to work. It’s a little frustrating. Am I missing something? Do I need to do something to get this working?
Part of the issue is how HA is setup to work OOTB - default recorder collecting everything, large DB file very quickly.
It’s been a while since I looked at the setup docs that cover the database, but being that this is an ongoing issue that is constantly posted about, perhaps a “recommended” setup for the recorder as part of the installation instructions might be a good idea?
I get everyone has a different use case, and you’ll want to give me caveats around telling people what they should or shouldn’t have data for, but I think it is something that is long overdue to be addressed.
8 Likes
Not much that I need, but since the MariaDB database lives on my NAS (HA in proxmox on NUC), I haven’t given much thought to fine-tuning the recorder yaml besides removing the obvious. It was 40GB once.
Mine finished overnight, took about 6h to complete. I would imagine many casual users that don’t read forums and release notes, and have large DB because they didn’t even know about recorder yaml, will be quite unhappy by this experience.
After the .4.1 release confirmed speedtest is working again for me 
1 Like
Good Morning everyone!
Anyone else having issues with ESPHome?
I can start it, but when I open the configuration screen it seems to crash and I have to restart it
[07:18:19] INFO: Installing esphome version 'dev' (https://github.com/esphome/esphome/archive/dev.zip)...
Collecting https://github.com/esphome/esphome/archive/dev.zip
Downloading https://github.com/esphome/esphome/archive/dev.zip (2.0MB)
esphome requires Python '>=3.7,<4.0' but the running Python is 3.6.9
[07:18:21] FATAL: Failed installing esphome pinned version.
[cont-init.d] 30-esphome.sh: exited 1.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] 99-message.sh: executing...
-----------------------------------------------------------
Oops! Something went wrong.
We are so sorry, but something went terribly wrong when
starting or running this add-on.
Be sure to check the log above, line by line, for hints.
-----------------------------------------------------------
[cont-finish.d] 99-message.sh: exited 0.
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
Hint is here
esphome requires Python ‘>=3.7,<4.0’ but the running Python is 3.6.9
and from the esphome git changes that were merged into dev yesterday
Raise minimum python version to 3.7 (#1673) · esphome/esphome@d92c8cc (github.com)
As @cgarwood stated, set_config_parameter is used specifically for the Configuration CC. It’s a separate service because it is more flexible (you can pass labels instead of strictly numbers) and can provide better validation since it’s scope is limited. set_value allows you to set the value of any CC value, so it covers a superset of what set_config_parameter does but it does very little validation so you have to know more about what you’re doing to get the desired outcome
1 Like
Thanks @DavidFW1960, I did not thought about this… However before trying to do something with DB it got fixed with 2021.4.1… Everything is snappy again. Somehow I suspect issues speedtest integration that it indirectly influenced other parts of the system.
Now only ESXi Stats that I need to bring back to life… Tried even server restart, but no change. Yet I’ll try to reinstall integration.
Thank for confirming. I was able to fix it on my core installation.
Where if not here do I report about the bug?
ps
reported it in GitHub.
Well, not fully true… I did set up my recorder to exclude everything, include only these entities that I use anywhere in Lovelace for displaying history graphs to limit amount of stored data.I keep 14 days of history. Issue is that we cannot differentiate between entities that we want to display 15 minutes of history (bandwidth consumption on network devices) vs. ones, that require full 14 days (weather historical data or home access data).
Moving to other solutions, like Influx would obviously solve this, but it worth to add complexity? Correct me if I’m wrong, but it is not fully transparent to HA to store specific data in secondary DB and then use this historical data inside Lovelace. You need to configure each and every entity to be stored outside and use Grafana to display results… it won’t work with standard HA charts (like ApexCharts). Am I wrong?
3 Likes
I had to make my own quirk, if you go to the quirks GitHub page and post an issue, someone might be able to help
Looking at the PR, your model is added but shown as untested. The signature is slightly different to yours:
I’d raise an issue here:
I tried all this but the error is the same. I don’t even use Philips Hue. I can not remove the ZHA integration either. The switch attached to the zigbee bridge is an important part of the PAF (and KAF).
any thoughts?
Database migration took 6 hours.
How about adding a console output: Migrating database.. please wait....
I was 2 sec away from pulling the plug - assuming it had stalled. The CPU load of the container remained at zero for a long time, giving the impression that nothing was going on. And there was no console activity either. I use an external SQL DB, and I guess most of the DB maintenance was done using stored procedures, and that’s why the core was mostly idle… ?
1 Like
yeah, apparently some users saw something like this in the log:
2021-04-07 15:29:15 WARNING (Recorder) [homeassistant.components.recorder.migration] Database is about to upgrade. Schema version: 12
2021-04-07 15:29:15 WARNING (Recorder) [homeassistant.components.recorder.migration] Modifying columns time_fired, created in table events. Note: this can take several minutes on large databases and slow computers. Please be patient!
2021-04-07 15:29:53 WARNING (Recorder) [homeassistant.components.recorder.migration] Modifying columns last_changed, last_updated, created in table states. Note: this can take several minutes on large databases and slow computers. Please be patient!
but even with the lower logger level, I didn’t see anything happening either. (using the beta’s). A better console warning should be secured.
Yes, I have the same just after updating to core-2021.4.1
[09:17:10] INFO: Installing esphome version 'dev' (https://github.com/esphome/esphome/archive/dev.zip)...
Collecting https://github.com/esphome/esphome/archive/dev.zip
Downloading https://github.com/esphome/esphome/archive/dev.zip (2.0MB)
esphome requires Python '>=3.7,<4.0' but the running Python is 3.6.9
[09:17:12] FATAL: Failed installing esphome pinned version.
[cont-init.d] 30-esphome.sh: exited 1.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] 99-message.sh: executing...
-----------------------------------------------------------
Oops! Something went wrong.
We are so sorry, but something went terribly wrong when
starting or running this add-on.
Be sure to check the log above, line by line, for hints.
-----------------------------------------------------------
[cont-finish.d] 99-message.sh: exited 0.
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
Seems this 2021.4.0 (and it’s beta’s) is causing some oddity with the presence tracking in my system, and it probably has to do with life360. At random times, 3 of my family members (who don’t live at home anymore) are spotted at home… Which of course is a nuisance. Not because I dont like them at home, but because several automations start doing their job. 
In the logbook, they are quite immediately after that marked not_home again, or, being in another zone if they are, but then the damage has already been done.
Has anyone else seen this changed behavior (on Life360)?
Is this a conscious choice or was it just not part of the initial release? It could add a lot of insights to popular custom integrations which could be added to core eventually.
3 Likes
Me too, so switched to stable version for now and that works fine, just don’t edit and upload any devices with the dev firmware loaded with the “older” version if you are using any features from the dev version