The image for 0.108.4 hasn’t been posted to Docker yet.
Yes add-on would be more correct a description than an integration (it’s past this swing shifter’s bed time, lol), and I would agree that the glitch may have been a random dependency getting corrupted during upgrade. This is further supported and obvious after doing another upgrade from 107.7 to 108.3, as the symptom didn’t reoccur… everything worked quite smoothly in fact this time around. Most likely a fluke… no matter how solid something might be, run it enough times and it’ll eventually fail at least once!
1 Like
Yep. Definitely broken. Rolled back to 0.107.7 and it works again.
Yep, Broadlink no longer working. Downgrade worked
I am seeing flic integration not loaded now, no error observed…
Read the whole thread. Yes broadlink is broken, yes there is a workaround, no you don’t have to downgrade.
Yes, I realize I can just ad it as a custom component, but looks like they already located the error, so hopefully the next release will have a fix.
I have one problem after upgrade: with recorder nad history. HA Core on Ubuntu server. HA can’t Intrall sqlalchemy:
‘’’
Log Details (ERROR)
Logger: homeassistant.util.package
Source: util/package.py:88
First occurred: 8:31:44 AM (2 occurrences)
Last logged: 8:34:21 AM
- Unable to install package sqlalchemy==1.3.15: ERROR: Command errored out with exit status 1: command: /usr/bin/python3 /usr/local/lib/python3.7/dist-packages/pip/_vendor/pep517/_in_process.py get_requires_for_build_wheel /tmp/tmp1oe4cehi cwd: /tmp/pip-install-xov87gxu/sqlalchemy Complete output (10 lines): Traceback (most recent call last): File “/usr/local/lib/python3.7/dist-packages/pip/_vendor/pep517/_in_process.py”, line 257, in main() File “/usr/local/lib/python3.7/dist-packages/pip/_vendor/pep517/_in_process.py”, line 240, in main json_out[‘return_val’] = hook(**hook_input[‘kwargs’]) File “/usr/local/lib/python3.7/dist-packages/pip/_vendor/pep517/_in_process.py”, line 85, in get_requires_for_build_wheel backend = _build_backend() File “/usr/local/lib/python3.7/dist-packages/pip/_vendor/pep517/_in_process.py”, line 76, in _build_backend obj = getattr(obj, path_part) AttributeError: module ‘setuptools.build_meta’ has no attribute ‘legacy’ ---------------------------------------- ERROR: Command errored out with exit status 1: /usr/bin/python3 /usr/local/lib/python3.7/dist-packages/pip/_vendor/pep517/_in_process.py get_requires_for_build_wheel /tmp/tmp1oe4cehi Check the logs for full command output.
- Unable to install package sqlalchemy==1.3.15: ERROR: Command errored out with exit status 1: command: /usr/bin/python3 /usr/local/lib/python3.7/dist-packages/pip/_vendor/pep517/_in_process.py get_requires_for_build_wheel /tmp/tmp65tj3liu cwd: /tmp/pip-install-_odk_tv4/sqlalchemy Complete output (10 lines): Traceback (most recent call last): File “/usr/local/lib/python3.7/dist-packages/pip/_vendor/pep517/_in_process.py”, line 257, in main() File “/usr/local/lib/python3.7/dist-packages/pip/_vendor/pep517/_in_process.py”, line 240, in main json_out[‘return_val’] = hook(**hook_input[‘kwargs’]) File “/usr/local/lib/python3.7/dist-packages/pip/_vendor/pep517/_in_process.py”, line 85, in get_requires_for_build_wheel backend = _build_backend() File “/usr/local/lib/python3.7/dist-packages/pip/_vendor/pep517/_in_process.py”, line 76, in _build_backend obj = getattr(obj, path_part) AttributeError: module ‘setuptools.build_meta’ has no attribute ‘legacy’ ---------------------------------------- ERROR: Command errored out with exit status 1: /usr/bin/python3 /usr/local/lib/python3.7/dist-packages/pip/_vendor/pep517/_in_process.py get_requires_for_build_wheel /tmp/tmp65tj3liu Check the logs for full command output.
‘’’
Any suggestion?
Just tried 108.4 and CPU utilization continues to increase slowly over time. Reverted back to 107.7 and CPU is stable again…
2 Likes
So does anyone know which components have started removing YAML configuration? I already have massive problems with the registry as I have multiple HASS instances to which I push the configuration using jinja2 templates from Ansible and discovery gives different devices different names across them. If the threat is going forward that there will be more of this I would be keen to fork the codebase and not merge PRs which regress on the configuration front, so I can keep the current level of functionality that I have. If it’s a manageable list to re-merge the YAML configuration functionality for, I’ll happily include modules I am not personally using.
List so far:
- Monoprice
- Ring
- UniFi
You do know there are a fair few repositories required for HA ecosystem. You will need to fork and maintain those
Why would it concern you? What part of forking the codebase to restore functionality I am using is offensive to you? I respect the goals of the project to make it available for the majority and I respect the work that the maintainers have done but I’ll be re-instating the YAML functionality where it affects me (and maybe where it doesn’t, if others find value) because I believe there is a power user base out there that doesn’t need deprecation to cascade into said fork as they are responsible for their own deployments and prefer the inclusive approach to the lowest common denominator approach.
That said, thanks for the feedback.
Did i say it offended me, i was merely pointing out what you would be taking on
This entire thread is full of posts attempting to tell people what they want. If your “reason” for preferring the original configuration standard that’s been in place for years now doesn’t stack up in the eyes of a few (such as backups or devops approaches) you’re told you don’t need it. It would be nice to have a small corner of this discussion where those of us who aren’t of the opinion that is true could discuss it without the holier than thou brigade, and if others agree then it is worth it, then I’ll do it.
It’s a major overstatement to suggest that this is a major undertaking. Regardless of how many disparate repos we are talking about here, it’s reverting a change to remove YAML parsing for a handful of modules, merging anything that doesn’t remove YAML parsing going forward and then making periodic fixes where YAML config parsing is impacted by those changes, for a small audience. Possibly of 1 at this point, but we’ll see. Anyone who would use this can feel free to drop me a message and I’ll gauge the worth of such a project from there.
I doubt it would extend to adding new YAML configuration interfaces for modules which don’t have one but let’s see, the more interest the more contributors, and the more contributors, the less effort amongst them. There might be others who simply want to revert the removal of some web scraping components because they’re useful and can be pretty easily updated if needed. In the whole scheme of the entire project maintaining some YAML parsing that was already there for the entire project previously across a handful of modules is no more effort than individuals contribute to HASS today in their free time, but this would be doing it in a parallel fork without the rigorous review for those who consider themselves advanced users who want a little more autonomy in configuration.
have you seen this: https://community.home-assistant.io/t/the-future-of-yaml ? For some background on the matter 
also https://github.com/home-assistant/architecture/tree/master/adr check 7 and 10
Yes, reading this is what has prompted this idea. At least one of my components has already removed YAML support and I have little doubt more will going forward.
Did you see what I proposed? Here is a part of the post you’ve referred me to:
In the beginning, Home Assistant was a small project; aimed at developers and the tech-savvy. With the growth of privacy concerns, but also the growth in the availability of IoT devices in our homes in general, the project gained traction; attracting lots of new community members that are not always the tech-savvy types.
As I have said, I respect the project’s direction however it deviates from my own state. I am tech savvy and I’m not interested in seeing functionality removed to make it easier for the non-tech savvy. I would prefer a version of the project that retains these hooks and mechanisms so I can keep using them. I would partner with others who feel the way I do to maintain a fork which simply does not remove features because they do not align with the non tech-savvy user base. It’s that simple.
Edit: Not looking to reply to any more discussion about this. Just interested in if others would use or contribute to such a “power-user” selective commit repo. You can PM me if you’re interested and I will share details, I won’t update this thread any further.
1 Like
yep, read what you wrote. No need to patronize.
Though I understand your suggestion, maintaining a separate fork would be an immense job. Not to mention make one lose all support … That might be a niche solution for some. It would push the worlds even further apart, iow no solution, but creating an even bigger problem. If there would be consensus on having a (1st world) problem in the first place.
I choose to have it grow on me and see what happens for now. As said, HA has never been better than is is in its current state.
Hello!! I recently purchased 2 Broadlink RM mini 3 and I am unable to integrate them with HA; I already have an RM pro model that works perfectly. Is there any effort to resolve this incompatibility? thankful
Hello and welcome. This is a post about the version 0.108 release. You would be better off by asking your question in a new topic.
You could achieve the same by just creating a custom component version where you bring back yaml. No need to fork everything.
1 Like