I’ll share how I’ve programmed it:
Here’s a screenshot of how I have Button 01 programmed for a US2-40 (Unit 001). It activates/deactivates a scene (link) called Porch Fountain.
Porch Fountain is scene (link) 006. It has no members other than Button 01 of Unit 001.
In Premise, I monitor Unit 001’s upbNetworkData property for a string containing the activate/deactivate command for link 6.
In Home Assistant, I monitor the UPB event for activating/deactivating scene.porch_fountain.
My thanks to the whole crew here for all you efforts in putting this together. I’ve been watching this thread for a few weeks and finally had change to try it out. Just got HA running on my imac and now have the library from @gwww running with a very basic UI. I’m using all SA devices, iMac connected to UPB via USB serial to SA UCS-01 in CIM mode. I have a mix of US2-40 and US22-40 (2 circuits per device). I’ve done some basic testing and can report that the US2-40 seems to work without issue so far. I can set it via on/off or dimmer control and they also respond to links. HA also appears to receive updates from the switches fine as well if they are adjusted at the switch. I’m not sure if you fully implemented them yet but the US22-40 switches still have some issues, the two channels appear to be interacting with each in interesting ways when being controlled via HA. They do seem to update HA correctly when set at the switch and also respond to links correctly (which you might expect). I updated some Java code in OpenHab a while ago to solve a similar problem so will try to take a look but I’m a python newbie. The OpenHab code never read the UPStart file though which made it a painful manual process to set up. This already seems better! I have some thoughts on how to handle the link controls also that I’ll post tomorrow. Thanks again for the effort on this!
@gwww, I did some code browsing and see that _encode_common in message.py is trying to use channel. I then noticed that all HA UPB entities had channel value of 0. I looked in parse_upstart.py and noticed that line 55 has light.channel = 0, I’m thinking that should be light.channel=channel but haven’t looked at it carefully. I’m not sure how to get HA to use a local copy of upb-lib though so haven’t tried it yet.
Good catch! I actually noticed that the other day too. I’m super happy there’s someone out there with multi-channel devices. I don’t have any way to test them.
How are you running your Home Assistant? Raspberry PI? Something else. When I test on my MacBook I just go into where the library is installed and edit what I want to change. On the RPi, not sure how to do that as everything’s in the Docker container.
OK, I did some more playing tonight and have my multi-channel devices working… I’m running HA on an iMac and managed to find the library. I modified parse_upstart.py to set light.channel = channel but still had issues. After a bit of fiddling (and rereading the PCS spec) I recalled that channel numbers need to start at 1 (0 means all channels) so now have light.channel = channel + 1. This still was acting strange so I looked at message.py and wound up tweaking _encode_common so it always sends channel args as follows…
if not link:
args.append(0xFF if rate == -1 else rate)
args.append(channel)
I tested this out on both my single and two channel switches and all were happy. I’m going to build a UI and lets this soak for a while but it seems pretty solid at this point. Nice work!
Could you try the code like this:
if not link and channel > 1:
args.append(0xFF if rate == -1 else rate)
args.append(channel)
elif rate != -1:
args.append(rate)
(The only change from my original version is changing the condition to channel > 1 from channel > 0.)
That should include the channel number only if its greater than 1.
Why? Because I’d like to send as few bytes on the wire as possible because UPB is a slow protocol. Of course if that doesn’t work then we can consider the options.
I hope to publish a new version tonight.
Will wait for it before carrying out the experiment with the USB CIM and Home Assistant installed in a venv (as opposed to docker). I don’t think the venv aspect will fix anything but I need to test and confirm it first.
BTW, Happy Cake Day!
I like your thinking… and I actually tried exactly that last night. Unfortunately, the 2 channel devices (US22-40t) seem to required a channel arg even for channel 1. All of my other (single channel) devices don’t seem to mind the channel arg so I settled on always having channel. The only way around it would be to check for what type of device you’re sending the command to.
BTW, I find it annoying that I have to send the rate arg in order to send the channel… I’d like to use the devices default rate. Do you happen to know if a rate arg of 0xFF is interpreted as use your default rate?
Also BTW, should UPB links be implemented as switches in HA? As scenes, it appears you can only activate them, if they were switches you’d be able to effectively use them as a switch that controlled a group of lights. If you wanted the link to be a HA scene you could then just define a HA scene that just turned that switch on. Thoughts?
OK, I know how to handle. I can set a flag on multi-channel devices to always send channel. Flag would be clear on single channel devices.
I also find it annoying with channel number following rate. I believe that to be a protocol design flaw. I believe that 0xFF means the default rate. That’s not in the docs but comes from @webmtn.
UPB links as scenes or switches is a great question. There’s some discussion earlier in this thread on exactly that. I started with them as lights (not switches). We decided scenes were best. Read through and see what you think. I’m OK if we revisit.
New upb-lib uploaded, version 0.4.1; new custom_component uses it (no changes, just bump lib req’t)
Have fun!
Hmmm… something broke. After various fooling around with the current HA install I ended up just reinstalled HA from scratch and then reinstalling usb-lib. I keep getting the following…
2020-04-07 22:05:18 INFO (MainThread) [upb_lib.upb] Connected to UPB PIM
2020-04-07 22:05:28 WARNING (MainThread) [upb_lib.upb] Timeout communicating with UPB device 9208
2020-04-07 22:05:38 WARNING (MainThread) [upb_lib.upb] Timeout communicating with UPB device 9209
2020-04-07 22:05:48 WARNING (MainThread) [upb_lib.upb] Timeout communicating with UPB device 9201
Any idea what might be going on?
Also, I looked through the previous conversations on how to implement UPB links in HA and may have a new thought to contribute. I think UPB link behavior could best be modeled in HA using two integrations. The first is the ‘scene’ integration which you already have and corresponds to a UPB link activate. But that leaves a great deal of the UPB link capabilities unavailable. The second integration would help with that. This would be the ‘light group’ integration which according the HA documentation has behavior that maps pretty well to a UPB link goto. It enables control of a group of lights. I didn’t see the ‘light group’ integration suggested before, perhaps it could be ‘overloaded’ for use with UPB.
I need a debug log. Take a look at the README for how to turn on. https://github.com/gwww/hass-upb/
If you want to email to me and keep it off the list then you can find my email here: https://github.com/gwww/upb-lib/blob/138f7f0930d6302f00c88ddf26ab56282b809204/pyproject.toml
What happened is a “works on my computer” The whole protocol layer has been under going a rewrite over the last week. The goal is to make it more robust.
So, question. Are all of those timeouts dual-channel devices? Cause I be there’s work to do there in the proto layer for that. As I write this response I can think of a couple of things that are broken. Second question. Are you seeing those messages on startup? (i.e.: before you try to do anything with the hass integration).
While it is possible that the device is actually timing out, it most likely is a bug.
My guess is this code is not working as intended, don’t know why without logs. https://github.com/gwww/upb-lib/blob/138f7f0930d6302f00c88ddf26ab56282b809204/upb_lib/proto.py#L150-L151
This code in particular is looking to see if a packet that came from a UPB device is one that we are waiting for a response from. The code is picking out the network_id and device_id and checking if it matches the last packet sent. If it does match a response we are looking for, we remove the packet from the write queue and move on to sending the next packet.
Since we get a timeout, two things could be happening. We are not getting a response. Unlikely since things were working before. Second, we have a bug in reading responses. Hence pointing at the code I did. Without logs hard to know why. Like I say works for me and I’ve tested a quite a bit. Certainly makes me curious about multi-channel support causing the problem.
A light or a light group has states (i.e. on/off) whereas a UPB link (a.k.a. scene) is stateless.
Activating/deactivating a link isn’t precisely the same as saying it is on/off. There’s nothing in UPB’s design that let’s you know if a given link is currently activated or deactivated. It’s more of a do this or that situation with no record-keeping to indicate which one is currently in effect. Home Assistant’s scene models this situation best because it is stateless.
Let’s say I activate link 3 which causes ten lights to turn on (and set themselves to whatever levels they were programmed to do for link 3). I can activate another link that changes all of those lights (even turning then off) and several others. It would be misleading to say link 3 is still “on” yet that’s what a light or light group would indicate.
Before I tinker with my production server (Home Assistant installed in a venv) I’d like to know if upb-lib supports direct USB communications.
Currently, it expects to be pointed to something that behaves like a serial port. That means when I connect my serial PIM (via a USB-to-Serial converter) the serial port appears as:
/dev/ttyUSB0
or via its named form:
/dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0
In contrast, when I plug in a USB PIM (direct USB connection; no converter cable is employed) it appears as:
/dev/usb/hiddev0
There’s no “tty” alias for it. That leads me to conclude it does not present itself as being a vanilla RS-232 serial port but a true-blue USB port.
Based on some (admittedly limited) research, I found there’s a python library, called pyusb, for communicating via a USB port. So does upb-lib know how to operate like pyusb in the event the PIM or CIM is the USB version as opposed to the serial version?
Best I can say is I think it should work. Get the device name right and away you go. That said, you are the first! Tell us how it work 
Looking at the device name usb-Prolific_Technology_Inc._USB-Serial_Controller I believe this is a USB to Serial converter, which is what I’ve been using to create all this software. I’m personally using a Keyspan USB to Serial converter.
I wish I had more of the UPB hardware to try. USB PIM would be interesting – especially if it turns out to be different than serial port. A multi-channel device would be even more interesting given the remote debugging that I’m doing on that now.
FYI, I’ve been working with @ajha off forum on the timeout issues that he is having. My current assessment is that the timeout are a result of his UPB installation actually being slow (>10 seconds to respond to a message).
TL;DR upb-lib appears to working as designed, design seems correct, everyone should try upb-lib 0.4.1 or later unless some new information comes to light (get it, comes to light. PIMs and UPB. OK, I’ll stop).
New lib version 0.4.2 released. New feature to allow renaming devices. See release notes for details.
Following up on this, I used the verify and signal-noise meter functions in UPstart to verify that I do indeed have significant noise on a few circuits while others check out with no problems. Seems to be intermittent as well. I’m running HA from a computer in a new location so never noticed this before. Of course this had to happen in the middle of trying out new code ;). Thanks for the help Glenn.