raspberry pi 5 support - Githubissues

toams commented 6 months ago

I'm having problems running hometop_HT3 on my new raspberry pi 5. First issue: when checking the status of the services I noticed following error with ht_collgate.service:

● ht_collgate.service - LSB: initscript for daemon: 'ht_collgate' connecting
     Loaded: loaded (/etc/init.d/ht_collgate; generated)
     Active: active (running) since Sun 2024-01-07 19:57:55 CET; 11min ago
       Docs: man:systemd-sysv-generator(8)
    Process: 925 ExecStart=/etc/init.d/ht_collgate start (code=exited, status=0/SUCCESS)
      Tasks: 7 (limit: 9262)
        CPU: 196ms
     CGroup: /system.slice/ht_collgate.service
             └─939 /usr/bin/python3 /home/tommi/HT3/sw/ht_collgate.py

Jan 07 19:57:55 rpi5 systemd[1]: Starting ht_collgate.service - LSB: initscript for daemon: 'ht_collgate' conne>
Jan 07 19:57:55 rpi5 ht_collgate[929]: Traceback (most recent call last):
Jan 07 19:57:55 rpi5 ht_collgate[929]:   File "/home/tommi/HT3/sw//etc/sysconfig/spi_clk_off.py", line 38, in <>
Jan 07 19:57:55 rpi5 ht_collgate[929]:     setup_gpio()
Jan 07 19:57:55 rpi5 ht_collgate[929]:   File "/home/tommi/HT3/sw//etc/sysconfig/spi_clk_off.py", line 36, in s>
Jan 07 19:57:55 rpi5 ht_collgate[929]:     GPIO.setup (11, GPIO.IN)
Jan 07 19:57:55 rpi5 ht_collgate[929]: RuntimeError: Cannot determine SOC peripheral base address
Jan 07 19:57:55 rpi5 systemd[1]: Started ht_collgate.service - LSB: initscript for daemon: 'ht_collgate' connec>

It seems that something about the GPIO's changed with the pi5 and the python3-rpi.gpio package doesn't support it(yet?). After some googling I was able to resolve this problem by uninstalling python3-rpi.gpio and installing rpi-lgpio which is a drop in replacement.

sudo apt remove python3-rpi.gpio
sudo pip3 install --break-system-packages rpi-lgpio

The error is now gone, but I'm still not receiving any data in Home Assistant. I checked everything else i can think of, but I'm unable to pinpoint the problem. So far i checked:

all services are running without errors (ht_collgate, ht_proxy, ht_2hass, ...

mqtt says state : online:

mosquitto_sub -h 127.0.0.1 -v -t "homeassistant/#"
homeassistant/sensor/heatersystem/status/config {"state_topic": "homeassistant/sensor/heatersystem/state", "value_template": "{{ value_json.status }}", "name": "status", "uniq_id": "status", "unit_of_measurement": ""}
homeassistant/sensor/heatersystem/state {"status": "Online"}

serial port should still be /dev/ttyAMA0 on the pi5 cat /dev/ttyAMA0 returns data, so i'm guessing this part also works. I can provide a datadump if you want

Any ideas what to check next?

norberts1 commented 5 months ago

@toams I'll think you are using the 'ht_pitiny' - board and not for the first time?

If it runs on any older RPi, then the board is ok.

Please check the 'green' LED. If it only flashes slowley then the board is running but no heaterbus-data is received. This can have different reasons:

Bus-connection to the heaterbus wrong
using wrong serial port in configuration: /dev/ttyAMA0 (RPi < 4) instead of /dev/serial0 (RPi4)
your mentioned error to run that script: 'spi_clk_off.py'

serial port should still be /dev/ttyAMA0 on the pi5

On my RPi4 it is a link to: /dev/serial0 -> ttyS0 I'm not sure what is required on the RPi5 cause I haven't one.

If you are using that 'ht_pitiny'-board then the script: 'spi_clk_off.py' must run without errors. On any other board it's not required. On that ht_pitiny- board the RPi 'SPI'-interface and it's CLK-output will block that receiving of heaterbus-data.

But this 'SPI'-interface is only used for software-updates on that ht_pitiny-board and switch off during heaterbus-data receiving.

I'll check your mentioned software-change rpi-lgpio for GPIO-ports on my RPi4 for workability. PS: I don't use pip3 anymore for installation.

toams commented 5 months ago

@toams I'll think you are using the 'ht_pitiny' - board and not for the first time?

that is correct

Please check the 'green' LED. is flashing quickly

the green led is flashing quickly so HW is good

Turns out the problem was indeed the serial port. The documentation about the serial ports on the pi 5 is confusing, but i was pretty sure i needed to use ttyAMA0. And in my memory this used to be the default. So i didnt check. But apparently the default changed to /dev/serial0. After manually changing the configfile to /dev/ttyAMA0 i got it to work! I'm sorry, I should have checked it before posting.

I'll check your mentioned software-change rpi-lgpio for GPIO-ports on my RPi4 for workability. PS: I don't use pip3 anymore for installation.

I also prefer apt over pip3, but unfortunately rpi-lgpio is not yet in the apt repo's? You have to use sudo pip3 install --break-system-packages rpi-lgpio to install the correct library

norberts1 commented 5 months ago

I should have checked it before posting.

Never mind. Your post is required for others to see what type of errors are there using the new RPi5.

The documentation about the serial ports on the pi 5 is confusing,...

YES, YES, YES. I never understood why they created a new name for that old 'ttyAMAxy' and set it to 'serialxy'. YES, this interface is serial one, but others too. Then the better name should be: async_serial. But anyway, mixing up the HW-type into the name of an interface is never a good idea.

See the URL for that confusing name-convention on that very very old async-serial interface: https://www.raspberrypi.com/documentation/computers/configuration.html#configuring-uarts

/dev/serial0 and /dev/serial1 are symbolic links which point to either /dev/ttyS0 or /dev/ttyAMA0. On the Raspberry Pi 5, /dev/serial0 is a symbolic link that points to /dev/ttyAMA10. Due to changes in Bookworm, /dev/serial1 does not exist by default. You can re-enable serial1 by setting the following values in config.txt

So it seems that the name /dev/serial0 is available for ALL RPi hardware-revisions using the latest OS-version. If NOT, then it's a bloody hell of disaster.

So, still open points on this issue:

New GPIO handling implemented on the RPi5, the old python-handling with 'RPi.GPIO' will not work anymore.
naming-convention for 'UART' serial port should be cleared.

toams commented 5 months ago

Problem is that /dev/serial0 points to /dev/ttyAMA10 on the pi5 while GPIO 14,15 is mapped to /dev/ttyAMA0. /dev/ttyAMA10 is mapped to a new dedicated uart debug port. This means that /dev/serial0 cannot be used anymore as a standard for all different pi's.

norberts1 commented 5 months ago

You are right. They make easy things complicated. I don't like there handling.

============================================ The documentation defines: Primary UART

On the Raspberry Pi, one UART is selected to be present on GPIO 14 (transmit) and 15 (receive) - this is the primary UART. By default, this will also be the UART on which a Linux console may be present. Note that GPIO 14 is pin 8 on the GPIO header, while GPIO 15 is pin 10.

On the Raspberry Pi 5, the primary UART appears on the Debug header.

============================================ My aim was to have a default configuration valid for any RPi-revision running out of the box. Now it's more complicated.

regarding the 'spi_clk_on.py / spi_clk_off.py' - runtime error I'm doing some tests with that gpiozero-lib: https://gpiozero.readthedocs.io/en/stable/installing.html This is default available, no installation required and easy to use.

If the test is finished on my RPi4 I'll post it for tests for your RPi5.

norberts1 commented 5 months ago

Some news on open point on this issue:

New GPIO handling implemented on the RPi5, the old python-handling with 'RPi.GPIO' will not work anymore.

The scripts: 'spi_clk_on.py / spi_clk_off.py' are required ONLY for that 'ht_pitiny'-board in the past. The problem: the SPI-clock (GPIO11) was forced to be an output and this blocked the rx-part of heaterbus-data.

For this reason the SPI-interface should be disabled for the ht_pitiny-board only.

I did some test on my RPi4 with enabled SPI-interface and disabled 'spi_clk_on.py / spi_clk_off.py' - scipts, but the above mentioned problem didn't occur anymore. So it seems they have changed that SPI-driver handling for the SPI-clock in the current OS-versions. As result the scripts seems to be not required anymore.

@toams could you please check this on your RPi5 with following configuration:

SPI interface enabled.
'spi_clk_on.py / spi_clk_off.py' - scipts with no active contend.
reboot after that changes is probably required.

If receiving of heaterbus-data is still possible then the scripts aren't required anymore.

If receiving is not possible anymore then use this attached script to disable that SPI-clock output (GPIO11). PS: it's using 'gpiozero' and no additional lib-installation is required.

spi_clk_off_gpiozero.zip

toams commented 5 months ago

I used raspi-config tool to enable spi
I commented out all code in spi_clk scripts
reboot

still receiving heaterbus-data, so looks like the scripts aren't needed anymore

norberts1 commented 5 months ago

still receiving heaterbus-data, so looks like the scripts aren't needed anymore

So, I'll remove that 'spi_clk scripts' from the startup-code.

Keep in mind: SPI-interface should be disabled and unused only for that: 'ht_pitiny'-board running on any RPi-type.

see item:#31 for startup update requirements.

norberts1 / hometop_HT3

raspberry pi 5 support #30