[Twiz O'Meter] Update to firmware 1.5

Hi everyone.
.
Time has come for a new firmware release!
.
In this fw you will find not only bug fixes, but a new trip mode with trips log and an huge improvement of the expansion port, for adding support to new accessories (the steering wheel buttons to control ToM) and external devices (auxiliary charger fan & reku stop light).
.
So, read the changelog to know in details what I'm discussing about. It's worth it!
.
What is new in firmware 1.5
=================================
- changed the way that Trip nr. 5 works. Now, if you select this trip number you'll enable an individual trip recording log. Each time you switch On and Off your Twizy to take a trip, the trip data will be added to the log. 20 trips can be saved. When exceed, the old ones will be overwritten. Trip nr. 1/4 work as before
- added the Trip log to webserver trip page
- added storing of fw files name updated via OTA and showing them in the webserver
- added additional Json payload over mqtt, for simplify integration in home automation. You can activate it from the webserver
- added the possibility to force a wi-fi connection attempt by tapping on the wi-fi or mqtt tray icons
- added support for steering wheel buttons to control ToM. It's needed an IR receiver sensor (connected to the expansion port), and a IR steering wheel remote controller
- redrawn webserver expansion port page for configuring IR sensor option.
- added in that page a receiver monitor for discovering IR codes. This will allow the use of different IR controller, with different codes database.
- when using pin1/2 as output, now it's possible to choose between a few types of specific device connected: "normal", for a standard device (like a relais module), "Charger aux fan", for auxiliary charger fan support, "Reku brake light", for brake light support during recuperation.
.
Bug fixed:
=================================
- proud to list that, after so much tries & tests by Snorre, a compatibility problem with OVMS, which sometimes caused ToM reboots during canbus SDO requests, has been partialy fixed. I wrote "partialy", because there is still a minor problem that, occasionaly, causes OVMS to report fake alerts
- configuration of expansion pins now works as it should
- publishing frequency now always matches the one set. Before, in some cases, publishing frequency wasn't correct
- display of "OnCharge" slider state is now correctly showed on entering in the settings page
- "boot from ..." buttons in webserver OTA page are fully working.
.
Known bugs:
=================================
- Sometimes web server has some troubles to load. In this case, it's helpul to connect your Twiz o'meter to a Wi-Fi network before attempting to load the web server main page.
.
Special thanks goes to:
=================================
- Snorre, for his constant support in ToM development, also in the difficult moments.
- Sherlock, the first one who engaged himself to realize a project for the expansion port, discovering some ToM issues in pins configuration and giving me some improving suggestion.
- Maikt, for the idea of a Json mqtt payload and for the patience to test all the relative beta fw.
- All the other members of this great forum: they spend their time to improve our little T., making it amazing!
.
Updating procedure:
=================================
To install the new fw you have to update both the Blackbox and the LCD display, as explained in detail in ToM manual except for these further instructions:
- coming from 1.4 fw (and later), the Blackbox can be updated also via OTA, without flashing
- coming from previuous versions (1.3 or 1.2) you have to update the Blackbox before to 1.4 (or 1.45) fw version, following the specific instructions reported in 1.4 / 1.45 topics, and only after to 1.5 fw.
.
And please, once again, you have to strictly follow all the mentioned steps!!!

Please, for the update, use the files in the archive attached to this post.
The one in first post has a corrupted file.

Hi Fabio,

Great job as usual. The fans do not start anymore when the engine is running. Perfect !

Thanks. Asap I'll also add a timer for turning off the fans a few minutes later after the charge stops.
How minutes do you prefer?

Delvecchio schrieb: Thanks. Asap I'll also add a timer for turning off the fans a few minutes later after the charge stops.
Howi minutes do you prefer?

It depends on external temperature, charger temperature,... I would say, not more than 10 minutes.

Sherlock schrieb:

Delvecchio schrieb: Thanks. Asap I'll also add a timer for turning off the fans a few minutes later after the charge stops.
Howi minutes do you prefer?

It depends on external temperature, charger temperature,... I would say, not more than 10 minutes.

Will ToM sleep delay be related to charger temperature? I think that would be a good thing, because if at the moment when the charge is stopped the temperature of the charger is lower than that intended for the start-up of the fans, the fans would not start and ToM would be switched on for nothing .
If it is possible from a technical point of view, it would be interesting to have the opportunity to modulate the operating time yourself over a range defined in advance (for example between 0 and 10 min).


Hängt die ToM-Schlafverzögerung mit der Temperatur des Ladegeräts zusammen? Ich denke, dies wäre eine gute Sache, denn wenn in dem Moment in dem das Aufladen gestoppt wird, die Temperatur des Ladegeräts niedriger wäre als die, die für den Start der Lüfter vorgesehen ist, würden diese nicht starten und ToM würde umsonst eingeschaltet sein .
Wenn technisch möglich, wäre es interessant, die Betriebszeit über einen vorab definierten Bereich (z. B. zwischen 0 und 10 Min.) selbst anpassen zu können.

Delay the fans only if the temperature was more than the reference value is in my plans.
Setting an user defined range no, because more complex.
If I remember right, when the charging process stops, there Is no traffic on canbus. So no longer possibility to read charger temperature.
But it should be possible to make the delay lasting more or less according to the last known charger temperature.
Can you give me some ranges for delta temperature / minutes delay?

Delvecchio schrieb: Delay the fans only if the temperature was more than the reference value is in my plans.
Setting an user defined range no, because more complex.
If I remember right, when the charging process stops, there Is no traffic on canbus. So no longer possibility to read charger temperature.
But it should be possible to make the delay lasting more or less according to the last known charger temperature.
Can you give me some ranges for delta temperature / minutes delay?

I would say two minutes per degree over the reference value, with a maximal delay of ten minutes.

Delvecchio schrieb: Please, for the update, use the files in the archive attached to this post.
The one in first post has a corrupted file.

Hello Fabio,

I need your help again.
I can not activate the version 1.5. I have installed both the update via cable and via OTA and booted from the appropriate partion.
However, FW1.4 is still displayed. The function at "5" (driving book) is available. I.e. it is probably still the FW1.4 active.
Do you have a tip for me ?

LG Tom

Hallo Fabio,

ich brauche noch mal deine Hilfe.
Ich kann die Version 1.5 nicht aktivieren. Ich habe sowohl das Update per Kabel eingespielt, als auch per OTA und von der entsprechenden Partion gebootet.
Trotzdem wird immer noch FW1.4 angezeigt. Die Funktion bei "5" (Fahrenbuch) steht zur Verfügung. D.h. es ist wohl weiterhin die FW1.4 aktiv.
Hast du einen Tipp für mich ?

LG Tom

Hi Tom,
if you have the "Trip history log" in the Trip page and if you see the option for "IR controller" in the expansion port page, you have the fw 1.5 running.
Let me know in this case, because it could mean there is a little bug in the fw version string.

@Tom:
Bei dir läuft mit hoher Wahrscheinlichkeit, die aktuellste Firmware.
Dass im LCD 1.4 angezeigt wird, scheint nur ein "optischer" Bug zu sein.

Was mich verwundert ist aber, dass du in der Partition 0 die "Fw15_ESP32.bin" geflasht hast und in der Partion 1 die "Fw15_ESP32.ino.bin"

Wieso hast du zwei unterschiedliche Dateinamen?


@Fabio:
Why is the filename of OTA0 different to the one in OTA1?
Any idea?

Snorre schrieb: @Tom:
Bei dir läuft mit hoher Wahrscheinlichkeit, die aktuellste Firmware.
Dass im LCD 1.4 angezeigt wird, scheint nur ein "optischer" Bug zu sein.

Was mich verwundert ist aber, dass du in der Partition 0 die "Fw15_ESP32.bin" geflasht hast und in der Partion 1 die "Fw15_ESP32.ino.bin"

Wieso hast du zwei unterschiedliche Dateinamen?


@Fabio:
Why is the filename of OTA0 different to the one in OTA1?
Any idea?

...das war nur ein Test mit dem Dateinamen - habe ich umbenannt...
Mich irritiert immer xxxx.xxxx.bin - old School wahrscheinlich...

LG Tom

Ulli-et-Tom schrieb:
...das war nur ein Test mit dem Dateinamen - habe ich umbenannt...
Mich irritiert immer xxxx.xxxx.bin - old School wahrscheinlich...

LG Tom

Okay, dann hat alles geklappt, außer dass da noch 1.4 steht.
In der "special partition" hat diese Firmware aber eigentlich nichts verloren.
Die ist für "höhere Aufgaben" vorgesehen.
Ist aber auch nicht schlimm.

@Fabio:
Problem about the filename is solved.

Snorre schrieb: @Fabio:
Problem about the filename is solved.

Ok. I'll look for the bug in the fw version string.

Delvecchio schrieb: Hi Tom,
if you have the "Trip history log" in the Trip page and if you see the option for "IR controller" in the expansion port page, you have the fw 1.5 running.
Let me know in this case, because it could mean there is a little bug in the fw version string.

Hi Fabio,

Yes, I see "ir controller" I.e. probably indeed that the FW1.5 is active.
You write that under "5" a logbook is logged. Do I see the single trips only in the web service ? Or also directly in the ToM.

LG Tom