This is an example of where I'm headed. This creates and activates a Once-off poll entry that doesn't block (and removes itself from the poll list once it is done).

A success will call Incoming_Full with a std::string buffer and a fail calls Incoming_Fail.

bool OvmsHyundaiIoniqEv::PollRequestVIN()

{

if (!StdMetrics.ms_v_env_awake->AsBool()) {

ESP_LOGV(TAG, "PollRequestVIN: Not Awake Request not sent");

return false;

}

auto poll_entry = std::shared_ptr<OvmsVehicle::OnceOffPoll>(

new OvmsVehicle::OnceOffPoll(m_can1,

std::bind(&OvmsHyundaiIoniqEv::Incoming_Full, this, _1, _2, _3, _4, _5, _6),

std::bind(&OvmsHyundaiIoniqEv::Incoming_Fail, this, _1, _2, _3, _4, _5, _6),

VEHICLE_OBD_BROADCAST_MODULE_TX, VEHICLE_OBD_BROADCAST_MODULE_RX,

VEHICLE_POLL_TYPE_OBDIIVEHICLE, 2,

ISOTP_STD, 0, 3/*retries*/ ));

PollRequest("!xiq.vin", poll_entry);

return true;

}

On Tue, 4 Apr 2023 at 07:13, Michael Geddes <frog@bunyip.wheelycreek.net> wrote:

Hi all,

I was after some feedback on
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/859
which moves the ISOTP polling into what is currently the ISOTP response thread.

This is part of a larger rework I have been doing to add flexibility to the loop and to move the poll-loop operations behind a clean interface.

I'm interested in feedback on the mechanism in the p/r directly, but I'm also happy to provide the usage examples I have (which would be the follow-up commits for Ioniq 5).

I'm also interested in other people's thoughts on where they see what improvements might be had to the poll-list mechanism.

Already Done:

* Clean up the blocking poll mechanism

* Allow for multiple concurrent poll lists (still executed sequentially)

* Add once-off non-blocking poll mechanism

* Add a poll-list that allows repeating more-frequently than the primary poll

Ideas:

* Add a user-configurable poller that could possibly utilise the DBC framework (on top of the existing vehicle framework) to allow exploring/experimenting with both passive data as well as polled data. (Given that the DBC framework already does the heavy lifting of interpreting data - adding a poll request to that seems to be a nice way of going)

* ??? Have a poll thread per bus ???

//.ichael