+1 for UPB Support. Thanks
I’m going to mention everyone that has hinted an interest in UPB…
@rismoney @llothos @eric24 @briodo @GraysonPeddie @jeremyowens @elcano @dramamoose @jasv
There have been people with interest in UPB since May of 2015 and here we are, over two years later and nothing in sight. This is basically an attempt to restart a conversation about getting this moving 
.
What do you guys think about getting our money together and hiring someone? Either we pay them in money or UPB hardware or a combination of the two.
I’m not sure the best way to organize the payment. Maybe gofundme.com? Maybe the honor system?
As for finding a developer. Maybe we can advertise on discord. Or maybe someone will chime in here?
If you’re interested, speak up with how you can contribute or other constructive thoughts are welcome!
I am definitely on board for payment to someone to do the work. Not sure what I have to offer, I might have some simply automated switches, a couple of omnistats I’m not using. But if cash is desired that’s fine and easier overall to deal with than shipping random parts. Not sure what it will take.
In the time I’ve spent trying to understand how to approach this project (which admittedly has only been several hours), I have not yet gotten a clear idea of exactly how to do it. I’m sure I could, given the time, but there aren’t enough hours in the day. That said, I’d be very interested in working with someone that has direct experience with doing this for HA, and paying them for their time. I would think the ideal person is someone that’s already on this forum, so if that person is out there, make an offer for the project or for an hourly rate, and let’s make it happen!
To be clear, what I want is a “native” solution, not one that uses shell scripts to execute UPB commands via some third-party command line tool. It should also be bidirectional, for lighting and switch control to the UPB devices and feedback so that changes to UPB devices can update HA and trigger events. This functionality is similar to Z-Wave, although UPB should be much simpler to implement (among other things, there is less variety in UPB devices). I’ve done significant research on that front, so I can certainly contribute to the project.
The alternative would be a guide on how to do this. I’ve read everything I could find about adding a platform (which is what I think we’re talking about here) to HA, but I still feel like there are too many gaps in that information for me to formulate a design approach. I know it can be done, but again, I have limited time to devote to this.
Well, sounds like we need someone more technical and knowledgeable with python/hass to push this along. I suggest you guys help try recruit someone 
I posted to Discord and a project recruiting website but haven’t gotten anywhere yet.
In case a developer is wondering what UPB is…
It’s “mostly” used for lighting control. This is acheived by a network that runs over the power wires in a house. The physical devices it consists of are “usually” wall switches, light modules (a box with a plug and outlet on it to control a lamp or appliance). The bridge between the computer and power line is a box (aka PIM) with a plug and serial port. The serial port connects to your computer.
The serial port spits out what is happening on the UPB network and also will take commands to control devices (switches and lamp modules). Each device has an ID and a on/off or light level value.
That’s the quick explanation. It can get more involved with groupings, links, and virtual devices, but if those basic things were integrated and working, I bet someone would pick up and expand on it.
Somewhat hackey solution but it works. More info here. I’ll probably just update the dev thread in the future if there is anything more to say.
I’m very interested in UPB support. I have a ton of old device that I’m not using, but now that I’m getting into Hassio, I would like to incorporate into my system. I’m not a strong developer, but I’m just starting to read through the docs and api’s to see if I can figure things out. Big mountain to climb for me.
1 Like
Try out what I have so far and see where you end up. I’m working on a solution to read from the lights and get the data into hass but it’s been tough. Programming in the bowels of hass is much more than basic scripting.
I know we still don’t have a great implementation of UPB but I did update mine to add flash/blink support. As a reminder, I have it working two-way, but it requires another daemon I can PM you. It’s super-hackish (coding wise) but actually works very well.
https://github.com/bbrendon/hass/tree/master/custom_components
I’m looking into building a UPB system for use with home-assistant using pyserial-asyncio, the protocol seems to be fairly straight forward although probably somewhat time consuming to implement. The pytomation and openhab modules seem to provide a good protocol implementation reference as well. I’ll probably order some sample hardware to test with soon but if someone has a UPB system I can test against remotely that would probably speed things up. I’m a fairly experienced python developer and have written a number of serial protocol modules in python for other projects, I’ve currently written one native home-assistant module so far for a relay controller which uses a serial over tcp protocol.
1 Like
I have several UPB dimmers (mostly Simply Automated US11-40 and a few US2-40) … but I’m not comfortable providing someone with remote access to my home automation system. However, I would be willing to test whatever you have to offer.
I currently use another home automation software (Premise) to interface with UPB lighting. Premise’s UPB driver is excellent. I have the source code (bajillion lines of C++) but a great deal of it involves managing the interface with Premise so I’m not sure it would be of much use to you. Anyhow, here are a few things the driver can do:
-
Supports automatic discovery of devices. By this I mean it not only detects the device’s presence but also the device’s model. For example, a US2-40 can be outfitted with one of 13 different faceplates which allow it to have from 1 to 4 rocker buttons or up to 8 buttons. Naturally, this impacts how the device is represented in the home automation software.
-
Supports the transmission of links. UPB links are scenes; a single command can activate multiple devices (a very efficient way to turn a large group of devices on/off). Each device can be programmed to respond to the link in the same way or uniquely.
-
Reports all of a device’s properties such as device name, room name, network id, load type (dimmer or switch), LED color, manufacturer, model, firmware version, fade rate, etc.
-
Supports programming UPB devices such as fade-rate, LED color, load type, if it reports its state-changes when manually operated, how many times it transmits a command, etc. To be fair, I don’t use this capability and wouldn’t expect to find it in other drivers. I prefer to use UpStart to program my UPB devices.
Here’s a screenshot of the details provided by Premise’s UPB driver. I think it gives you a rough idea of what all that C++ code under the hood is doing in order to provide a live UI for the device. This is for a US2-40 configured for one rocker switch on its upper half (represented as TopUpper and BottomUpper) and four buttons on its lower half (Button1 to Button4).
For starters, I would be happy with the ability to have a UPB component support sending/receiving UPB commands and links. Automatic discovery of devices would be a bonus.
That would be useful, the more reference source code the better as I like to verify protocol implementation logic against other implementations when writing serial drivers.
OK, I’ll have to find the soft-copy first. I know where the hard-copy version is (dog-eared spiral-bound book of 3000+ lines of code) but that’s a bit awkward to share with you.
I did find this which seems to be a UPB driver for premise(not sure if it’s the same one you have). The code seems to be more complete than any of the other reference code I’ve come across.
That’s the one. Sheesh, I forgot I posted it there! Ten years ago! Time really does fly.
Cool, I went ahead and uploaded it here to make it easier to search/view. Once I get some sample hardware to test against I should be able to start writing a python module for it.
I suggest purchasing one of Simply Automated’s starter kits. It’s more cost-effective than buying the items separately. It includes:
- 2 x US11-40-W single white rocker dimmer/switch
- 1 x US2-40 universal dimmer/switches
- 1 x ZS25O-W rocker+4 oval button face plate installed
- 1 x UMC-DB9-W Serial CIM Interface
- 1 x ZPCI-W Wire-In Phase Coupler
The interface module is available with either an RS-232 serial interface (Serial CIM) or USB interface (USB CIM). I have the serial version and use it with a RS-232 to USB converter.
FWIW, I have a phase coupler and installing it has been on my ‘to-do’ list for years. The Upstart software can tell you the signal strength at the device’s end. So far, I’ve always seen strong signals for all devices in my home even the ones located on the opposite phase from the one the CIM is plugged into. Based on that, I haven’t found a pressing need to install the phase coupler. However, YMMV.
Do you have a store link for that?
I cannot vouch for this supplier because I’ve never done business with them (seem to offer an odd mix of products). However, this is an attractive price for what appears to be the starter kit with the serial CIM (you’ll need a serial-to-USB converter).
If you need a Canadian supplier, I’ve purchased from Aartech.ca and they provide great service. Here’s the starter kit with serial CIM (they also offer the USB version). Prices are, of course, in Canadian currency.
Here’s Simply Automated’s description of the (serial) starter kit:
http://www.simply-automated.com/products/items/DKIT-serial_cim_wire-in.php
PCS also manufactures UPB lighting (I believe they invented it) but I find their products to be more expensive. http://www.pcslighting.com/
Right now I’m trying to decide between going with a UPB system or Insteon system, they both seem to use a powerline type protocol for communications(although insteon seems to also use RF as a backup). Is anyone familiar with the advantages of one over the other?