Michael, 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). 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). Regards, Mark
On 14 Mar 2024, at 11:01 AM, Michael Geddes <frog@bunyip.wheelycreek.net> wrote:
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@expeedo.de <mailto:dexter@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@bunyip.wheelycreek.net> <mailto:frog@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev