<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Aptos;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-AU link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt'>Thanks Michael,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>I’ve fixed the register/deregister and also fixed a few issues / dependencies for compiling when OVMS_COMP_POLLER is not selected.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>//.ichael<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif'> OvmsDev <ovmsdev-bounces@lists.openvehicles.com> <b>On Behalf Of </b>Michael Balzer<br><b>Sent:</b> Sunday, April 7, 2024 4:44 PM<br><b>To:</b> ovmsdev@lists.openvehicles.com<br><b>Subject:</b> Re: [Ovmsdev] OBD poller module shell proposal<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>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">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><o:p></o:p></p><div><p class=MsoNormal>Am 31.03.24 um 01:44 schrieb Michael Geddes:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>I have pushed up changes for PR#966 as well as to the 'new-poller' branch that handle the PollerStateTicker() <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>//.ichael<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Sat, 30 Mar 2024 at 08:39, Michael Geddes <<a href="mailto:frog@bunyip.wheelycreek.net">frog@bunyip.wheelycreek.net</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><div><p class=MsoNormal>Thanks so much for giving this a good run. <o:p></o:p></p></div><div><p class=MsoNormal>I totally missed that about the purpose of PollerStateTicker() damn.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></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.<o:p></o:p></p></div><div><p class=MsoNormal>In the original PR# 966 PollerSend() is an OvmsVehicle() member and as such this is a no-brainer. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></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 <o:p></o:p></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.<o:p></o:p></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()<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>//.ichael<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></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">dexter@expeedo.de</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><p class=MsoNormal style='margin-bottom:12.0pt'>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><o:p></o:p></p><div><p class=MsoNormal>Am 26.03.24 um 08:46 schrieb Michael Geddes:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>Yeah wow. So close and yet so far. <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Fix pushed.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>//.<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Sat, 23 Mar 2024 at 21:58, Michael Balzer <<a href="mailto:dexter@expeedo.de" target="_blank">dexter@expeedo.de</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><p class=MsoNormal style='margin-bottom:12.0pt'>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:#D83A3A'>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:#D83A3A'>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><o:p></o:p></p><div><p class=MsoNormal>Am 21.03.24 um 10:17 schrieb Michael Geddes:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><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">https://github.com/frogonwheels/Open-Vehicle-Monitoring-System-3/tree/new-poller</a> <o:p></o:p></p><div><p class=MsoNormal>partly for feedback, and partly because I wanted it backed up!<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></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 <o:p></o:p></p></div><div><p class=MsoNormal>documentation for that which I'm quite happy to accept any critiques or requests for specific information!<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The Duktape metrics 'stale, age' methods are probably ready for a p/r as-is.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>//.ichael<o:p></o:p></p></div></div></div><p class=MsoNormal><o:p> </o:p></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">frog@bunyip.wheelycreek.net</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><p class=MsoNormal>Thanks Michael, <o:p></o:p></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?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>In my example the event notification looks like this:<br> void PollRunFinished(canbus *bus)<br> {<o:p></o:p></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> });<o:p></o:p></p></div><div><p class=MsoNormal> }<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thoughts?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>//.ichael<o:p></o:p></p></div><div><p class=MsoNormal>--------------8< -----------------------------------<o:p></o:p></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><o:p></o:p></p></div></div></div><p class=MsoNormal><o:p> </o:p></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">mark@webb-johnson.net</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><p class=MsoNormal>Michael, <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></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).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></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).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Regards, Mark<o:p></o:p></p><div><p class=MsoNormal><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><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">frog@bunyip.wheelycreek.net</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><div><p class=MsoNormal>Thanks Michael, Mark,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Sorry for not acknowledging earlier.. this feedback is great; I've just been cogitating on the consequences. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></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). <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></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..<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></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).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>//.ichael<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Mon, 11 Mar 2024 at 14:51, Michael Balzer <<a href="mailto:dexter@expeedo.de" target="_blank">dexter@expeedo.de</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><p class=MsoNormal style='margin-bottom:12.0pt'>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><o:p></o:p></p><div><p class=MsoNormal>Am 11.03.24 um 00:51 schrieb Mark Webb-Johnson:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>Michael, <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></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).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>If *only* within vehicle framework, then putting it as a sub-command under ‘vehicle’ seems sensible.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>If more general purpose, then perhaps look at ‘copen’ (component/canopen) as an example.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Regards, Mark.<o:p></o:p></p><div><p class=MsoNormal><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><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"><frog@bunyip.wheelycreek.net></a> wrote:<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><div><p class=MsoNormal>Hi all,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></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).<o:p></o:p></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). <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Should 'vehicle' be exclusively for switching the vehicle type? Should the 'poller' command be top-level? Under obdii? <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thoughts welcome.<o:p></o:p></p></div><div><p class=MsoNormal>If you do vehicle poller pause then the last line reads 'Vehicle OBD Polling is paused'<o:p></o:p></p></div><div><p class=MsoNormal>//.<o:p></o:p></p></div><div><p class=MsoNormal>-------8<----------------------------------------<o:p></o:p></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<o:p></o:p></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.<o:p></o:p></p></div></div><p class=MsoNormal>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><br><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><o:p></o:p></p></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal><br><br><o:p></o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>OvmsDev mailing list<o:p></o:p></pre><pre><a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><o:p></o:p></pre><pre><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><o:p></o:p></pre></blockquote><p class=MsoNormal><br><br><o:p></o:p></p><pre>-- <o:p></o:p></pre><pre>Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal<o:p></o:p></pre><pre>Fon 02333 / 833 5735 * Handy 0176 / 206 989 26<o:p></o:p></pre></div><p class=MsoNormal>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><br><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><o:p></o:p></p></blockquote></div><p class=MsoNormal>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><br><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><o:p></o:p></p></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><br><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><o:p></o:p></p></blockquote></div></blockquote></div><p class=MsoNormal><br><br><o:p></o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>OvmsDev mailing list<o:p></o:p></pre><pre><a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><o:p></o:p></pre><pre><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><o:p></o:p></pre></blockquote><p class=MsoNormal><br><br><o:p></o:p></p><pre>-- <o:p></o:p></pre><pre>Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal<o:p></o:p></pre><pre>Fon 02333 / 833 5735 * Handy 0176 / 206 989 26<o:p></o:p></pre></div><p class=MsoNormal>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><br><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><o:p></o:p></p></blockquote></div><p class=MsoNormal><br><br><o:p></o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>OvmsDev mailing list<o:p></o:p></pre><pre><a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><o:p></o:p></pre><pre><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><o:p></o:p></pre></blockquote><p class=MsoNormal><br><br><o:p></o:p></p><pre>-- <o:p></o:p></pre><pre>Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal<o:p></o:p></pre><pre>Fon 02333 / 833 5735 * Handy 0176 / 206 989 26<o:p></o:p></pre></div><p class=MsoNormal>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><br><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><o:p></o:p></p></blockquote></div></div></blockquote></div><p class=MsoNormal><br><br><o:p></o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>OvmsDev mailing list<o:p></o:p></pre><pre><a href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a><o:p></o:p></pre><pre><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><o:p></o:p></pre></blockquote><p class=MsoNormal><br><br><o:p></o:p></p><pre>-- <o:p></o:p></pre><pre>Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal<o:p></o:p></pre><pre>Fon 02333 / 833 5735 * Handy 0176 / 206 989 26<o:p></o:p></pre></div></body></html>