search

home-assistant / operating-system

:beginner: Home Assistant Operating System
Apache License 2.0
4.78k stars 957 forks source link

HASSOS 5.5 +RPI4 UART issue #1006

Closed leo231191 closed 2 years ago

leo231191 commented 3 years ago

Hello,

The UART no longer works on 5.5 booted from SSD My MHZ-19 CO2 sensor is connected directly to the PI UART PINS (14 , 15) , this worked fine before with HASSIO 4.X and SD card. I added enable_uart=1 in the config.txt. I can see /dev/ttyS0 under System–> Hardware, but HA dont receive any data from that sensor.

I followed this guide to setup the MHZ-19 sensor: https://home-assistant-china.github.io/components/sensor.mhz19/

agners commented 3 years ago

Just tested, serial port /dev/ttyS0 does work here on a RPi4.

Which version did you use before? I assume you are using 64-bit? Is the Home Assistant Core log saying something wrt this integration?

leo231191 commented 3 years ago

Only this:

Logger: pmsensor.co2sensor Source: /usr/local/lib/python3.8/site-packages/pmsensor/co2sensor.py:43 First occurred: 4:15:42 PM (26 occurrences) Last logged: 4:27:49 PM read timeout after 2 seconds, read 0 bytes

I have 64-bit version.

LE: image Seems that at some point he sent some values, but very unreliable

giannello commented 3 years ago

:+1: After updating to 5.5, my Zigbee shield stopped working. The serial port shows up in "hardware", but ZHA cannot initialize the device. Works again after downgrading to 5.4.

agners commented 3 years ago

@leo231191 kinda hard to tell why this device doesn't work while UART generally seems to work. Maybe the device is a bit picky when it comes to UART clock accuracy. Although, its only running at a rather low baudrate with 9600... I tried 9600 here too, and it seems to work as well. Does it help when you explicitly set the baudate from the OS shell using stty -F /dev/ttyS0 9600?

@giannello what Zigbee shield exactly? Do you happen to know what baudrate it is using?

Nemesis24 commented 3 years ago

For me it's a RaspBee and i'v got the same with 5.6

giannello commented 3 years ago

@giannello what Zigbee shield exactly? Do you happen to know what baudrate it is using?

@agners an Elelabs ELR023 - the baud rate is 115200

philrich commented 3 years ago

Hi,

I have a RaspBee connected to the GPIO Pins of my Raspberry PI4 4GB. Tried to move to SSD (following this guide: https://community.home-assistant.io/t/installing-home-assistant-on-a-rpi-4b-8gb-with-ssd-boot/) so installed HassOS 5.6 64Bit (upgrading from 4.17 32 Bit). I also tried HassOS 5.6 32Bit first but it did not boot. After importing my Backup everything worked but RaspBee. I see messages like this in the Deconz Log:

12:34:47:135 dev /dev/ttyAMA0
12:34:47:254 COM timout query bootloader, assume application
12:34:48:086 wait reconnect 3 seconds

I tried to specify /dev/ttyS0 instad of /dev/ttyAMA0 in the config but the addon still tries to connect to /dev/ttyAMA0?!

I also tried to downgrade to HassOS 5.5 and 5.4 but nothing worked.

In my config.txt I have

enable_uart=1
dtoverlay=pi3-miniuart-bt

Anything else I could try?

giannello commented 3 years ago

Anything else I could try?

@philrich 5.4 is the last working version for me - the serial is /dev/ttyS0, your config.txt seems OK, but please make sure that in the cmdline.txt file you remove the reference to the serial port.

philrich commented 3 years ago

I tried to specify /dev/ttyS0 instad of /dev/ttyAMA0 in the config but the addon still tries to connect to /dev/ttyAMA0?!

This did not work because of this issue: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3681#issuecomment-729102833

I downgraded the deconz addon to version 6.4.1 as this version does not ignore the device configuration (/dev/ttyS0), now I have a working deconz addon with HassOS 5.6 and RaspBee I.

What I don't understand is, why it is now /dev/ttyS0 instead of /dev/ttyAMA0. I think I have already seen this in the past when HassOS (v4.x) switched to kernel 5 for a short time.

agners commented 3 years ago

@philrich When HassOS 4.x was using the 5.4 kernel for a while it was pretty much mainline (RPi did not patch the kernel a lot). Now the kernel is the one RPi OS uses, and therefor should behave like Raspberry Pi OS does (when it comes to kernel things). In fact HAOS 5.6 uses the exact same kernel git hash (https://github.com/raspberrypi/linux/commit/9797f1a4938c20139b00a25de93cc99efb5c291b) as Raspberry Pi OS 2020-12-02/04 does (https://downloads.raspberrypi.org/raspios_armhf/images/raspios_armhf-2020-12-04/).

An OS update deploys a new boot partition. This means config.txt gets overwritten.

On Raspberry Pi, pin 14/15 are the primary UART. By default, the primary UART is configured as mini UART which is /dev/ttyS0 (see https://www.raspberrypi.org/documentation/configuration/uart.md).

When you use disable-bt or miniuart-bt, /dev/ttyAMA0 will be the primary UART. So maybe you have used one of those overlays earlier?

agners commented 3 years ago

@leo231191 did you use /dev/ttyS0 on 4.x as well? ttyS0 is the mini UART, which has a smaller FIFO. You can try using the disable-bt overlay, which makes the primary UART a full PL011 UART under /dev/ttyAMA0. Maybe this helps?

philrich commented 3 years ago

An OS update deploys a new boot partition. This means config.txt gets overwritten.

This is not my experience. The OS update did not change my manual config.txt changes. As already pointed out, I have added these two lines to it when I bought the Raspbee:

enable_uart=1
dtoverlay=pi3-miniuart-bt

I did many OS upgrades in the meantime and config.txt never changed.

When you use disable-bt or miniuart-bt, /dev/ttyAMA0 will be the primary UART. So maybe you have used one of those overlays earlier?

yes. earlier and now.

Since HassOS 5.x I have to use /dev/ttyS0, with HassOS 4.x it was /dev/ttyAMA0

nsotnikov commented 3 years ago

Hi,

I have a RaspBee connected to the GPIO Pins of my Raspberry PI4 4GB. Tried to move to SSD (following this guide: https://community.home-assistant.io/t/installing-home-assistant-on-a-rpi-4b-8gb-with-ssd-boot/) so installed HassOS 5.6 64Bit (upgrading from 4.17 32 Bit). I also tried HassOS 5.6 32Bit first but it did not boot. After importing my Backup everything worked but RaspBee. I see messages like this in the Deconz Log:

12:34:47:135 dev /dev/ttyAMA0
12:34:47:254 COM timout query bootloader, assume application
12:34:48:086 wait reconnect 3 seconds

I tried to specify /dev/ttyS0 instad of /dev/ttyAMA0 in the config but the addon still tries to connect to /dev/ttyAMA0?!

I also tried to downgrade to HassOS 5.5 and 5.4 but nothing worked.

In my config.txt I have

enable_uart=1
dtoverlay=pi3-miniuart-bt

Anything else I could try?

Hey, I have the same hardware configuration and the same problem. Did you already found any solution?

nsotnikov commented 3 years ago

OK, my raspbee was just broken. I have connected it shifted.

Just bought new one, it works with Pi4 4 GB, 64b HassOS:

Deconz config: 

device: /dev/ttyS0

And my config.txt:

enable_uart=1
dtoverlay=pi3-miniuart-bt
agners commented 3 years ago

@philrich you are right config.txt gets preserved. The changed name likely is due to #862/#915. But with that we should be closer to how Raspberry Pi OS behaves.

@leo231191 @philrich @giannello is UART still behaving problematic with latest releases?

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Alexs784 commented 3 years ago

Hello,

The UART no longer works on 5.5 booted from SSD My MHZ-19 CO2 sensor is connected directly to the PI UART PINS (14 , 15) , this worked fine before with HASSIO 4.X and SD card. I added enable_uart=1 in the config.txt. I can see /dev/ttyS0 under System–> Hardware, but HA dont receive any data from that sensor.

I followed this guide to setup the MHZ-19 sensor: https://home-assistant-china.github.io/components/sensor.mhz19/

I am in the same exact situation. My Raspberry is a 3B+, I also want to add that I have 2 sensors: one MHZ-19B and one MHZ-19C (new version), both of them are recognised but don't work, and on the logs I can see many read timeout after 2 seconds, read 0 bytes errors

Home Assistant OS 5.12 supervisor-2021.03.6 core-2021.3.4

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] commented 2 years ago

There hasn't been any activity on this issue recently. To keep our backlog manageable we have to clean old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant OS version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.