At most it can be an add-on to Home Assistant (formerly known as Hass.io) but it’s not an integration. In fact, I run Node_Red on a separate machine from Home Assistant.
To be clear, I’m not questioning your observation that 0.108.3 appears to be negatively affecting your Node-Red flow. I’m just clarifying that the difficulties you are experiencing with the alexa-remote2 node are just a symptom of a (as yet unidentified) underlying problem in Home Assistant 0.108.3. If you are running Node-Red as an add-on then that arrangement is slightly ‘less independent’ and perhaps that’s where the glitch was accidentally introduced.
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!
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?
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.
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.
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.
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.
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
