Hallo und guten Abend.
ich habe mir einen meatPI https://github.com/meatpiHQ/wican-fw#mqtt (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 (https://forum.fhem.de/index.php?topic=106753.0) Thread eine Anleitung gefunden, wie ich den Payload senden können sollte. Dachte ich jedenfalls.
Den Publish habe ich von hier (https://openwb.de/forum/viewtopic.php?t=4820) geklaut. Der funktioniert auch super - so lange ich dafür dieses Kommando auf Linux absetze:
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:
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!
Sieht soweit gut aus.
Probier mal:
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.
attr MQTT2_meatPI IODev MQTT2_FHEM_Server
Gruß Jens
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 (https://github.com/meatpiHQ/wican-fw#6-request-battery-soc-mqtt-example).
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:
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
gelöst
edit: sorry, kann das Thema irgendwie technisch nicht auf gelöst setzen?
Einfach den Betreff des ersten Posts editieren.
Gruß Jens
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?
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
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
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
Hallo Thomas,
poste doch mal ein list von Deinem MQTT2 Server und Deinem meatpi Device.
Vielleicht sehe ich ja was...
Hallo,
vielleicht könnt ihr mir bei einem ähnlichen Thema weiterhelfen: https://forum.fhem.de/index.php?topic=137907.msg1310691#msg1310691