Hi @Sourcer63
one possible way to get the device_id is by creating an automation via the UI and select the desired device (LCN module) in the trigger or action part. Then click on the three dots and switch to yaml-mode. There you will find the corresponding device_id.
Unfortunately I will have to remove the address parameter as the core developers prefer the device_id for addressing HA devices.
I hope that they will implement an easier way to obtain the device_id.
Or you have to create your automations only via the UI. Then you never will be bothered with the device_id.
It will work with the PCK action because only the command part and not the address part needs to be provided.
I had the idea to provide an action to convert the LCN address to the device_id but that was rejected, too.
The problem is that the PCHK host coupler (and therefore the integration instance itself) cannot be uniquely identified. There is no name, serial number, etc. provided by the hardware. Only an IP address but that‘s not really an option.
Internally HA uses something like an iteration id (config_entry id) but that‘s even harder to obtain for the user because it’s only shown in the debug logs.
Luckily I still had a (quite complex) HA device list that I exported as csv. In there I can search for the module number and then copy the device number.
So I started to modify the automations accordingly. I also wanted have a comment to link the automation to the respective LCN module number. But HA deletes the comment! That means that once assigned, you have no idea which module is addressed by the automation.
I have a lot of respect for the core developers, but this design is far from being intelligent. A 32 digit code is meaningless for a human being without a friendly name. I can imagine your discussions though.
The reason for the device_id is to identify the device internally. As long as the user does not modify the YAML directly, he will only see human readable device names and descriptions in the UI (for LCN the module name or a descriptive placeholder).
This is due to the switch of the LCN configuration from the configuration.yaml to the UI configuration . The reason for this switch was, that the HA core developers do not accept new features for integrations which are configured via the configuration.yaml (a design decision which is documented here.
The configuration.yaml identified the LCN modules (devices) by their LCN segment id, module id and a name for the host coupler (integration name).
If an integration (any brand) can be set up via the UI, there is an integration name as well.
So, my idea when programming the UI was to just take that name as an identifier for the integration instance.
And that was the point of discussion which was not accepted. This name can be changed by the user at any time and if so, will break all automations for this integration instance.
If you have an idea how to uniquely identify the integration (the host coupler) by any name, property or id which is not the HA integration name, that would be a solution to the problem and we can go back to the LCN address ids.
But besides the IP address of the PCHK host, I have no idea.
As you can see module names are sometimes truncated. And for the non-standard virtual modules I only get “en”, which I can’t modify. Although specific to my case, the HA logic builds on the assumption that a name is unique.
I understand that, although a broken automation is more the user’s problem. I believe that being able to edit a table that holds the fixed device_id information together with an editable friendly name (or the “descriptive placeholder”) would address most if not all issues. But that’s of course up to the team, and in light of the HA logic unlikely to be seen in the future.
Hopefully there won’t be that many changes with LCN anymore after all.
Sorry, I completely forgot about your problem with the module names.
As soon as I have time I will investigate this. I might have some questions and need help from you…
I do believe though that if HA organized its device definition in a database rather than a text file, life would be much easier. In that case changing the name could be automatically reflected in all places where it is used, if the reference would be to that field rather than an absolute name.
Like you I see no way to automatically recognize an existing host coupler unless it provides a defined recognition dialogue - which it doesn’t . I remember that initially you were using a manual definition in the configuration file to set its IP address and port within HA.
How is it done now? Imagine that somebody wanted to change the coupler’s IP address…
When you create a new integration instance (aka config_entry), HA assigns an id to that instance. Internally the instances are referenced by this id. So you may change any parameter, incl. name, IP address, etc. and HA can still reference the integration.
An idea:
Most (if not all) LCN actions could be replaced by entites/platforms. This was not possible a few years ago because there were very few entity types back then.
Using entities in automations/script is the preferred way over using devices or actions as they are identified by their entity_id, which is visible/editable to the user.
Mmh, coming and thinking in terms of LCN parametrization, this would indeed be a major change. One just don’t thinks that way when using LCN Pro. Replacing the module number by a device id was already a major break of LCN philosophy. But maybe I misunderstand your idea.
That said, the number of LCN installations that are used in connection with Home Assistant is relatively small. You might be better off by following your own likes and dislikes.
Personally, I try to keep basic functionalities within LCN. If for whatever reason Home Assistant is down, being able to open/close shutters and garage, switch on a light as well as a functional heating is definitely a good thing to keep my wife happy.