The warning comes not being able to communicate with the device listed (I keep meaning to update the error message to put in the name). The timeout happens after two attempts to talk to the device and waiting for a response for 5 seconds each time. 164C is a hex string where 16 is the network number (22 decimal) and 4c is the device number (76 decimal).
light_update_status can be used if to get the status from a device (brightness level). It was thought by @123 to be useful, and trivial to add.
That service is for keeping multiple UPB controllers in sync.
You would need at least two separate systems, each with its own PIM, in order to test light_update_status. For example, UPStart on one computer and Home Assistant on another.
This appears to be a common deficiency with the, recently promoted, ‘config flow’ style of configuration. While setting up my new server, I decided to forego YAML configuration of MQTT and use config flow. First thing I noticed is that now I have no means of changing MQTT Discovery’s root name (defaults to homeassistant).
Config flow may be powerful and flexible on initial use but after it has done its job, there’s no means to modify the resulting configuration (or at least none that I have found). That’s a major chunk of missing functionality.
EDIT
I imagine the current solution/workaround is the nuclear option: delete the existing integration and re-install it using the new desired parameters (serial port).
Understood but you have to admit there’s irony in this being the way to modify an existing configuration produced by config flow.
Config flow is the ‘shallow end of the pool’; it’s friendly to novices installing an integration. We’re throwing them into the “deep end” if they must manually edit JSON (typically undocumented JSON) in order to modify an existing integration’s parameters.
That’s the irony of config flow in its present form. The only novice-friendly way to modify the integration’s parameters is to re-install it.
The pull request to put the lights into hass should be approved today. Since pull requests are to be broken up, scenes are next up.
There is a breaking change for lights (perhaps more than one, I can remember one). That is update_status is removed. It is replaced with homeassistant.update_entity.
There will be breaking changes for scenes. upb.activate is removed in favour of scene.activate. The second breaking change, so far, is that event will no longer be used. They are not allowed by integrations any longer. Events will be replaced with device_triggers – which I know nothing about yet. All that said, scenes may get done first and then a subsequent change will contain the device_trigger work.
Right now, lights should make the 0.110 release. Scenes should too. I’m hoping to figure out triggers to get them done too, just a warning they may miss the 0.110 cut.
This is much more work than I hoped for! However, through some excellent help by @bdraco he has helped me through this. I already said it to him on the pull request thread, but let me say where more will see it: Thank you Nick! I really appreciate the help. Gold standard on collaboration!
Thank you for the update. The changes all seem reasonable to me.
Ditto. I look forward to learning more about it because detecting when a link is activated/deactivated is important to my automations.
That’s an interesting development. Integrations like zigbee and zwave generate all kinds of events so I imagine those integrations will eventually be overhauled? Talk about a breaking change!
YiKES. Okay, it sounds like we should stick with the custom_component for a bit then? I can’t say I’ve ever heard about device_trigger. Doesn’t ring a bell.
I suspected a device_trigger is part of Device Automations and the Developer Docs appear to confirm that.
I believe this mean the only way to detect link activation/deactivation will be via a Device Automation. They’re designed to be created via the UI, not via YAML. If anyone has ever looked at the YAML version of a Device Automation’s trigger they’ll understand what I mean. Getting the device’s identifier value would mean exploring core.device_registry.
The Developer Docs surprised me when it used ZHA and Deconz as examples. I believe they also support events. So the new directive is effectively grandfathering events in existing integrations in favor of device_triggers for all new integrations. Is that your impression as well?
Finally got around to playing around with this a bit more, been super busy with work in general so I’ve had limited time to look into this. I have a tool I started writing called upbshark which is a decoder proxy that sites between upstart and ser2net attached to a PIM.
The idea is that it can be used to do logic traces for upstart and any other UPB compatible software to verify the command/decoder logic is correct before actually building out a library that is capable of handling pulse mode properly.
So apparently pcs open sourced upstart or at least part of upstart here. At first glance this code is not at all easy to read, especially due to the widespread use of magic constants throughout the codebase, the premise source is much cleaner IMO but this may fill in some missing feature gaps for things that premise doesn’t implement.
I’ve made a number of updates to my upbshark utility, I think for the most part I’ve got pulse mode decoding figured out(I still need to finish building out some parsers for all the features but they generally seem to follow the same pattern), I’m currently reading out buffered data from pulse mode for commands generated by upstart such as MDID_CORE_COMMAND_GETREGISTERVALUES. Next I’ll probably work on writing a parser for the register maps but that should be relatively straight forward.
Latest update: not using device triggers. Using events again. However, events are not allowed from entities, so event cannot have entity_id in it. Don’t ask me why, cause every time I try to understand I get shut down. You can see the discussion that happened on this topic on Sunday afternoon on the Discord chat server in the #dev channel.
So, if I understand, and that’s a big if, I will be generating events from the integration level. Event type is something such as upb.link_changed (name not final yet) and the contents being:
Type of change (e.g.: activated, goto, etc.)
Address of link in the form <upb_network_number>_<upb_link_number> (e.g.: 42_6 for link 6 on network 42)
Brightness, -1 if default or does not apply
Rate, -1 if default or does not apply
I plan to submit the PR tonight.
I also plan to open an architectural issue around creating events out of entities.
Its not very complicated; an entity belong in hass state machine and should focus on describing one thing. An event is stateless and thus doesn’t belong in the state machine and is only relevant in the moment. A device can be a combination of entities and events. This is also why device triggers exist, to combine entities and events when writing automations. Which is nice, device automations really improves the simplicity in creating automations, when you want it.
If I create a Device Automation, the device_trigger contains a device_id. This is a unique identifier assigned to the device at the time the integration created it.
If I uninstall the integration and then re-install it, the device will be assigned a new unique device_id.
That means the Device Automation I created will have an invalid device_trigger because its device_id is still the original one, not the new one. Is what I’ve described correct?
In contrast, an automation using an event trigger isn’t so tightly integrated with its device. So if a device_id changes it makes no difference to the event trigger. It’s only affected if the actual event name changes.
Hmm, I wonder how this would work if we have home-assistant fully manage the UPB device configuration like premise does, in premise how do you set a uniquely identify UPB devices?
Thank you. I was kind of sorry to hear I got that right because there’s no simple way of fixing the broken device automation.
Sure, you only have to replace its device_id with the newest value but getting that value is (currently) not a straightforward process (and to be fair, it was never meant to be handled manually). You find it in core.device_registry or make a new device automation, examine it in YAML form, copy the new device_id, then paste it in the broken device automation.
