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
Hi Thanks @ochlocracy for adding Camera support to Alexa! I just got this working on my FireTV Stick
As I understand from this, the video stream does not go up somewhere to the cloud and back, but stays local; Something like camera->HA->routerās hairpin->AlexaDevice. Correct?
Iām using Haaska in my setup. However Iām not using port 443, as Iāve configured Haaska to use another port. Iāve found that camera support for Alexa works fine using this other port, although I had to change the HA Alexa entity.py code to get around the 443 check. Would it be possible for you to remove the 443 check in a future release?
Logger: homeassistant.core
Source: components/mystrom/switch.py:60
First occurred: 15. April 2020, 21:28:28 (1 occurrences)
Last logged: 15. April 2020, 21:28:28
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 295, in async_add_entities
await asyncio.gather(*tasks)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 447, in _async_add_entity
await entity.async_update_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 284, in async_update_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 320, in _async_write_ha_state
state = self.state
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 612, in state
return STATE_ON if self.is_on else STATE_OFF
File "/usr/src/homeassistant/homeassistant/components/mystrom/switch.py", line 60, in is_on
return bool(self.data["relay"])
KeyError: 'relay'
Quite relieved to see this sorry. It was driving me crazy, i have RM Pro 3+ and 50% of my devices have stopped working. My RF curtains Arent working but RF lights and all IR stuff is still working. I then recalled that this started happening after the upgrade and finding that other have had same problem was a relief as i started looking at other ways of controlling my curtains. I have a feeling its because of way codes are being encoded or parsed (not an expert here) which is why some are failing and some arent.
What did others do to fix this can you share please? just a roll back? any help/instructions will help.
UPDATE: saw one fellow giving instruction to roll back. appreicated.
I saw no log entry for broadlink even with debug level thats why i gave up. I dot know of any way to dig deeper. But i am planinng to downgrade now, after i test release 108.5. Some of my RF stuff is working and most isnt.
sorry. It was driving me crazy, i have RM Pro 3+ and 50% of my devices have stopped working. My RF curtains Arent working but RF lights and all IR stuff is still working. I then recalled that this started happening after the upgrade and finding that other have had same problem was a relief as i started looking at other ways of controlling my curtains. I have a feeling its because of way codes are being encoded or parsed (not an expert here) which is why some are failing and some arent.