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.
Code uploaded to git. Hereā¦ https://github.com/gwww/upb
This is the python library only. No Home Assistant integration started yet.