There is a story. SAI and I made our agreements with PCS at the same time - it was just luck that I was assigned the MID of 3 while SAI got 4. The founder of SAI was a former boss of mine and we have always collaborated in some manner and have had a very close working relationship since SAI was founded.
1 Like
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.