[Twiz O'Meter] MQTT data format questions

Delvecchio schrieb: You are right. I totaly forgot a piece of code!

Unfortunately, the ddd still cannot be activated.

Delvecchio schrieb: Yes, this happens for the same reason.
ToM switches off when there isn't traffic on the canbus for more than 500msec, so it's possibile that if a payload is sent during that period all values are zeroed.
If this is a problem, I can try to invent something to prevent it. But I'm not sure to succeed.

Yes, that's a problem because the GUI only shows valid data when the TOM is active. Can you check the data for plausibility before sending it? One or two (first and last) values are definitely enough.

maikt schrieb: Unfortunately, the ddd still cannot be activated.

It works in my ToM. Exactly what does it happen with your ToM? Can't you flag the checkbox or isn't the flag retained?

maikt schrieb: Can you check the data for plausibility before sending it? One or two (first and last) values are definitely enough.

I followed your suggestion, but checking SOC and SOH. If both are greater than 0, the payload is sent. I didn't test it because today my mqtt broker is down.
Anyway I enclose it.

Now I can activate the Json payload und it works

But C13 is still missing.

maikt schrieb: But C13 is still missing.

Found the bug: a "break" missing in a switch case. So C13 was skipped.
I hope this is the right time!

Hey, it works great, thanks

Is it possible, that the setting for the MQTT "Publish Frequency (ms)" does has no effect? I get data multiple times per second even though I set 15000ms.

maikt schrieb: Is it possible, that the setting for the MQTT "Publish Frequency (ms)" does has no effect? I get data multiple times per second even though I set 15000ms.

After some tests, it seems to me the publishing frequency is correct.
Give a look at the following screenshot

"TopicJoson" was published by Tom of my Twizy, parked in the garage, during background charging.
Instead, "Arduino/TwizyOmeter" was published by another ToM I was testing.
Is "Arduino" what you mean for "clientID" ?

Delvecchio schrieb: After some tests, it seems to me the publishing frequency is correct.
Give a look at the following screenshot

Very strange. I have set 15s refresh interval and I get multiple refreshes per second. But 5s also didn't work. See Screenshot

Delvecchio schrieb: "TopicJoson" was published by Tom of my Twizy, parked in the garage, during background charging.
Instead, "Arduino/TwizyOmeter" was published by another ToM I was testing.
Is "Arduino" what you mean for "clientID" ?

Basically, that's what I mean. The data from the TOM should be grouped to the entry TwizyOMeter. Like e.g. the data from Shelly in my screenshot. Or "TwizyOMeter > state > raw" and "TwizyOMeter > state > json" (just as an example)

maikt schrieb: Basically, that's what I mean. The data from the TOM should be grouped to the entry TwizyOMeter.

To achieve this, I simply added "Arduino/" in the topic field.
But Json topic is hardcoded (it hasn't its customizable field).
So... in this moment, the only idea I have is to add a checkbox in the webserver, for adding the ClientID before the topic name, as part of it. What about?

About publishing frequency, I'll check. May be there is something wrong only in Json publishing.

Delvecchio schrieb: So... in this moment, the only idea I have is to add a checkbox in the webserver, for adding the ClientID before the topic name, as part of it. What about?

OK, but the client ID can also always be sent for all TOM data (without a separate check box). All MQTT devices I know do at least that way.

I have to think about, to check if there are some side effects (for sure, for example, the android app would have to be updated).

Delvecchio schrieb:

Sherlock schrieb: I'll test it in a few days.

Sherlock, be aware: this version is previous the expansion pins fix!
It was intended only for testing the full Json payload, with all the values.

Many thanks Fabio,

I will better not test it

I noticed today that my TOM with firmware Json-5 sometimes turns on and then sends permanent partially empty data to the MQTT broker:

{ "XXX": "255", "SOC": "97.5", "SOH": "100", "B-T": "", "M-T": "", "Tun": "", "kWh": "6.0", "Amp": "0", "RPM": "", "Nm ": "", "FW ": "", "C01": "4.11", "C02": "4.11", "C03": "4.11", "C04": "4.11", "C05": "4.11", "C06": "4.11", "C07": "4.11", "C08": "4.11", "C09": "4.11", "C10": "4.11", "C11": "4.11", "C12": "4.11", "C13": "4.11", "C14": "4.11", "Pac": "57.5", "T01": "22", "T02": "22", "T03": "22", "T04": "22", "T05": "22", "T06": "22", "T07": "22", "Reg": "", "ECO": "", "Nor": "", "Spo": "", "CSt": "0", "tAY": "", "B12": "", "PN1": "", "PN2": "", "KmT": "", "KmR": "", "KmH": "", "SeT": "", "tKT": "", "tKR": "", "tTM": "", "tKW": "", "t10": "", "t01": "", "tMN": "", "tKH": "", "kW ": "0.00", "CEt": "", "CdK": "", "C-T": "24", "CKw": "", "Min": "", "T-T": "", "Acc": "", "AnX": "", "AnY": "", "AnZ": "" }

If you have the new battery charger (the one which keep charged the service battery), it's normal and it's due to the background charging of the service battery.
In those moments the LCD is dark (not enlighted).
You can check this with "CSt": "0".
At the moment if its value is 1, traction battery charging is in progress; in the other cases is 0. I'll soon add a specific value (CSt": "2") for background charging of the service battery.

OK, thanks But why are some data empty?

I think because during this process, only some devices send their parameters via the canbus.
As you can see, are available only the data concerning the traction battery.
It should be available also the 12v battery, but, as I retrieve it (with other values) with a specific request over the canbus, this task is performed only when ToM is switched on.
But, I can check if I can retrieve it also during backgroung charging: it could have sense since background charging is meant to charge the service battery.