The one that matters most is OvmsPoller::m_poll_state - as that is the one used in processing. It is possible to set this separately per bus. The one at OvmsPollers level is there if you choose to keep one 'poll-state' and so set the values on all busses together... which is normally the case. It's mostly there so multiple calls to setting poll-state without actually changing the poll-state will not actually have to queue calls. The one at OvmsVehicle is there because that used to be where it sat. It's still there for reading convenience and for non-blocking access to the value.. but it really should always just be a reference copy of the m_poll_state on OvmsPollers. This (on OvmsVehicle) is probably one the one that could easily go. //.ichael On Sun, 23 Feb 2025, 21:25 Chris Box via OvmsDev, < ovmsdev@lists.openvehicles.com> wrote:
Hi everyone
While trying to resolve the Leaf's poll state management, I find myself needing to understand the different levels of poller state that exist in the main (non-vehicle-specific) code.
What is the semantic difference between these?
OvmsVehicle::m_poll_state
OvmsPollers::m_poll_state
OvmsPoller::m_poll_state
To me it appears the first two duplicate each other, and I'm not sure why.
The third one is a little different as it's per poller (i.e. per bus).
If I follow how changes are propagated to these for my car, I see:
OvmsVehicle::PollSetState(state)
This immediately sets OvmsVehicle::m_poll_state = state, and calls:
OvmsPollers::PollSetState(state)
This immediately sets OvmsPollers::m_poll_state = state, and queues a request to set the lowest level states.
When the request is processed, it loops through the buses. For each it calls:
OvmsPoller::Do_PollSetState(state)
This sets this instance's OvmsPoller::m_poll_state = state, and updates some associated variables.
What is the logic behind having so many poll states?
Chris
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev