Another hass release, another set of breaking changes. NWS can no longer be configured by YAML. The project moved to NWS from Met.no because the same thing happened there.
The days of us being able to programatically interact with the hass configuration are gone.
The result for us is going to be a few things:
First-time setup is going to involve a lot more manual work. Adding new HASPs to an existing setup should continue to be easy, but getting the first one going is going to need a lot of clicking around in the UI.
Iām going to need to re-write deployhasp.sh and a lot of documentation. This is going to take some time.
New users trying to deploy their first HASP under 109+ are going to get configuration errors until I complete the new setup procedure
This is going to keep happening until the end of time because there is no roadmap or overt statement of direction that will allow us to avoid doing things that the hass development team will later break.
The core issue here is that the capability we were using for programmatic configuration of Home Assistant is systematically being dismantled with each new release. There are no plans to replace it with an API. We could go and hit the .storage/ files directly but have been advised against doing so, so if we do that we have then put everyone in the position where some future update breaks that too, but does so without publishing a ābreaking changeā notice because nobody was supposed to be touching those files.
The days of a declarative configuration of Home Assistant are over. What weāre left with is a manual process.
Home Assistant used to be targeted at developers, now theyāre targeting end-users, and I guess end users like to use a mouse. End users also like to pay $5/mo, and now Home Assistant has employees to pay, so I understand this new alignment away from technical users and towards end users simply because there are more of them and the project now has mouths to feed.
I anticipate we will see more and more of this sort of thing as time moves on. Home Assistant lives on volunteer code contributions but is run by a group that is looking for a paycheck.
Do any other icons work? Can you tell me the name of the specific glyph you are looking to use? I can try it on my side here and see if something is effed up.
I noticed that if I have certain font(s?) set that the icons wonāt show. Try changing your font to something different in the HA dashboard dropdown and then try again.
100% this - only the Noto Sans font has the FA icons. The Consolas font remains as-is for backward compatibility, and I didnāt see much point in adding icons to Webdings
Home Assistant Cloud subscription. Needed if you want remote access (with opening port on your router), Alexa and Google Home the easy way. Check https://www.nabucasa.com
No, totally free to use if you choose. You can pay to get easier voice assistant integration if you want. I also think kicking the core dev team a few bucks isnāt a bad idea.
The larger point is that the Home Assistant project is no longer run by volunteers, there are cash-flow commitments in place, and itās reasonable to expect that these commitments are going to shape decisions around the future of the project.
I donāt think itās unreasonable to frame existing decisions (like forcing all configuration to happen in the UI) in this light. Making hass more accessible to new users == more users == more potential for cash flow == more core devs working on a cool project.
Okay. But I still think they could accommodate both end users and developers. With the way things are going based on your description, it sounds like the direction it is going is to drive out 3rd party developers.
Iām only guessing as to the intent, but the direction is laid out here. GUI is the direction, YAML configuration will not be acceptable for most configuration tasks.
Personally, I donāt really care how the configuration is stored, so long as there is a means to interact with that configuration via code. This decision removes the ability to hit a yaml file to make changes and replaces it with a workflow that requires a user navigating a web browser. It doesnāt have to be like this, an API could be provided to accomplish those same tasks alongside the UI process, but the dev team doesnāt seem to think itās important.
As a result, we have to deal with the reality in front of us: Home Assistant is moving in a direction that doesnāt allow for automated configuration.
New users probably donāt want to deal with YAML, and one can safely assume that there are substantial financial motivations for attracting more new users. Iāll leave it to the reader to draw their own conclusions about those two facts.
That is what I was kind of getting at. New users want to use the GUI UI and that is great. YAML gave me a bit of a problem when I first started. But 3rd party supplies need to be able to install via an API or accessing files. By not supplying the API or other access, they are shutting out 3rd party products, or making it harder on the End User because now they have to do the work the product developer would have done via the API. Seems they are hurting themselves in the long run based on this direction.
There is a lightbulb ICON there now (is that webdings?)I just wanted to change it to Something else.
I get the feather ICON to work but was trying Water, is it a space issue?
here is where Iām changing it in the payload of mqtt publish
- alias: hasp_back_door_p10_FanLightOnIcon
trigger:
- platform: state
entity_id: "binary_sensor.back_door_connected"
to: "on"
- platform: homeassistant
event: start
- platform: state
entity_id: "switch.spa_spillover"
to: "on"
- platform: mqtt
topic: 'hasp/back_door/command/page'
payload: '10'
- platform: mqtt
topic: 'hasp/back_door/state/p[10].b[4]'
payload: 'OFF'
- platform: state
entity_id: input_number.hasp_back_door_selectedbackgroundcolor
- platform: state
entity_id: input_number.hasp_back_door_unselectedbackgroundcolor
- platform: state
entity_id: input_number.hasp_back_door_selectedforegroundcolor
- platform: state
entity_id: input_number.hasp_back_door_unselectedforegroundcolor
condition:
condition: and
conditions:
- condition: template
value_template: "{{ (states('input_number.hasp_back_door_activepage')|int) == 10 }}"
- condition: state
entity_id: "switch.spa_spillover"
state: "on"
action:
- service: mqtt.publish
data:
topic: "hasp/back_door/command/json"
payload: '["delay 1","xstr 5,15,50,65,8,65280,0,1,1,3,\"ļ³\""]'
I am the codeowner of the NWS integration. If you want to have a self contained weather interegration builtin to your setup that can be programmatically included in others setups, Iād recommend rolling your own custom component. That way you are not beholden to anyone elseās whims or perceived motives.
Custom components can be configured any way you like. You should be able to grab the prior version of NWS and make it a custom component drop in (you may or may not have to rename the integration and the domain, etcā¦). If you need help with this let me know.
That really is an interesting idea but then Iām faced with the challenge of becoming the maintainer of my copy of that component and Iām fully unfamiliar with Python.
Stillā¦ something to chew on, and also THANK YOU for your rad component
Definitely not an ideal situation. If you arenāt familiar with Python and home assistant backend, I probably wouldnāt recommend it. But it is the most flexible.
It is unfortunate that yaml support isnāt supported at all for configuration for integrations that gather data from services. I personally like the UI configuration better, but it limits really cool applications like this.
