[Twiz O'Meter] Update to firmware 1.80

That is a great list to start with, thanks!

Tun, FW, Reg, ECO Nor: unused
kWh: enery available in the battery
Amp: instant current consumption
RPM: motor rpm
B12: service battery voltage
PN1: state of pin 1 of the extension connector
PN2: state of pin 2 of the extension connector
KmT: dashboard total km
KmR: dashboard km left
KmH: dashboard speed
CEt: charging ETA in minutes
CdK: kWh charged from the begining of the charge
C-T: charger temperature
CKw: charging power
T-T: temperature inside the blackbox
MIN: seconds from last ToM reboot
Acc, AnX, Any, AnZ: gyroscope data

Excellent, thank you! I'm going to tinker some more with it in the coming few days.

Hi, some feedback for having used the ToM for some time now.

* Generally works well.

* Documentation could use an update for the newer firmware version, if you want I can help you with that. I write English technical manuals as part of my job.

* Reduced charging power still sometimes, but not always, still bounces around a lot:



If there's anything I can do to help troubleshoot this, like pull a log file or something, please let me know.

* I've had once or twice that the charge had stopped way lower than the set end-SoC. Like end-SoC set to 85%, but actual SoC was something like 61%. Both times occurred when charging power was reduced, probably to 0,4 or 0,7 kW (because that's what I've used most so far)

* The KmT field in the MQTT message gives the total km as a factor of ten too high. For instance, MQTT message says "KmT": "152112", but actual dashboard odometer says 15211. I can easily correct for that in Home Assistant but it's better when the input data is correct.

* I would like to experiment with sending MQTT messages to the ToM, to set charging power etc, is there any documentation about that? Like the exact topic name, and how the messages should be formatted etc?

PriusTwizy schrieb: * I would like to experiment with sending MQTT messages to the ToM, to set charging power etc, is there any documentation about that? Like the exact topic name, and how the messages should be formatted etc?

I reply at the moment to the last question.

Topic names are:
"ToM/001/set" for abort charging. Payload: "0" (to abort) or "1"
"ToM/002/set" for charge power linit. Payload: "0", "1", "2", "3", "4", "5", "6", "7"
"ToM/003/set" for stop charge at SOC%. Payload: a number between "20" and "100"

"ToM/001/state" returns charging state. Payload: none
"ToM/002/state" returns charge power limit. Payload: none
"ToM/003/state" returns stop charge at SOC%. Payload: none

A possible (small) bug; here in the Netherlands we switched to winter time last weekend. This morning I arrived at work at 07:22, but this is what the Date/Time field showed:



It seems like the ToM didn't switch to winter time. Totally not important to me, the trip data is volatile anyway, and I'm mainly going to look in Home Assistant anyway, but I thought I'd let you know.

PriusTwizy schrieb: * Documentation could use an update for the newer firmware version, if you want I can help you with that. I write English technical manuals as part of my job.

Your help is welcome!

PriusTwizy schrieb: If there's anything I can do to help troubleshoot this, like pull a log file or something, please let me know.

When I'll finish current tasks, I'll try to see if it is possible to improve it.

PriusTwizy schrieb: * The KmT field in the MQTT message gives the total km as a factor of ten too high. For instance, MQTT message says "KmT": "152112", but actual dashboard odometer says 15211. I can easily correct for that in Home Assistant but it's better when the input data is correct.

I'll fix it!

I've finally found a bit of time to start experimenting with sending MQTT to the ToM. But I can't get it to work. See this screenshot:



This is within Home Assistant, I have installed the MQTT addon. On the bottom you can see the last packet of the topic ToM/TopicJson, so listening to packets works fine. However, as you can see I send a 0 to the topic ToM/001/set, which should stop the charging process, correct?

Well, the charge prcoess doesn't stop. I should get some sort of confirmation on topic ToM/001/state, correct? That doesn't arrive, either.

Am I misunderstanding something? Thank you.

Hey, I've made some progress. If I change the charging speed from the webserver, I do receive a confirmation on topic ToM/002/state:



So, the problem seems to lie in what how I send the command to the topics ToM/001/set and ToM/002/set. Does that need some sort of formatting I'm not aware of?

In the web server, I've set the MQTT setting as such, is this correct?

None particular formatting is required.
For topic 001, payoload 0 to abort.
For topic 002 , payload 0 or 1 ... or 7 to set the desired charging level.
For topic 003, payload with two digits of the value you want to set.

I'll look at the code of topic 001 as soon as I'll be at home, may be there is something I don't remember.

All right, thank you. No hurry, I'm just playing around.

The main function (for me) of the ToM works perfectly: ending the charge at 85%.

I checked.
For topic 001, I didn't send the confirmation of the updated state inside the callback function like for the other topics.
The reason is that the changing of the charging state is controlled elsewhere, upon receipt of the stop charging value from the canbus.
Since I rewrote the part of the code I used before to retrieve the Twizy states (charging/stop charging included) and considered that abort charge is performed with a sort of "brutal force", sending some values via the canbus, I think that abort charge isn't followed by the same canbus traffic as a normal stop charging and so ToM doesn't recognize the transition from charging state to another, this means that no update of the charging state is send via mqtt.
It's only a supposition I have to verify.
Anyway, this shouldn't affect abort charge to work properly.
Can you confirm if the charging process really abort or not, despite the missing of the update state confirmation?

Delvecchio schrieb: I checked.
Can you confirm if the charging process really abort or not, despite the missing of the update state confirmation?

When I attempted to abort the charge by sending the 0 via MQTT, I did not get a confirmation via the state topic and the charge did not abort.

When I attempted to abort the charge from the webserver, I got a confirmation via the state topic and the charge aborted.

I am 99% sure that channel 002 reacted exactly the same. Sending MQTT messages did not actually change the charging power.

I did not test channel 003.

@PriusTwizy:
Can you attach the screenshot of your Network settings page of the webUI?
Remind to obfuscate sensible settings.

I tested publishing of a payload to topics 001 / 002 / 003 and ToM reacts as expected.
I think you didn't enable subscribing to topics in the Network settings web page.