I’m using this thread like a diary to document my project. I encourage anyone with an interest, or expertise, in UPB to jump in and help out.
This winter’s project is to create a UPB to MQTT converter (upb2mqtt). Any home automation software than supports MQTT will be able to take advantage of it. For example, Home Assistant’s MQTT Light integration will be able to use it.
UPB’s computer interface device is called a PIM (Powerline Interface module). I have one connected via a USB-RS232 converter to a Raspberry Pi 3B hosting Node-Red and an MQTT Broker. A PIM has two modes of operation:
In this mode, it reports all UPB activity. However, the information, although very comprehensive, is reported as tiny packets. The burden of assembling these packets into meaningful UPB messages is left to the software developer.
In this mode, it reports a subset of all UPB activity. Only complete UPB messages are reported. This mode makes the software developer’s life easier. Most UPB integrations I’ve found use Message Mode (DaAwesomeP’s UPB for node-js, cvanorman’s UPB for openHAB, and Jason Sharpee’s UPB for Pytomation).
I currently use Premise which has an excellent UPB integration that uses Pulse Mode. It serves as a reference for comparing the differences between what can be accomplished using Pulse versus Message modes (a little foreshadowing here).
The first drawback of Message Mode that I’ve encountered is one involving scenes (a.k.a. links):
Scene members do not report status upon deactivation.
- Upon activating a scene (link), ReportState commands are sent to all scene members.
- They reply with their current state via a DeviceStateReport.
- Upon deactivating a scene (link), no ReportState commands are sent so none of the scene members report their current state.
For example, assume a scene simply turns on/off three devices.
- When the scene is activated, each scene member will report its current state (on).
- When the scene is deactivated, each scene member will NOT report its current state (off).
This is an annoying deficiency (for obvious reasons) and DaAwesomeP mentioned it in this post:
whenever a scene/link change is sent out by a switch, the switches affected by the scene don’t broadcast their states; this is a limitation of UPB
However, I believe that statement requires qualification; it is a limitation of UPB’s Message Mode. The limitation doesn’t appear in Premise’s UPB integration (which uses Pulse Mode). When I deactivate a scene, the new status of all scene members, in Premise, is updated. So at first glance, it appears there’s some kind of enhanced scene reporting mechanism available in Pulse Mode that doesn’t exist in Message Mode. However, the programming challenge of using Pulse Mode is a bit daunting to me.
Here’s another behavioral quirk that, as far as my tests show, occurs in both Message and Pulse modes.
When manually dimming/brightening a switch (that is already on and configured to report its state), it sends two DeviceStateReports:
- First Report: False values
- If you are increasing its brightness, it reports its level is 100 (i.e. turned on).
- If you are decreasing its brightness, it reports its level is 0 (i.e. turned off).
- Second Report: True values
- It reports its actual, true level.
The purpose of the first report is unclear to me. It looks exactly like the report generated when a switch is turned on or off but that’s not what’s actually happening (it’s level is simply changing to a value between 0 and 100). The second report is correct.
- The device does not issue an initial false report if it is initially off and you manually turn it on or if it is initially on and you turn it off.
- The false initial report only occurs when the light is already on and then you manually dim/brighten it.
This quirk produces an undesirable cosmetic defect. For example, if you manually dim a switch from 75 to 50, in Home Assistant the switch’s slider will initially, and very briefly, move from the three-quarter position to zero before moving to the halfway position. That’s because it is responding to the first report (level is 0) before it responds to the second report (level is 50). This can escalate from being a cosmetic defect to a functional one if you have automations triggered by the switch’s state changing to on or, more significantly, to off.
I’ve been thinking of a mechanism (involving the use of a queue) to discard the first report if it is immediately followed by a second one. However, the darn thing will have to be foolproof otherwise it may discard legitimate reports of a switch turning on or off.
Scenes are stunted in Message Mode and switches will briefly report invalid states when operated manually. Using Pulse Mode should fix scenes but at the cost of development complexity.
My first attempt to transmit a UPB message was a failure. It not only failed to control the switch, it locked up the serial port node and prevented the flow from receiving anything from the PIM. Deleting and re-adding the serial port node cleared it up (but that’s no way to run a railroad). The UPB message was valid because it was generated by the message-building utility (supplied by the manufacturer). Clearly, there’s something important I’ve missed and will take more time than anticipated. Hopefully, not longer than one winter season …