Basically, adding the Z-Wave controller appears to lock out the Bluetooth adapter, unless you do an unsupported fix by changing /boot/config.txt which will then be overwritten when a HassOS update happens. This problem seems to be very common, which leads me to wonder who HassOS is for if something so common causes a problem that must be fixed in an unsupported way that gets nuked by updates?
Springboarding off that, I’m wondering if there is a way to have “supervised” HomeAssistant such that add-ons work without having to struggle with this UART device lock-out issue.
Can you clarify which Z-Wave controller you have? In the linked posted you mention you have a “z-wave dongle”, a dongle typically refers to a plugin device like a USB stick. USB sticks don’t have any conflict with RPi bluetooth and will work fine with HAOS out of the box. If you actually have a Pi HAT/Shield (which would not typically be called a “dongle”), then yes that’s more of a configuration issue.
It is a USB stick. If I configure the Z-Wave add-on, Bluetooth stops working. If I disable or remove it, Bluetooth starts working again. (To be clear, I mean the RPi built-in Bluetooth.)
Then something is wrong with your installation. Mine (basically same configuration, Zooz 700 stick, and a Conbee 2 AND an additional external Bluetooth adapter to run BLE) none conflict with each other (except Bluetooth wifi and Zigbee radios but that’s a different context and not applicable to your situation)
So what’s the log say when Bluetooth fails to start.
Which USB stick?? /dev/ttyAMA0 is not a USB device path, and never will be, it’s the GPIO on the RPi4. The fact that you’ve configured Z-Wave to talk to that port is your issue, as writing to it is going to mess with the bluetooth process.
If you have a Aeotec Gen5 (not Gen5+), then your issue is the USB stick. Get an un-powered USB hub. If you have another stick, we’ll need that info.
the two undervoltage events at the bottom are when I connected one of my keyboards (didn’t work after) and then when I reconnected the Z-Wave device (it did work after, or at least it stayed lit afterwards).
Line 216 of your pastebinned dmesg I think confirms that ttyAMA0 is the bluetooth PL011 chip as described in the Stack Exchange link I posted previously
[ 1.658040] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 17, base_baud = 0) is a PL011 rev2
So it probably explains a bit
Can you please post the output of the following with the stick plugged and unplugged?
ls -l /dev/tty*
ls -l /dev/serial/by-id
ls -l /dev/serial/by-path
Also, plugging a keyboard in and getting an undervoltage should not happen, fix your power supply!
The dmesg log isn’t showing any USB serial device being detected, and your /dev directory listings confirm that. So there must be some hardware issue somewhere. Your dmesg log looks like this:
[ 1.607012] usbcore: registered new interface driver usbserial_generic
[ 1.608554] usbserial: USB Serial support registered for generic
[ 1.610356] mousedev: PS/2 mouse device common for all mice
A proper log looks similar to this when a USB serial device is detected:
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial support registered for generic
usbcore: registered new interface driver cp210x
usbserial: USB Serial support registered for cp210x
cp210x 1-1.4:1.0: cp210x converter detected
usb 1-1.4: cp210x converter now attached to ttyUSB0
There’s nothing around the undervoltage logs that show a USB device being detected either. Maybe those messages are indicating a faulty power supply, or something else in the power path. I have no undervoltage errors with my Pi4 and Canakit PS.
Maybe you need a better USB cable. Lots of articles about Pi4 undervoltage and all seem to relate to bad or poorly designed power supplies or cables.
something else worth noting is that when I plug in a powered USB hub, it seems like nothing happens, and nothing I plug into it is detected? does that help narrow things down?
