First, let me say that I am an HA neophyte. But I had this working fairly well, but after a system crash, I got everything back and working. But I think an update, whether the UPB-LIB of the HA updates that happened, caused things to go a bit hay-wire. My HA log is filling up with a whole lot of this:
ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback SerialTransport._read_ready()
Traceback (most recent call last):
File "/usr/local/lib/python3.7/asyncio/events.py", line 88, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.7/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
self._protocol.data_received(data)
File "/usr/local/lib/python3.7/site-packages/upb_lib/proto.py", line 74, in data_received
LOG.debug("message received: %10s '%s'", self._msgmap[line[1]], line)
KeyError: 'Ć'
I donāt know if it is directly related to the UPB integration or not. But if I remove it, HA settles down to normal.
I am running the most recent docker image and V1.08.1 of HA. And I am running on a Linux box with Docker.
Again, I donāt know if I installed this incorrectly, or if somethings not right. I installed the UPB-LIB from a CLI inside the HA container. Then copied the UPB integration to custom_components. And it was working a week ago without incident.
I recognize that code! Why it was working and is not working now is a bit puzzling. If you could do two things. First, in the custom components directory there is a manifest.json file. What version of upb_lib is referenced in that file?
Second, grab a new version of the custom_component. There have been many updates to the custom component and to upb_lib. The update will make that exception go away. That particular line of code has changed since the version you have. The code fix may not be enoughā¦ I wonder if you have a problem that is surfaced by the bad code. Iām wondering if the PIM has gotten itself into some funky state. If the problem persists then I will need debug logs. The instructions for turning on debugging are at the bottom of the README for the custom component.
My guess is that your PIM is in pulse mode vs message mode. Two things you can try. Use UPStart to connect to the network using the PIM, let the network verify run, then close UPStart. This should reset the PIM back to message mode. Try again with HA. If this doesnāt work, reset the PIM. Thereās a reset button on the side of it. Youāll have to read the PIM manual to get the reset sequence. What is recall is you have to press it 10 times reasonably quickly.
When this problem started, were you using UPStart? Perhaps it did not shut down properly?
I think I owe you a beer. Reset the PIM and all is well. And itās 5-10-2 on the presses.
Now I need to figure our why my master bedroom switch seems to have failed for the second time. I suspect a wiring problem.
And @123 - Thatās the switch with the button I was trying to get working. Turns out UPStart canāt always see it. So I think thereās a lot of noise on that circuit.
Iāll make some updates to the library so this doesnāt crash. Actually already made that.
Iāll look at putting the PIM into message mode on startup. I had code that did that but it seems to erase the version number of my PIM, setting it to zero. Doing the reset sequence with the button on the PIM would fix it. So, I ended up taking the code out. Iāll take another look, donāt know if Iāll make the change.
FYI: Premise uses the PIM in Pulse mode. This UPB integration uses it in Message mode.
Use UPStart to measure the noise level at the affected device. Repeat the test when potentially noisy appliances are in operation, especially if they are on the same circuit (refrigerator, microwave oven, switching power supplies, etc). If the level is unacceptably high, youāll need to either remove the noisy device from that circuit or suppress the noise with a filter.
0.4.4 of the lib is published; custom component updated to support. I have nothing more on my backlog for this lib except possibly ensuring PIM is in message mode on startup. No bugs open.
Test away please.
Multi channel support is ādoneā but I cannot do testing. If you have multi-channel devices please test out the features!
I have fixed quite a few bugs over the last week. Check out the github history to get a sense of those.
Discussion point: Should UPB dimmer switches also be represented as ādevicesā?
Iāve noticed a growing emphasis on the concept of ādevicesā. A given physical device isnāt just modeled in the traditional way, using entities, but also with the new ādeviceā concept. For example, hereās one of my LIFX bulbs (Developer Tools > Devices > LIFX1):
It reveal the deviceās assigned area (Bedroom), manufacturerās information, and whatever automations, scenes, and scripts that reference this device (in my case, nothing for now).
For a LIFX bulb thereās a straightforward, one-to-one relationship between the LIFX device and the single entity that models it (namely light.lifx1). I imagine that would be the same simple relationship for a given UPB device and its light entity. Ideally, the UPB scenes associated with the UPB device (if any) would be listed in its Devices view.
The relationship can be more complex. For example, hereās my laser printer:
The key difference is that a single device may have its functionality exposed using multiple entities. I donāt foresee this occurring with UPB devices (perhaps if they also reported light level or temperature, but they donāt).
I like the idea. I donāt have energy for this one right now. Log a enhancement request against the hass integration.
I took a look at the docs for the device registry. Doesnāt look too hard on the surface. Of course its the details that where things start to add up.
Happy that this is a hass request vs the base library requestā¦ Iām looking to close off the library code sooner than later. This request may get some play when the integration into hass distro starts.
OK, sounds good. Iāll post it as Feature Request in the hass-upb repo. Itās a ānice to haveā and thereās no pressing need for it at this time; everything youāve already created is more than enough to control a typical UPB installation.
I spent some time testing the 0.4.4 lib this afternoon. The lib appears to be working in my tests. Release notes indicated changes to sync code which I assume is used primarily during hass startup. So I stopped my hass server, went around and adjusted levels on all my 2 channel lights and restarted hass. I can see the 2 channel device status messages being received in the logs and levels being correctly interpreted. I also noticed that you seem to have removed the channel attribute from the entities, perhaps because the channel number is now part of the name? If so, you may want to add 1 to the name channel numbers so they directly match the upb channel number. They currently start at 0, which in pub land I believe means āall channelsā.
Sync is used on the library startup to get the status from all the devices in the UPB network. Itās needed for hass to know the status of any device.
Channel number moved to UpbAddr. The idea of UpbAddr is that a single object contains the network id, device id, channel number, and if the device is multi-channel. I went with zero based numbering which is what the UPE export file uses, and I prefer 0-based indexing. When a channel is required to send in a message I add 1; never should the code ever send a 0 in the channel number.
It would be a great help if you could also provide Glenn with a UPIM-01 USB/UPB Interface Module.
He currently has no way of determining why the UPB integration is unable to communicate with the USB version of the PIM. This is a useful variant of the old-style serial PIM because it eliminates the need for purchasing an RS232-to-USB converter cable.
I didnāt know that you had tried it. Could you send me full debug logs with logging levels as described in the hass component readme. My email is in the UPB lib pyproject.toml file.
Having a USB PIM would also be great for coding and debugging.
Just for informational purposes, there are actually two USB PIMs available - one from SA and one from PCS. The one from SA uses a generic chip set that should be recognized by Windows and drivers installed automatically. Weāve had issues with this one, just due to how Windows handles generic USB devices and it has been problematic at times. In addition, we donāt recommend this particular device for long term 24x7 type of controller operations as it has a small bug in it where occasionally it will lock up and you have to repower it. Now, thatās with Windows. It might not have this issue with Linux or HASS.
The other USB PIM from PCS comes with drivers that you load onto Windows. It tends to be more stable and easier to get up and working, but it is more expensive.
I donāt recommend either USB PIM to my customers (most of whom are Windows users). I actually tell them to go get a USB to serial adapter - one that has drivers for the OS theyāre using - and use it with the serial PIM. The serial PIM is rock solid and we have practically no failures with it. And, since the adapter has drivers, it makes it more rock solid as well.
And, samgreco is correct - the correct procedure to get the PIM out of Pulse mode and into Message mode is the 5-10-2 taps. This is the same procedure that you use on any UPB module to do a factory reset.
