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 #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 #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]

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.

[7wells]

Hier noch ein Screenshot vom MQTT Explorer, welcher die Veränderung von ausgeschaltetem Lüfter (Off) auf Lüfterstufe 1 (Vent 1) zeigt:

Die Lüfterstufe habe ich jedoch am CP+ Bedienpanel geändert, nicht über MQTT. Wie das geht, weiß ich nicht, denn ich vermisse wie zuvor beschrieben control_status.

[7wells]

Ich kann nicht behaupten, alle Funktionen des MQTT Explorers bzw. allgemeiner alle Möglichkeiten der Formatierung von MQTT Publishing-Kommandos (RAW, XML, JSON) zu verstehen, aber ich habe einfach alle 3 nacheinander gewählt und jeweils 0 als Wert verwendet und gepublisht.

Ergebnis: Nun steht im Fenster links auch control_status drin mit vent_mode = 0 (also das, was ich gepublisht habe), aber oben steht unter display_status nach wie vor vent_mode = Vent 1, also hat sich nach dem Publishing via MQTT Explorer nichts geändert.

Vermutlich liegt's daran, dass ich es nicht richtig verwendet habe und besser der README folgen und das über die Konsole machen sollte. Aber das ist etwas für die kommenden Tage.

Schönen Abend Euch allen!

[danielfett]

Hast du Init ausgeführt am CP Plus? Wenn der control_status nicht von selbst auftaucht, hat das CP Plus noch nicht die Anwesenheit der "iNet-Box" erkannt.

Aber: Das kann jetzt auch wirklich ein Versionsproblem sein! Kannst du das ganze mal mit den drei genannten DEBUG-Optionen starten (auf der Kommandozeile, nicht als Service) und berichten, was da kommt?

Bitte dafür ein neues Issue aufmachen, ist ein anderes Thema.

[7wells]

Ja, PR SET => INIT hatte ich nach der letzten Umverkabelung gemacht. Gerne reiche ich die Infos in einem neuen Thread nach: #19

Kurze Frage noch: Wie oft (alle wie viele Sekunden oder Minuten) werden eigentlich die Daten gelesen? Sorry, falls ich das überlesen habe.

[danielfett]

Die Daten unter display_status kommen ca. alle 10 Sekunden, control_status minütlich oder schneller, wenn die Heizung aktiv ist.

[7wells]

Dass control_status bei mir nicht von alleine kommt, kann evtl. woran liegen?

(neues Thema?)

[danielfett]

Das wäre ein neues Thema, bitte. Möglicherweise anderes Protokoll, daher brauche ich die Debug-Logs.

[7wells]

Ok, siehe #19

[morawekj]

Ich habe mal das LIN Interface fertig gemacht und spontan 20 Stück bestellt. Ob das mit dem USB Port und Timing funktioniert, muss man testen, das sind aber kein 5 $ Unterschied. lässt sich auch mal als Stand Alone USB Uart verwenden.
Der CP2102N kann eigentlich 3 MBs, sollte eigentlich für die 9K6 reichen, aber der Teufel liegt im Detail.

[7wells]

Ich scheine ein Stück weitergekommen zu sein, denn jetzt taucht auch control_status im MQTT Explorer auf:

Darf ich mich freuen?

Ich war mir sehr sicher, dass ich nach der Umverkabelung (GND etc.) gemäß des aktualisierten README auch RESET => PR SET am CP+ durchgeführt hatte. Vielleicht war es nochmal nötig? Ansonsten habe ich nämlich weder an der Hardware, noch an der Software etwas verändert seit gestern - außer, dass ich für das Debug Log den miqro_truma Service gestoppt und danach wieder gestartet habe.

Mich irritiert, dass ich zwar nun ein Thema control_status habe, jedoch fehlt dort das vent_mode, das ich nur unter dem Thema display_status sehe. Ist das normal? Ich frage, weil ich zum Testen die Lüfterstufe via mosquitto_pub ändern möchte. Ich habe es nacheinander (bei laufendem miqro_truma Service) mit 'Off' und mit '0' versucht:

pi@pi4:~ $ mosquitto_pub -t 'service/truma/set/vent_mode' -m '0' -u pi -P Pitest
pi@pi4:~ $ mosquitto_pub -t 'service/truma/set/vent_mode' -m 'Off' -u pi -P Pitest

Beides wird aber jeweils mit derselben Fehlermeldung im MQTT Explorer quittiert:

Conversion function not defined - is this key defined?

[7wells]

Leider kann ich immer noch nicht die Lüfterstufe setzen:

pi@pi4:~ $ mosquitto_pub -d -t 'service/truma/set/vent_mode' -m 'Off' -u pi -P Pitest
Client (null) sending CONNECT
Client (null) received CONNACK (0)
Client (null) sending PUBLISH (d0, q0, r0, m1, 'service/truma/set/vent_mode', ... (3 bytes))
Client (null) sending DISCONNECT

Im MQTT Explorer wird dies quittiert mit:
error = Conversion function not defined - is this key defined?

Der vent_mode steht doch im Screenshot (oben unter display_status) mit dem Wert Off. Es sollte doch möglich sein, den Wert einfach nochmal auf Off zu setzen, ohne dass ein Fehler produziert wird. Oder verstehe ich die Syntax falsch?

[danielfett]

Du kannst nur Werte aus control_status setzen. Wo vent_mode in den inetbox-Steuerpaketen kodiert ist (also Lüftung unabhängig von der Heizung), habe ich noch nicht rausgefunden.

[7wells]

Ah, danke! Kann man denn die Heizung auf "Off" schalten, aber gleichzeitig die Lüftung auf "eco", um damit eine normale Lüftung zu realisieren? Mit dem CP+ geht das so ja nicht.

[danielfett]

Nein, das scheint nicht zu gehen.

[skrebber]

Ich bin wieder zurück und konnte weiter testen und das Problem lösen:
mein Rpi4 ist das Problem gewesen. Ich habe nur den Rpi4 gegen einen RpiZero W getauscht und es ging (fast) sofort. Interessanterweise funktioniert der Kurzschluss von 14&15 beim Rpi4 trotzdem. Da kann ich die gesendeten Zeichen direkt zurück sehen. Aber am LIN UART kommt gar nichts.
Also an alle, die keine Daten bekommen: ich würde den pi tauschen.

Vielleicht auch für den einen oder anderen interessant: nach pi-Tausch kam sofort der Datenmüll im screen an. Jedoch hat Daniels truma_service keinen sync bekommen (DEBUG_LIN=1 anschalten, dann sieht man's).
Alle Kabel abgezogen und ansteckt, truma_service neugestartet, alles nichts gebracht.
Wie es dann ging: alles angesteckt und so den pi neugestartet, danach hatte er sofort sync. Ob es am Neustart während die Schnittstelle schon angeschlossen war oder es Zufall war, weiß ich nicht.

Vielen Dank an Daniel für die tolle Software!

[7wells]

@skrebber
Ist es der Raspberry Pi Zero W oder Pi Zero 2 W?

Hier ein Vergleich für Interessierte:
https://geizhals.de/?cmp=1585318&cmp=2628565&active=1

Evtl. hilft auch dieser Hinweis von @mc0110: #19 (comment)

[skrebber]

Ich habe den alten pi Zero W rumliegen gehabt und verwendet.

[maseb24]

ich habs wohl auch hinbekommen, dass mein pi als 3. Gerät von der Truma akzeptiert wird.

nach starten des Skripts kommt es zu einer Verbindung zur Truma

2022-10-20 12:15:55,177 truma.main WARNING Service configuration for truma not found in 'services' section of configuration file miqro.yml. Using empty configuration.
2022-10-20 12:15:55,178 truma.main INFO started
2022-10-20 12:15:55,180 truma.main INFO Using serial device /dev/serial0
2022-10-20 12:15:55,182 truma.main INFO Loop stats:
2022-10-20 12:15:55,183 truma.main INFO - Loop(_update_online_status) called 0 times, average duration 0.0s, load=0%
2022-10-20 12:15:55,184 truma.main INFO - Loop(send_status) called 0 times, average duration 0.0s, load=0%
2022-10-20 12:15:55,254 truma.main INFO MQTT connected, client=<paho.mqtt.client.Client object at 0x75ecc478>, userdata=None, rc=0
2022-10-20 12:15:55,255 truma.main INFO Subscribing to ...
2022-10-20 12:15:55,255 truma.main INFO - service/truma/set/#
2022-10-20 12:15:55,256 truma.main INFO - service/truma/enabled
2022-10-20 12:16:02,407 inet-lin INFO Received status data from cp plus
2022-10-20 12:16:02,409 app WARNING Unknown status buffer type b'\n\x15'
2022-10-20 12:17:09,939 inet-lin INFO Received status data from cp plus
2022-10-20 12:17:09,940 app WARNING Unknown status buffer type b'\n\x15'
2022-10-20 12:18:01,803 inet-lin INFO Received status data from cp plus
2022-10-20 12:18:01,804 app WARNING Unknown status buffer type b'\n\x15'
2022-10-20 12:18:55,196 truma.main INFO Loop stats:
2022-10-20 12:18:55,197 truma.main INFO - Loop(_update_online_status) called 1 times, average duration 0.00216s, load=0%
2022-10-20 12:18:55,198 truma.main INFO - Loop(send_status) called 60 times, average duration 6.423333333333333e-05s, load=0%
2022-10-20 12:19:08,148 inet-lin INFO Received status data from cp plus

Im MQTT Explorer kommt nur der topic service/truma/online =1

Was könnte ich noch probieren um im MQTT Explorer die anderen topics zu empfangen

LG Rudi

[danielfett]

@maseb24 Das sieht gut aus. Du müsstest auch Daten im MQTT bekommen. Vielleicht nochmal INIT machen, während die Anwendung läuft?

[7wells]

Es kann auch ein paar Minuten dauern, bis in MQTT Explorer Daten kommen. Immerhin steht im Output die letzte Zeile drin, die bei mir immer noch fehlt. Vielleicht kann ich meinen RPi 2 probehalber dafür nutzen, aber der ist schon in Verwendung.

[ak68-hub]

Ich habe das selbe Problem wie mehrere hier: Keine Verbindung
MQTT zeigt cp_plus_status=waiting :(

Da Datenmüll bei Daniel´s Anleitung ankommt, scheint ja die serielle Verbindung korrekt zu sein !

jedoch bei "DEBUG_LIN=1 truma_service" weiterhin keine Synchronisation möglich
(Init davor danach und weitere gefühlte 100x durchgeführt !)

2023-10-08 15:14:23,660 inet.lin DEBUG in < 00 ac not a proper sync -wait for sync-
2023-10-08 15:14:23,663 inet.lin DEBUG in < 30 60 not a proper sync -wait for sync-
2023-10-08 15:14:23,666 inet.lin DEBUG in < ff ff not a proper sync -wait for sync-
2023-10-08 15:14:23,670 inet.lin DEBUG in < ff ff not a proper sync -wait for sync-
2023-10-08 15:14:23,712 inet.lin DEBUG in < 00 ac not a proper sync -wait for sync-
2023-10-08 15:14:23,715 inet.lin DEBUG in < 34 7c not a proper sync -wait for sync-
2023-10-08 15:14:23,718 inet.lin DEBUG in < ff ff not a proper sync -wait for sync-
2023-10-08 15:14:23,722 inet.lin DEBUG in < ff ff not a proper sync -wait for sync-
2023-10-08 15:14:23,764 inet.lin DEBUG in < 00 ac not a proper sync -wait for sync-
2023-10-08 15:14:23,767 inet.lin DEBUG in < 3d 20 not a proper sync -wait for sync-
2023-10-08 15:14:23,770 inet.lin DEBUG in < 35 21 not a proper sync -wait for sync-
2023-10-08 15:14:23,774 inet.lin DEBUG in < a1 8d not a proper sync -wait for sync-
2023-10-08 15:14:23,816 inet.lin DEBUG in < 00 ac not a proper sync -wait for sync-
2023-10-08 15:14:23,820 inet.lin DEBUG in < ee 33 not a proper sync -wait for sync-
2023-10-08 15:14:23,823 inet.lin DEBUG in < 37 76 not a proper sync -wait for sync-
2023-10-08 15:14:23,826 inet.lin DEBUG in < 1a 62 not a proper sync -wait for sync-
2023-10-08 15:14:23,868 inet.lin DEBUG in < 00 ac not a proper sync -wait for sync-

Ich habe keine Ahnung, wo das Problem liegen könnte

Um weitere Ideen wäre ich sehr dankbar :)

[ak68-hub]

Hardware: Raspi Zero 2 + T151

ERFOLG: durch folgende Maßnahmen habe ich ERSTMALS eine Verbindung zur Truma D6E:

Zum Erfolg führte:
In /boot/config.txt die Zeilen ergänzt:
core_freq=250
enable_uart=1
dtoverlay=pi3-miniuart-bt
und dann noch: sudo systemctl disable hciuart

Egänzung:
leider zu früh gefreut, jetzt funktioniert meine BT-Anbindung an Bluebattery nicht mehr, da ich ja offensichlich mit
sudo systemctl disable hciuart die BT-Schnittstelle deaktiviert habe

Wie kann ich Beides (Truma/ UART und Bluebattery/ BT) am gleichen Raspberry Zero 2) nutzen ?