[Ovmsdev] OBD poller module shell proposal

Michael Geddes frog at bunyip.wheelycreek.net
Thu Mar 14 11:01:41 HKT 2024


Thanks Michael, Mark,

Sorry for not acknowledging earlier.. this feedback is great; I've just
been cogitating on the consequences.

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).

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..

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.

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).

//.ichael


On Mon, 11 Mar 2024 at 14:51, Michael Balzer <dexter at expeedo.de> wrote:

> 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.
>
> 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).
>
> Regards,
> Michael
>
>
> Am 11.03.24 um 00:51 schrieb Mark Webb-Johnson:
>
> Michael,
>
> 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).
>
> If *only* within vehicle framework, then putting it as a sub-command under
> ‘vehicle’ seems sensible.
>
> If more general purpose, then perhaps look at ‘copen’ (component/canopen)
> as an example.
>
> Regards, Mark.
>
> On 10 Mar 2024, at 7:25 AM, Michael Geddes <frog at bunyip.wheelycreek.net>
> <frog at bunyip.wheelycreek.net> wrote:
>
> Hi all,
>
> 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).
> My question is not so much about the functionality and status information,
> but about the location of the *poller* subcommand. (See below).
>
> Should 'vehicle' be exclusively for switching the vehicle type?  Should
> the 'poller' command be top-level?  Under obdii?
>
> Thoughts welcome.
> If you do  vehicle poller pause  then the last line reads  'Vehicle OBD
> Polling is paused'
> //.
> -------8<----------------------------------------
>
> *OVMS# vehicle ?*
> Usage: vehicle [list|module|poller|status]
> list                 Show list of available vehicle modules
> module               Set (or clear) vehicle module
> poller               OBD polling status
> status               Show vehicle module status
> *OVMS# vehicle poller ?*
> Usage: vehicle poller [pause|resume]
> pause                Pause OBD Polling
> resume               Resume OBD Polling
> *OVMS# vehicle poller*
> OBD Polling running on bus 1 with an active list
> Time between polling ticks is 1000ms with 1 secondary sub-ticks
> Last poll command received 1s (ticks) ago.
> Vehicle OBD Polling is running.
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20240314/61d06669/attachment.htm>


More information about the OvmsDev mailing list