UPB lighting

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 :smiley: 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).

Annotation 2020-03-26 103351

1 Like

Thanks Taras! Seems like youā€™ve been helping me for years :slight_smile:

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.

Screenshot from 2020-04-04 17-53-40

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ā€ :slight_smile: ).

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.