This project is for the likely-very-small Venn Diagram of People Who Use UPB Home Automation and People Who Are Makers. Might only be me.
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
UPBDescriptionv1.4.pdfFrom the designers of the protocol itself, more than you ever wanted to know. Handy when parsing UPB commands though.Adobe Portable Document Format - 432.38 kB - 06/03/2026 at 19:30 |
|
|
PIMDescriptionV1.7.pdfFrom the designers of the protocol and hardware itself, and has the bit about the magic charge pump to make the RS232 interface work with microcontrollers.Adobe Portable Document Format - 273.77 kB - 06/03/2026 at 19:30 |
|
|
IMG_3901a.JPGThis one is my development rig. The two DB9 ports mean it can do pass-through to watch what UPStart is saying to the PIM, has a coupla toggle switches to change options (or just say "Mode Execute Ready") and blinkenlights to monitor line and WiFi traffic, etc. You'd not need one of these, just a demo of the depth of the rabbit hole gone down to do the PIM emulation in particular.JPEG Image - 357.92 kB - 06/03/2026 at 18:58 |
|
|
IMG_3902a.JPGBridge from WiFi to line, using SAI PIM.JPEG Image - 346.77 kB - 06/03/2026 at 18:23 |
|
|
IMG_3916a.JPGBridge from WiFi to line, using SAI PIM.JPEG Image - 233.09 kB - 06/03/2026 at 18:23 |
|
|
The devices can emulate either of two Simply Automated dimmers, the US140T single-channel or US2240 dual channel.
I most often use use the '140; its feature set works nicely for window shades, for instance, so that it receives links to set the dim level == open/closure level. Since there's the WUPB bridge, this means my existing wall switches can send to the shades and don't know any better.
The '140 also works well for motion/occupancy sensors, so that it *sends* links when it senses, to the existing light switches. These have timer links that go off after a short delay, but the occupancies reset the timer each time they sense a person (and occasionally a cat.) Due to the aforementioned feline helpers, the occupancies also have links to disable them, so they're on schedules that turn them on after sunset until we go to bed, and then turn them off at sunrise as they aren't needed when there's natural light.
Due to the size of my UPB deployment (several dozen line devices), I set up a separate WiFI network on its own subnet and VLAN. Each device uses a static IP on that subnet matching its UPB device ID (that is, UPB device 12 uses IP address my.sub.net.12.) I found it much easier to keep the static IP to device mapping than to mess with DHCP; this way if you have connectivity issues you can just ping your.sub.net.deviceid and know you should be getting that target.
For smaller deployment or to start with, you could just assign your devices and bridge static IP's on your existing subnet. Also unless you are a network admin extraordinaire (I am not!) I do not recommend VLAN's.
I use an RPi for MQTT because I had an RPi running other stuff, so it was no additional hassle. There is an MQTT broker for ESP32, but it uses ESP-IDF, not the Arduino IDE, so I don't know anything about it. Maybe you have one already for your home automation, otherwise, setting that up is left as the proverbial exercise to the reader.
The MQTT topic is "home/UPBtraffic" and can be changed in the ESP32UPBsecrets.h if that annoys you.
Images are an in-wall occupancy sensor next to a factory Simply Automated US140, a motor unit that sits on the end of a window shade, and a coupla external occupancy sensors, one using an AM312 IR sensor, the other using an LD2410 radar sensor, and finally the insides of the shade motor unit.
In other words, all COTS hardware with an ESP32 inside. Lot of 3D printed bits, some magic indistinguishable from technology, but all Make-able.
For all sketches, edit ESP32UPBsecrets.h as to your specific network details (IP addresses, WiFi connection). You'll also need an MQTT server, even just an RPi or ESP32.
First, the bridge.
Parts:
RS232 PIM with a DB9 (either SAI or PCS. HAI would require different cable for its RJ14)
ESP32S, specifically, aka "ESP32-WROOM", *not* ESP32-S3 or ESP32C or any other ESP32-letter. I've used both the 38-pin and the D1 Mini-32 type (not the 8266, but the ESP32). The 30-pin on a breakout board can be handy too
Watch the breakout boards as some LOOK like they're Arduino form factor but aren't quite, so they don't fit neatly into Arduino cases.
TTL-to-RS232 converter like https://www.amazon.com/Anmbest-Converter-Connector-Raspberry-Microcontrollers/dp/B07LBDZ9WG (that's an example, never actually bought that particular one I don't think). Note that the PIM requires DTR to be high (see PIMDescriptionV1.7.pdf actual page 19). This will require some detective work with a voltmeter and a bodge wire on your adapter. I'll attach some pictures of my examples. I recommend DB9M, either to attach directly to the PIM or use a short DB9 M-F cable. Mixing and matching types on RS232 can lead to confusion as to Tx and Rx pins.
Handful of Dupont jumper cables. Any real Arduino nerd will have a pile.
USB power supply, as used for phone charger
Short USB cable from the charger to whatever USB plug the ESP32 has (micro USB, USB-C)
Assembly:
Wire DB9 converter to 3v3 and ground on ESP32, Rx to D19, Tx to D18. If your particular board doesn't have those or you REALLY want to change it you can just change the sketch.
Software:
Open and upload wupb_bridge_13
Watch serial monitor for complaints. at default DEBUG_LEVEL 1 you should see UPB line traffic (like hit a light switch so it sends data) as Line -> MQTT 12345678...
If no traffic, swap 18 and 19 in sketch or your wiring, re-upload. Happens to me all the time and I've been doing this for years.
I recommend once it shows data, to disconnect it from the computer and put it aside for a minute. with many ESP32's on the desk it's easy to get them confused and upload a sketch to the wrong unit.
Parts:
Second ESP32S as above
Momentary pushbutton switch
Assembly:
Switch on pin 18 and ground
Software:
Upload set_eeprom_140t_new_device. this sets the EEPROM as if it were an SAI US140-T, as device 254 (unprogrammed)
Upload demo_device. this is the actual code for the US140, and the demo is the bare minimum code required to act as a WUPB device. It will turn the onboard LED on and off as the load.
Verify it has loaded by opening http://my.sub.net.254 in your browser. It should have a web page, albeit with a message at the bottom about "error 255". Clicking Clear error will remove that.
Clicking "On" and "Off" under "Currently (whichever)" should turn the LED on and off.
Clicking "Enter setup mode" should blink the LED, as should pressing the pushbutton for about five seconds.
Parts:
third ESP32S as above
Upload PIM_emulator_for_WUPB_programming_1
Do not open the serial monitor as UPStart will need to use that port. Launch UPStart. Disconnect it from existing PIM, and configure UPStart to use whatever port (e.g. COM4, /dev/ttyS0, whatever) to which the PIM emulator was just uploaded.
To add device to network, put device into setup mode. Either launch its web interface as above and choose "enter setup mode", or press and hold the momentary switch on pin 18 for about five seconds. The onboard LED should start blinking.Add the device in UPStart. It may fail to find the module in setup the first time; Retry should resolve this. UPStart's serial interface can be persnickety.
Assuming it added successfully, the device can be turned on and off from UPStart, programmed to respond to links, whatever.
Create an account to leave a comment. Already have an account? Log In.
Become a member to follow this project and never miss any updates
mcThings
Sylwester
Roman V