Sync is used on the library startup to get the status from all the devices in the UPB network. It’s needed for hass to know the status of any device.
Channel number moved to UpbAddr. The idea of UpbAddr is that a single object contains the network id, device id, channel number, and if the device is multi-channel. I went with zero based numbering which is what the UPE export file uses, and I prefer 0-based indexing. When a channel is required to send in a message I add 1; never should the code ever send a 0 in the channel number.
It would be a great help if you could also provide Glenn with a UPIM-01 USB/UPB Interface Module.
He currently has no way of determining why the UPB integration is unable to communicate with the USB version of the PIM. This is a useful variant of the old-style serial PIM because it eliminates the need for purchasing an RS232-to-USB converter cable.
I didn’t know that you had tried it. Could you send me full debug logs with logging levels as described in the hass component readme. My email is in the UPB lib pyproject.toml file.
Having a USB PIM would also be great for coding and debugging.
Just for informational purposes, there are actually two USB PIMs available - one from SA and one from PCS. The one from SA uses a generic chip set that should be recognized by Windows and drivers installed automatically. We’ve had issues with this one, just due to how Windows handles generic USB devices and it has been problematic at times. In addition, we don’t recommend this particular device for long term 24x7 type of controller operations as it has a small bug in it where occasionally it will lock up and you have to repower it. Now, that’s with Windows. It might not have this issue with Linux or HASS.
The other USB PIM from PCS comes with drivers that you load onto Windows. It tends to be more stable and easier to get up and working, but it is more expensive.
I don’t recommend either USB PIM to my customers (most of whom are Windows users). I actually tell them to go get a USB to serial adapter - one that has drivers for the OS they’re using - and use it with the serial PIM. The serial PIM is rock solid and we have practically no failures with it. And, since the adapter has drivers, it makes it more rock solid as well.
And, samgreco is correct - the correct procedure to get the PIM out of Pulse mode and into Message mode is the 5-10-2 taps. This is the same procedure that you use on any UPB module to do a factory reset.
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.
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.
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.
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.
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.
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?
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.
** 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.
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.
