<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Michael,<div><br></div><div>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).</div><div><br></div><div>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).</div><div><br></div><div>Regards, Mark<br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On 14 Mar 2024, at 11:01 AM, Michael Geddes <frog@bunyip.wheelycreek.net> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr"><div>Thanks Michael, Mark,</div><div><br></div><div>Sorry for not acknowledging earlier.. this feedback is great; I've just been cogitating on the consequences. </div><div><br></div>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).<div><br></div><div>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..<br><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>//.ichael</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 11 Mar 2024 at 14:51, Michael Balzer <<a href="mailto:dexter@expeedo.de">dexter@expeedo.de</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>
    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>
    <br>
    <div>Am 11.03.24 um 00:51 schrieb Mark
      Webb-Johnson:<br>
    </div>
    <blockquote type="cite">
      
      Michael,
      <div><br>
      </div>
      <div>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).</div>
      <div><br>
      </div>
      <div>If *only* within vehicle framework, then putting it as a
        sub-command under ‘vehicle’ seems sensible.</div>
      <div><br>
      </div>
      <div>If more general purpose, then perhaps look at ‘copen’
        (component/canopen) as an example.</div>
      <div><br>
      </div>
      <div>Regards, Mark.<br id="m_393746923709381916lineBreakAtBeginningOfMessage">
        <div><br>
          <blockquote type="cite">
            <div>On 10 Mar 2024, at 7:25 AM, Michael Geddes
              <a href="mailto:frog@bunyip.wheelycreek.net" target="_blank"><frog@bunyip.wheelycreek.net></a> wrote:</div>
            <br>
            <div>
              <div dir="ltr">
                <div>Hi all,</div>
                <div><br>
                </div>
                <div>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).</div>
                <div>My question is not so much about the
                  functionality and status information, but about the
                  location of the <b>poller</b> subcommand. (See
                  below). </div>
                <div><br>
                </div>
                <div>Should 'vehicle' be exclusively for switching the
                  vehicle type?  Should the 'poller' command be
                  top-level?  Under obdii?  </div>
                <div><br>
                </div>
                <div>Thoughts welcome.</div>
                <div>If you do  vehicle poller pause  then the last line
                  reads  'Vehicle OBD Polling is paused'</div>
                <div>//.</div>
                <div>-------8<----------------------------------------</div>
                <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<b><br>
                </b>
                <div><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.<br>
                </div>
              </div>
              _______________________________________________<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><br>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">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">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" rel="noreferrer" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote></div>
_______________________________________________<br>OvmsDev mailing list<br>OvmsDev@lists.openvehicles.com<br>http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br></div></blockquote></div><br></div></body></html>