Am I missing something or we can no longer configure Onvif via yaml ? This breaks our whole cicd promotion pipeline. We better wait for a fix before updating prods environnements.
I believe the fix for the hue tap devices (and potentially others mistakenly cleaned up by the device clearup routine) is in the 0.110.2 fix. I’m awaiting that to be released to confirm.
Picture entity cards no longer seem to be reporting their correct height and end up in one long column.
Possibly something to do with the time it takes to load the picture as a subsequent revisit to the view displays the cards correctly.
The /community_plugin/ bit in the resource folder isn’t working for my custom header and auto-entities installs. I had to point to the local www folder directory direction (https://xxxx.duckdns.org/local/community/lovelace-auto-entities/auto-entities.js
It is not community_plugin anymore. The endpoint is hacsfiles not community_plugin now (and for some time)
I don’t use this integration, but the docs of the intrgration say nothing about YAML configuration, so I’d assume you are now only able to configure through the GUI.
If this is true, YAML config will not come back, as you can read in this blogpost, the future for integration config is UI based and YAML is slowly removed. The devs promised that automations, etc. will stay in YAML, but to be honest, after all the decisions they took recently, I don’t believe anything they say anymore.
6 Likes
First release I had to back out of, due to breaking changes on missing icons.
Little cuts and little lies!
1 Like
Never did see this before: Home Assistant made a booboo and left a core dump…
And it keeps appearing after the av/* stuff I already replied on earlier. I truly never ever did see this happen with HA!
2020-05-24 12:05:31 ERROR (SyncWorker_8) [root] Uncaught exception
Traceback (most recent call last):
File "av/container/output.pyx", line 22, in av.container.output.close_output
File "av/container/core.pyx", line 267, in av.container.core.Container.err_check
File "av/error.pyx", line 328, in av.error.err_check
File "av/container/pyio.pyx", line 39, in av.container.pyio.pyio_write_gil
TypeError: 'NoneType' object is not callable
tail: /etc/homeassistant/home-assistant.log: file truncated
And throw in a little censorship…
2 Likes
If this is true, YAML config will not come back
I thought they would have postponed this kind of silly decisions… Time to leave or time to fork.
1 Like
Same issue here.
Has anyone filed an issue already?
I’m a little embarassed to say that having said (on numerous occasions) that I will not be moving forward with new releases here I have in fact done so and (surprise, surprise) I found that (for my config) this release is proving to be (by far) the best release I have moved to since leaving 0.94.2.
I approached this upgrade from a totally different direction than my usual method. Initially I was just interested to see what a new install from scratch was like really and I had no intention of moving my config across. So, I set this up as a brand new docker with a blank /config folder. After the onboarding I switched the new container to a different port so it could run along with my production system (running 0.107.7) on the same network.
# Configure a default setup of Home Assistant (frontend, api, etc)
default_config:
http:
server_port: 8125
# Text to speech
tts:
- platform: google_translate
lovelace:
mode: yaml
arch x86_64 dev false docker true hassio false installation_type Home Assistant Core on Docker os_name Linux os_version 4.2.8 python_version 3.7.7 timezone Australia/Brisbane version 0.110.1 virtualenv false
Once I was satisfied how well it was running I installed a couple of the minor built-in UI installed integrations and let it run for a few days. It ended up running so well I edited the config.yaml to enable lovelace and added my full (unedited) ui-lovelace.yaml and checked how that went.
No problems with all the views except no entities were available due to the config being unpopulated with my config at that time.
So…with my interest pricked I just added my complete config (and a few other required folders)…restarted my container and with great surprise I found literally everything worked with minimal errors and warnings in the log.
The only errors pertained to the one and only ‘custom_component’ I run and that is the safepay Fronius Component.
These errors have existed since 0.107.7 and pertain to not generating unique ID’s.
## Log Details (ERROR)
Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:436
Integration: Sensor ([documentation](https://www.home-assistant.io/integrations/sensor), [issues](https://github.com/home-assistant/home-assistant/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+sensor%22))
First occurred: 7:15:11 PM (9 occurrences)
Last logged: 7:15:11 PM
* Entity id already exists - ignoring: sensor.fronius_ac_current. Platform fronius_inverter does not generate unique IDs
* Entity id already exists - ignoring: sensor.fronius_ac_voltage. Platform fronius_inverter does not generate unique IDs
* Entity id already exists - ignoring: sensor.fronius_ac_frequency. Platform fronius_inverter does not generate unique IDs
* Entity id already exists - ignoring: sensor.fronius_dc_current. Platform fronius_inverter does not generate unique IDs
* Entity id already exists - ignoring: sensor.fronius_dc_voltage. Platform fronius_inverter does not generate unique IDs
So its now been about 5 days and I can not fault how this release is running so ‘hats off’ to all who had anything to do with it really.
I would like to ask the developers to please consider halting the removal of YAML as for me the total removal of YAML functionality would be a dealbreaker to me moving further forward with new releases.
Failing that I would ask you to consider ensuring that Nabu Casa remains 100% compatible with ALL releases back to say 0.90.xx as it seems clear to me that a great many users are still running installations at least back to there. No doubt many of those may also be using Nabu Casa as well?
If at all possible could the quality and quantity of communication between developers and the wider user base be improved significantly as right now it is at an unsustainably low level IMHO.
If you must continue to remove YAML functionality I personally will stop on whatever release suits my purposes best. In fact I am right now working on finding the best place to dig in.
That is of course UNLESS you remove Nabu Casa backwards compatibility as at that point I will totally abandon this project.
Thanks for listening!
3 Likes
I do not think so. Its a fairly new fan. On the Tuya integration page it says it supports fan.
It’s a very simple fix. Just rename ClimateDevice to ClimateEntity and it will work. Had to do this with a few of my custom components.
how to change,
where is ClimateDevice?
i cant even figureout.
please guide
thanks
Same issue here. Was just about to open an issue right now, but it seems like 0.110.2 fixes it. (It’s working normally now.)
If it is your component, then just search your Python code for references to ClimateDevice, and rename it to ClimateEntity.
If it is in a component that someone else has written, and you can’t wait for the fix from the component author, then you can do the following workaround:
- Copy the code for the component from GitHub
- Create a custom_components directory in your config directory (if it isn’t already there)
- In the custom_components directory, create a directory whose name is the name of your component. So if your component is called foo, create a foo directory.
- Copy the code you downloaded from GitHub into this directory.
- Search all the files for ClimateDevice, and rename to ClimateEntity
- Restart HA
I think that should do it.
They postponed the decision to deprecate the supervisor install on a generic linux system. It has been stated multiple times that YAML will not be removed and as you can see from this release and some other topics in this forum, this is not true. If you ask me, they are slowly killing YAML completely, that’s why I (and some other regulars here on the forum as well as far as I can see) are reducing/stopping their help here on the forum.
I’ll almost certainly continue using HA, because it is such an amazing software, that is unmatched by any competitor in my opinion, and a big thanks to anyone that ever contributed to this project. But I’ll definitely not provide help to users posting screenshots of their automations that don’t work and then tell them “click on the red circle in the screen here and then …”, no thanks!
1 Like
Do you know this problem? I have this on all my battery entities.
Thanks to you
Détails du journal ( WARNING )
Logger: homeassistant.helpers.condition
Source: helpers/condition.py:222
First occurred: 18:40:38 (1 occurrences)
Last logged: 18:40:38
Value cannot be processed as a number: <state sensor.sonnette_battery=88; attribution=Data provided by Ring.com, unit_of_measurement=%, friendly_name=Sonnette Battery, icon=mdi:battery-90, device_class=battery @ 2020-05-24T18:40:38.060712+02:00> (Offending entity: battery)