UPB lighting

tofof · July 8, 2025, 5:44pm

Is the heartbeat expected to constantly buzz both the pim and other devices in the house with communications? I have disabled both the ‘automatically add new devices’ and the ‘poll for state changes’ options hoping they were the problem and they aren’t. I’ve restarted the UPB integration afterward and even rebooted the machine and no help.

I just rebuilt my HA box after my SD card died, so it’s possible I was on an un-updated version of UPB integration – it’s been working fine for me for years, since at least 2023 when we got the rate setting bug I diagnosed for you fixed. The buzzing of UPB signals on my lights in my study every several minutes is absolutely not something that happened for those intervening years and has only just started since getting my new box up and running again. To be clear, I restored my old config from backup so everything should be identical, which is why I suspect an unapplied update on the prior machine vs the fully updated one here, particularly with the mention of adding heartbeat.

Nothing is touching the values of these lights; there is no legitimate traffic. The brightness on the lights is not being changed by any of the phantom traffic. There’s a single switch in the room that can adjust them that is not being used, and there’s a script at 0600 and at 1900 to dim them up or down slowly. The HA logbook shows no entries for the devices except hours ago.

Again, this configuration was stable for years without this behavior so it’s not something that’s changed in the module programming themselves – it’s been similar years since I’ve gotten upstart out and done anything to any modules.

I get 2 buzzes (I have 2 dimmer modules, so I suspect once on each, but have in no way confirmed this because they’re imposible to physically reach without moving huge 400 lb cabinets). It’s possible other modules are being ping’d too, but none would be audible in this room. (E.g. the ceiling light to this room has a hardwired module but it is much less audible in regular operation, so I would probably not hear it if it was being touched). While the PIM was in this room it was buzzing much more frequently than just the times that my dimmers in here responded, so I suspect it is looping through other devices, but I’ve moved it to where I cannot hear it.

12:45:15 appliance dimmer buzz (1/2?)
12:45:17 appliance dimmer buzz (2/2?)
12:47:25 appliance? dimmer buzz (one only, fainter, MIGHT be ceiling light)
(might have failed to notice some buzzes here)
12:59:58 appliance dimmer buzz (1/2?)
13:00:00 appliance dimmer buzz (2/2)
13:06:08 appliance dimmer buzz
13:06:10 hard to tell, might have been a second buzz
13:08:13 appliance dimmer buzz (1/2)
13:08:17 appliance dimmer buzz (2/2)
13:10:18 appliance dimmer buzz (1/2)
13:10:22 appliance dimmer buzz (2/2)
13:12:21 appliance dimmer buzz (1/2)
13:12:25 appliance dimmer buzz (2/2)
13:14:27 appliance dimmer buzz (1/2)
13:14:32 appliance dimmer buzz (2/2)
13:16:30 appliance dimmer buzz (1/2)
13:16:35 appliance dimmer buzz (2/2)
13:18:37 appliance dimmer buzz (1/2)
13:18:41 appliance dimmer buzz (2/2)
13:20:44 appliance dimmer buzz (1/2)
13:20:50 appliance dimmer buzz (2/2)

LOGS ok looks like problems here…

Warning 1 from UPB

Logger: upb_lib.upb
Source: runner.py:154
First occurred: 12:17:32 PM (650 occurrences)
Last logged: 1:21:30 PM

Timeout communicating with UPB device: Study Sunset C (99_5_0)
Timeout communicating with UPB device: Study Sunset D (99_6_0)
Timeout communicating with UPB device: Christmas Tree (LR) (99_1_0)
Timeout communicating with UPB device: Christmas Decorations (BR) (99_2_0)
Timeout communicating with UPB device: Dev’s room Lamp Module (99_8_0)

Warning 2 from UPB

Logger: upb_lib.connection
Source: runner.py:154
First occurred: 12:21:13 PM (29 occurrences)
Last logged: 1:19:49 PM

PIM at serial:///dev/serial0 disconnecting (heartbeat timeout)

The new heartbeat is probably a big part of the problem. How do I disable it? And it’s polling all sorts of devices that aren’t plugged in and shouldn’t be because … it shouldn’t be polling at all.

gwww · July 8, 2025, 6:47pm

I don’t have time to go through your entire message. Re the heartbeat it does not send messages onto the power line network. It only pokes the PIM for one of its registers. That does not cause buzzing. The heartbeat cannot be disabled without a software change.

gwww · July 8, 2025, 7:54pm

Another quick reply. What I see in the small log you included is that there are timeouts communicating with the UPB devices. You will probably find that the buzzing is 5 seconds before the timeout message.

Seems to me that PIM is not installed correctly.

If you include a full debug log for the UPB integration I might be able to tell more.

tofof · July 8, 2025, 9:57pm

Ok, bulleted list version.

Working install for 8+ years with UPB, previously openhab then homeassistant; I found, reported, and located the flawed code for the rate bug in Feb 2023.
Rpi SD card died. New SD card, fresh install, copy full backup of configuration. No configuration changes. It is possible, even likely that the old install was not on the latest version of the UPB integration. Was certainly current to 2024 builds.
All hardware is installed exactly as it has always been. Zero hardware changes. Full functionality in network. PIM is plugged into same socket as it always has been, on same phase of power, and still works to control all lights and devices without issue. Do not see any way for PIM to be “installed incorrectly” given its 100% functionality compared to past capability.
All devices, including sources of buzz, can still be reached and controlled through the HA upb integration as normal, even during the buzzing behavior. Legitimate traffic (which is only manual testing at this time of day) goes through, but 90+ seconds delayed because of the queue of crap from the PIM trying in loop to query every single device.
Every device buzzes every ~125 seconds, log claims each ‘timed out’. PIM buzzes every 5 seconds. Log shows PIM is failing heartbeat, then enumerating every single installed device on the network, choking it and causing them to buzz, which takes about 125 seconds per loop.

To be clear, the PIM is connected perfectly, is able to immediately clog the network with trying to enumerate every device, and all actual legitimate traffic works – though takes 90+ seconds delayed by the queue of useless enumerating.

Moving this to an issue to I can attach logs properly.

paulrother · January 27, 2026, 2:31am

Happy new year everyone! I’m new on HA here. I am having a problem with dimming HAI UPB switches. I have about 30 some UPB switches already on line. I had a HAI OmniPro system at our last house and totally familiar with UpStart and the like.

I was able to get the integration working using the WebMountain IP interface. My issue now is that the integration assumes that non-dimming HAI switches are non-dimming. That makes sense, but in reality, you can dim the non-dimming as well as treat the dimming switches as on/off (snap) switches. The difference between a dimming and non dimming is in name and SKU only. Upstart allows dimming on non dimming switches as did my old HAI Omnipro. So I now have a lot of switches i want to dim, but cannot through the HA interface. I was able to change “5,16” to “5,1” (5 being HAI and 1 and 16 being the dimming non-dimming” product codes respectively) in the upe export/inport file. It does trick the product (name) attribute to be dimming, but the dimmable attribute flag still comes up false, and thus I’m not able to dim the light through the interface, just on/off. I’m not seeing anything else in the upe file to tweak, and I can’t find where this info is stored within Home Assistant to make the change.

Any help here getting my switches to dim would be greatly appreciated. I’m really not up for buying 20 more switches, and swapping them in. Thank you in advance.

gwww · January 27, 2026, 3:11am

Hey! Welcome!

It’s been a very long time since I’ve looked at this code, so I might ask some dumb questions as I rediscover this stuff.

In the UPE file, there is something called a channel record. It is record type number 8. Here is a sample from my UPE file:

8,0,19,1,3 which says for device #19 it is dimmable - the 1. Any other number is treated as non-dimmable.

Let me know!

paulrother · January 28, 2026, 3:50am

Yes, that totally worked. Thank you so much, a big relief for me. It’s been overwhelming learning HA but I’m now starting to know my way around and it feels good.