[Ovmsdev] Ioniq 5 - Pushing up some prerequisite changes to components/vehicles

[Michael Geddes]

Hi all,

I have 6 commits that I would _like_ to get pushed up that are changes to
components/vehicles required for my Ioniq 5 changes to work.

I can push them all up in a single merge request for review, or separate
them out into bits.  Some of them I am expecting there to be opinions on.
I'm prepared to simplify some, and one in particular has grounds for
nixing. I think it's a good change, but I could manage without it.

One is a simple bugfix - a literal one-character change:
void OvmsVehicle::BmsRestartCellTemperatures()
   {
   m_bms_bitset_t.clear();
-  m_bms_bitset_v.resize(m_bms_readings_t);
+  m_bms_bitset_t.resize(m_bms_readings_t);
   m_bms_bitset_ct = 0;
   }

On is a simple code readability change. Using an enum instead of magic
status values for m_bms_talerts.  Simple enough, but I'm prepared to
simplify that to a standard enum or get rid of it.

There's some battery related ones where I want to be able to not quite know
the number of cells from the start and let the OBD responses specify.

There's also a battery one where the info for the cells have different
timings (because one has other info), so I want to be able to clear a range
of cells rather than just reset and start filling the info again.

I've modified slightly the dump for the battery cell voltage/temperature,
allowing for either or both columns to be visible if available. It also
copes with the above 'not set' scenario.

Finally, the controversial one:  I am using std::vector<uint8_t> as a
buffer in my ioniq5 code.. and I wanted to be able to use it for the
polling instead of std::string. I've not replaced the std::string but added
the ability to have either.

If my aversion to using std::string for binary data is misplaced, then I'm
ok with the currently small modification to my code that would use the
std::string version.

Thoughts? Shall I just push the code up to my own repo? Merge request?

//.ichael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20221019/6ab02c55/attachment.htm>