[Twiz O'Meter] MQTT data format questions

Ich habe mein TOM gerade auf die Firmware verion 1.45 geupdatet und wollte mal schauen welche Fahrzeugdaten an meinen MQTT Broker übertragen werden und wie ich diese dann über meine Hausautomatisierung anzeigen und weiter verarbeiten kann. Das Datenformat, welches ich vom TOM bekomme unterscheidet sich aber stark von den Datenformaten anderer MQTT Geräte und es lässt sich so nur schwierig weiter verarbeiten. Folgendes ist mir aufgefallen:
1. Die ClientID scheint nicht mit an den MQTT Broker übermittelt zu werden. Im Prinzip wird das Topic ohne ClientID direkt an den MQTT Broker gesendet.
2. Die Daten werden alle in einem einzigen Topic binär übertragen. Andere Geräte übertragen ihre Daten in separaten Untertopics oder als json Struktur.

Mache ich etwas faslch? Oder was kann ich tun um verarbeitbare Daten zu erhalten?

Um mein Problem zu veranschaulichen habe ich einen Screenhot vom MQTT Explorer angehangen:


English version:
I have updated my TOM to firmware version 1.45 and wanted to see which vehicle data is being transmitted to my MQTT broker and how I can then display and process it via my home automation. However, the data format that I get from the TOM is verry different to the data formats of other MQTT devices and is therefore difficult to process further. I recognized the following:
1. The ClientID is not sent to the MQTT Broker. In principle, the topic is sent directly to the MQTT broker without the ClientID.
2. The data will be transferred binary in a single topic. Other devices transmit their data in separate subtopics or as a json structure.

Am I doing something wrong? Or what can I do to get processable data?

Ich fasse mal kurz zusammen, was ich verstanden habe....

Ich ... und... habe... schwierig... Geräte.

Hehe, genau, das dachte ich mir schon. Die wenigsten werden MQTT bei ihrem TOM verwenden. Hatte mir extra WLAN in meinen Carport gelegt (nicht nur für das TOM) und die Hoffnung die Twizy Ladung wie bei der Zoe in OpenHAB visualisieren und steuern zu können. Aber die TOM Daten lassen sich da ziemlich schwer weiter verarbeiten, da sie scheinbar binär übertragen werden. In openHAB (und anderen Homeautomatisierungslösungen) kann man normalerweise jeden Wert vom MQTT Broker über einen separaten Channel abfragen. Naja mal schauen was mir dazu noch einfällt

Und dass das TOM seine ClientID nicht mit sendet ist unschön, da es seine Daten am MQTT Broker so ziemlich unschön und unstrukturiert hinterlässt. Das sieht man schön auf dem Screenshot.

Die AhoyDTU vom Screenshot ist im übrigen auch ein auf einem ESP32 basierendes Open Source Projekt, um Hoymiles Wechselrichter per Funk auslesen zu können: github.com/lumapu/ahoy

The AhoyDTU (to be seen on my screenshot in the first post) is also an ESP32 open source project, to read out Hoymiles pv inverter via the built-in radio module. See: github.com/lumapu/ahoy

maikt schrieb: 1. The ClientID is not sent to the MQTT Broker. In principle, the topic is sent directly to the MQTT broker without the ClientID.

ClientID is sent. It's named "TwizOmeter".

maikt schrieb: 2. The data will be transferred binary in a single topic. Other devices transmit their data in separate subtopics or as a json structure.

Correct, the payload is sent binary, in one topic.
You have to process it on the receiving devices.
Splitting in subtopic would be complicated for the number of values sent (now about 70).
If you explain me how you want to elaborate data for your home automation, I can try to help you to decode ToM payload.

TwizyChrisy schrieb: Ich fasse mal kurz zusammen, was ich verstanden habe....

Ich ... und... habe... schwierig... Geräte.

TC, wir können besser Hardware.
Laß die Hausautomaten mal den Akku mit 2 Blechrampen ausbauen.

dingdong schrieb:

TwizyChrisy schrieb: Ich fasse mal kurz zusammen, was ich verstanden habe....

Ich ... und... habe... schwierig... Geräte.

TC, wir können besser Hardware.
Laß die Hausautomaten mal den Akku mit 2 Blechrampen ausbauen.

Wär auch langweilig wenn alle alles könnten.....

Delvecchio schrieb: ClientID is sent. It's named "TwizOmeter".

OK, but can you check it with the MQTT Explorer? On my MQTT Broker, I can't see the ClientID, see my screenshot in the first post

Delvecchio schrieb: Correct, the payload is sent binary, in one topic.
You have to process it on the receiving devices.
Splitting in subtopic would be complicated for the number of values sent (now about 70).
If you explain me how you want to elaborate data for your home automation, I can try to help you to decode ToM payload.

OK, and would it be possible to send the data as json string? Thanks

I would like to visualize some data on my home automation and stop the loading process at a defined value. It would be cool if you could also specify the charging power via MQTT

dingdong schrieb:

TwizyChrisy schrieb: Ich fasse mal kurz zusammen, was ich verstanden habe....

Ich ... und... habe... schwierig... Geräte.

TC, wir können besser Hardware.
Laß die Hausautomaten mal den Akku mit 2 Blechrampen ausbauen.

Null Problemo, an der Hardware bau ich auch gern, eben alles was Spaß macht

maikt schrieb: I would like to visualize some data on my home automation and stop the loading process at a defined value. It would be cool if you could also specify the charging power via MQTT

All valued managed by ToM are already available via Mqtt (about 70), charging power included.
For json string, dou you mean something like this:
{ "SOC": "98%", "SOH": "100%"} ?
In case, I can try to compile a ToM fw version which sends a short json string and if it works, I'll do for all the values,
Have you time to test it?

Yes, that would be great, thanks

Here it is!
As you can see in the picture, ClientID is sent, but it ìs shown by the receiver app only in case of non binary payload. The blanked payload, with a strange date, are the binary ones.

You can OTA update the fw (after extraction from the archive). Keep in mind this is a "test version", with other addings under development. So it could be unstable.
Values name is restricted to 3 digits for my convenience, I hope this isn't a problem, because wouldn't be easy for me adding others digits.
"XXX" element is a check control, 255 means you are receiving all the values.
I looking forward to receive news from you, in order to proceed with the other values

Oh thanks, I will check it...

So, I updated the device via ESP32 flashing tool because somehow the OTA update didn't work. But now I can see the new "TopicJson" with the new json data

But strangely I still don't see a ClientID.

Now (tomorrow) I will look how I can use the json data in OpenHAb. But I know that this has to work, just not yet how.

By the way, the web interface (and everything else) turned out pretty cool

Ahh, the MQTT Explorer doesn't show the ClientID, but the MQTT prefix. It just had the same name: