Just to clarify, I’ve only tried the USB PIM with gwww’s UPB integration running in Linux (the PIM is from Simply Automated). Specifically with Home Assistant Core as a docker container.
gwww,
I’ll collect the requested logging info and email it to you.
Howdy,
So, as you requested, I attempted to test receiving a GOTO message from a multichannel device. The thing is, that is not an easy thing to make happen with just UPB switches and one PIM. My PIM is connected to my HA system ‘watching’ the UPB network. So I went into Upstart and attempted to program one of my multi channel switches to publish the desire message… but they don’t normally do that. By using some features in Upstart that don’t appear to be covered in the documentation I attempted to get the switch to publish a direct packet GOTO. Under Edit device / Transmit Components I set the switch mode to custom and the single tap to GOTO on. Then under options I enabled Rocker 1 Transmits and under Advanced set Transmit Type to Direct Packet. This was all guess work. This did not seem to have the desired affect because after programmed the switch seemed to be spewing out UPB traffic non stop. Luckily, I was able to reprogram it to its previous state. So, all that to say I wasn’t able to perform the test, but also, I’m not sure its a message type you need to worry about unless there is another PIM on the network that can generate it.
Regarding UPB Links represented as light groups. Its true a UPB link itself does not have a state but a state could be inferred from the state of all the lights in the group in the same way a regular light group seems to. Since we know what lights are affected by the link by virtue of the Upstart UBP config file we know what lights are in the group and could then determine a state through a simple rule. For example, in any light in the group is ‘on’ then the group state would be ‘on’. BTW, it appears the default display in Lovelace for the UPB lights is in an entities card with a switch at the top that effectively acts as a light group. But when I turn it off it sequentially works its way through the lights and turns then off one at a time. Since UPB is a slow network you can actually watch the lights go out one at a time.
In any case, what I’m really after is at least a way to issue a UPB link deactivate from within HA. I have my UPB network programmed to turn my various ‘light groups’ off in response to a deactivate. Without it, I will need to create dozens of new links in Upstart just to cleanly turn groups of lights off with a single UPB command.
Perhaps representing UPB dimmer switches as “devices” as you suggested in a later post has some flexibility beyond the limits of HA scenes.
The UPB standard itself doesn’t track a Link’s state so I see no reason to “infer” it just so we can force a round peg into a square hole. Home Assistant’s scenes model UPB links to a tee (both are effectively stateless).
This is already possible via a service provided by the UPB integration. Go to Developer Tools > Services and scroll the list down to where all the UPB services are listed.
The one you want is called upb.link_deactivate and can be called from a script, automation, or directly from certain Lovelace cards.
Latest update…
I have done the integration work with hass, so that this is no longer a custom_component. It is not submitted as a PR yet so the only way to test is to download and run hass from my github instance which is found here: https://github.com/gwww/core
In doing the integration work, UPB is now only configurable through the GUI. Support for editing the configuration.yaml is no longer supported. That is mostly a hass architecture decision. I say mostly because they do still allow config through yaml if you have the config through GUI (if I understand correctly). I chose to simplify the code and lower the support surface area.
The upb_lib version is bumped to 0.4.6. It has a couple of small but fixes.
The service calls have been tweaked. This is probably is a breaking change, but I’m guessing it affects no one or I might have heard about it sooner. The change is to do with transition rates. I found that they were not being treated as a time in seconds everywhere. Also they were being treated as integer vs floats. So now you give 3.6 (seconds) as the transition time, which will map to 3.3 in what the UPB devices support.
Blink rate has also been changed in the hass service call to take seconds. The call accepts a value between .25 and 4.25 seconds, where 4.25 is the max value the UPB devices support. The value in seconds get translated by the lower level API to Hz which is what the devices support (although I cannot find documentation to support that claim, testing has shown that it appears true).
The service calls that take a brightness now take it in both forms that hass uses: a percentage or a number between 0 and 255.
I also added manufacturer to the device attributes.
Before I submit the PR, who can check this out and make sure it it working? Testing help needed! All the service calls should be tested. Actually all everything you can think of should be tested. Feel free to report bugs and missing features. Be ready to supply debug logs! I may be able to fix many things without but I may require for some fixes.
What else? Did I miss anything?
(Edited to fix typos.)
@gwww Am I too fast or did you forget to push to github? I don’t see anything new under hass-upb.
EDIT: NEver mind. I guess by the time I got to the end I forgot the first sentence 
Okay. So I tried to cheat and sneak it into the 108 release. I’m not sure what I did wrong but when I clicked on add integration nothing would happen. I’m guessing it’s probably because I didn’t follow your instructions :).
If anyone else is going to give this a go, you better bust out your git skills (which I lack). I found gwww’s stuff (HIDING ) in the upb branch. https://github.com/gwww/core/tree/upb.
Thx for that @bbrendon . Git link with correct branch. https://github.com/gwww/core/tree/upb
Sneaking it into an existing release won’t work. Part of integrating a new component is that there’s a couple of file outside of the integration that get updated. One is a list of supported config flows. The other is the all requirements file. There may also be one with the GUI translations, that one is magic to me… I ran a script and it worked.
If you look at the commit history https://github.com/gwww/core/commits/upb you will be able to see all the files that changed.
Can you explain how to do that? I haven’t done a non-Docker installation in a very long time. How does one adapt the official installation instructions to use your version rather than the latest official release?
Ditto.
Be brave 
Assuming that you have git and python installed. Start with: git clone https://github.com/gwww/core.git. This will create a new directory called core. Change into the core directory cd core. Switch to the upb branch: git checkout upb.
Now you should be able to follow the directions here, starting at the section “Setting up your virtual environment”: https://developers.home-assistant.io/docs/development_environment. Specifically these 4 commands:
$ python3.7 -m venv venv
$ source venv/bin/activate
$ script/setup
$ hass
** Before running hass it is wise to save your .homeassistant configuration directory. I use just rename it and I do not recreate another one as running hass will create it for you.
Once hass is running goto the configuration section and add a new UPB configuration.
@123 Its a variation of this.
https://developers.home-assistant.io/docs/development_environment/
git clone https://github.com/gwww/core
cd core
git checkout upb
… Then follow the rest above.
Thank you both.
I’m currently in the middle of transitioning to a new server, and migrating more services from Premise to Home Assistant, so I currently have limited time (let alone a spare server) to devote to re-testing the entire UPB integration.
@gwww I tested your branch and I did a few things… No glaring issues. I did notice two things. 1. a GUI issue which I don’t think is you. (see below). and 2. You can’t edit the serial port or UPE filename after enabling the integration, though I’m not sure HASS even allows modifying stuff? I don’t use the GUI much.
Other than that, I turned some lights on/off. Poked around.
There is a scrolling issue on the GUI. I couldn’t scroll to the bottom. I’m guessing that someone else’s problem. I just closed the dialog box and went on my way and all was fine.
Thank you!! The GUI issue is in the core so nothing I can do about it. The editing is something I just don’t know about… is it even supported to edit an integration once it is configured. I’ll poke around, maybe ask on Discord.
If you can play with the services that would be good too.
I have to get the docs page together, a bit more testing, then I’m ready to submit this as a PR to be a core integration.
Thanks again!
ok ok. I know you need more testing. I broke down . No issues except an error in the log I couldn’t reproduce.
I tested these…
upb.light_blink
upb.light_fade_start
upb.light_update_status – called service, not sure what to look for.
upb.link_activate
upb.link_blink
upb.link_deactivate
upb.link_fade_start
upb.link_goto
I got this error but I’m not sure what caused it and I couldn’t reproduce it.
WARNING (MainThread) [upb_lib.upb] Timeout communicating with UPB device 164C
Love it!
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).
A second option is to go into the .storage directory and edit the parameters. This should be done while hass is stopped.
That said, when the UPB integration is configured the parameters are checked by initiating the UPB connection and checking that the UPE file exists.
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.
