<div dir="auto">Ah. You did merge those in.<div dir="auto"><br></div><div dir="auto">I'll rebase and out up a request.</div><div dir="auto"><br></div><div dir="auto">Michael </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 27 Apr 2024, 09:04 Michael Geddes, <<a href="mailto:frog@bunyip.wheelycreek.net">frog@bunyip.wheelycreek.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>That's great news, and I can certainly do this. My only concern is that this branch as a whole contains a whole bunch of smaller pieces scattered through it.</div><div><br></div><div>I have raised a number of pull requests over the last week that incorporate various of the things I have added...</div><div>but if you are sure, I can certainly raise it as a single p/r with the branch as-is.</div><div><br></div><div>If you accepted those recent p/r I would then rebase that whole branch before doing the new p/r. But the result would be the same. <br></div><div>Just depends on how you want to track it. Again, I'll follow your lead.</div><div><br></div><div>//.ichael</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 27 Apr 2024 at 00:59, Michael Balzer via OvmsDev <<a href="mailto:ovmsdev@lists.openvehicles.com" target="_blank" rel="noreferrer">ovmsdev@lists.openvehicles.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
Michael,<br>
<br>
I've been using the new poller for two weeks now without issues.
VWTP also works flawlessly.<br>
<br>
I'd say we merge this now, so more tests can be done on a wider
variety of vehicles.<br>
<br>
Can you please update your pull request?<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div>Am 09.04.24 um 04:35 schrieb
<a href="mailto:frog@bunyip.wheelycreek.net" target="_blank" rel="noreferrer">frog@bunyip.wheelycreek.net</a>:<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal"><span style="font-size:11pt">Thanks
Michael,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">I’ve fixed
the register/deregister and also fixed a few issues /
dependencies for compiling when OVMS_COMP_POLLER is not
selected.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">//.ichael<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif" lang="EN-US">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif" lang="EN-US"> OvmsDev
<a href="mailto:ovmsdev-bounces@lists.openvehicles.com" target="_blank" rel="noreferrer"><ovmsdev-bounces@lists.openvehicles.com></a> <b>On
Behalf Of </b>Michael Balzer<br>
<b>Sent:</b> Sunday, April 7, 2024 4:44 PM<br>
<b>To:</b> <a href="mailto:ovmsdev@lists.openvehicles.com" target="_blank" rel="noreferrer">ovmsdev@lists.openvehicles.com</a><br>
<b>Subject:</b> Re: [Ovmsdev] OBD poller module shell
proposal<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-bottom:12pt">Michael,<br>
<br>
I think this…<br>
<br>
<a href="https://github.com/frogonwheels/Open-Vehicle-Monitoring-System-3/blob/new-poller/vehicle/OVMS.V3/components/vehicle/vehicle.cpp#L358" target="_blank" rel="noreferrer">https://github.com/frogonwheels/Open-Vehicle-Monitoring-System-3/blob/new-poller/vehicle/OVMS.V3/components/vehicle/vehicle.cpp#L358</a><br>
<span style="font-family:"Courier New""> MyPollers.<b>RegisterRunFinished</b>(TAG,
std::bind(&OvmsVehicle::PollerStateTickerNotify, this,
_1, _2));</span><br>
<br>
…should be a call to MyPollers.RegisterPollStateTicker()
instead, and OvmsVehicle::ShuttingDown() is missing a call to
DeregisterPollStateTicker().<br>
<br>
Regards,<br>
Michael<br>
<br>
<u></u><u></u></p>
<div>
<p class="MsoNormal">Am 31.03.24 um 01:44 schrieb Michael
Geddes:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal">I have pushed up changes for PR#966 as
well as to the 'new-poller' branch that handle the
PollerStateTicker() <u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">//.ichael<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Sat, 30 Mar 2024 at 08:39, Michael
Geddes <<a href="mailto:frog@bunyip.wheelycreek.net" target="_blank" rel="noreferrer">frog@bunyip.wheelycreek.net</a>>
wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal">Thanks so much for giving this a
good run. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I totally missed that about the
purpose of PollerStateTicker() damn.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I think I can call this on
primary ticks only from PollerSend() itself outside
of the mutex. That would work - I'll get onto that.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">In the original PR# 966
PollerSend() is an OvmsVehicle() member and as such
this is a no-brainer. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">That would mean it will get
called from the Rx/Poller task rather than the
schedule (ticker1) task which is not necessarily a
bad thing... but different.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I believe that for the Poller
implementation though, this will need to be an event
similar to PollRunFinished() - which kind of has
similar usage but occurs between (effectively)
poller ticks (ie when all the <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">entries in the list have been
dealt with) rather than what will be at the
beginning of each Primary tick.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Unless you have an objection -
I'll pass in <span style="font-family:"Courier New"">(canbus*
bus)</span> to this - similar to PollRunFinished()<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">//.ichael<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">On Fri, 29 Mar 2024 at 21:51,
Michael Balzer <<a href="mailto:dexter@expeedo.de" target="_blank" rel="noreferrer">dexter@expeedo.de</a>>
wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal" style="margin-bottom:12pt">Michael,<br>
<br>
first feedback: testing this revealed some
strange issues with vehicle state changes
apparently not being detected or reacted to
properly.<br>
<br>
A quick first check shows you have changed the
way, the PollerStateTicker() hook works: it's
now called independently from / as of the
component ticker.1 registration sequence after
the poller's primary send, rather than before.<br>
<br>
The callback was explicitly meant to provide a
means to change the poller state just before the
next poll would take place:<br>
<br>
<span style="font-family:"Courier New"">/**<br>
* PollerStateTicker: check for state changes
(stub, override with vehicle implementation)<br>
* This is called by VehicleTicker1() just
before the next PollerSend().<br>
* Implement your poller state transition
logic in this method, so the changes<br>
* will get applied immediately.<br>
*/<br>
</span><br>
This change is already present in PR #966, so
I'll delay merging that.<br>
<br>
Apart from that, the new poller seems to work
normally, i.e. the polling scheme works and
results are coming in, at least regarding ISOTP.
I haven't tested VWTP yet.<br>
<br>
Regards,<br>
Michael<br>
<br>
<u></u><u></u></p>
<div>
<p class="MsoNormal">Am 26.03.24 um 08:46
schrieb Michael Geddes:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal">Yeah wow. So close and
yet so far. <u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Fix pushed.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">//.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Sat, 23 Mar 2024 at
21:58, Michael Balzer <<a href="mailto:dexter@expeedo.de" target="_blank" rel="noreferrer">dexter@expeedo.de</a>>
wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal" style="margin-bottom:12pt">Michael,<br>
<br>
looking forward to test this, but trying
to run your branch with the VW e-Up
leads to an early crash boot loop.<br>
<br>
Apparently
`OvmsPollers::PollSetPidList()` doesn't
check for a NULL plist:<br>
<br>
<span style="font-family:"Courier New"">0x40195b6f is in
OvmsPollers::PollSetPidList(canbus*,
OvmsPoller::poll_pid_t const*,
OvmsPoller::VehicleSignal*)
(/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/poller/src/vehicle_poller.cpp:1201).<br>
1196 bool
hasbus[1+VEHICLE_MAXBUSSES];<br>
1197 for (int i = 0 ; i <=
VEHICLE_MAXBUSSES; ++i)<br>
1198 hasbus[i] = false;<br>
1199 <br>
1200 // Check for an Empty list.<br>
<b><span style="color:rgb(216,58,58)">1201
if (plist->txmoduleid == 0)</span></b><br>
1202 {<br>
1203 plist = nullptr;<br>
1204 ESP_LOGD(TAG,
"PollSetPidList - Setting Empty
List");<br>
1205 }<br>
0x401a2675 is in
OvmsVehicle::PollSetPidList(canbus*,
OvmsPoller::poll_pid_t const*)
(/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/vehicle/vehicle.cpp:2278).<br>
2273 return m_pollsignal;<br>
2274 }<br>
2275 void
OvmsVehicle::PollSetPidList(canbus*
bus, const OvmsPoller::poll_pid_t*
plist)<br>
2276 {<br>
2277 m_poll_bus_default = bus;<br>
2278
MyPollers.PollSetPidList(bus, plist,
GetPollerSignal());<br>
2279 }<br>
2280 #endif<br>
2281 <br>
2282 /**<br>
0x4023209e is in
OvmsVehicleVWeUp::OBDInit()
(/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/vehicle_vweup/src/vweup_obd.cpp:233).<br>
228 obd_state_t previous_state =
m_obd_state;<br>
229 m_obd_state = OBDS_Config;<br>
230 <br>
231 if (previous_state !=
OBDS_Pause)<br>
232 {<br>
<b><span style="color:rgb(216,58,58)">233
PollSetPidList(m_can1, NULL);</span></b><br>
234 PollSetThrottling(0);<br>
235
PollSetResponseSeparationTime(1);<br>
236 <br>
237 if
(StandardMetrics.ms_v_charge_inprogress->AsBool())</span><br>
<br>
<br>
Regards,<br>
Michael<br>
<br>
<u></u><u></u></p>
<div>
<p class="MsoNormal">Am 21.03.24 um
10:17 schrieb Michael Geddes:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal">I've pushed up my
working tree here: <a href="https://github.com/frogonwheels/Open-Vehicle-Monitoring-System-3/tree/new-poller" target="_blank" rel="noreferrer">https://github.com/frogonwheels/Open-Vehicle-Monitoring-System-3/tree/new-poller</a>
<u></u><u></u></p>
<div>
<p class="MsoNormal">partly for
feedback, and partly because I
wanted it backed up!<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">This
incorporates about 10
pull/requests worth of work
which is why I didn't even add
it as a draft, so I see this as
taking some number of months to
push up.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Of
interest is really the final
components/poller/src/vehicle_poller*
files and how that has all come
together.. I've added some
preliminary <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">documentation
for that which I'm quite happy
to accept any critiques or
requests for specific
information!<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The Duktape
metrics 'stale, age' methods are
probably ready for a p/r as-is.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">//.ichael<u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Sun, 17 Mar
2024 at 16:58, Michael Geddes <<a href="mailto:frog@bunyip.wheelycreek.net" target="_blank" rel="noreferrer">frog@bunyip.wheelycreek.net</a>>
wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal">Thanks
Michael, <u></u><u></u></p>
<div>
<p class="MsoNormal">I'll
definitely add the config -
pretty much sorted out the
singleton (except for the
change of directory). Just
wondering if I should rebase
this change down earlier or
just keep it as the 'last
change' that is making the
final break. It might be a
better transition that way?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Anyway have
a look at this little class
below; we have a bunch of
different implementations for
an event register and came up
with the OvmsCallBackRegister
below.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">In my
example the event notification
looks like this:<br>
void
PollRunFinished(canbus *bus)<br>
{<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">
m_runfinished_callback.Call(<br>
[bus](const
std::string &name, const
PollCallback &cb)<br>
{<br>
cb(bus, nullptr);<br>
});<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> }<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I could
possibly but it in
main/ovms_utils.h ?? It
could also use a std:map to
implement it, though I think
we save space this way and tbh
the use case wouldn't be doing
a lot of Register and
Unregister which would be the
slowest operations... I've
made it not shrink the list
size .... but again, not that
important in the context.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thoughts?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">//.ichael<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">--------------8<
-----------------------------------<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New"">/* Call-back register.<br>
* The list does not
shrink which is fine for
this use-case.<br>
* Can be made
inexpensively
threadsafe/re-entrant
safe.<br>
*/<br>
template <typename
FN><br>
class OvmsCallBackRegister<br>
{<br>
private:<br>
class CallbackEntry<br>
{<br>
public:<br>
CallbackEntry(const
std::string &caller,
FN callback)<br>
{<br>
m_name = caller;<br>
m_callback =
callback;<br>
}<br>
~CallbackEntry() {}<br>
public:<br>
std::string m_name;<br>
FN m_callback;<br>
};<br>
typedef
std::forward_list<CallbackEntry>
callbacklist_t;<br>
callbacklist_t m_list;<br>
public:<br>
~OvmsCallBackRegister()<br>
{<br>
}<br>
void Register(const
std::string &nametag,
FN callback)<br>
{<br>
// Replace<br>
for (auto it =
m_list.begin(); it !=
m_list.end(); ++it)<br>
{<br>
if ((*it).m_name
== nametag)<br>
{<br>
(*it).m_callback
= callback;<br>
return;<br>
}<br>
}<br>
if (!callback)<br>
return;<br>
for (auto it =
m_list.begin(); it !=
m_list.end(); ++it)<br>
{<br>
if
(!(*it).m_callback)<br>
{<br>
CallbackEntry
&entry = *it;<br>
entry.m_name =
nametag;<br>
entry.m_callback
= callback;<br>
return;<br>
}<br>
}<br>
m_list.push_front(CallbackEntry(nametag,
callback));<br>
}<br>
void Deregister(const
std::string &nametag)<br>
{<br>
Register(nametag,
nullptr);<br>
}<br>
typedef
std::function<void
(const std::string
&nametag, FN
callback)> visit_fn_t;<br>
void Call(visit_fn_t
visit)<br>
{<br>
for (auto it =
m_list.begin(); it !=
m_list.end(); ++it)<br>
{<br>
const
CallbackEntry &entry =
*it;<br>
if
(entry.m_callback)<br>
visit(entry.m_name,
entry.m_callback);<br>
}<br>
}<br>
};</span><u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, 14
Mar 2024 at 12:08, Mark
Webb-Johnson <<a href="mailto:mark@webb-johnson.net" target="_blank" rel="noreferrer">mark@webb-johnson.net</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal">Michael,
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I
suggest that if it is a
separate component then
better to move it to it’s
own component directory
(just as canopen is done).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">For
completeness, I suggest it
would also be good to
include
a CONFIG_OVMS_COMP_*
sdkconfig (default: yes),
and put that as a
requirement for your
component (as well as for
any vehicle doing polling,
I guess).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Regards,
Mark<u></u><u></u></p>
<div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal">On
14 Mar 2024, at
11:01<span style="font-family:Arial,sans-serif"> </span>AM, Michael
Geddes <<a href="mailto:frog@bunyip.wheelycreek.net" target="_blank" rel="noreferrer">frog@bunyip.wheelycreek.net</a>>
wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">Thanks Michael, Mark,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Sorry for not acknowledging earlier.. this feedback is
great; I've just
been cogitating
on the
consequences. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">I
still have the
Poller hanging
onto the vehicle
by a thread so I
should just cut
the thread making
the Poller a
separate singleton
(it's still
embedded in the
vehicle class for
now with a small
interface joining
them). <u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">If I do, does it need to get moved to a new directory
or can it stay
in the vehicle/
directory? The
file
vehicle_poller.cpp
(and the _isotp
and vwtp parts
to it) are still
pretty much as
they were with
only a change in
class name..<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I think I just need the poller to get its own values
of m_can1 etc
and provide a
different way
of getting the
feedback
results.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I also need to make sure I'm not cutting off the
'vehicle'
class' access
to
non-solicited
messages (ie
stuff that is
just on the
bus).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">//.ichael<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, 11 Mar 2024 at 14:51, Michael Balzer <<a href="mailto:dexter@expeedo.de" target="_blank" rel="noreferrer">dexter@expeedo.de</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal" style="margin-bottom:12pt">Actually, separating the
poller from
the vehicle
was part of
the plan of
reworking it
into a
job/worker
architecture.
I see no
reason the
generalized
poller would
need to remain
coupled to the
vehicle.<br>
<br>
That's why I
placed the OBD
single request
command in the
"obdii"
hierarchy
(although a
more proper
naming would
have been e.g.
"isotp", but
changing the
name or having
both would
confuse users
-- and
meanwhile the
poller also
supports a
non-ISO TP
variant).<br>
<br>
Regards,<br>
Michael<br>
<br>
<u></u><u></u></p>
<div>
<p class="MsoNormal">Am 11.03.24 um 00:51 schrieb Mark Webb-Johnson:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<p class="MsoNormal">Michael, <u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">It depends on whether the poller can *only* be used in
the vehicle
class or if it
is a framework
all by itself
(for example
with commands
to manually
poll specific
PIDs, etc).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">If *only* within vehicle framework, then putting it as
a sub-command
under
‘vehicle’
seems
sensible.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">If more general purpose, then perhaps look at ‘copen’
(component/canopen) as an example.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Regards, Mark.<u></u><u></u></p>
<div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal">On 10 Mar 2024, at 7:25<span style="font-family:Arial,sans-serif"> </span>AM, Michael
Geddes <a href="mailto:frog@bunyip.wheelycreek.net" target="_blank" rel="noreferrer"><frog@bunyip.wheelycreek.net></a> wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">Hi all,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I know some of this (especially for the status)
functionality
is predicated
on code that's
not gone up
yet - however
this is
allowing
'pause' and
'resume' of
the poller
(which has
been merged).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">My question is not so much about the functionality and
status
information,
but about the
location of
the <b>poller</b> subcommand.
(See below). <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Should 'vehicle' be exclusively for switching the
vehicle type?
Should the
'poller'
command be
top-level?
Under obdii? <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thoughts welcome.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">If you do vehicle poller pause then the last line
reads
'Vehicle OBD
Polling is
paused'<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">//.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">-------8<----------------------------------------<u></u><u></u></p>
</div>
<p class="MsoNormal"><br>
<b>OVMS#
vehicle ?</b><br>
Usage: vehicle
[list|module|poller|status]<br>
list
Show
list of
available
vehicle
modules<br>
module
Set (or
clear) vehicle
module<br>
poller
OBD
polling status<br>
status
Show
vehicle module
status<br>
<b>OVMS#
vehicle poller
?</b><br>
Usage: vehicle
poller
[pause|resume]<br>
pause
Pause
OBD Polling<br>
resume
Resume
OBD Polling<u></u><u></u></p>
<div>
<p class="MsoNormal"><b>OVMS# vehicle poller</b><br>
OBD Polling
running on bus
1 with an
active list<br>
Time between
polling ticks
is 1000ms with
1 secondary
sub-ticks<br>
Last poll
command
received 1s
(ticks) ago.<br>
Vehicle OBD
Polling is
running.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
OvmsDev
mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" rel="noreferrer">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" rel="noreferrer">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<pre>_______________________________________________<u></u><u></u></pre>
<pre>OvmsDev mailing list<u></u><u></u></pre>
<pre><a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" rel="noreferrer">OvmsDev@lists.openvehicles.com</a><u></u><u></u></pre>
<pre><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" rel="noreferrer">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><u></u><u></u></pre>
</blockquote>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<pre>-- <u></u><u></u></pre>
<pre>Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal<u></u><u></u></pre>
<pre>Fon 02333 / 833 5735 * Handy 0176 / 206 989 26<u></u><u></u></pre>
</div>
<p class="MsoNormal">_______________________________________________<br>
OvmsDev mailing
list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" rel="noreferrer">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" rel="noreferrer">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal">_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" rel="noreferrer">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" rel="noreferrer">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" rel="noreferrer">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" rel="noreferrer">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><u></u><u></u></p>
</blockquote>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<pre>_______________________________________________<u></u><u></u></pre>
<pre>OvmsDev mailing list<u></u><u></u></pre>
<pre><a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" rel="noreferrer">OvmsDev@lists.openvehicles.com</a><u></u><u></u></pre>
<pre><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" rel="noreferrer">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><u></u><u></u></pre>
</blockquote>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<pre>-- <u></u><u></u></pre>
<pre>Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal<u></u><u></u></pre>
<pre>Fon 02333 / 833 5735 * Handy 0176 / 206 989 26<u></u><u></u></pre>
</div>
<p class="MsoNormal">_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" rel="noreferrer">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" rel="noreferrer">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<pre>_______________________________________________<u></u><u></u></pre>
<pre>OvmsDev mailing list<u></u><u></u></pre>
<pre><a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" rel="noreferrer">OvmsDev@lists.openvehicles.com</a><u></u><u></u></pre>
<pre><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" rel="noreferrer">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><u></u><u></u></pre>
</blockquote>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<pre>-- <u></u><u></u></pre>
<pre>Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal<u></u><u></u></pre>
<pre>Fon 02333 / 833 5735 * Handy 0176 / 206 989 26<u></u><u></u></pre>
</div>
<p class="MsoNormal">_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" rel="noreferrer">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" rel="noreferrer">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<pre>_______________________________________________<u></u><u></u></pre>
<pre>OvmsDev mailing list<u></u><u></u></pre>
<pre><a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" rel="noreferrer">OvmsDev@lists.openvehicles.com</a><u></u><u></u></pre>
<pre><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" rel="noreferrer">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><u></u><u></u></pre>
</blockquote>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<pre>-- <u></u><u></u></pre>
<pre>Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal<u></u><u></u></pre>
<pre>Fon 02333 / 833 5735 * Handy 0176 / 206 989 26<u></u><u></u></pre>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" rel="noreferrer">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" rel="noreferrer">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" rel="noreferrer">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" rel="noreferrer noreferrer" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote></div></div>
</blockquote></div>