UPB lighting

[123 (Taras)]

Update:

That worked but not without some resistance. The command as shown results in BusyBox responding with a help menu suggesting to use b, c, or p for the second option. I tried it with c and it produced the help menu again. At that point I looked in /dev and it now listed /dev/ttyUSB0 so I can’t be sure which of the two commands actually created it (despite both variations resulting in a help menu).

The UPB integration was able to find the port, open it, and poll all the devices listed in upb.upe. I successfully turned one light on/off to confirm the integration is working.

So it all boils down to my first observation: the assigned port (/dev/ttyUSB0) is not visible within the homeassistant container.

I assume this is something that should be managed by Supervisor (or some other service).

What’s next? Shall I post this as an Issue in the Supervisor repo?

[gwww (Glenn Waters)]

I’d try to get the attention of @frenck At least that might be enough to figure out another what’s next.

[PureeTofu (Billy)]

@123 for clarification I’m using HASS.io on a Raspberry Pi 4b (2GB)

[123 (Taras)]

Thank you for your reply.

I found your predicament interesting because, in your case, the ttyUSB* device is present in /dev. In my case,Supervisor reports the converter cable is on /dev/ttyUSB0 yet no such tty device exists in the homeassistant container.

[123 (Taras)]

After performing the test on Home Assistant 0.110.2 on an RPI3 (using the official disk-image) I repeated the test using a machine running Home Assistant Supervised 0.110.2 on Ubuntu. The result is exactly the same:

• Supervisor reports the converter cable in the Hardware view
• There is no /dev/ttyUSB0 device in the homeassistant container.
• The UPB integration fails to find and open /dev/ttyUSB0.

To exclude the possibility that this behavior is due to the model of converter cable being used, I tried one from another manufacturer. The results remain the same:

Supervisor’s Hardware view reports it as follows:

    /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A906U593-if00-port0
    /dev/ttyUSB0

Nevertheless, there is no /dev/ttyUSB0 in the homeassistant container and the UPB integration fails to connect.

---

---

UPDATE

My third and final test using Home Assistant Core 0.110.2 installed as a docker container on Ubuntu.

The docker-compose.yaml file contains the required device mapping:

    devices:
      - "/dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0:/dev/ttyUSB0"

The homeassistant container contains /dev/ttyUSB0 and the UPB integration finds and opens it successfully.

Conclusion:

For whatever reason, these two installation methods fail to expose the USB port as a tty device:

• Home Assistant 0.110.x (Raspberry PI3 disk-image)
• Home Assistant Supervised 0.110.x on generic linux

This prevents the UPB integration from accessing the PIM.

That means only these two installation methods are currently compatible with the UPB integration:

• Home Assistant Core 0.110.x in a python virtual environment
• Home Assistant Core 0.110.x in a docker container

[123 (Taras)]

I found the answer: restart Home Assistant.

---

And Now For Something Completely Different: Feature Requests

Drop-down list for Serial Device selection

Here’s the config flow for the ZHA integration. It also requires a Serial Device Path.

It offers the added convenience of a drop-down list for the Serial Device Path, listing the available devices:

In addition to the convenience of not having to type the path (and possibly introduce a typing error), it also provides visual confirmation of the available devices.

Options

The HACS integration provides an Options button:

It allows for changing the integration’s configuration without having to uninstall/re-install it.

This would be a valuable addition to the UPB integration. Currently, if you want to change the Serial Device Path or UPE file name, it requires uninstalling/re-installing the integration. If you have changed the friendly names of any of the discovered lights, that work is lost when the integration is uninstalled.

[samgreco]

First, let me say that this integration has been perfect thus far. Not a single glitch.

Now I need to finally revisit a scene button triggering a script in HA. I can’t seem to make it work.

So I tailed the log file to see if HA is seeing anything when I press that button. It does. This is what I get:
2020-07-11 08:30:04 DEBUG (MainThread) [upb_lib.proto] data_received: ‘PU89009E070CFFFFFFC9’

And this is what I have in my automation:

#All-off button from bedroom
 - alias: 'Goodnight Scene Activated'
   trigger:
     platform: event
     event_type: upb.scene_changed
     event_data:
       command: activated
       address: '158_7'  
   action:
      - service: script.goodnight

Any thoughts on where this is going wrong?

[gwww (Glenn Waters)]

Your config looks Ok at first glance.

I would start by testing the event using the HASS developer tools.

Goto Developer Tools (near the bottom in the sidebar). Select Events tab from the list of tools along the top of the dev tools pane. Near the bottom of the the Events tab is a Listen to events. Start listening for upb.scene_changed. Try you scene and check the output. Here is the output I see when I activate a link:

Event 0 fired 1:25 PM:

{
    "event_type": "upb.scene_changed",
    "data": {
        "command": "activated",
        "address": "201_9",
        "brightness_pct": -1,
        "rate": -1
    },
    "origin": "LOCAL",
    "time_fired": "2020-07-11T17:25:59.936910+00:00",
    "context": {
        "id": "3c1703bf39594423bc09349e0e419999",
        "parent_id": null,
        "user_id": null
    }
}

[samgreco]

I have done that. I never sees anything. Just sits there saying it’s listening.

[gwww (Glenn Waters)]

I’m leaning to user error… If the UPB PIM doesn’t see the link it clearly won’t report it. Try some other links around the house that you have configured. Do they show up?

EDIT: could be communication error as well. i.e.: the link does not get to the PIM because of powerline noise.

[samgreco]

Where can I verify the “address”? I have 158_7. 158 being the network ID and 7 being the scene. My UPE file shows:

0,5,20,15,158,5272
2,1,Scene001
2,2,Scene002
2,3,Scene003
2,4,Scene004
2,5,Scene005
2,6,Scene006
2,7,Scene007
2,8,Scene008
2,9,Scene009
2,10,Scene010

So Scene007 is what the button in question is programmed for. I am correct in my address? Or am I failing that simply?

[gwww (Glenn Waters)]

Try turning on UPB debug logging. In your configuration.yaml config the logging section as so:

logger:
  default: info
  logs:
    upb_lib: debug

Take a look at the UPB logs. You should see every message that comes into the PIM (and much more).

EDIT: 158_7 looks right to me.

[samgreco]

I did. That’s how I got the DEBUG (MainThread) [upb_lib.proto] data_received: 'PU89009E070CFFFFFFC9'

At this point, I’m going to assume the it’s something in that switch. Although I’ll double check the programming in UPStart. But I think a new switch plugged in somewhere else to test this is the ultimate answer.

Thanks for the help. It’s mostly a sanity check to make sure I wasn’t making a mistake. And unless I find something in UPStart, it’s probably not me.

[gwww (Glenn Waters)]

You’ve got me curious. The command that you sent is nothing I have seen before!

When I activate a link here is the message that I see:

PU 8904 C20909 20 FFFF81

C20909 is my network, source link, and dest link. 20 is activate link command. The rest does not matter for this discussion.

Yours…

PU 8900 9E070C FF FFFFC9

9E is your network, 07 your source link, and 0C the destination. The FF is supposed to be the a command, presumable activate in your case, which is 20. FF is not a recognized UPB command, hence the message is ignored by the library.

Any more that you can share?

[samgreco]

Well, that’s curious. I’ll need to get UPStart connected and check comms and programming.

This is a different link on the same switch:
DEBUG (MainThread) [upb_lib.proto] data_received: 'PU89009E0A0CFFFFFFC6

[samgreco]

So this led me down the path of assuming the switch was not programmed correctly. I wiped it (5-10-2) and rebuilt it from scratch. And Viola! all works exactly as expected. All 4 buttons are received and my HA automation and scene trigger as expected.

Thanks again Glenn.

[123 (Taras)]

The UPB integration’s documentation states that its “IoT Class” is “Local Polling”.

Does the integration do any periodic polling of all devices?

My impression is that it doesn’t but I’d like to confirm that.

[bbrendon]

Yea. That’s wrong. It only polls when HASS starts or when there is a service call to do it manually.

EDIT: I submitted a PR.

[gwww (Glenn Waters)]

Mostly. Slightly different wording. It polls whenever HASS connects to the PIM. This is different than when starting HASS since there are cases where the PIM will disconnect. In those cases periodic attempts to reconnect are made. Two specific cases are when the PIM is unplugged from the serial port and the second is when using a network PIM and a connection cannot be made to the PIM.

[123 (Taras)]

I noticed that even the ZigBee (ZHA) integration is listed as Local Polling. I guess if there’s even a limited possibility of the integration performing polling, the convention is to classify it as “Local Polling”.

It’s slightly misleading because, for example, the Philips Hue integration is “Local Polling” and it really polls periodically to ensure device states are synced with Home Assistant. Their API provides no means for a device to “publish” its state-changes (like a UPB device can do). So the three integrations, Hue, ZHA, and UPB, are all Local Polling but only Hue fits that description perfectly.

---

Anyway, the reason I asked is because I’m trying to get the bottom of an issue with disabling/re-enabling an entity. Go to Configuration > Entities, click the filter icon (upper right hand corner) and select “Show disabled entities”. Now click a UPB-based light, turn off Enable_entity, then click Update.

The light’s name will now be Unavailable and it will disappear from the States view and the auto-generated Lovelace UI. So far, everything works as one would expect of a disabled entity.

While still in the Entities page, click the disabled entity and re-enable it (don’t overlook to click Update). The entity’s name remains Unavailable and it’s still missing from the States page. That’s unexpected. However, wait about 20 seconds and its name will be restored and it will re-appear everywhere else as well. Note: if you refresh the web-page during this time period, it will not fix the problem.

This behavior can be duplicated in other integrations that use config-flow. However, the entity’s “restoration time” varies from mere seconds to about a minute (based on the handful of integrations I have tried). My theory was that this time period was due to some sort of polling activity performed by the integration itself.

In contrast, the MQTT integration’s IoT Class is Local Push. If you disable an auto-disovered MQTT entity, re-enabling it never restores it to full functionality. You have to restart Home Assistant. The same is true for any Helper (input_number, input_boolean, etc) created via the UI.

This is what led me to theorize that only “Local Polling” integrations eventually restore the re-enable entity due to periodic refreshing. Well, it was my theory until it was discredited by the fact the UPB integration performs no periodic polling. If the 20-second delay to restore the entity is not the integration’s doing then I don’t know what’s responsible for it.

tl;dr
Re-enabling a disabled entity produces inconsistent behavior that may even require restarting Home Assistant in order to truly re-enable the entity.