Oh my goodness I’ve been missing this UPB goodness, time to dust off my old gear! Hope I didn’t get rid of to much stuff. I used to have quite a bit of switches 30+
I did suffer with a issue I believe from the power company with a substantial amount of noise after they shut down the power to change some transformers I believe. It’s been years 
Let the fun begin!
So I’ve finally had a chance to switch over to this from Premise/MQTT. Everything is talking from HA to UPB. However, I don’t seem to be getting Report State back from any of the dimmers or lamp modules. If I turn on a device, HA still shows it being off.
Also, when I switch on or off from HA I get a long fade in or out. Can I adjust that somewhere? Or do I need to reprogram the devices with UPStart? Otherwise everything seems to be working.
Restarted a couple of times and reporting seems to be working now. Still not sure where to change the fade rates.
Hi Sam!
Use the transition option with either the light.turn_on or light.turn_off services.
This UPB integration is still in beta so a few things may still need to be revised. Whereas Home Assistant defines transition as the number of seconds, to change from one brightness level to another, the UPB integration doesn’t conform to that definition. It takes whatever number you enter for transition and uses it as the UPB device’s fade_rate.
As we both know, there are only 16 discrete fade_rate values. In addition, the fade_rate value is simply an index number and not the actual time in seconds. For example, fade_rate=8 represents 30 seconds (and not 8 seconds).
| TIME | FADE_RATE |
|---|---|
| SNAP | 0 |
| 0.8 seconds | 1 |
| 1.6 seconds | 2 |
| 3.3 seconds | 3 |
| 5 seconds | 4 |
| 6.6 seconds | 5 |
| 10 seconds | 6 |
| 20 seconds | 7 |
| 30 seconds | 8 |
| 1 minute | 9 |
| 2 minutes | 10 |
| 5 minutes | 11 |
| 10 minutes | 12 |
| 15 minutes | 13 |
| 30 minutes | 14 |
| 1 hour | 15 |
What all this means is that transition, when used with the current version of the UPB integration, is not the time in seconds (Home Assistant’s default definition) but the fade_rate from the table shown above.
You can test it using Developer Tools > Services. In this example, it turns on the light to 100% brightness over a period of 10 seconds (fade_rate=6).
1 Like
Thanks Taras! Seems like you’ve been helping me for years 
I’ll test this later today. I’m having issues with my Russound crashing since I rebuilt my HA server (it used to do this, but has been stable for months now). So once I establish if HA is the cause or not, I’ll try the transition setting.
I’ve had success using a serial PIM but I need guidance for configuring a USB PIM (both are from Simply Automated). According to the documentation for upb-lib I should be able to specify a USB port:
url: This is the PIM to connect to. It is formatted as a URL. Two formats are supported:serial://<device>where<device>is the serial/USB port on which the PIM is connected;
However, I’ve had no success configuring it correctly (i.e. UPB integration fails to detect the USB PIM).
When I plug in the USB PIM, it appears as:
/dev/usb/hiddev0
In docker-compose.yaml, I map it like this:
devices:
- "/dev/usb/hiddev0:/dev/ttyUSB0"
In configuration.yaml, I leave it exactly the way it was configured for the serial CIM (which worked):
upb:
url: serial:///dev/ttyUSB0:4800
file_path: ./upb.upe
This fails to work for the USB PIM and the log contains the following:
homeassistant | 2020-03-26 14:04:08 INFO (MainThread) [upb_lib.upb] Connecting to UPB PIM at serial:///dev/ttyUSB0:4800
homeassistant | 2020-03-26 14:04:08 WARNING (MainThread) [upb_lib.upb] Could not connect to UPB PIM (Could not configure port: (22, ‘Invalid argument’)). Retrying in 60 seconds
I changed:
url: serial:///dev/ttyUSB0:4800
to:
url: serial:///dev/ttyUSB0
and restarted Home Assistant but that resulted in the same log messages.
What am I doing wrong?
I don’t know the answer. What I do know that I have successfully connected to a PIM to a USB port. It was on a MacBook and it was with the USB to Serial converter, with the PIM plugged into the serial port of the converter.
So, two new variables in what you are doing. Linux and Docker. I’ve seen a number of threads around mapping ports in Docker, which you are doing. I can’t tell you what is going wrong.
I also use a Serial-to-USB converter cable to connect my serial PIM. The configuration in docker-compose.yaml is this:
devices:
- "/dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0:/dev/ttyUSB0"
Basically, within the Home Assistant docker container, dev/ttyUSB0 represents the “real port” which is that long-winded path shown above.
I thought the same principle would apply with the USB PIM where dev/ttyUSB0 (internally) represents dev/usb/hiddev0 (externally), but no joy. It seems like upb-lib doesn’t like what it sees.
My production server runs Home Assistant in a venv. I’ll try the UPB integration on it, with the USB PIM, just to eliminate docker as a potential factor.
So, I have everything working. Set transitions to 0 or 1 and it seems to be working.
Now I have one switch in the bedroom with a rocker on the top half, and 4 buttons below. I’d like to capture a button press and have it trigger a script. In my case, the buttons seem to be sscene.scene007, 008. etc.
How can I accomplish that?
Here are a few automations I had used to test scenes.
This one detects when a specific scene is activated (and reports it as a persistent notification). Replace the scene.all_exterior with your scene’s name (i.e. scene.scene007) and replace the contents of action with whatever you want to happen when your scene is activated.
- alias: 'UPB scene activated'
trigger:
platform: event
event_type: upb.scene_activated
event_data:
entity_id: scene.all_exterior
action:
service: persistent_notification.create
data_template:
message: 'entity_id: {{trigger.event.data.entity_id}}'
title: 'UPB Scene Activated'
To detect when the scene is deactivated, simply create another automation with:
event_type: upb.scene_deactivated
These three automations simply report to the log whenever any scene is activated, deactivated, or uses goto.
- alias: "Scene activated"
trigger:
platform: event
event_type: upb.scene_activated
action:
service: system_log.write
data_template:
level: warning
message: "Activated '{{trigger.event.data.entity_id}}' Data '{{trigger}}'"
- alias: "Scene deactivated"
trigger:
platform: event
event_type: upb.scene_deactivated
action:
service: system_log.write
data_template:
level: warning
message: "Deactivated '{{trigger.event.data.entity_id}}' Data '{{trigger}}'"
- alias: "Scene changed"
trigger:
platform: event
event_type: upb.scene_goto
action:
service: system_log.write
data_template:
level: warning
message: "Changed '{{trigger.event.data.entity_id}}' Data '{{trigger}}'"
Quick update from me. I’ve been working on a couple of things.
One is a serial to TCP bridge to access any serial port over TCP. In particular the PIM. Yes, there’s are many of those out there. This one works on Windows and Unix (Mac tested). This one also allows for two clients to connect and that’s where it is different. It allows for a “regular” client and a “priority” client. The regular client bridges the serial/TCP ports until a priority client connects. When a priority client connects the regular client has all communications paused until the priority client disconnects.
Use case? hass connects to the PIM as a regular client, does it stuff. UpStart connects as a priority client, causing the hass connection to pause. UpStart does its thing, disconnects, and then the regular client picks up again. There’s one more thing. When a regular client is paused, a “special message” is sent to the client saying “PAUSED”, so it knows that communications are paused. When a regular client is resumed a RESUMED message is sent which in the upb-lib caused a resync to happen.
Code here: https://github.com/gwww/ser2tcp
Second thing I’ve been working on is the upb-lib. After much reflection on how the existing protocol handling worked (proto.py) I rewrote it. The big change is that it waits for specific messages, timing out when they are not received. Example… Terminology first. A UPB device is on a network with an ID and has a device number. Let’s say network id == 19 and device == 42. (19, 42). When a packet is sent to (19, 42) then the protocol handler now looks specifically for a response from (19,42). When that is received, only then is the next message sent on the UPB network. If a response is not received in 5 seconds then a timeout occurs. Retry logic to be written.
This new protocol handler seems much more reliable than the previous one. In the previous one occasional responses where lost most likely because packets were being sent out too quickly onto the UPB network.
This new code is not pushed to github yet. Still testing it. When I do push I’ll be looking for testers.
So, not sure what I’m getting wrong here, but I have the following. As a test, I have it simply turning on one light in the same room with the switch that has the switch with the button I am trying to use.
- alias: 'Goodnight Scene Activated'
trigger:
platform: event
event_type: upb.scene_activated
event_data:
entity_id: scene.goodnight
action:
- service: homeassistant.turn_on
# - service: script.goodnight
entity_id: light.masterbedroom_overhead
Nothing happens. Is there any way to see if the button press actually gets to HA?
BTW, I also tried -service: light.turn_on
Go to Developer Tools > Services and manually trigger the automation. This process skips the automation’s trigger (and condition, if any) and just executes the automation’s action.
The light in the Master bedroom should turn on.
- If it doesn’t then you know you need to focus on fixing that part of the automation.
- If it does then you know there’s something wrong with the automation’s trigger.
If you want to monitor UPB events, you can go to Developer Tools > Events > Listen to events. The available events are listed on the right hand side. Select upb.scene_activated then click Start listening. Proceed to activate the actual light switch to make it transmit the UPB scene activate command. You should see it appear on the page.
That’s what I needed! Thanks.
Part one triggers the light correctly. Part two, listening for an event gets nothing. I have the buttons (it’s a switch with a rocker on the top half and 4 buttons below) all programmed top transmit scenes. I’ve played with how the buttons react to pressing to experiment. But no matter what I do, I get nothing from the switch.
When I was using Premise, I could see the code sent in a logic block and then use that to trigger whatever I needed. Usually scenes.
So, just to be clear as well, I don’t use any scenes programmed in UPStart, into the switches. Just software. Especially sine I’m mixing UPB, Z-Wave and Zigbee.
So I’m stumped…
I’m stumped too. How can you have buttons “programmed to transmit scenes” but also “I don’t use any scenes programmed in UPstart”?
I have uploaded a new version of the library, version 0.4.0. There is a small tweak to the hass code to support this, so a new version of the custom component is required.
The library had a substantial overhaul of the protocol layer (proto.py). This was done to treat UPB devices more like network devices in how the library communicates with them. It also takes into account that on the wire only one device can be communicating at a time, so communication to one device at a time is enforced.
I have been using the code quite a bit over the last couple of weeks, but while under active development. It would be good if people could try it out. It has been very stable in my environment (that’s my nice way of saying “works on my machine” ).
I have also solidified the TCP code to talk to TCP based PIM or, in my case, to talk to a serial to TCP software bridge which runs on Windows. That code also appears to work well and has a couple of features that people might find appealing. Check out ser2tcp in my github.
Feedback appreciated!
As far as I can see in UPStart, the buttons can only be programmed to trigger scenes. But there doesn’t need to be an actual scene behind that. The button still sends a trigger. I used it that way in Premise.
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
upbNetworkDataproperty 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.