[gelöst] MQTT2_DEVICE publish funktioniert nicht (meatPI ESP32 OBD2/CAN Adapter)

[mähschaf]

Hallo und guten Abend.

ich habe mir einen meatPI https://github.com/meatpiHQ/wican-fw#mqtt gegönnt, um den SOC meines PHEV ohne Cloud etc. auszulesen.

Das Gerät ist ein ESP32, der im WLAN hängt und OBD2 in MQTT übersetzt.

[Interessanterweise werden über Autocreate insgesamt zwei MQTT2_DEVICE angelegt, aber das stört mich nicht, da es rein kosmetische Effekte zu haben scheint.]

Ich habe in diesem Thread eine Anleitung gefunden, wie ich den Payload senden können sollte. Dachte ich jedenfalls.

Den Publish habe ich von hier geklaut. Der funktioniert auch super - so lange ich dafür dieses Kommando auf Linux absetze:

Code Auswählen Erweitern

mosquitto_pub -h localhost -t "wican/dc547550c9e9/can/tx" -m "{ \"bus\": \"0\", \"type\": \"tx\", \"frame\": [{ \"id\": 2021, \"dlc\": 8, \"rtr\": false, \"extd\": false, \"data\": [3, 34, 2, 140, 170, 170, 170, 170] }] }"
Sofort aktualisiert er die Daten in diesem Device:

Code Auswählen Erweitern

Internals:
   CID        MQTT2_FHEM_Server
   DEF        MQTT2_FHEM_Server
   FUUID      654d04dc-f33f-2b6d-d635-feccd8ba99d3071a
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_CONN MQTT2_FHEM_Server_127.0.0.1_60260
   MQTT2_FHEM_Server_MSGCNT 8
   MQTT2_FHEM_Server_TIME 2023-11-09 18:15:20
   MSGCNT     8
   NAME       MQTT2_meatPI
   NR         73181
   STATE      read_SoC
   TYPE       MQTT2_DEVICE
   eventCount 15
   READINGS:
     2023-11-09 17:12:12   IODev           MQTT2_FHEM_Server
     2023-11-09 18:15:20   SoC             55
     2023-11-09 18:15:20   bus             0
     2023-11-09 18:15:20   frame_1_data_1  3
     2023-11-09 18:15:20   frame_1_data_2  34
     2023-11-09 18:15:20   frame_1_data_3  2
     2023-11-09 18:15:20   frame_1_data_4  140
     2023-11-09 18:15:20   frame_1_data_5  170
     2023-11-09 18:15:20   frame_1_data_6  170
     2023-11-09 18:15:20   frame_1_data_7  170
     2023-11-09 18:15:20   frame_1_data_8  170
     2023-11-09 18:15:20   frame_1_dlc     8
     2023-11-09 18:15:20   frame_1_extd    false
     2023-11-09 18:15:20   frame_1_id      2021
     2023-11-09 18:15:20   frame_1_rtr     false
     2023-11-09 17:57:23   state           read_SoC
     2023-11-09 18:15:20   type            tx
   hmccu:
Attributes:
   DbLogExclude .*
   readingList MQTT2_FHEM_Server:wican/dc547550c9e9/can/tx:.* { json2nameValue($EVENT) }
MQTT2_FHEM_Server:ESP32_50C9E8_wican/dc547550c9e9/can/tx:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    read_SoC:noArg wican/dc547550c9e9/can/tx {"bus":"0","type":"tx","frame":[{"id":2021,"dlc":8,"rtr":false,"extd":false,"data":[3,34,2,140,170,170,170,170]}]}
   userReadings SoC {return sprintf("%.0f", ReadingsNum($NAME, 'frame_1_data_4', 0) * 100 / 255)}
   verbose    2
Ich würde die Aktualisierung jedoch gerne direkt aus FHEM anstoßen. Das setList-Kommando aus dem Device-List habe ich zunächst mit mehr Leerzeichen gehabt und diese Leerzeichen zu Testzwecken entfernt.

Ich mache bestimmt irgendwas ganz dämliches falsch, komme aber leider auf keinen grünen Zweig.

Kann mir bitte jemand einen Denkanstoß geben? Danke im Voraus für Eure Hilfe!

[JensS]

Sieht soweit gut aus. 
Probier mal:

Code Auswählen Erweitern

set MQTT2_FHEM_Server publish wican/dc547550c9e9/can/tx {"bus":"0","type":"tx","frame":[{"id":2021,"dlc":8,"rtr":false,"extd":false,"data":[3,34,2,140,170,170,170,170]}]}  Evtl. hilft es, das IODev-Atrribut zu setzen.

Code Auswählen Erweitern

attr MQTT2_meatPI IODev  MQTT2_FHEM_Server
Gruß Jens

[mähschaf]

Hallo Jens,

erstmal ein großes Danke für Deine Hilfe!

Ich habe totalen Blödsinn gemacht und weiß gar nicht, wo ich anfangen soll:

1. Das zweite MQTT2_DEVICE habe ich selber angelegt, indem ich den mqtt_publish abgesetzt habe.

2. Die vermeintliche Antwort war in Wirklichkeit mein Publish

3. Ich habe auch noch die falschen Werte kopiert. Die richtigen finden sich hier.

Nachdem ich das bereinigt hatte, musste ich noch verstehen, dass die Antwort des wican nur Millisekunden sichtbar ist, bevor sie wieder überschrieben wird. Deshalb musste ich das Userreading anpassen.

So sieht es jetzt aus, und ich glaube, es funktioniert:

Code Auswählen Erweitern

Internals:
   CID        ESP32_50C9E8
   DEF        ESP32_50C9E8
   FUUID      654d0590-f33f-2b6d-f815-d56559318e4b5283
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_CONN MQTT2_FHEM_Server_192.168.5.133_63934
   MQTT2_FHEM_Server_MSGCNT 8162
   MQTT2_FHEM_Server_TIME 2023-11-09 21:03:40
   MSGCNT     8162
   NAME       MQTT2_ESP32_50C9E8
   NR         73222
   STATE      online
   TYPE       MQTT2_DEVICE
   eventCount 8165
   READINGS:
     2023-11-09 17:15:12   IODev           MQTT2_FHEM_Server
     2023-11-09 21:02:42   SoC             62
     2023-11-09 21:03:40   bus             0
     2023-11-09 21:03:40   frame_1_data_1  32
     2023-11-09 21:03:40   frame_1_data_2  16
     2023-11-09 21:03:40   frame_1_data_3  0
     2023-11-09 21:03:40   frame_1_data_4  0
     2023-11-09 21:03:40   frame_1_data_5  0
     2023-11-09 21:03:40   frame_1_data_6  0
     2023-11-09 21:03:40   frame_1_data_7  0
     2023-11-09 21:03:40   frame_1_data_8  0
     2023-11-09 21:03:40   frame_1_dlc     8
     2023-11-09 21:03:40   frame_1_extd    true
     2023-11-09 21:03:40   frame_1_id      401604624
     2023-11-09 21:03:40   frame_1_rtr     false
     2023-11-09 21:02:42   state           read_SoC
     2023-11-09 20:03:33   status          online
     2023-11-09 17:15:12   subscriptions   wican/dc547550c9e9/can/tx
     2023-11-09 21:03:40   ts              10940
     2023-11-09 21:03:40   type            rx
   hmccu:
Attributes:
   DbLogExclude .*
   event-on-change-reading .*
   event-on-update-reading status,type
   readingList ESP32_50C9E8:wican/dc547550c9e9/status:.* { json2nameValue($EVENT) }
ESP32_50C9E8:wican/dc547550c9e9/can/rx:.* { json2nameValue($EVENT) }
   room       Garten->Garage
   setList    read_SoC:noArg wican/dc547550c9e9/can/tx {"bus":"0","type":"tx","frame":[{"id":2015,"dlc":8,"rtr":false,"extd":false,"data":[2,1,91,170,170,170,170,170]}]}
   stateFormat status
   userReadings SoC:frame_1_data_4:.* {
if (ReadingsNum($NAME, 'frame_1_data_1', 0)  == 3 and ReadingsNum($NAME, 'frame_1_data_2', 0) == 65 and ReadingsNum($NAME, 'frame_1_data_3', 0) == 91) {
return sprintf("%.0f", ReadingsNum($NAME, 'frame_1_data_4', 0) * 100 / 255)
} else {
return ReadingsNum($NAME, 'SoC', 0)
}
}
   verbose    2
Manchmal ist man (bin ich) einfach nur zu blöd 

Danke!
Martin

[mähschaf]

gelöst

edit: sorry, kann das Thema irgendwie technisch nicht auf gelöst setzen?

[JensS]

Einfach den Betreff des ersten Posts editieren.

Gruß Jens

[beaune]

ich hab mir auch gerade den MeatPI Dongle angeschafft und bin an Erfahrungen interessiert. Eine Frage hätte ich zu dem Userreading, mit dem das SoC-Reading erzeugt wird: Jedes Byte des CAN-Telegramms erzeugt anscheinend ein eigenes Reading. Und wenn man sich die Events anschaut sieht man, dass die Reihenfolge immer mal wieder variiert. Muß man nicht irgendwie sicherstellen, dass man im Userreading die Bytes aus demselben CAN-Telegramm miteinander verknüpft? Gibt es ne chicke Methode, wie man hier die Readings mit demselben Zeitstempel erwischt? Oder läßt sich im MeatPI irgendwas konfigurieren, dass er immer ganze Telegramme als MQTT-Nachricht verschickt? Dann müßte man das zwar selbst zerlegen, wär aber sicher, dass die Bytes konsistent sind. Hat hier jemand Ideen?

[mcscotty]

Hallo Martin,

Dein Beitrag ist zwar schon eine Weile her und eigentlich auch gelöst. Trotzdem ist mir eine Sache noch nicht klar: Du hast geschrieben:

Nachdem ich das bereinigt hatte, musste ich noch verstehen, dass die Antwort des wican nur Millisekunden sichtbar ist, bevor sie wieder überschrieben wird. Deshalb musste ich das Userreading anpassen.

Genau das Problem habe ich auch. Wenn ich den SoC abfrage, dann sehe ich als Antwort immer das hier

bus             0
frame_1_data_1  32
frame_1_data_2  16
frame_1_data_3  0
frame_1_data_4  0
frame_1_data_5  0
frame_1_data_6  0
frame_1_data_7  0
frame_1_data_8  0
frame_1_dlc     8
frame_1_extd    true
frame_1_id      c
frame_1_rtr     false

und nicht wie erwartet das Byte 4 der ID 2029. Wenn ich Dich richtig verstehe, dann wird die ID 2029 zwar übermittelt, aber nach Millisekunden von dem Telegramm mit der extended ID 401604624 überschrieben? Ist das so richtig?

Gruß Thomas

[mähschaf]

Hallo Thomas,

Mit Telegrammen und IDs (z. B. die von Dir erwähnte 2029) kenne ich mich jetzt nicht so richtig aus, aber vielleicht bekommen wir es ja hin.

Was Du siehst (bzw. gepostet hast) ist nicht die Antwort auf die Abfrage des SoC, sondern quasi der Grundzustand. Das gleiche sehe ich aktuell auch, wenn ich keine Abfrage sende.

Sobald die Abfrage gestellt ist, wird sie in wenigen Millisekunden beantwortet, dann aber direkt wieder vom "Grundzustand" überschrieben. Hätte ich die Readings nicht flackern sehen, wäre ich darauf gar nicht gekommen. Im Antworttelegramm des meatPi auf die SoC-Anfrage hat data_1 immer den Wert 3, data_2 den Wert 65 und data_3 den Wert 91. Die Herausforderung besteht nun darin, diesen nur für Millisekunden verfügbaren Zustand in ein Reading zu "retten", was ich über das Userreading gemacht habe.

Diese Bedingung (data_1 bis data_3) kann man auch im Userreading sehen. In data_4 ist dann der SoC versteckt, den man über eine Formel ermitteln und in ein Reading packen kann.

Wird es so klarer und bekommst Du so die Werte?

Viele Grüße,
Martin

[mcscotty]

Hallo Martin,

vielen Dank für die Rückmeldung. Leider kommt bei mir überhaupt keine brauchbare Antwort, sei sie auch noch so kurz. Ich logge den MQTT Traffic mit MQTT.fx mit. Es kommt pro tx request nur 10x nacheinander das hier {"bus":"0","type":"rx","ts":41300,"frame":[{"id":401604624,"dlc":8,"rtr":false,"extd":true,"data":[32,16,0,0,0,0,0,128]}]}, immer gleich, nur mit jeweils anderer "ts". Auffällig ist auch, dass "extd" immer auf "true" ist, also 29 Bit. Ich habe 2 wican CAN Adapter hier, kann also ein Problem in Verbindung mit dem Adapter ausschließen. Weiterhin habe ich die Abfrage bei 2 Fahrzeugen wechselweise probiert. Gleiches Ergebnis. Mit der Baudrate auf dem CAN habe ich ebenfalls experimentiert. Wenn ich die 500 kBaud nehme, dann kommen Antworten geordnet rein, wenn auch 10x unbrauchbar, wie beschrieben. Wähle ich "Auto", dann kommen diese Antworten mit extrem hoher Frequenz, bestimmt 30-40 pro Sekunde! Wenn ich mit der Frequenz runtergehe kommt gar keine Antwort.

Ich bin erstmal mit meinem Latein am Ende, mir fällt keine Sache ein, die schuld sein könnte. Immerhin scheints bei anderen ja zu funktionieren. Werde vielleicht mal beim meatpi Entwickler anklingeln, vielleicht hat der och eine Idee.

Viele Grüße,
Thomas

[mähschaf]

Hallo Thomas,

poste doch mal ein list von Deinem MQTT2 Server und Deinem meatpi Device.

Vielleicht sehe ich ja was...

[tupol]

Hallo,
vielleicht könnt ihr mir bei einem ähnlichen Thema weiterhelfen: https://forum.fhem.de/index.php?topic=137907.msg1310691#msg1310691