I switched to the UPB integration in 110 Core. Thanks to the core devs I had to spend a good 10 minutes of intense clicking to do the migration. I had to tweak the scene automatons which wasn’t terrible. Can’t say I like their new GUI much, but that’s a whole different topic.
So far it seems solid!
Thank you @gwww for all the hard work!
Have you learned anything new today? I think your best bet is to ask on the hass Discord. Clearly the TTY device is not understood for whatever reason. The Discord will have people hanging out that should be able to help you debug further. Keep us posted. I want to understand too!
As much as I would like to help you fix the integration, joining Discord is not in the cards for me.
I started a separate thread asking how USB ports are mapped in Home Assistant (RPI3 disk-image). So far, it remains unclear why /dev/ttyUSB0 is unreachable by the integration.
Worst case, you may have to indicate that the integration cannot be used with Home Assistant installed on an RPI3 (and possibly others as well; anything where Core is running on HassOS).
EDIT
Just saw this:
Sounds similar; unable to connect to a USB-connected device. The main difference is that his ssh console is showing the USB device in /dev whereas it is not present on my system.
When working with containers you generally need to be careful to check if you are working in the base system or in the container environment as which /dev devices are exposed to the container may be limited compared to the base system. There’s also many types of containers and isolation methods, systemd for example has its own native container management system called systemd-nspawn which uses similar techniques to docker such as cgroups/namespaces to isolate a container.
When you ssh in are you in the same namespace/container as home assistant or are you in the base system? Also what does dmesg show?
I am using the Portainer Add-On to give me access to the homeassistant docker container (i.e. the one containing Home Assistant Core). Portainer allows me to open a console in the container.
lsusb shows the Raspberry Pi 3B’s hardware:
bash-5.0# lsusb
Bus 001 Device 006: ID 0557:2008 ATEN International Co., Ltd UC-232A Serial Port [pl2303]
Bus 001 Device 003: ID 0424:ec00 Microchip Technology, Inc. (formerly SMSC) SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Microchip Technology, Inc. (formerly SMSC) SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
bash-5.0#
dmesg reports the number of times I connected/disconnected the converter cable. In all instances, it detected the converter and assigned it to ttyUSB0
bash-5.0# dmesg | grep -i usb
[227725.011438] usb 1-1.4: new full-speed USB device number 4 using dwc_otg
[227725.143792] usb 1-1.4: New USB device found, idVendor=0557, idProduct=2008, bcdDevice= 3.00
[227725.149981] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[227725.156251] usb 1-1.4: Product: USB-Serial Controller D
[227725.159440] usb 1-1.4: Manufacturer: Prolific Technology Inc.
[227725.226218] usbcore: registered new interface driver pl2303
[227725.228585] usbserial: USB Serial support registered for pl2303
[227725.240810] usb 1-1.4: pl2303 converter now attached to ttyUSB0
[228939.439616] usb 1-1.4: USB disconnect, device number 4
[228939.443497] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[229085.649906] usb 1-1.4: new full-speed USB device number 5 using dwc_otg
[229085.782166] usb 1-1.4: New USB device found, idVendor=0557, idProduct=2008, bcdDevice= 3.00
[229085.788235] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[229085.794384] usb 1-1.4: Product: USB-Serial Controller D
[229085.797471] usb 1-1.4: Manufacturer: Prolific Technology Inc.
[229085.811877] usb 1-1.4: pl2303 converter now attached to ttyUSB0
[230076.079572] usb 1-1.4: USB disconnect, device number 5
[230076.083527] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[230679.769963] usb 1-1.4: new full-speed USB device number 6 using dwc_otg
[230679.902304] usb 1-1.4: New USB device found, idVendor=0557, idProduct=2008, bcdDevice= 3.00
[230679.908398] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[230679.914576] usb 1-1.4: Product: USB-Serial Controller D
[230679.917703] usb 1-1.4: Manufacturer: Prolific Technology Inc.
[230679.931096] usb 1-1.4: pl2303 converter now attached to ttyUSB0
bash-5.0#
Nevertheless, for reasons I don’t understand, ttyUSB0 is not present in the /dev directory:
bash-5.0# ls /dev/ttyUSB*
ls: /dev/ttyUSB*: No such file or directory
bash-5.0#
You could try mknod /dev/ttyUSB0 4 64 to create the USB device. Need to do that inside the container. The tty name is not important /dev/ttyFOO would work equally well. The 4 says create a tty. The 64 is more magic and that’s what all the articles I just read use. If that doesn’t work and you need to dig deeper the 4 64 are known as major and minor numbers.
I’ll try it as an experiment. However, it’s my understanding that this kind of patching inside of a container cannot survive a reboot.
Update:
It does appear to survive a reboot. I guess it will disappear only if the container is recreated from its image (like during an upgrade).
Update:
That worked but not without some resistance. The command as shown results in BusyBox responding with a help menu suggesting to use b, c, or p for the second option. I tried it with c and it produced the help menu again. At that point I looked in /dev and it now listed /dev/ttyUSB0 so I can’t be sure which of the two commands actually created it (despite both variations resulting in a help menu).
The UPB integration was able to find the port, open it, and poll all the devices listed in upb.upe. I successfully turned one light on/off to confirm the integration is working.
So it all boils down to my first observation: the assigned port (/dev/ttyUSB0) is not visible within the homeassistant container.
I assume this is something that should be managed by Supervisor (or some other service).
What’s next? Shall I post this as an Issue in the Supervisor repo?
I’d try to get the attention of @frenck 
At least that might be enough to figure out another what’s next.
Thank you for your reply.
I found your predicament interesting because, in your case, the ttyUSB* device is present in /dev. In my case,Supervisor reports the converter cable is on /dev/ttyUSB0 yet no such tty device exists in the homeassistant container.
After performing the test on Home Assistant 0.110.2 on an RPI3 (using the official disk-image) I repeated the test using a machine running Home Assistant Supervised 0.110.2 on Ubuntu. The result is exactly the same:
/dev/ttyUSB0 device in the homeassistant container./dev/ttyUSB0.To exclude the possibility that this behavior is due to the model of converter cable being used, I tried one from another manufacturer. The results remain the same:
Supervisor’s Hardware view reports it as follows:
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A906U593-if00-port0
/dev/ttyUSB0
Nevertheless, there is no /dev/ttyUSB0 in the homeassistant container and the UPB integration fails to connect.
My third and final test using Home Assistant Core 0.110.2 installed as a docker container on Ubuntu.
The docker-compose.yaml file contains the required device mapping:
devices:
- "/dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0:/dev/ttyUSB0"
The homeassistant container contains /dev/ttyUSB0 and the UPB integration finds and opens it successfully.
For whatever reason, these two installation methods fail to expose the USB port as a tty device:
This prevents the UPB integration from accessing the PIM.
That means only these two installation methods are currently compatible with the UPB integration:
I found the answer: restart Home Assistant.
Here’s the config flow for the ZHA integration. It also requires a Serial Device Path.
It offers the added convenience of a drop-down list for the Serial Device Path, listing the available devices:
In addition to the convenience of not having to type the path (and possibly introduce a typing error), it also provides visual confirmation of the available devices.
The HACS integration provides an Options button:
It allows for changing the integration’s configuration without having to uninstall/re-install it.
This would be a valuable addition to the UPB integration. Currently, if you want to change the Serial Device Path or UPE file name, it requires uninstalling/re-installing the integration. If you have changed the friendly names of any of the discovered lights, that work is lost when the integration is uninstalled.
First, let me say that this integration has been perfect thus far. Not a single glitch.
Now I need to finally revisit a scene button triggering a script in HA. I can’t seem to make it work.
So I tailed the log file to see if HA is seeing anything when I press that button. It does. This is what I get:
2020-07-11 08:30:04 DEBUG (MainThread) [upb_lib.proto] data_received: ‘PU89009E070CFFFFFFC9’
And this is what I have in my automation:
#All-off button from bedroom
- alias: 'Goodnight Scene Activated'
trigger:
platform: event
event_type: upb.scene_changed
event_data:
command: activated
address: '158_7'
action:
- service: script.goodnight
Any thoughts on where this is going wrong?
Your config looks Ok at first glance.
I would start by testing the event using the HASS developer tools.
Goto Developer Tools (near the bottom in the sidebar). Select Events tab from the list of tools along the top of the dev tools pane. Near the bottom of the the Events tab is a Listen to events. Start listening for upb.scene_changed. Try you scene and check the output. Here is the output I see when I activate a link:
Event 0 fired 1:25 PM:
{
"event_type": "upb.scene_changed",
"data": {
"command": "activated",
"address": "201_9",
"brightness_pct": -1,
"rate": -1
},
"origin": "LOCAL",
"time_fired": "2020-07-11T17:25:59.936910+00:00",
"context": {
"id": "3c1703bf39594423bc09349e0e419999",
"parent_id": null,
"user_id": null
}
}
I have done that. I never sees anything. Just sits there saying it’s listening.
I’m leaning to user error… If the UPB PIM doesn’t see the link it clearly won’t report it. Try some other links around the house that you have configured. Do they show up?
EDIT: could be communication error as well. i.e.: the link does not get to the PIM because of powerline noise.
Where can I verify the “address”? I have 158_7. 158 being the network ID and 7 being the scene. My UPE file shows:
0,5,20,15,158,5272
2,1,Scene001
2,2,Scene002
2,3,Scene003
2,4,Scene004
2,5,Scene005
2,6,Scene006
2,7,Scene007
2,8,Scene008
2,9,Scene009
2,10,Scene010
So Scene007 is what the button in question is programmed for. I am correct in my address? Or am I failing that simply?
Try turning on UPB debug logging. In your configuration.yaml config the logging section as so:
logger:
default: info
logs:
upb_lib: debug
Take a look at the UPB logs. You should see every message that comes into the PIM (and much more).
EDIT: 158_7 looks right to me.
I did. That’s how I got the DEBUG (MainThread) [upb_lib.proto] data_received: 'PU89009E070CFFFFFFC9'
At this point, I’m going to assume the it’s something in that switch. Although I’ll double check the programming in UPStart. But I think a new switch plugged in somewhere else to test this is the ultimate answer.
Thanks for the help. It’s mostly a sanity check to make sure I wasn’t making a mistake. And unless I find something in UPStart, it’s probably not me.