[Twiz O'Meter] Update to firmware 1.80

Since I received a few reports of occasional failures to power on ToM in certain hardware configurations, especially after prolonged periods of parking, I decided to rewrite a significant part of the code that handles the startup, the recognition of the Twizy states and the shutdown of the device.
I strongly suggest the update even to those who haven't experienced the above problem, because this new firmware allows an improvement in performance.
.
What is new in firmware 1.80
=================================
- completely rewritten the code that retrieves the Twizy states (off, drive, charge, background charge, etc.)
- improved shutdown speed
- added a safety check that prevents ToM from occasionally failures to power on in certain hardware configurations, especially after prolonged periods of parking
.
Bug fixed:
=================================
- solved the problem which prevented the charge control limit from working properly in fw 1.70 and later
.
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 (or to the hotspot of your phone, if your Wi-Fi network is out of range) before attempting to load the web server main page.
.
Special thanks goes to:
=================================
Snorre, as usual, for helping me in testing the new firmware and for his costant suggestions and contribution of ideas
Daniel for discovering the charge control limit problem and testing the new fw patch
.
Updating procedure:
=================================
To install the new fw you have to update the Blackbox 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 before to 1.4 (or 1.45) fw version, following the specific instructions reported in 1.4 / 1.45 topic, and only then to 1.6 fw.

And please, once again, you have to strictly follow all the mentioned steps!!!

That's all... for now!

My Twiz O'Meter has just arrived in the mail!

Where can I find the latest user manual please?

This is the last and only version available.
For the new functions, you have to read in the publishing topic of each firmware release.
Sooner or later I'll update the manual. I promise it!

Hi Delvecchio,

I have received the Twin O'Meter, thank you!

I've tested it out a little bit and I have some feedback/questions.

1. One of the features I wanted to have the most was limiting the charge power so that I could use more of our solar power. Setting it manually is easy, and does work - somewhat. However, it behaves in a way that I do not understand. I'll show a picture first, as that should say more than thousand words.



The top graph displays the power draw of the Twizy charging (in blue) and how much the solar panels are producing (in purple). The bottom graph show how much our household is drawing from the electrical grid (in blue) or how much were feeding back into the grid (in purple). Because the first two are measured in watts, and the last two in kilowatts, they end up in different graphs.

As you can see I started charging the Twizy at 11:43. In the ToM I had limited the charging power too 0,7kW. As you can see, every 6 minutes, there's a spike where it starts drawing its full 2+ kW for 50-55 seconds, and then drops back to 0,7 kW again. In between there are also smaller/ shorter spikes, but interestingly, these almost disappear after around 12:33. Then, at 13:23, I increased the charging power to 1 kW because I saw we were still feeding back solar power into the grid. It did raise the power to 1 kW, and continued to display the spikes every 6 six minutes. Until, at around 13:38 it starting bouncing wildly between 1 kW and 2 kW. It did that until 13:57, where it returned to the "one big 2 kW spike" behaviour again. It then continued to charge until 14:06, where it cut off at the 85% SoC I had set it to.

What I'm curious about is, what causes these spikes? The way it behaves, it still should help me use more solar power and less grid power, but the spikes will still cause some power to come from the grid.

If it would help you I can export the data behind these graphs into a csv file and send them to you.

2. Before the charging session above I had set the charge end point at 85% in the ToM. I was cleaning the Twizy, so I could occasionally check the percent meter on the dashboard, and I saw it go from 82-83-84-dark. So I'm pretty sure it stopped around the 85% mark. I think (but am not completely sure) that I also saw something like 85.3% SoC on the ToM's display. Good.

However, I then disconnected the charging cable, and started up the Twizy, I noticed that all the bars in the battery meter were filled up. I then checked the ToM, and saw that the Twizy was actually charged to 95.9%:



Any idea what could have gone wrong there?

Thanks for the feedback
Since I know you were interested in charging control, I flashed in the second partition version 1.65.
Can you boot from this partition and make the same test, reporting back the results?

Anyway, spikes are a side effects of the way the control current limit is achieved.
ToM rewrite on the fly the current level trasmitted in the canbus and periodicaly the original value prevails.

About stopSOC I don't know.
Can you try to test a control type at a time?
And then test stopSOC together with current limit, without changing the level via mqqt?

So I'll a complete visione where to search for fixing.

Hi.

I`ll give you some answers to your questions to save a Fabio some time.

Update:
I was too late, Fabio already answered!

-> 2.
I`m quite sure that ToM aborted charging at SOC 85,00%.
ToM continously reads the SOC value on the CAN bus, that is provided by the Twizy BMS.
When BMS "said": "now SOC 85% is reached", ToM aborted charging!
After you disconnected the plug and started the Twizy, the BMS checked all battery values and calculated the SOC value again.
Altough the values haven`t changed significant since the end of charging, it now "says": "Oh, SOC is at 95,9 %".
So this is not a problem of ToM, but of the Twizy BMS.
You will find lots of posts describing this when you search the forum for "SOC-Sprung" or "SOC-Sprünge" .
A SOC jump value of more than 10% is not so often, but not unusual.
You can do the following test:
Do a trip with the Twizy, at the end immediately turn it off, but remember the SOC,
Then wait 10 - 15 minutes, turn on the Twizy again and you`ll see that the SOC has again changed.
Probably less than 10%, but itś the same effect.

-> 1.
The spikes every 6 minutes are known too.
Usually they last only around 20 second.
What happened around 13:38 till 13:57 to me is yet unkown.
Maybe Fabio will be able to optimize this a bit.

However, I then disconnected the charging cable, and started up the Twizy, I noticed that all the bars in the battery meter were filled up. I then checked the ToM, and saw that the Twizy was actually charged to 95.9%:

On my Twizy, the "true" SOC display is reached after about 3-5 minutes of drive (at least if the battery was not charged fully). Right after charging or even after the Twizy was "resting" a while (thus parking switched off after e.g. a 40% drive) the SOC is always some 5-8% too high.

Thanks for the feedback everybody! I didn't know how the power limiting worked, I assumed the ToM would just order the charger to limit the power once, but I now understand that the charger coninuously tries to raise the power to the maximum, and the ToM keeps lowering it. While not 100% effective, this is still helpful in using more of my solar power directly.

I may have time to do another test Thursday. Coming few days I only charge at work, and I don't have the ToM mounted permanently yet.

Delvecchio schrieb: About stopSOC I don't know.
Can you try to test a control type at a time?
And then test stopSOC together with current limit, without changing the level via mqqt?

I don't use mqqt (yet), I found out I need to buy a wifi extender to reach my Twizy when it's parked. Do I understand correctly you'd like me to set a maximum SoC and a charge current limit simultaneously? That what I did in the first test so that is fine. When I've done such a test, I'll report back.

PriusTwizy schrieb: Do I understand correctly you'd like me to set a maximum SoC and a charge current limit simultaneously? That what I did in the first test so that is fine. When I've done such a test, I'll report back.

I meant before to try separatly and then together. Just to exlude that there is a problem of interaction between the two controls while running together.

Okee dokee, now I understand. I will test and I will report back.

Today I finally had some time to play with my ToM. The sun is lower in the sky now, so the solar panels are not producing as much as they did during the summer, so I limited the charging power to 0,7kW during this session:



The purple line is the dishwasher, I manually switched off charging when it started heating water, and switched charging back on when that stopped. I manually stopped charging at the end when I had to use the Twizy.

It seems to have worked as you explained. The ToM tries to keep the charging power at 0,7kW, but the Twizy's charger keeps fighting that and wins for a short time about every six minutes. It would be great if this could be improved, but I can live with this. This will greatly increase the amount of energy the Twizy will draw from my solar panels.

I'll see if I can perform experiment two tomorrow or Monday; no power limit, SoC limit set at a value < 100% and see if the set SoC is kept.

I did try the trip monitor today:



That is all interesting information! I don't quite understand, however, why the same information is not showing on the ToM's web pages:



I need to study the user manual some more.

PriusTwizy schrieb: I don't quite understand, however, why the same information is not showing on the ToM's web pages:

Starting from Fw 1.5, if you select trip number 5 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 indipendently and aren't saved.

Thank you for that explanation! I was wondering what that long empty list at the bottom of the web page was for, and I couldn't find it in the manual. Now I know. I think I'll leave the ToM on trip 5 now

I did some charge experiments over the weekend:

• Charging with reduced power and without a set end-SoC: normal beheviour with the expected 2kW peaks every few minutes. No weird short ones.
• Charging at full 2 kW power and to 100%: same, expected behaviour.
• Charging with reduced power and the end-SoC set at 85%: same, expected behaviour. Shortly after the charge finished, the SoC read 85.1%, and when I checked about 2 hours later, it read 91%. So again, this is as expected.

So it seems like the odd behaviour that I had last week was a fluke, it seems to work perfectly as designed.

Next step (for me) is to order a wifi extender so that the Twizy has solid network connectivity when it's parked at home, and then I can start to tinker with MQTT/Home Assistant.

I finally found the time to tinker with networking / MQTT / Home Assistant.

I'll save you the difficulties I had in getting sufficent wifi-signal on my driveway, something I still have not fully solved. I work with ESP32s a lot, and the pcb antennas are simply not great.

In any case, I've set up NAT on my router to expose my MQTT broker (I'm using the HA addon) to the internet, so no matter how the Twizy is connected, it can connect to my MQTT broker. When I had these things configured, it was easy to configure a sensor in HA, in this case SoC:



(as you can see, when set to a charge power limit of 0,7 kW, the actual power drawn still jumps around... when it briefly goes to zero is because I switched off the power briefly, to test something)

But I'm happy that I now at least to have the MQTT basics configured. Tomorrow, when I'll drive to work, I'll see how such a drive looks in HA. I love graphs and numbers, so I think this is great!

Is there a list with what all the json entries mean? I can guess a few, but not all:

{ "XXX": "255", "SOC": "46.7", "SOH": "100", "B-T": "20.14", "M-T": "", "Tun": "", "kWh": "2.8", "Amp": "11", "RPM": "", "Nm ": "", "FW ": "", "C01": "3.91", "C02": "3.91", "C03": "3.91", "C04": "3.91", "C05": "3.91", "C06": "3.90", "C07": "3.91", "C08": "3.91", "C09": "3.91", "C10": "3.91", "C11": "3.91", "C12": "3.91", "C13": "3.91", "C14": "3.91", "Pac": "54.70", "T01": "21", "T02": "20", "T03": "20", "T04": "20", "T05": "20", "T06": "20", "T07": "20", "Reg": "", "ECO": "", "Nor": "0", "220": "1", "CSt": "1", "tAY": "", "B12": "13.81", "PN1": "1", "PN2": "0", "KmT": "150253", "KmR": "9", "KmH": "0.0", "SeT": "", "tKT": "", "tKR": "", "tTM": "", "tKW": "", "t10": "", "t01": "", "tMN": "", "tKH": "", "kW ": "0.69", "CEt": "101", "CdK": "0.9", "C-T": "49", "CKw": "0.69", "Min": " 3728", "T-T": "20.00", "Acc": "0.43", "AnX": "46.34", "AnY": "-2.34", "AnZ": "-4139.53" }

PriusTwizy schrieb: I finally found the time to tinker with networking / MQTT / Home Assistant.


Is there a list with what all the json entries mean? I can guess a few, but not all:

{ "XXX": "255", "SOC": "46.7", "SOH": "100", "B-T": "20.14", "M-T": "", "Tun": "", "kWh": "2.8", "Amp": "11", "RPM": "", "Nm ": "", "FW ": "", "C01": "3.91", "C02": "3.91", "C03": "3.91", "C04": "3.91", "C05": "3.91", "C06": "3.90", "C07": "3.91", "C08": "3.91", "C09": "3.91", "C10": "3.91", "C11": "3.91", "C12": "3.91", "C13": "3.91", "C14": "3.91", "Pac": "54.70", "T01": "21", "T02": "20", "T03": "20", "T04": "20", "T05": "20", "T06": "20", "T07": "20", "Reg": "", "ECO": "", "Nor": "0", "220": "1", "CSt": "1", "tAY": "", "B12": "13.81", "PN1": "1", "PN2": "0", "KmT": "150253", "KmR": "9", "KmH": "0.0", "SeT": "", "tKT": "", "tKR": "", "tTM": "", "tKW": "", "t10": "", "t01": "", "tMN": "", "tKH": "", "kW ": "0.69", "CEt": "101", "CdK": "0.9", "C-T": "49", "CKw": "0.69", "Min": " 3728", "T-T": "20.00", "Acc": "0.43", "AnX": "46.34", "AnY": "-2.34", "AnZ": "-4139.53" }

Ich hatte mir einmal diese Zusammenstellung gemacht:

Raw payload is in this format: 3 digits (=bytes) for the name and 8 digits (=bytes) for the value
- C01 - to C14 are battery cells value
- SoC – State of Charge
- SoH – State of health
- T01 - T07 are battery temperature sensors value
- Pac is total battery voltage
- Cst is charging state
- 220 is main plug state
- SeT sevcom temperature
- starting with t are Trip values