Truma D6e

[maseb24]

Hallo,

ich habe deine Software nochmal auf einer neuen Raspi Installation aufgesetzt.

Das Skript starte ich von Hand, den service habe ich erst gar nicht enabled. Wenn ich nun truma_service als normaler user starte kommen Fehlermeldungen

pi@raspberrypi:~ $ truma_service 2022-10-06 13:52:32,220 truma.main INFO started Traceback (most recent call last): File "/home/pi/.local/lib/python3.9/site-packages/serial/serialposix.py", line 322, in open self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK) PermissionError: [Errno 13] Permission denied: '/dev/serial0'

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/home/pi/.local/bin/truma_service", line 8, in sys.exit(truma_service.run()) File "/home/pi/.local/lib/python3.9/site-packages/inetbox/truma_service.py", line 56, in run miqro.run(TrumaService) File "/home/pi/.local/lib/python3.9/site-packages/miqro/init.py", line 578, in run service( File "/home/pi/.local/lib/python3.9/site-packages/inetbox/truma_service.py", line 21, in init self.serial = Serial(serial_device, 9600, timeout=0.03) File "/home/pi/.local/lib/python3.9/site-packages/serial/serialutil.py", line 244, in init self.open() File "/home/pi/.local/lib/python3.9/site-packages/serial/serialposix.py", line 325, in open raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg)) serial.serialutil.SerialException: [Errno 13] could not open port /dev/serial0: [Errno 13] Permission denied: '/dev/serial0'

Kannst du mir einen Tip geben wie ich weiterkommen könnte.

LG Rudi

[danielfett]

Hallo Rudi,

da fehlt die Berechtigung, den Port als normaler Benutzer zu nutzen. Du hast zwei Optionen:

1. Du kannst die Berechtigung vergeben: sudo adduser pi dialout -> wichtig: danach ausloggen und wieder einloggen (oder neustarten), sonst ist die Berechtigung nicht aktiv.
2. Du kannst das Skript auch mit sudo installieren und starten. (Alle Befehle wie in der Readme, aber mit sudo davor.)

[maseb24]

Hallo Daniel,

der user pi war bereits in der Gruppe dialout.

Nach der Installation des Skripts mit sudo kann man truma_service ohne Fehler aufrufen. Eine Verbindung zur CP Plus findet aber nicht statt.

Was mich stutzig macht, ist das das Programm read-logfile.py nicht gefunden wird.

PATH habe ich angegeben mit PATH=$PATH:/home/pi/.local/bin

in .local/bin sind folgende Dateien enthalten pi@raspberrypi:~/.local/bin $ ls -l insgesamt 12 -rwxr-xr-x 1 pi pi 220 6. Okt 12:56 pyserial-miniterm -rwxr-xr-x 1 pi pi 222 6. Okt 12:56 pyserial-ports -rwxr-xr-x 1 pi pi 228 6. Okt 12:56 truma_service

Gruß Rudi

[danielfett]

Hallo Rudi,

read-logfile.py wird nicht installiert, sondern muss direkt gestartet werden. Es ist aber nur für spezielle Anwendungen notwendig.

Was heißt denn genau, dass keine Verbindung stattfindet?

Bist du dir sicher, dass du den richtigen PIN am RJ12-Stecker angezapft hast und dass RX/TX richtig verkabelt sind?

[7wells]

Nach der Installation des Skripts mit sudo kann man truma_service ohne Fehler aufrufen. Eine Verbindung zur CP Plus findet aber nicht statt.

@maseb24 Hallo Rudi! Wie meinst Du das mit "findet nicht statt"? Fehlt bei Dir auch diese Zeile? (kopiert aus Daniels README)) 2022-10-02 14:21:27,234 inet-lin INFO Received status data from cp plus

Bei mir fehlt sie, und ich bin noch nicht dahinter gekommen, woran es liegt (siehe https://github.com/danielfett/inetbox.py/issues/8).

[maseb24]

Hallo Rudi! Wie meinst Du das mit "findet nicht statt"? Fehlt bei Dir auch diese Zeile? (kopiert aus Daniels README)) 2022-10-02 14:21:27,234 inet-lin INFO Received status data from cp plus

Bei mir fehlt sie, und ich bin noch nicht dahinter gekommen, woran es liegt (siehe https://github.com/danielfett/inetbox.py/issues/8).

Ja genau, diese Zeile kommt nicht.

Ich werde als nächstes versuchen die Verbindung zur Truma mit dem RJ12 Splitter zu machen. Dafür fehlt mir aber noch ein weiteres RJ12 Kabel. Muss ich mir erst besorgen. Die direkte Verbindung über die zweite RJ12 Buchse an der Truma scheint nicht zu funktionieren.

Gruß Rudi

[7wells]

Ich habe beides versucht, d.h. am 2. Anschluss der Truma, also parallel zum Kabel, das zum CP+ geht, sowie mit dem Splitter, also das vorhandene Kabel vom CP+ (vom Truma-Anschluss 1 kommend) getrennt, an den Splitter (Seite mit 1 Buchse) dran und auf der anderen Seite des Splitters (Seite mit 2 Buchsen) das Kabel zum CP+ dran sowie das Kabel, von dem nur 1 Ader dann an LIN des UART-Boards geht. Ergebnis aber leider bisher identisch, d.h. die letzte Zeile kommt nicht.

Mir ist noch völlig unklar, ob's rein Problem mit der Verkabelung oder der Software-Installation gibt.

Ich habe die Combi EDIT: 4 (nicht 6) ohne E.

Vielleicht findest Du ein RJ12 Kabel mit 6 Adern bei einem alten Telefon- oder Routerset (Fritzbox o.ä.).

@danielfett Kann es sein, dass es Unterschiede aufgrund verschiedener Truma Firmwares gibt? Oder müsste diese letzte Zeile immer kommen (korrekte Verkabelung vorausgesetzt)?

[danielfett]

@7wells Das ist möglich, aber aufgrund der Fehlerbeschreibung eher nicht wahrscheinlich - mal schauen.

Zur Sicherheit: Eure CP Plus hat jeweils das "inet Ready"-Symbol?

[danielfett]

Ich habe hier einen Hinweis hinzugefügt:

https://github.com/danielfett/inetbox.py#hardware-requirements

[7wells]

Ja, hat es, und ich hatte auch schon die iNet Box angeschlossen und konnte mit der Truma App auf dem Handy via Bluetooth einiges einstellen und auswerten.

Ich frage mich auch gerade, ob ich die iNet Box für Deine Skripte noch verwenden kann, also im Sinne von Testen und Vergleichen von Werten, Reaktionen etc. Sag gerne Bescheid, ob das Sinn macht.

Aber zuerst muss ich das Ganze ohne die iNet Box zum Laufen bekommen.

Vielleicht hat @maseb24 Rudi noch eine Idee.

[maseb24]

ich habe auch CP Plus mit iNetReady im Bus installiert.

ich bekomme die Initialisierung mit dem LIN Bus der Truma nicht zum laufen.

Daniel hat das schon mal jemand hin bekommen, ausserhalb deiner Installation?. Ich muss passen.

Gruß Rudi

[danielfett]

Ja, das wurde schon reproduziert. Insofern ist es zumindest kein grundlegender Fehler, sondern irgendwas anders...

Welche Pi-Version benutzt ihr jeweils?

Könnt ihr bitte einmal folgendes ausprobieren?

• sudo apt install --no-install-recommends screen um das Programm screen zu installieren
• sudo systemctl disable miqro_truma um den Dienst zu deaktivieren, falls er schon installiert wurde
• Pi neustarten (wichtig!)
• sudo screen /dev/serial0 9600 starten
• Dort sollte spätestens alle 10 Sekunden Datenmüll vorbeikommen. Wenn ihr nichts seht, gibt es ein Problem mit der Verbindung. Ihr könnt dann noch /dev/serial1 statt serial0 testen.
• Mit Strg+A, dann K kommt ihr wieder aus screen raus.

Kommt Datenmüll rein oder nicht?

[danielfett]

Und falls keine Daten kommen:

sudo apt install wiringpi
sudo gpio -g mode 15 up

• dann bitte nochmal probieren.

[appi1]

hallo bin am selben Punkt angelangt, bekomme die Initialisierung auch nicht zum laufen. mit sudo screen /dev/serial0 9600 kommt im Sekundentakt Datenmüll (unleserlich). Habe Bulleye installiert und wiringpi gibt es nicht mehr als Paket.

[maseb24]

Hallo, ich bekomme auch mit sudo screen /dev/serial0 9600 Datenmüll. Auf serial1 bleibt der screen leer. Wiringpi lässt sich ebenfalls nicht installieren. Ich habe auch Bullseye installiert

Mein Raspi ist ein Pi 3 B V 1.2 aus 2015.

Immerhin mal ein Erfolgsergebnis. Aber eine Initialisierung mit dem LIN Bus der Truma ist nicht möglich.

LG Rudi

[skrebber]

Ich ergänze auch mal, hatte mit Daniel direkt geschrieben:

Truma 6 Gasheizung mit CPplus. Rpi4 mit exakt dem LIN Transceiver aus der readme. Gleiches Fehlerbild wie bei euch: stecke ich den pi an, geht das display auf W255H, ein PR RESET dauert ewig und anschließend ist die Heizung im Display "weg". Die Zeile "inet-lin INFO Received status data from cp plus" kommt nicht. Der Datenmüll bei mir sieht aus wie im Anhang.

VG, Sönke

[7wells]

Momentan kann ich das nicht live testen, aber Anfang kommender Woche.

Ich verwende einen RPi 4 Model B (Debian bullseye).

Müssen bei den Interfaces evtl. noch andere Sachen aktiviert werden wie 1-wire oder remote GPIOs?

[morawekj]

Wenn das CP Plus den Fehler 255h meldet, kann es nicht mehr mit der Combi reden, das heisst es liegt ein Anschlussfehler am LIN vor. Wichtig, das Interface braucht auch die Vbat (12V vom Wohnmobil) Spannung. bitte auch noch mal zusätzlich die Ground am RJ12 Verbinden.

[7wells]

Der Fehler "W255 H" kommt bei mir regelmäßig, wenn ich die Verkabelung neu herstelle. Aber nach "PR SET" geht sie sofort weg (dauert höchstens ein paar Sekunden).

Das UART-Board versorge ich mit 12V direkt von einer 12V Camping-Steckdose vom WoMo (auch GND, es ist ja derselbe Stecker). Die grüne LED ist an, und die Spannung ist gemessen ok.

Ich vermute ein Problem bei der Verkabelung mit dem RJ12-Kabel/Stecker.

Später mache ich nochmal einen Versuch...

[skrebber]

Ich teste heute Abend auch gerne noch den GND-pin vom RJ12 auch aufzulegen. Was jedoch bei mir schon funktioniert, lässt mich zweifeln, ob's daran liegt: mit exakt gleicher Verkabelung zum LIN Transceiver, nur das CPplus ausgesteckt und die RX-TX vom LIN Transceiver auf nen ESP32 gelegt, kann ich mit dem Code aus der WomoLIN Gruppe die Heizung steuern.

Sind die RX-TX pins vom pi eigentlich galvanisch getrennt? Ne, oder? Mir fällt gerade auf, dass der ESP32 über die 12V vom CPplus (also Womo-Batterie) läuft und daher sicher das gleiche GND-Niveau wie die Truma hat. Den pi habe ich aber zum Testen über Wechselrichter und 230V Netzteil betrieben.

VG, Sönke!

[mc0110]

Hallo Sönke,

das mit dem GND aus dem Wechselrichter ist sicher kein Batterie-GND.

Könntest Du mal einen Link zu dem ESP32-Code teilen. Das wäre toll. Ich würde es gerne auf der Plattform zum Laufen bringen.

Danke und LG Magnus

[mc0110]

Was meinst Du mit "dem Code aus der WOMOLin Gruppe"

[morawekj]

Exakt der Fehler, ohne GND passieren komische Dinge. Die TX/RX Pins sind nicht getrennt, es könnten Ausgleichströme fließen, die den Uart im PI zerstören. Die GND verbindung ist deshalb auch wichtig.

[skrebber]

Es gibt eine Telegram-Gruppe, dort gibt es einen Arduino-Code, der ein CPplus emuliert und über MQTT Status bereitstellt und sich über MQTT steuern lässt.

[mc0110]

Oh je, das klingt interessant, aber da komme ich wohl nicht an den Code. Aber danke für Deine schnelle Antwort.

[skrebber]

Direkt auf der Startseite ist der Link zur Telegram-Gruppe. ;-) https://womolin.de Dort unter Dateien in der Gruppe "Code_v2.ino"

[mc0110]

Super hilfreich, ich danke Dir!

[7wells]

Exakt der Fehler, ohne GND passieren komische Dinge. Die TX/RX Pins sind nicht getrennt, es könnten Ausgleichströme fließen, die den Uart im PI zerstören. Die GND verbindung ist deshalb auch wichtig.

@morawekj @danielfett Verstehe ich das richtig, dass wir nicht nur Tx und Rx zwischen LIN UART-Board und RPi anschließen sollen (Tx und Rx natürlich "verdreht"), sondern auch GND zwischen LIN UART-Board und RPi verbinden sollen?

[skrebber]

GND vom Truma RJ12 Connector PIN5 auf GND LIN Transceiver UND GND LIN Transceiver auf GND vom pi. Damit alle auf dem gleichen Niveau sind.

[7wells]

Welches ist denn PIN 5 (GND) an der Truma bzw. am RJ12-Stecker?

Links im Bild ist das von @danielfett farblich hervorgehobene LIN-Kabel, und rechts im Bild mein RJ12-Stecker:

[skrebber]

Der markierte ist LIN pin3. Rechts pin1. Links ist pin6.

Ist es ohne Bild verständlich? ;-)

[7wells]

Achtung, der Stecker rechts ist mein Kabel und hat nichts mit dem Foto von Daniel links zu tun!

D.h., dass Pin3 links natürlich auch Pin3 bei mir (also rechts im Bild) ist.

Entschuldigt bitte, dass ich hier evtl. Verwirrung gestiftet habe.

[skrebber]

Ich habe zu kurz geschrieben. In dem Stecker des linken Bildes ist der rechteste Pin die Nr 1 und der linkeste Pin die Nr 6. D.h der GND Pin Nr 5 ist im linken Bild der zweite von links.

So deutsche Sprache verunglimpft und hoffentlich alle Klarheiten beseitigt. ;-)

[skrebber]

So jetzt konnte ich testen. Wenn ich die RX/TX so anstecke, dass der oben gezeigte Datenmüll kommt und ich dann noch GND vom raspi mit mit GND vom LIN Transceiver und Truma Bus verbinde, dann hört der Datenmüll sofort auf. Trenne ich die GND Verbindung, läuft der Datenmüll wieder los.

Wenn ich RX/TX so anstecke, wie ich meine, dass es richtig wäre und zusätzlich die GND Verbindung habe, dann kommt leider gar nix auf der Schnittstelle. Aber auch vertauscht und zusätzlich GND kommt auch nix auf der Schnittstelle.

Ich würde sagen der UART vom pi ist gehimmelt. :-( Oder siehst du das anders, @morawekj?

Jetzt bin ich mit testen erst mal raus, bis ich nächste Woche wieder zu Hause bin und den nächsten pi nehmen kann. Es sei denn, der UART ist doch nicht hin und es hat noch jemand eine weitere Idee, was ich probieren könnte.

[7wells]

Wie lässt sich der UART vom Pi denn hinsichtlich seines Zustands testen?

@skrebber @morawekj @danielfett Könnte man nicht direkt Tx und Rx am RPi shorten und auf 2 Terminals beobachten, was gesendet und empfangen wird?

Ist es evtl. nötig, eine bestimmte Baudrate, Software- vs. Hardware-Handshake, Flusskontrolle ein/aus etc. einzustellen? Siehe z.B. dort: https://buyzero.de/blogs/news/praktische-kommunikation-per-uart-und-rs485-am-raspberry-pi

Außerdem fallen mir noch vage dazu ein:

• Anzahl der Datenbits
• Anzahl der Stopbits
• Parität
• Echos an/aus?

[morawekj]

Verbinde RX und TX, mache eine serielle konsola auf, kein Echo, irgendeine Baudrate z.B. 19200 8N1 software handschake und tippe etwas ein, wenn der Uart OK ist, kannst du deinen Text dann im Terminal lesen.

[morawekj]

Evtl. ist auch der LIN Transceiver defekt, irgendein Oszi etc. vorhanden ?

[7wells]

Oszi habe ich nicht, mache aber am Dienstag den Loopback-Test, um zumindest zu sehen, ob der UART des RPi einen Hau hat oder ok ist.

[skrebber]

Verbinde RX und TX, mache eine serielle konsola auf, kein Echo, irgendeine Baudrate z.B. 19200 8N1 software handschake und tippe etwas ein, wenn der Uart OK ist, kannst du deinen Text dann im Terminal lesen.

Danke Jan, an diesen einfachen Test hatte ich gar nicht gedacht! Aber der UART geht noch. Gut! Aber irgendwie auch nicht. ;-) Dann bin ich nämlich auch noch nicht weiter mit dem debugging... Der LIN Transceiver ist aber auch ok, wenn ich die RX/TX Kabel auf meinen ESP32 stecke, kann ich alles steuern und Temperaturen lesen. Dann wird der wohl auch ok sein.

[morawekj]

Habe mal ein universelles LIN Interface das per USB oder UART angesprochen werden kann, zusammen geklickt. Voll ESD protected und galvanisch getrennt. https://gitlab.womolin.de/public-repository/ti-ci-lin-interface

[7wells]

@morawekj Öhm, was genau können wir mit den Dateien unter LIN-Interface machen? EDIT: Ah, z.B. mit LibrePCB? https://librepcb.org Ach, nee, KiCAD: https://www.kicad.org

Welche Hardware hast Du verwendet? Dasselbe, das auch Daniel nutzt oder evtl. dieses hier? https://buyzero.de/products/lin-bus-breakout-board (habe beide, bisher aber nur das von Daniel verwendet)

[7wells]

Verbinde RX und TX, mache eine serielle konsola auf, kein Echo, irgendeine Baudrate z.B. 19200 8N1 software handschake und tippe etwas ein, wenn der Uart OK ist, kannst du deinen Text dann im Terminal lesen.

Ich bin mittels putty/ssh vom Windows PC am RPi eingeloggt (falls das relevant ist für picomm). Wenn ich folgendes im putty-Fenster aufrufe und auf der PC-Tastatur "A" tippe, wird im putty-Fenster ein "a" angezeigt. Ist es das, was ich erwarten sollte?

pi@pi4:~ $ picocom -b 19200 -d 8 -f n -p e /dev/serial0
picocom v3.1

port is        : /dev/serial0
flowcontrol    : none
baudrate is    : 19200
parity is      : even
databits are   : 8
stopbits are   : 1
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
hangup is      : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv -E
imap is        :
omap is        :
emap is        : crcrlf,delbs,
logfile is     : none
initstring     : none
exit_after is  : not set
exit is        : no

!! Settings mismatch !! Type [C-a] [C-v] to see actual port settings
Type [C-a] [C-h] to see available commands
Terminal ready
a

Sollte mich die "!! Settings mismatch !!" Meldung zu Änderungen veranlassen?

Tx und Rx am RPi sind miteinander verbunden, und der RPi hängt mit original Netzteil an 240V auf dem Schreibtisch zu Hause (nicht im WoMo).

Mit Strg+A und dann Strg+Q kann ich picomm beenden.

[7wells]

PS: Soweit so gut, d.h. die Zeichen kommen im Loopback, solange ich Tx und Rx verbunden habe, nicht aber, nachdem ich sie getrennt habe. Wenn ich das richtig verstehe, ist der UART meines RPIs wohl nicht defekt.

Interessant ist, dass nach dem Abklemmen noch "Datenmüll" im Terminal erscheint. Ich nehme an, das ist völlig normal, wenn die Verbindung während des Sendens unterbrochen wird? (ich habe einfach den Finger auf einer Taste gelassen, während ich das Kabel an Tx abgezogen habe)

[7wells]

sudo screen /dev/serial0 9600

Nach ein paar Sekunden kommt Datenmüll. Aber wie bereits in https://github.com/danielfett/inetbox.py/issues/8#issuecomment-1276495628 beschrieben, kommt leider auch nach aktualisierter Verkabelung nicht das gewünschte Ergebnis, d.h. die Zeile inet-lin INFO Received status data from cp plus fehlt:

pi@pi4:~ $ truma_service
2022-10-12 19:15:17,216  truma.main  INFO       started
2022-10-12 19:15:17,217  truma.main  INFO       Using serial device /dev/serial0
2022-10-12 19:15:17,218  truma.main  INFO       Loop stats:
2022-10-12 19:15:17,218  truma.main  INFO        - Loop(_update_online_status) called 0 times, average duration 0.0s, load=0%
2022-10-12 19:15:17,219  truma.main  INFO        - Loop(send_status) called 0 times, average duration 0.0s, load=0%
2022-10-12 19:15:17,226  truma.main  INFO       MQTT connected, client=<paho.mqtt.client.Client object at 0x7f80318af0>, userdata=None, rc=0
2022-10-12 19:15:17,226  truma.main  INFO       Subscribing to ...
2022-10-12 19:15:17,226  truma.main  INFO         - service/truma/set/#
2022-10-12 19:15:17,226  truma.main  INFO         - service/truma/enabled

[7wells]

Und falls keine Daten kommen:

sudo apt install wiringpi sudo gpio -g mode 15 up

dann bitte nochmal probieren.

wiringpi wird nicht mehr gepflegt und ist nicht mehr im offiziellen Repo von Debian 11 "bullseye" 64-bit verfügbar. Es gibt aber Alternativen. Falls nicht bereits installiert: sudo apt install pigpio pigpiod

Die Steuerung der GPIOs erfolgt mit dem Kommandozeilentool pigs. Damit das funktioniert, muss man zuerst den pigpio-Daemon starten: sudo systemctl start pigpiod

Wenn man möchte, dass der Daemon automatisch bei Systemstart gestartet wird, dann muss folgendes Kommando ausgeführt werden: sudo systemctl enable pigpiod

Danach kann man die einzelnen GPIOs mit pigs konfigurieren (Quelle).

Eine Übersicht der Möglichkeiten zeigt die Hilfe an: pigs h

[7wells]

Hallo zusammen, es funktioniert! 😄

Zwar erscheint im Terminal nicht die Zeile inet-lin INFO Received status data from cp plus, aber "zufällig" fand ich sinnvollen Output im MQTT Explorer, der auf meinem Windows PC läuft und auf den MQTT Dienst meines Raspberry Pi 4 lauscht:

Ich habe die Truma Combi EDIT: 4 (nicht 6) ohne "E". Die Werte stimmen mit dem überein, was ich im WoMo am CP+ Bedienfeld ablesen kann.

Was die "unknown" Werte bedeuten, weiß ich nicht, und ich muss jetzt überlegen wie es weitergeht, aber die Verkabelung scheint nun zu passen.

Danke an Euch alle für die vielen sehr hilfreichen Tipps dazu und natürlich vor allem an Daniel (@danielfett) und die Macher von WomoLIN (@morawekj u.a.) für das Projekt und die Idee. Ich hoffe, dass wir uns hier weiter austauschen werden. 👍

PS: Mit pigs habe ich gar nichts gemacht, sondern nur truma_service gestartet. Der Output sieht so aus:

pi@pi4:~ $ truma_service
2022-10-13 12:16:16,946  truma.main  INFO       started
2022-10-13 12:16:16,947  truma.main  INFO       Using serial device /dev/serial0
2022-10-13 12:16:16,949  truma.main  INFO       Loop stats:
2022-10-13 12:16:16,949  truma.main  INFO        - Loop(_update_online_status) called 0 times, average duration 0.0s, load=0%
2022-10-13 12:16:16,950  truma.main  INFO        - Loop(send_status) called 0 times, average duration 0.0s, load=0%
2022-10-13 12:16:16,956  truma.main  INFO       MQTT connected, client=<paho.mqtt.client.Client object at 0x7f869aeaf0>, userdata=None, rc=0
2022-10-13 12:16:16,956  truma.main  INFO       Subscribing to ...
2022-10-13 12:16:16,956  truma.main  INFO         - service/truma/set/#
2022-10-13 12:16:16,956  truma.main  INFO         - service/truma/enabled
2022-10-13 12:19:16,954  truma.main  INFO       Loop stats:
2022-10-13 12:19:16,955  truma.main  INFO        - Loop(_update_online_status) called 1 times, average duration 0.000937s, load=0%
2022-10-13 12:19:16,956  truma.main  INFO        - Loop(send_status) called 60 times, average duration 0.0011171s, load=0%
2022-10-13 12:22:16,971  truma.main  INFO       Loop stats:
2022-10-13 12:22:16,972  truma.main  INFO        - Loop(_update_online_status) called 1 times, average duration 0.003677s, load=0%
2022-10-13 12:22:16,973  truma.main  INFO        - Loop(send_status) called 60 times, average duration 0.0009742999999999996s, load=0%
2022-10-13 12:25:16,988  truma.main  INFO       Loop stats:
2022-10-13 12:25:16,989  truma.main  INFO        - Loop(_update_online_status) called 1 times, average duration 0.002638s, load=0%
2022-10-13 12:25:16,989  truma.main  INFO        - Loop(send_status) called 60 times, average duration 0.0010785333333333336s, load=0%
2022-10-13 12:28:16,991  truma.main  INFO       Loop stats:
2022-10-13 12:28:16,992  truma.main  INFO        - Loop(_update_online_status) called 1 times, average duration 0.002325s, load=0%
2022-10-13 12:28:16,992  truma.main  INFO        - Loop(send_status) called 59 times, average duration 0.0009585084745762711s, load=0%

[mc0110]

Gratulation - sieht gut aus! Und Du bist der Erste, der Vollzug meldet. Das motiviert.

[7wells]

Danke, mich freut das auch! 🙂 Anbei noch ein paar "Kurven":

[skrebber]

Gratulation. Kannst du eingrenzen, welcher Schritt/Änderung/etc zum Erfolg geführt hat?

und es wäre sicherlich auch interessant den korrekten Datenmüll einmal zu sehen. Kannst du davon auch man einen Screenshot posten?

[7wells]

Ich habe nur die Verkabelung angepasst gemäß Daniels Updates, d.h. die Verbindung der GNDs über alles (LIN-UART, RPI, Truma). Am Software-Setup habe ich nichts geändert [aber siehe EDIT2], d.h. ich verwende bisher nur truma_service mit direktem Aufruf (ohne Hintergrunddienst).

EDIT1: (davon kommt immer mehr, je länger ich warte)

EDIT2: Ich hatte zwischendurch (zum Checken des UARTs des RPIs) Pins 14+15 verbunden und dies aufgerufen: picocom -b 9600 -d 8 -f n -p e /dev/serial0

Vielleicht wurde erst damit die serielle Schnittstelle des RPi bzw. des Raspberry Pi OS auf funktionierende Werte gesetzt? Dazu fehlt mir leider das Fachwissen, das richtig einzuschätzen.

[7wells]

Im README steht:

MQTT topics for receiving status

service/truma/error - some error messages are published here

service/truma/display_status/# - frequent updates from CP Plus, similar to what is shown on the display. Note that not all values have been decoded yet.

service/truma/control_status/# - less frequent updates, but includes values that can be modified. These are the values that would otherwise be available in the Truma inet app.

Im MQTT Explorer sehe ich nur display_status, aber nicht control_status.

Außerdem taucht bei mir nie die Zeile inet-lin INFO Received status data from cp plus auf.