Yeah, I know, lots of people still prefer YAML, and I really tried to keep support for it. I even took the time to add a reload service. Maybe I can just do away with the id option, or turn it into a unique ID for use in the entity registry instead. I’m trying not to break things, but it’s getting harder to do so. I haven’t decided either way yet.
1 Like
Meh…
if it’s easier just pull the band-aid off now and be done with it. It’s the way of the HA future anyway.
Ok, I think I’ve come up with a workable compromise. I’ll continue YAML support, and it will work the same as it did before (i.e., same options having the same effects.)
But, for UI based config flow I won’t prompt for an object ID. Rather, it will create the object IDs automatically. E.g., if “Mr Phil” is entered as the name, that will become the name of the config entry, and it will become the name of the device_tracker entity. The name of the speed sensor will be the name + “speed” (translated.) So, in this example, “Mr Phil speed”. The tracker entity ID would be device_tracker.mr_phil, and for the speed sensor it would be sensor.mr_phil_speed (again, the speed part translated.)
If you want different entity IDs, they can be changed via the entities’ settings.
If you want to change the names, you can rename the config entry (via the three-dot menu.) The names of the two entities will be updated accordingly, but the entity IDs will not change. Or you can override the names via the entities’ settings, in which case the config entry name will no longer have any effect on the entities.
3 Likes
I prefer yaml as many users.
More control.
Hope you will find a good compromise.
Actually, in this case, there isn’t anything you can do via YAML that you can’t do via the UI.
Yep, I did, and I explained it above.
I’m very close to releasing a beta. All the code changes are done, and seem to work fine. I just need to update the docs accordingly.
There is in fact - Package management.
Disable everything related to device xyz - including a corr. Composite device.
Or move whole package to another setup.
moving to another setup would be considered a very very niche, rarely used requirement .
for me, once you’re used to using these UI configs, there’s no going back. it’s all so very easy and hassle free when done well.
and temporarily disabling for testing is a 1 click option, even easier than using a package which requires file access.
Really glad you are modernizing this integration Phil, it has been awesome since day 1, and now will get even better.
Sure hope it will take out the silly “more than 10 second” warning we get now (we discussed that elsewhere).
the only thing I would like to say here now is, that one should not specifically need to designate an entity which will be used.
I say that because I use pictures not set in any of these entities, but special ones, indicating to me it is from another integration.
Since we can not set entity pictures via the UI, I need to do so via customize.
would be nice if we could forgo that too in the new version?
Wrong in a case when your “package” for some task/device/whatever contains 10 integrations.
yep, I admit sometimes a packages is very handy indeed. Personally I am weary of moving my automations from yaml to the UI for that reason. (and the commenting)
but it’s the way forward, so I guess we should adapt.
in this case, the UI is making our lives easier, so no issue in adapting.
and you’ve probably got to admit, that changing those 10 integrations is not a day to day business. at least I would hope so.
Making easier for inexperienced people should not cause problems for experienced.
Very same may be said in general: “silly” people should educate themselves up to “smart” people, but it tends to become “smart people have to walk down to be understood”.
No gonna discuss it here.
please dont, as you’re bloating a non-discussion. Phil has stated he will keep the yaml, there is no issue at all in your case, just keep doing what you do now.
No I am not. And using expressions like “bloating” tells smth about you since these words should no be used.
I just expressed my appreciation that Phil is trying his best with maintaining yaml-config.
where was that?
My expression was said here in this thread many times verbally & by likes.
You managed to start a flood, congratulations, enjoy yourself)
That’s organization, not functionality. I was talking about functionality.
But this is really a moot point since I decided not to remove the existing YAML support. In fact, I’ve even added reload support.
Open an issue requesting this feature. I’ll consider it after I get the 3.0.0b0 release out.
This is very useful.
Some people moved from yaml to UI for some integrations also because of a possibility to reload in UI (which is absent in yaml).
sure, see FR: add option to set entity_picture in UI · Issue #56 · pnbruckner/ha-composite-tracker · GitHub
thanks for considering
went straight to 3.0.0b1 and HA wont startup anymore…
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "/usr/src/homeassistant/homeassistant/__main__.py", line 221, in <module>
sys.exit(main())
^^^^^^
File "/usr/src/homeassistant/homeassistant/__main__.py", line 209, in main
exit_code = runner.run(runtime_conf)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/runner.py", line 188, in run
return loop.run_until_complete(setup_and_run_hass(runtime_config))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/asyncio/base_events.py", line 653, in run_until_complete
return future.result()
^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/runner.py", line 154, in setup_and_run_hass
hass = await bootstrap.async_setup_hass(runtime_config)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/bootstrap.py", line 147, in async_setup_hass
config_dict = await conf_util.async_hass_config_yaml(hass)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/config.py", line 501, in async_hass_config_yaml
await merge_packages_config(hass, config, core_config.get(CONF_PACKAGES, {}))
File "/usr/src/homeassistant/homeassistant/config.py", line 1078, in merge_packages_config
merge_list = _identify_config_schema(component) == "list"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/config.py", line 976, in _identify_config_schema
default_value = module.CONFIG_SCHEMA({module.DOMAIN: key.default()})[
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/voluptuous/schema_builder.py", line 272, in __call__
return self._compiled([], data)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/voluptuous/schema_builder.py", line 595, in validate_dict
return base_validate(path, iteritems(data), out)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/voluptuous/schema_builder.py", line 433, in validate_mapping
raise er.MultipleInvalid(errors)
voluptuous.error.MultipleInvalid: length of value must be at least 1 for dictionary value @ data['composite']['trackers']