I’m currently just waiting on installation so that I can test against the hardware, it’s taking a while since I’m essentially rewiring everything, running new subpanels and pulling in additional power(upgrading from 200A to 800A).
Plan to do some arc-welding at home? 
Well I’m running a lot of new circuits and will have a total of 4 200A subpanels. One will be for high speed electric car chargers in the garage, one for the kitchen outlets/appliances, one for the basement and rest of the first floor and the other for the 2nd and 3rd floor(along with AC). Might also plug in some bitcoin miners. 
Good morning. Let me be upfront here - I am a vendor of UPB equipment - Web Mountain Technologies. We design, manufacture, and sell UPB products - our own and products from other UPB vendors. I hope it’s permissible for me to post this on this forum. Over the past year or so, I’ve had a few people ask about UPB support within Home Assistant. I’ve started looking into it and ran across this forum thread.
I’d like to offer my support to those of you on this post to see if I could help come up with a implementation to support UPB on Home Assistant. I can’t provide much in the way of Home Assistant support itself as we’ve never looked at it, but I can help with general knowledge on UPB, on the protocol, providing test products, providing a test bed, etc. I personally know enough about Python to be dangerous. We also make a UPB controller product based on the Beaglebone Black so we have quite a bit of experience with Linux as well.
If you’re interested, contact me and we’ll see what we can put together.
2 Likes
@webmtn Thanks. There is a discussion on cacoontech about how UPB is a dead. It’s sad really. It’s a superior system to many of the mainstream products. I think the problem is it is too expensive and most integrations of it are poorly done. Sadly, the best UPB experience I have had is with my janky component I wrote for HASS. It works better than two commercial solutions I previously used. I have never used your productions so you’re off the hook 
Any idea why the cost of UPB is so high? Is it PCS? The nature of the market? The manufactures trying to drive it into the ground?
In my opinion if PCS/SAI/HAI wanted to sell the product they would have made a UPB integration for HASS. Not doing so leaves a lot of money on the table or maybe they really are trying to kill it. HASS has the largest install base over any other product which could integrate with UPB. It would seem like a no-brainer for them to want to make an integration.
My winter-time project is to create a UPB to MQTT converter using Node-RED. The idea is that it will be easy to design and implement (and modify) and will work with anything that talks MQTT.
All my UPB devices are from Simply Automated (most affordable, at least here in Canada) and are mostly US1-40 and a handful of US2-40 models (configured as one upper rocker and four lower push-buttons).
I have two PIMs, one is connected to my home automation system running Premise. It has an excellent UPB driver that can auto-discover devices, list all of their programming (name, room, device-type, etc), control devices and scenes, signal strength, etc. This is my ‘gold standard’ and I compare whatever I create to how things work with Premise’s UPB driver. I should mention it uses Pulse Mode whereas as I’m using Message Mode so it’s not likely I’ll be able to implement some of the Premise driver’s features (or at least that’s my understanding).
The other PIM is connected to a Raspberry Pi hosting Node-RED. So far I can receive incoming UPB packets, validate them, decode them, and forward DeviceStateReports to MQTT. I can also send test packets to control a light. In other words I have just enough of it working to allow me to explore how the UPB commands work.
First thing I noticed is that if I send a GoTo command to a device, it does not report its status (the device is, in fact, configured to report its status but I think it only applies to when the switch is manually operated). So upon receiving GoTo 50, the device doesn’t automatically produce a DeviceStateReport (thereby disallowing the second PIM to be aware of the device’s new state).
If I follow up the Goto command with a ReportState command, that will cause the device to report its state. So to get what I want, it appears I have to follow up every GoTo (and StartFade and StopFade) with a ReportState so that other UPB listeners are apprised of the device’s new state. Is this typical?
I’ve observed similar behavior with scenes but specifically when turning off a scene (the devices do not report their state).
The most odd thing I’ve observed is when manually dimming/brightening a light. If the light is on at 50% and I manually dim it to 25%, the device’s first state report indicates the light’s level is zero. It is immediately followed by a second state report indicating the light is 25.
If the light is at 50% and I manually brighten it to 75%, the first state report indicates the level is 100%. The second one states 75%.
Why does it work this way? Why are their two state reports where the first one is incorrect and the second one is correct?
In response to bbrendon, this is why I’m responding on this post - I’m interested in working with whoever to develop an implementation for UPB with the Home Assistant ecosystem. I can provide products, test beds, general and detailed information, some development support, etc.
Now, to Taras. Also, to bbrendon and Taras, I do love reading on automation forums where people are doing projects like this. I’m amazed at what folks are doing on their own!
I don’t have any knowledge or experience with the Premise system, but I’d be surprised (and impressed) if they are using the Pulse mode in their implementation. About the only implementation I’ve seen that uses Pulse mode is the actual Upstart software. The advantage of Pulse mode is that it allows you to measure in real time noise and signal levels. When the PIM is in Pulse mode, it is generating idle reports back to the host that one can interpret for this information, but it’s pretty complex. There is also a mechanism to actually identify devices on the powerline, if you don’t know anything at all about what is out there. If Premise implemented it in this fashion, they basically created their own version of Upstart, or tied into Upstart somehow. Almost everyone I’ve seen implements their controller software using Message mode. And, in most cases, I would believe that Message mode is more than appropriate for a desired implementation.
Most implementations just export the UPE export file from Upstart into the controller to learn everything there is to know about the UPB network, rather than do an Upstart type of discovery. The UPE file includes all the information you were mentioning - names, rooms, type, scenes, etc. It doesn’t provide signal strengths or noise strengths but you can query for that information.
In terms of status reporting, practically no device reports status on its own. Most wall dimmers have an option where you can program the unit to send out a status message if the rocker has been activated manually. But, they won’t send out status on their own after they receive a command. There is one device - the SA UMI IO module that does send out status information on its own, but that’s the only one I can think of that does that.
Scene commands (also known as link commands) have the same issue. When a device receives a scene command, it does not report its status. And, think about this for a minute. What if you had 200 devices on one scene (it happens - I’ve seen a home with 200 switches in it and all respond to an ALL ON command)? If they all responded to receiving the All ON command, there would be 200 devices trying to respond at the same time. Obviously, you could figure out a way to avoid the collisions, but it would require some time to get all the responses.
Again, what I’ve seen implemented in the past on controllers is that the controller trying to keep up with the state of devices will receive a command on the powerline, has enough information to know what devices are impacted by that command, will make a leap of faith and assume that the device responded appropriately, go ahead and update the status table to reflect that, then verify by querying the device for status. If there are 200 devices, it will take an extended period of time to query all units and get updated status. And, you’re putting lots of traffic on the powerline.
So, yes, to get the state of a device after a command, you will need to query the device.
On the last issue where you are getting the two state reports, I’ve not seen that, and I’ll need to try that myself. Perhaps that is something specific to the SA devices. It might take me a couple of days to get to it, but I’ll try to test that soon.
1 Like
I didn’t read your entire post but the way I deal with keeping links and HASS in sync is to reference the upstart export file to find out what needs to be updated in HASS when a link is seen on the network.
Very good. That’s the way most controllers do it - export the UPE file into their controllers, then use that information to determine what devices are impacted by what commands, update their state based on the assumption they performed the command correctly, then verify by querying units. Some controllers just make the assumption and never query the units. Most of the time, it’s going to be correct.
Prepare to be surprised and impressed.
Premise provides a utility to view serial port traffic (Port Spy). The UPB PIM is connected to COM5 and here’s the Pulse Mode traffic it sees when I manually dim a US1-40.
Here is how Premise reports the PIM’s configuration. Note the following:
- In the Explorer pane, the devices labeled USQ, USQ2, USQ3, etc are automatically discovered devices (on startup and when the serial port is reset).
- In the Properties pane, the Pulse Strength property.
Here’s how a typical UPB device appears in Premise. Note it shows the full compliment of the device’s configuration parameters. The only thing it has mislabeled is LEDOffColor. My Simply Automated devices show a Blue indicator when off and Green when on. I can change the colors but Red is not one of them (I believe PCS devices support Red).
Because it enumerates all devices at startup, it also gets their Transmit and Receive Components. Here’s a sample of one device’s Receive Components. This one shows that when it receives LinkID 1 it should snap to 100%.
As an aside, this also explains one of my observations made during testing. When I transmit a link (a.k.a. scene) all devices comply but do not send status updates (as you’ve confirmed) yet Premise would know the meaning of that link and update the status of all associated UPB devices. At first I thought this was due to some kind of Pulse Mode magic but it’s not. I completely forgot that Premise has a copy of every device’s Transmit and Receive Components so it knows what to do when it sees a link-based command. So it’s like having a UPE file for reference, only better because there’s nothing to export/import.
I had posted the source code here, on Cocoontech, back in 2009 (many, many lines of C++). The driver’s author is only known to me by the moniker “georges” and it is dated 2005. For convenience, community member jameshillard re-posted the code in his GitHub repo here. There you will find a Word document explaining everything the driver does, down to the level of each property.
Here are highlights of it’s advanced features:
• Enumerate of the device network, and module instance creation
• Address conflict detection and resolution
• Automatic password discovery
• Routing of broadcast packets
• Duplicate message detection
• Network packet collision handling
• Idle time status polling
Now you know why I called it the “gold standard” because, as you inferred, it operates like UPstart therefore is “all seeing and all knowing”.
It appears I have two paths forward:
- Import a UPE file to know (at the very least) a link’s membership and how each member respond to it.
- Implement automatic discovery and keep a copy of the entire UPB network’s configuration.
I know HomeSeer, Charmed Quark Controller, and Elve (defunct) import the UPE file (for their respective UPB integrations). Not sure I want to swim against the current and try to implement automatic discovery … although it spares the end-user of the whole export/import rigmarole.
EDIT
Regarding the last issue, namely the doubled status reports, where the first one is incorrect (zero if you’re dimming and 100 if you’re brightening), I thought it might be due to some sort of weird interaction when there are two PIMs in operation (I know, kind of a stretch). I disconnected one of the PIMs but the behavior persisted.
In practice the effect is barely perceptible but it does exist. I have Premise communicating with Home Assistant via MQTT (i.e. Premise handles UPB and reports everything via MQTT which Home Assistant monitors and displays as lights or switches). When I manually dim a light that is already on, the first status report indicates a level of zero, and I can briefly observe that in Home Assistant’s UI: the light’s slider moves down to zero for a brief moment and then moves up to the value reported by the second status report. I can post samples of the Message Mode traffic if you think it will help.
Well, I am very surprised and I’m totally impressed! That took a tremendous amount of effort! Just understanding and interpreting the pulse mode messages is a big undertaking. I’ve done that manually in the past, troubleshooting issues, so I’m very appreciative of the amount of effort that went into this.
Did Premise open source this code or make it available for use in general? Is all the information you’ve shared from a Premise device, or do you have this code running on something else like a server, or something very light, such as a Raspberry Pi?
I’m going to try to duplicate your status reports this afternoon.
Premise Home Control (it’s full name) was home automation software developed by former Microsoft employees and professional systems integrators, designed for use by professional systems integrators (and home automation enthusiasts). The company, Premise Systems, started in 1998 then, a few years later, was bought by Lantronix, then by Motorola which, shortly thereafter, discontinued the product in 2006. They did not open-source the code but they did disable the product’s license control so that anyone could continue to use it for free. I first became aware of it in 2007 and have been using it since 2008.
If memory serves me correctly, the UPB driver, and its source-code, was published on Premise’s web-site (in their community forum). Motorola eventually decommissioned that site so I preserved a lot of its content in Cocoontech (including all the UPB software).
Premise runs on a Windows PC exclusively (Premise’s demise predates the Raspberry Pi by 6 years). It was designed to run on the PCs of its day, so that’s over 15 years ago; it flies on just about anything you would use today. For many years I had it running just fine with a VIA Nano CPU which is very pokey. Nowadays I have it running on a 4-year old HP Stream Mini equipped with an Intel Celeron 2957U.
I continue to use Premise to automate my home. It communicates with Home Assistant via MQTT. Home Assistant provides a modern user-interface and functionality that did not exist back in Premise’s heyday, like HomeKit integration (among many other things).
Anyway, it serves as a rock-solid UPB driver for Home Assistant but it would be nice to have that functionality as an independent service.
Ok, as always, this is going to be a bit more complicated that I originally thought to test. I just played with it, but the tools I’m using automatically account for multiple transmissions, plus I was sending the commands manually, so there was a lot of time between when I sent the dimming command and when I sent the request for status. The status reports I’m seeing are exactly what I would expect to see. So, I’m going to have to write some kind of script it order to more closely duplicate what you’re doing.
Rather than doing that right now, can I request that you post some samples of the Message mode traffic you’re seeing, please? I’m pretty sure I already know the answer to why you’re seeing two status reports, but at the moment, I don’t have a good explanation why the first status report shows the level going to 0 or 100. Seeing the message mode commands might help with this.
Thanks.
For this test, device 9 is initially off and I press and hold its rocker button to turn it on to a desired level (i.e. not to maximum brightness).
Device 9 is configured to report its state and to send multiple UPB messages (i.e. multiple consecutive transmissions of the same information).
My Node-RED flow is designed to “de-duplicate” these repeated UPB messages (it keeps the zeroth one of the sequence and discards the others). After the redundant instances are filtered out, I would expect to see just one 0x86 report from device 9 indicating its new brightness level. However, I see two and they contain different values for the level.
The result of this test produces two distinct 0x86 reports:
PU080C960009866463
PU080C9600098626A1
You can already see that the first one contains a level of 0x64 = 100 whereas the second one has 0x26 = 38 (the true level).
Here are the two messages after they’ve been processed by the Node-RED flow:
If I now tap the bottom half of the rocker, the device turns off and it produces only one 0x86 report.
PU080C9600098600C7
Tapping the top half of the rocker turns it on. The device is configured to turn on to its previous level and it produces only one 0x86 report. It resumes a level of 0x26 = 38.
PU080C9600098626A1
Now I press and hold the top half of the rocker to brighten the light. It generates two 0x86 reports. The first one indicates a level of 100 and the second one is 76.
PU080C960009866463
PU080C960009864C7B
Finally, I press and hold the bottom half of the rocker to dim the light. It generates two 0x86 reports. The first one indicates a level of 0 and the second one is 38.
PU080C9600098600C7
PU080C9600098626A1
In a nutshell, the ‘double-reporting’ behavior appears when one presses and holds the rocker button.
Ok, this is what I believe is going on. First, the process of dimming a light switch manually involves two steps or commands - the initial press and hold then the release. There is a UPB command generated for both of those actions (stays within the unit, but there are commands). I’m betting that the way the feature that automatically generates a status response based on manual activation of the rocker is that it generates the status report based on the internal commands sent. I haven’t tried to prove it, but I’m betting this is the case.
There are four actions a user can take with a rocker - single tap, double tap, press and hold, release. A single tap only causes one command to be sent - probably an Activate or deactivate, depending on how you have it programmed. Double tap is the same. However, when you press and hold, you have to have a release - two commands.
For the press and hold, a FADE START command is generated. From the UPB System Description document:
The Fade Start Command
The “Fade Start” Command is used to request the receiving dimming-type device or a group of “linked” Device Components on dimming-type devices to fade to a specified Level at a specified Rate. Non-dimming type devices shall ignore the “Fade Start” Command. The “Fade Start” Command has the Message Data ID of 0x23 and has two different syntaxes based on how it is packaged. The “Fade Start” Command can either be packaged in a Link Packet to affect a group of “linked” Device Components or it can be packaged in a Direct Packet to affect an individual device.
The message syntax for the “Fade Start” Command packaged in a Direct Packet is designed to account for multiple-channel devices and is as follows:
MDID Arg1 Arg2 Arg3
0x23 LL [RR] [CC]
Where LL is the specified Level (0x00 – 0x64) and [RR] is the optional specified Rate (0x00 – 0xFF) and [CC] is the optional specified Channel (0x00 – 0xFF). When the addressed UPB device receives this command, it shall set the specified Channel to the specified Level at the specified Rate. If the Channel is not specified in the command then all of the device’s channels shall be affected. If the Rate is not specified in the command then each device’s Default Rate shall be used instead.
While again I haven’t proven this, I’m betting that the dimmer is programmed that when you press the down side of the rocker, the level in the Fade Start command is set to “0” and if you press the up side of the rocker, the level in the command is set to “100”. Would make perfect sense.
Then, when you release the rocker, the unit sends the FADE STOP command. Again, from the UPB System Description document:
The Fade Stop Command
The “Fade Stop” Command is used to request the receiving dimming-type device or a group of “linked” Device Components on dimming-type devices to stop fading and stay at their current Level. The “Fade Stop” Command can either be packaged in a Link Packet to affect a group of “linked” Device Components or it can be packaged in a Direct Packet to affect an individual device. The “Fade Stop” Command has the Message Data ID of 0x24 and has the following syntax:
MDID
0x24
When the addressed UPB device receives this command, it shall stop any fading operation that is currently going on.
So, I believe this is why you are getting two status responses - there were two commands generated within the unit and with the option selected within UPstart for the device to automatically send status responses upon rocker activation, it generates the two status responses based on the two commands.
You don’t see the two commands on the powerline, because they are contained within the dimmer. It would be interesting to select the option in Upstart that Rocker 1 Transmits, and then you would probably see those two commands show up on the Powerline and within Upstart.
The one response that is confusing to me is the fact that the first status report shows the level as 0 or 100, depending on which direction you’re dimming. I would have guessed that you would have received some intermediate value between the level it started at and the ending value. I’ve seen this happen when we’ve played with changing the intensity value and immediately polled for status - if the dimming is a little slower, issuing the status request will catch it before it gets to its final value and it reports something in between. We typically put in a small delay when polling to allow the unit to get to where it needs to be before querying it.
So, I don’t understand why it would report the level it’s going to rather than the level it’s currently at unless the way this is implemented within the dimmer is that a status report generated upon manual activation just reads the values from the Fade Start command or the level register within the dimmer is temporarily set to the final value and isn’t rewritten until the Fade Stop command is received (this last one would be my suspicion). I need to read through the FADE START process doc again and think it through. But, no matter what, the level of the first status report is not what you want.
But, this is probably why you’re getting two status responses and probably why the first one shows a level of 0 or 100, but the second one is correct.
A disclaimer. I could try to test this using one of my SW7 switches but I think you said you had SA switches. There might be a slight difference between the two and I don’t have any recent SA switches to test with. While these are system level actions and they should be the same, I’d really want to see the two side by side to confirm. And, my apologies - I keep saying “I believe” or “I bet” - I don’t have actual proof. To get actual proof of these would entail quite a bit of work on my part - someone would probably have to go back into the source firmware for the switches to confirm and that would be hard to accomplish. But, I believe the explanation makes sense and is what is happening. This particular part of the firmware was written many years ago. And, I’m not sure this is necessary - I feel pretty confident this is the reason for the two responses and their levels.
Just tried to reply to 123 Taras but the system won’t allow a “new” user to post more than 3 times on a particular topic. While I’m not a new user, it has been quite a while since I spent much time on Cocoontech. Here’s what I wanted to say:
sorry for the delay in responding - I’ve been traveling a lot over the holidays.
I’m trying to put myself in the shoes of the original designers but this would seem to make some sense for the FADE START command. The issue there is that when you want to start fading (dimming up or dimming down), you would have to tell the device or network which direction you want to dim - 0 or 100. But, it appears that this value is also written into the level register overwriting the actual level. I don’t know if that was intentional or by accident.
I don’t know what you’re trying to accomplish or how you’re writing you software but it would seem that one option would be to not worry about the first report - don’t worry about ignoring it - shouldn’t your status be overwritten the minute you “release” the rocker and get the second status report? That’s typically going to be done within a few seconds and status should get back in sync again?
I know of one software controller implementation that watches for status commands such as this and updates status internally. I hadn’t paid this close to attention to it, but I bet if I went back and looked at their logs, we’d see that first status message reporting the 0 or 100 level, but it would immediately have been overwritten by the second status message generated by the FADE STOP command. In this case, I’ll bet no one had even noticed the first status message.
Anyway, I’m very impressed that you found this issue and how in depth you’re getting in the UPB protocol and operation. I’ll be very interested in following your progress. Please keep this post updated on your efforts.
Thanks for the explanation. The upshot is that the two messages are sent because there are two rocker events: ‘press and hold’ followed by ‘release’.
For ‘press and hold’ it reports 0 for dimming and 100 for brightening. It’s as if it is attempting to indicate the ‘direction of travel’. What remains unclear is why UPB’s designers believed it was necessary to report it. After all, it is exactly the same information the device reports when someone just turned it on or off.
In other words, upon receiving a status of 100 or 0 you can’t assume it means the device was turned on or off. It may just be indicating the ‘direction of travel’. You’re obliged to wait and see if there’s a second status report.
- If there is, then the second should be used and first one ignored.
- If there isn’t, then the first one should be used.
The potential for receiving ‘two-part’ status messages seems to needlessly complicate how all status messages must be handled.
Just an update, I now have a test UPB setup @webmtn dropped off who is local to where I live so that I can start implementing the home-assistant module. My house renovation project has been taking way longer than originally expected so I didn’t get any of the UPB switches actually installed in my house yet. Anyways hopefully my schedule doesn’t get too much more crazy so that I actually get some time to implement this(I’m effectively CTO for 3 different companies at the moment so I’ve been juggling a bunch of projects).
Glad to hear you’re still in the game.
Hopefully some of the recent test results and observations posted above will help jump-start your project. In a nutshell:
- Running the PIM in Pulse Mode provides access to more information (it’s the mode Upstart uses). However, it requires far more programming effort to decode/encode the packets in this mode. Running it in Message Mode allows for simpler packet-decoding but you lose the ability to access advanced features like determining pulse strength, the network’s configuration, etc.
- Performing a ‘press and hold’ on the switch’s rocker will generate two UPB messages where the first one is completely misleading. In practice, the first message causes the UI to momentarily show a dimmer switch is fully on (or off) and then the second message shows its true brightness level.
- To properly support links (scenes), the integration will need access to the network’s configuration (i.e. to determine which devices respond to a given link). If using Message Mode, the integration will need to import Upstart’s export file (there is an option to export the configuration in JSON format). In Pulse Mode you’re able to perform a discovery and maintain your own record of the network’s configuration.
I just stumbled across this thread. I started implementing a library to talk to the PIM. The goal is for HA integration.
So far I have it communicating with the PIM, importing a UPE file, handling activate and deactivate commands.
The python library I’m writing is based on the ElkM1 python library I wrote. I did that because it has async IO – so necessary for working with HA. My github id is gwww.
Nothing uploaded to git yet but I could put something up. It is in a VERY early stage but the structure is there for IO, receiving and decoding message, and the ability to send messages (but MUCH more to do there).
I have mostly SA devices. Two SA serial PIMs, one of them connected to my MacBook Pro with a serial to USB device.
I saw this thread over a year ago, didn’t realize people has reignited the discussion. I’ll upload stuff to git today and post.
I came across this thread as I was googling for more info on the protocol. In particular the status reports just show in the docs that they return lots of values. But no description of what the values are, trying to figure out how to use them. I have not explored much yet but suspect the value returned is the dim level. Here is one example message:
message received: update 'PU0805C200098600A2'
Lnk 0 Repeater 0 Len 8 Ack 0 Transmit 1 Seq 1
NID 194 Dst 0 Src 9 Cmd 0x86
How can I help?
As I understand it running in message mode is the right thing to do. See this application note from PCS Lighting: http://www.pcslighting.com/resources/PulseWorx/Software/PWX_126_PIM_Apps.pdf. Page 1, Basic Need to Know section, paragraph 2.
Until I read that I considered using pulse mode and have not explored pulse mode further.