Adding Pollers object to Duktape
I figured I may as well add an OvmsPoller object to DukTape for Ovms. I'm waiting to get back to my OVMS so that I can test it.. but this is the documentation I have for the stuff I have coded. Thoughts on this? What do people think of OvmsPoller.Times sub-object? I've added a general mechanism for this. Also should I have OvmsPoller.Pause() or OvmsPoller.SetUserPaused(true) ? //. OvmsPoller ^^^^^^^^^^ The Ovms Poller object represents the poller sub-system. It contains the following methods: - ``ispaused = OvmsPoller.GetPaused()``: Return true if the poller is paused by the system/user. - ``ispaused = OvmsPoller.GetUserPaused()``: Return true if the poller is paused by the user. - ``OvmsPoller.Pause()``: Pause the poller (adds User poller pause) - ``OvmsPoller.Resume()``: Remove the User poller pause. - ``tracemode = OvmsPoller.GetTrace()``: Return the current trace mode. - ``OvmsPoller.SetTrace(tracemode)``: Set the current trace mode. The Traces still require that 'Verbose' and 'Debug' levels (depending) for the 'vehicle-poll' debug tag are set. Trace modes for verbose logging can be one of: - ``on``: On for poller loop - ``txrx``: On for txrx queue (this can be hazardous for some cars) - ``all``: On for both poller loop and txrx queuing - ``off``: Logging Off Note that only ``on`` and ``off`` are recommended. The poller object also contains a ``Times`` property for the OBD Poll-Time tracing which contains the following methods: - ``isrunning = OvmsPoller.Times.GetEnabled()``: Returns true if the time-tracing is enabled - ``OvmsPoller.Times.SetEnabled(isrunning)``: Sets the enabled status of the timer-tracing - ``OvmsPoller.Times.Reset()``: Reset the timers (doesn't affect their current state). - ``OvmsPoller.Times.GetStatus()``: Gets the status of the various times. This returns an object of this format: .. code-block:: javascript return_value = { "items": { "Poll:PRI" : { "count_hz": 1, "avg_util_pm": 0.529, "peak_util_pm":0.652, "avg_time_ms": 0.052, "peak_time_ms":1.516 }, "Poll:SRX": { "count_hz": 1.47, "avg_util_pm": 0.302, "peak_util_pm":0.44, "avg_time_ms": 0.02, "peak_time_ms":0.573 }, "RxCan1[778]": { "count_hz": 0.74, "avg_util_pm": 0.427, "peak_util_pm":0.826, "avg_time_ms": 0.063, "peak_time_ms":1.872 }, "RxCan1[7a8]": { "count_hz": 0.35, "avg_util_pm": 0.183, "peak_util_pm":0.355, "avg_time_ms": 0.052, "peak_time_ms":1.382 }, "TxCan1[7b3]": { "count_hz": 0.07, "avg_util_pm": 0.005, "peak_util_pm":0.01, "avg_time_ms": 0.007, "peak_time_ms":0.099 }, "TxCan1[7c6]": { "count_hz": 0, "avg_util_pm": 0, "peak_util_pm":0.009, "avg_time_ms": 0.004, "peak_time_ms":0.098 }, "Cmd:State": { "count_hz": 0, "avg_util_pm": 0, "peak_util_pm":0, "avg_time_ms": 0.011, "peak_time_ms":0.109 } }, "tot_count_hz": 11.76, "tot_util_pm": 6.247, "tot_time_ms": 4.628 };
OH, and also, What do you think of treating the OvmsPoller.Times.GetStatus() items as an associative array - or should I treat it as a normal array? //.ichael On Wed, 3 Jul 2024 at 14:24, Michael Geddes <frog@bunyip.wheelycreek.net> wrote:
I figured I may as well add an OvmsPoller object to DukTape for Ovms. I'm waiting to get back to my OVMS so that I can test it.. but this is the documentation I have for the stuff I have coded. Thoughts on this?
What do people think of OvmsPoller.Times sub-object? I've added a general mechanism for this.
Also should I have OvmsPoller.Pause() or OvmsPoller.SetUserPaused(true) ? //.
OvmsPoller ^^^^^^^^^^ The Ovms Poller object represents the poller sub-system. It contains the following methods:
- ``ispaused = OvmsPoller.GetPaused()``: Return true if the poller is paused by the system/user. - ``ispaused = OvmsPoller.GetUserPaused()``: Return true if the poller is paused by the user. - ``OvmsPoller.Pause()``: Pause the poller (adds User poller pause) - ``OvmsPoller.Resume()``: Remove the User poller pause.
- ``tracemode = OvmsPoller.GetTrace()``: Return the current trace mode. - ``OvmsPoller.SetTrace(tracemode)``: Set the current trace mode.
The Traces still require that 'Verbose' and 'Debug' levels (depending) for the 'vehicle-poll' debug tag are set. Trace modes for verbose logging can be one of: - ``on``: On for poller loop - ``txrx``: On for txrx queue (this can be hazardous for some cars) - ``all``: On for both poller loop and txrx queuing - ``off``: Logging Off Note that only ``on`` and ``off`` are recommended.
The poller object also contains a ``Times`` property for the OBD Poll-Time tracing which contains the following methods: - ``isrunning = OvmsPoller.Times.GetEnabled()``: Returns true if the time-tracing is enabled - ``OvmsPoller.Times.SetEnabled(isrunning)``: Sets the enabled status of the timer-tracing - ``OvmsPoller.Times.Reset()``: Reset the timers (doesn't affect their current state). - ``OvmsPoller.Times.GetStatus()``: Gets the status of the various times. This returns an object of this format: .. code-block:: javascript return_value = { "items": { "Poll:PRI" : { "count_hz": 1, "avg_util_pm": 0.529, "peak_util_pm":0.652, "avg_time_ms": 0.052, "peak_time_ms":1.516 }, "Poll:SRX": { "count_hz": 1.47, "avg_util_pm": 0.302, "peak_util_pm":0.44, "avg_time_ms": 0.02, "peak_time_ms":0.573 }, "RxCan1[778]": { "count_hz": 0.74, "avg_util_pm": 0.427, "peak_util_pm":0.826, "avg_time_ms": 0.063, "peak_time_ms":1.872 }, "RxCan1[7a8]": { "count_hz": 0.35, "avg_util_pm": 0.183, "peak_util_pm":0.355, "avg_time_ms": 0.052, "peak_time_ms":1.382 }, "TxCan1[7b3]": { "count_hz": 0.07, "avg_util_pm": 0.005, "peak_util_pm":0.01, "avg_time_ms": 0.007, "peak_time_ms":0.099 }, "TxCan1[7c6]": { "count_hz": 0, "avg_util_pm": 0, "peak_util_pm":0.009, "avg_time_ms": 0.004, "peak_time_ms":0.098 }, "Cmd:State": { "count_hz": 0, "avg_util_pm": 0, "peak_util_pm":0, "avg_time_ms": 0.011, "peak_time_ms":0.109 } },
"tot_count_hz": 11.76, "tot_util_pm": 6.247, "tot_time_ms": 4.628 };
please have a good look at the function names.. when I have Get and Set prefixes.. should I have them.. etc to be consistent. But Just FYI (a couple of silly bugs later) - This is the full output from a test proving that both the 'Times' property works and that at least as a concept- having the "Poll:PRI" as a key works. //. ----8<------------------- JSON.print(OvmsPoller.Times.GetStatus()) { "items": { "Poll:PRI": { "count_hz": 1.00600004196167, "avg_util_pm": 0.5598000288009644, "peak_util_pm": 0.6503999829292297, "avg_time_ms": 0.05350000038743019, "peak_time_ms": 0.9779999852180481 }, "Poll:SRX": { "count_hz": 1.1330000162124634, "avg_util_pm": 0.18970000743865967, "peak_util_pm": 0.23240000009536743, "avg_time_ms": 0.015799999237060547, "peak_time_ms": 0.3319999873638153 }, "RxCan1[778]": { "count_hz": 1.8489999771118164, "avg_util_pm": 1.2870999574661255, "peak_util_pm": 1.8909000158309937, "avg_time_ms": 0.06909999996423721, "peak_time_ms": 2.7119998931884766 }, "RxCan1[7bb]": { "count_hz": 0.2240000069141388, "avg_util_pm": 0.10409999638795853, "peak_util_pm": 0.25859999656677246, "avg_time_ms": 0.043800000101327896, "peak_time_ms": 1.50600004196167 }, "RxCan1[7ea]": { "count_hz": 1.0670000314712524, "avg_util_pm": 0.4699000120162964, "peak_util_pm": 0.7283999919891357, "avg_time_ms": 0.04830000177025795, "peak_time_ms": 1.5379999876022339 }, "RxCan1[7ec]": { "count_hz": 1.8669999837875366, "avg_util_pm": 0.8090000152587891, "peak_util_pm": 0.9458000063896179, "avg_time_ms": 0.04639999940991402, "peak_time_ms": 2.2769999504089355 }, "TxCan1[770]": { "count_hz": 0.9240000247955322, "avg_util_pm": 0.039400000125169754, "peak_util_pm": 0.054499998688697815, "avg_time_ms": 0.0038999998942017555, "peak_time_ms": 0.08699999749660492 }, "TxCan1[7b3]": { "count_hz": 0.041999999433755875, "avg_util_pm": 0.0035000001080334187, "peak_util_pm": 0.008299999870359898, "avg_time_ms": 0.008500000461935997, "peak_time_ms": 0.09200000017881393 }, "TxCan1[7e2]": { "count_hz": 0.21199999749660492, "avg_util_pm": 0.01600000075995922, "peak_util_pm": 0.020500000566244125, "avg_time_ms": 0.006800000090152025, "peak_time_ms": 0.08500000089406967 }, "TxCan1[7e4]": { "count_hz": 0.21199999749660492, "avg_util_pm": 0.006899999920278788, "peak_util_pm": 0.009800000116229057, "avg_time_ms": 0.002899999963119626, "peak_time_ms": 0.05299999937415123 }, "Cmd:Thrtl": { "count_hz": 0.014999999664723873, "avg_util_pm": 0.0006000000284984708, "peak_util_pm": 0, "avg_time_ms": 0.004699999932199717, "peak_time_ms": 0.04699999839067459 }, "Cmd:State": { "count_hz": 0.039000000804662704, "avg_util_pm": 0.002300000051036477, "peak_util_pm": 0.007000000216066837, "avg_time_ms": 0.006500000134110451, "peak_time_ms": 0.09000000357627869 } }, "tot_count_hz": 8.59000015258789, "tot_util_pm": 3.488300085067749, "tot_time_ms": 3.1019999980926514 } On Wed, 3 Jul 2024 at 14:31, Michael Geddes <frog@bunyip.wheelycreek.net> wrote:
OH, and also,
What do you think of treating the OvmsPoller.Times.GetStatus() items as an associative array - or should I treat it as a normal array?
//.ichael
On Wed, 3 Jul 2024 at 14:24, Michael Geddes <frog@bunyip.wheelycreek.net> wrote:
I figured I may as well add an OvmsPoller object to DukTape for Ovms. I'm waiting to get back to my OVMS so that I can test it.. but this is the documentation I have for the stuff I have coded. Thoughts on this?
What do people think of OvmsPoller.Times sub-object? I've added a general mechanism for this.
Also should I have OvmsPoller.Pause() or OvmsPoller.SetUserPaused(true) ? //.
OvmsPoller ^^^^^^^^^^ The Ovms Poller object represents the poller sub-system. It contains the following methods:
- ``ispaused = OvmsPoller.GetPaused()``: Return true if the poller is paused by the system/user. - ``ispaused = OvmsPoller.GetUserPaused()``: Return true if the poller is paused by the user. - ``OvmsPoller.Pause()``: Pause the poller (adds User poller pause) - ``OvmsPoller.Resume()``: Remove the User poller pause.
- ``tracemode = OvmsPoller.GetTrace()``: Return the current trace mode. - ``OvmsPoller.SetTrace(tracemode)``: Set the current trace mode.
The Traces still require that 'Verbose' and 'Debug' levels (depending) for the 'vehicle-poll' debug tag are set. Trace modes for verbose logging can be one of: - ``on``: On for poller loop - ``txrx``: On for txrx queue (this can be hazardous for some cars) - ``all``: On for both poller loop and txrx queuing - ``off``: Logging Off Note that only ``on`` and ``off`` are recommended.
The poller object also contains a ``Times`` property for the OBD Poll-Time tracing which contains the following methods: - ``isrunning = OvmsPoller.Times.GetEnabled()``: Returns true if the time-tracing is enabled - ``OvmsPoller.Times.SetEnabled(isrunning)``: Sets the enabled status of the timer-tracing - ``OvmsPoller.Times.Reset()``: Reset the timers (doesn't affect their current state). - ``OvmsPoller.Times.GetStatus()``: Gets the status of the various times. This returns an object of this format: .. code-block:: javascript return_value = { "items": { "Poll:PRI" : { "count_hz": 1, "avg_util_pm": 0.529, "peak_util_pm":0.652, "avg_time_ms": 0.052, "peak_time_ms":1.516 }, "Poll:SRX": { "count_hz": 1.47, "avg_util_pm": 0.302, "peak_util_pm":0.44, "avg_time_ms": 0.02, "peak_time_ms":0.573 }, "RxCan1[778]": { "count_hz": 0.74, "avg_util_pm": 0.427, "peak_util_pm":0.826, "avg_time_ms": 0.063, "peak_time_ms":1.872 }, "RxCan1[7a8]": { "count_hz": 0.35, "avg_util_pm": 0.183, "peak_util_pm":0.355, "avg_time_ms": 0.052, "peak_time_ms":1.382 }, "TxCan1[7b3]": { "count_hz": 0.07, "avg_util_pm": 0.005, "peak_util_pm":0.01, "avg_time_ms": 0.007, "peak_time_ms":0.099 }, "TxCan1[7c6]": { "count_hz": 0, "avg_util_pm": 0, "peak_util_pm":0.009, "avg_time_ms": 0.004, "peak_time_ms":0.098 }, "Cmd:State": { "count_hz": 0, "avg_util_pm": 0, "peak_util_pm":0, "avg_time_ms": 0.011, "peak_time_ms":0.109 } },
"tot_count_hz": 11.76, "tot_util_pm": 6.247, "tot_time_ms": 4.628 };
Michael, looks good to me. IMO API calls representing direct shell commands should not be represented as getters/setters in the JS API, so ".Pause()" & ".Resume()" are better. They are also more readable (e.g. "Resume()" vs "SetUserPaused(false)") and leave room for future command specific arguments. Using an object structure is OK for the times, unless you want/need to make sure the same order as with the other outputs (shell/data) will be kept stable on any object transformation or transfer. Object properties (if they are strings) are normally kept in insertion order, but only within Javascript. When deserializing JS objects into other environments, the order isn't guaranteed. Regards, Michael Am 06.07.24 um 03:12 schrieb Michael Geddes via OvmsDev:
please have a good look at the function names.. when I have Get and Set prefixes.. should I have them.. etc to be consistent.
But Just FYI (a couple of silly bugs later) - This is the full output from a test proving that both the 'Times' property works and that at least as a concept- having the "Poll:PRI" as a key works. //. ----8<-------------------
JSON.print(OvmsPoller.Times.GetStatus())
{ "items": { "Poll:PRI": { "count_hz": 1.00600004196167, "avg_util_pm": 0.5598000288009644, "peak_util_pm": 0.6503999829292297, "avg_time_ms": 0.05350000038743019, "peak_time_ms": 0.9779999852180481 }, "Poll:SRX": { "count_hz": 1.1330000162124634, "avg_util_pm": 0.18970000743865967, "peak_util_pm": 0.23240000009536743, "avg_time_ms": 0.015799999237060547, "peak_time_ms": 0.3319999873638153 }, "RxCan1[778]": { "count_hz": 1.8489999771118164, "avg_util_pm": 1.2870999574661255, "peak_util_pm": 1.8909000158309937, "avg_time_ms": 0.06909999996423721, "peak_time_ms": 2.7119998931884766 }, "RxCan1[7bb]": { "count_hz": 0.2240000069141388, "avg_util_pm": 0.10409999638795853, "peak_util_pm": 0.25859999656677246, "avg_time_ms": 0.043800000101327896, "peak_time_ms": 1.50600004196167 }, "RxCan1[7ea]": { "count_hz": 1.0670000314712524, "avg_util_pm": 0.4699000120162964, "peak_util_pm": 0.7283999919891357, "avg_time_ms": 0.04830000177025795, "peak_time_ms": 1.5379999876022339 }, "RxCan1[7ec]": { "count_hz": 1.8669999837875366, "avg_util_pm": 0.8090000152587891, "peak_util_pm": 0.9458000063896179, "avg_time_ms": 0.04639999940991402, "peak_time_ms": 2.2769999504089355 }, "TxCan1[770]": { "count_hz": 0.9240000247955322, "avg_util_pm": 0.039400000125169754, "peak_util_pm": 0.054499998688697815, "avg_time_ms": 0.0038999998942017555, "peak_time_ms": 0.08699999749660492 }, "TxCan1[7b3]": { "count_hz": 0.041999999433755875, "avg_util_pm": 0.0035000001080334187, "peak_util_pm": 0.008299999870359898, "avg_time_ms": 0.008500000461935997, "peak_time_ms": 0.09200000017881393 }, "TxCan1[7e2]": { "count_hz": 0.21199999749660492, "avg_util_pm": 0.01600000075995922, "peak_util_pm": 0.020500000566244125, "avg_time_ms": 0.006800000090152025, "peak_time_ms": 0.08500000089406967 }, "TxCan1[7e4]": { "count_hz": 0.21199999749660492, "avg_util_pm": 0.006899999920278788, "peak_util_pm": 0.009800000116229057, "avg_time_ms": 0.002899999963119626, "peak_time_ms": 0.05299999937415123 }, "Cmd:Thrtl": { "count_hz": 0.014999999664723873, "avg_util_pm": 0.0006000000284984708, "peak_util_pm": 0, "avg_time_ms": 0.004699999932199717, "peak_time_ms": 0.04699999839067459 }, "Cmd:State": { "count_hz": 0.039000000804662704, "avg_util_pm": 0.002300000051036477, "peak_util_pm": 0.007000000216066837, "avg_time_ms": 0.006500000134110451, "peak_time_ms": 0.09000000357627869 } }, "tot_count_hz": 8.59000015258789, "tot_util_pm": 3.488300085067749, "tot_time_ms": 3.1019999980926514 }
On Wed, 3 Jul 2024 at 14:31, Michael Geddes <frog@bunyip.wheelycreek.net> wrote:
OH, and also,
What do you think of treating the OvmsPoller.Times.GetStatus() items as an associative array - or should I treat it as a normal array?
//.ichael
On Wed, 3 Jul 2024 at 14:24, Michael Geddes <frog@bunyip.wheelycreek.net> wrote:
I figured I may as well add an OvmsPoller object to DukTape for Ovms. I'm waiting to get back to my OVMS so that I can test it.. but this is the documentation I have for the stuff I have coded. Thoughts on this?
What do people think of OvmsPoller.Times sub-object? I've added a general mechanism for this.
Also should I have OvmsPoller.Pause() or OvmsPoller.SetUserPaused(true) ? //.
OvmsPoller ^^^^^^^^^^ The Ovms Poller object represents the poller sub-system. It contains the following methods:
- ``ispaused = OvmsPoller.GetPaused()``: Return true if the poller is paused by the system/user. - ``ispaused = OvmsPoller.GetUserPaused()``: Return true if the poller is paused by the user. - ``OvmsPoller.Pause()``: Pause the poller (adds User poller pause) - ``OvmsPoller.Resume()``: Remove the User poller pause.
- ``tracemode = OvmsPoller.GetTrace()``: Return the current trace mode. - ``OvmsPoller.SetTrace(tracemode)``: Set the current trace mode.
The Traces still require that 'Verbose' and 'Debug' levels (depending) for the 'vehicle-poll' debug tag are set. Trace modes for verbose logging can be one of: - ``on``: On for poller loop - ``txrx``: On for txrx queue (this can be hazardous for some cars) - ``all``: On for both poller loop and txrx queuing - ``off``: Logging Off Note that only ``on`` and ``off`` are recommended.
The poller object also contains a ``Times`` property for the OBD Poll-Time tracing which contains the following methods: - ``isrunning = OvmsPoller.Times.GetEnabled()``: Returns true if the time-tracing is enabled - ``OvmsPoller.Times.SetEnabled(isrunning)``: Sets the enabled status of the timer-tracing - ``OvmsPoller.Times.Reset()``: Reset the timers (doesn't affect their current state). - ``OvmsPoller.Times.GetStatus()``: Gets the status of the various times. This returns an object of this format: .. code-block:: javascript return_value = { "items": { "Poll:PRI" : { "count_hz": 1, "avg_util_pm": 0.529, "peak_util_pm":0.652, "avg_time_ms": 0.052, "peak_time_ms":1.516 }, "Poll:SRX": { "count_hz": 1.47, "avg_util_pm": 0.302, "peak_util_pm":0.44, "avg_time_ms": 0.02, "peak_time_ms":0.573 }, "RxCan1[778]": { "count_hz": 0.74, "avg_util_pm": 0.427, "peak_util_pm":0.826, "avg_time_ms": 0.063, "peak_time_ms":1.872 }, "RxCan1[7a8]": { "count_hz": 0.35, "avg_util_pm": 0.183, "peak_util_pm":0.355, "avg_time_ms": 0.052, "peak_time_ms":1.382 }, "TxCan1[7b3]": { "count_hz": 0.07, "avg_util_pm": 0.005, "peak_util_pm":0.01, "avg_time_ms": 0.007, "peak_time_ms":0.099 }, "TxCan1[7c6]": { "count_hz": 0, "avg_util_pm": 0, "peak_util_pm":0.009, "avg_time_ms": 0.004, "peak_time_ms":0.098 }, "Cmd:State": { "count_hz": 0, "avg_util_pm": 0, "peak_util_pm":0, "avg_time_ms": 0.011, "peak_time_ms":0.109 } },
"tot_count_hz": 11.76, "tot_util_pm": 6.247, "tot_time_ms": 4.628 };
_______________________________________________ OvmsDev mailing list 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
I'll change SetUserPaused. I flip flopped a bit on that so happy to go with your suggestion which makes sense. The order doesn't matter on the dictionary. A lot of JSON serialised like to alphabetise so aware of that. Anyway internally it's a map which doesn't guarantee order afaik. Could be in hash order anyway! Also That's partly why I had separate total properties on the base object. Michael. On Sat, 6 July 2024, 14:54 Michael Balzer via OvmsDev, < ovmsdev@lists.openvehicles.com> wrote:
Michael,
looks good to me.
IMO API calls representing direct shell commands should not be represented as getters/setters in the JS API, so ".Pause()" & ".Resume()" are better. They are also more readable (e.g. "Resume()" vs "SetUserPaused(false)") and leave room for future command specific arguments.
Using an object structure is OK for the times, unless you want/need to make sure the same order as with the other outputs (shell/data) will be kept stable on any object transformation or transfer. Object properties (if they are strings) are normally kept in insertion order, but only within Javascript. When deserializing JS objects into other environments, the order isn't guaranteed.
Regards, Michael
Am 06.07.24 um 03:12 schrieb Michael Geddes via OvmsDev:
please have a good look at the function names.. when I have Get and Set prefixes.. should I have them.. etc to be consistent.
But Just FYI (a couple of silly bugs later) - This is the full output from a test proving that both the 'Times' property works and that at least as a concept- having the "Poll:PRI" as a key works. //. ----8<-------------------
JSON.print(OvmsPoller.Times.GetStatus())
{ "items": { "Poll:PRI": { "count_hz": 1.00600004196167, "avg_util_pm": 0.5598000288009644, "peak_util_pm": 0.6503999829292297, "avg_time_ms": 0.05350000038743019, "peak_time_ms": 0.9779999852180481 }, "Poll:SRX": { "count_hz": 1.1330000162124634, "avg_util_pm": 0.18970000743865967, "peak_util_pm": 0.23240000009536743, "avg_time_ms": 0.015799999237060547, "peak_time_ms": 0.3319999873638153 }, "RxCan1[778]": { "count_hz": 1.8489999771118164, "avg_util_pm": 1.2870999574661255, "peak_util_pm": 1.8909000158309937, "avg_time_ms": 0.06909999996423721, "peak_time_ms": 2.7119998931884766 }, "RxCan1[7bb]": { "count_hz": 0.2240000069141388, "avg_util_pm": 0.10409999638795853, "peak_util_pm": 0.25859999656677246, "avg_time_ms": 0.043800000101327896, "peak_time_ms": 1.50600004196167 }, "RxCan1[7ea]": { "count_hz": 1.0670000314712524, "avg_util_pm": 0.4699000120162964, "peak_util_pm": 0.7283999919891357, "avg_time_ms": 0.04830000177025795, "peak_time_ms": 1.5379999876022339 }, "RxCan1[7ec]": { "count_hz": 1.8669999837875366, "avg_util_pm": 0.8090000152587891, "peak_util_pm": 0.9458000063896179, "avg_time_ms": 0.04639999940991402, "peak_time_ms": 2.2769999504089355 }, "TxCan1[770]": { "count_hz": 0.9240000247955322, "avg_util_pm": 0.039400000125169754, "peak_util_pm": 0.054499998688697815, "avg_time_ms": 0.0038999998942017555, "peak_time_ms": 0.08699999749660492 }, "TxCan1[7b3]": { "count_hz": 0.041999999433755875, "avg_util_pm": 0.0035000001080334187, "peak_util_pm": 0.008299999870359898, "avg_time_ms": 0.008500000461935997, "peak_time_ms": 0.09200000017881393 }, "TxCan1[7e2]": { "count_hz": 0.21199999749660492, "avg_util_pm": 0.01600000075995922, "peak_util_pm": 0.020500000566244125, "avg_time_ms": 0.006800000090152025, "peak_time_ms": 0.08500000089406967 }, "TxCan1[7e4]": { "count_hz": 0.21199999749660492, "avg_util_pm": 0.006899999920278788, "peak_util_pm": 0.009800000116229057, "avg_time_ms": 0.002899999963119626, "peak_time_ms": 0.05299999937415123 }, "Cmd:Thrtl": { "count_hz": 0.014999999664723873, "avg_util_pm": 0.0006000000284984708, "peak_util_pm": 0, "avg_time_ms": 0.004699999932199717, "peak_time_ms": 0.04699999839067459 }, "Cmd:State": { "count_hz": 0.039000000804662704, "avg_util_pm": 0.002300000051036477, "peak_util_pm": 0.007000000216066837, "avg_time_ms": 0.006500000134110451, "peak_time_ms": 0.09000000357627869 } }, "tot_count_hz": 8.59000015258789, "tot_util_pm": 3.488300085067749, "tot_time_ms": 3.1019999980926514 }
On Wed, 3 Jul 2024 at 14:31, Michael Geddes <frog@bunyip.wheelycreek.net> wrote:
OH, and also,
What do you think of treating the OvmsPoller.Times.GetStatus() items as an associative array - or should I treat it as a normal array?
//.ichael
On Wed, 3 Jul 2024 at 14:24, Michael Geddes <frog@bunyip.wheelycreek.net> wrote:
I figured I may as well add an OvmsPoller object to DukTape for Ovms. I'm waiting to get back to my OVMS so that I can test it.. but this is the documentation I have for the stuff I have coded. Thoughts on this?
What do people think of OvmsPoller.Times sub-object? I've added a general mechanism for this.
Also should I have OvmsPoller.Pause() or OvmsPoller.SetUserPaused(true) ? //.
OvmsPoller ^^^^^^^^^^ The Ovms Poller object represents the poller sub-system. It contains the following methods:
- ``ispaused = OvmsPoller.GetPaused()``: Return true if the poller is paused by the system/user. - ``ispaused = OvmsPoller.GetUserPaused()``: Return true if the poller is paused by the user. - ``OvmsPoller.Pause()``: Pause the poller (adds User poller pause) - ``OvmsPoller.Resume()``: Remove the User poller pause.
- ``tracemode = OvmsPoller.GetTrace()``: Return the current trace mode. - ``OvmsPoller.SetTrace(tracemode)``: Set the current trace mode.
The Traces still require that 'Verbose' and 'Debug' levels (depending) for the 'vehicle-poll' debug tag are set. Trace modes for verbose logging can be one of: - ``on``: On for poller loop - ``txrx``: On for txrx queue (this can be hazardous for some cars) - ``all``: On for both poller loop and txrx queuing - ``off``: Logging Off Note that only ``on`` and ``off`` are recommended.
The poller object also contains a ``Times`` property for the OBD Poll-Time tracing which contains the following methods: - ``isrunning = OvmsPoller.Times.GetEnabled()``: Returns true if the time-tracing is enabled - ``OvmsPoller.Times.SetEnabled(isrunning)``: Sets the enabled status of the timer-tracing - ``OvmsPoller.Times.Reset()``: Reset the timers (doesn't affect their current state). - ``OvmsPoller.Times.GetStatus()``: Gets the status of the various times. This returns an object of this format: .. code-block:: javascript return_value = { "items": { "Poll:PRI" : { "count_hz": 1, "avg_util_pm": 0.529, "peak_util_pm":0.652, "avg_time_ms": 0.052, "peak_time_ms":1.516 }, "Poll:SRX": { "count_hz": 1.47, "avg_util_pm": 0.302, "peak_util_pm":0.44, "avg_time_ms": 0.02, "peak_time_ms":0.573 }, "RxCan1[778]": { "count_hz": 0.74, "avg_util_pm": 0.427, "peak_util_pm":0.826, "avg_time_ms": 0.063, "peak_time_ms":1.872 }, "RxCan1[7a8]": { "count_hz": 0.35, "avg_util_pm": 0.183, "peak_util_pm":0.355, "avg_time_ms": 0.052, "peak_time_ms":1.382 }, "TxCan1[7b3]": { "count_hz": 0.07, "avg_util_pm": 0.005, "peak_util_pm":0.01, "avg_time_ms": 0.007, "peak_time_ms":0.099 }, "TxCan1[7c6]": { "count_hz": 0, "avg_util_pm": 0, "peak_util_pm":0.009, "avg_time_ms": 0.004, "peak_time_ms":0.098 }, "Cmd:State": { "count_hz": 0, "avg_util_pm": 0, "peak_util_pm":0, "avg_time_ms": 0.011, "peak_time_ms":0.109 } },
"tot_count_hz": 11.76, "tot_util_pm": 6.247, "tot_time_ms": 4.628 };
_______________________________________________ OvmsDev mailing listOvmsDev@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Soo.. for the start stop of the Poller itself we still have OvmsPoller.Pause OvmsPoller.Resume print(OvmsPoller.GetUserPaused()) then for the timer we now have OvmsPoller.Times.Start OvmsPoller.Times.Stop print( OvmsPoller.Times.GetStarted()) For the tracing (which is simply setting 2 bits) I'm torn between having the following mirroring the commands: OvmsPoller.Trace.On(), OvmsPoller.Trace.TxRx() OvmsPoller.Trace.AllOn() OvmsPoller.Trace.Off() print(OvmsPoller.Trace.GetStatus()) Or to have 2 properties 'Trace.Poller' and 'Trace.TxRx' with "C" getter/setter (which I have implemented successfully) OvmsPoller.Trace.Poller = true OvmsPoller.Trace.TxRx = false print(OvmsPoller.Trace.Poller) I don't know about the existing GetTrace() and SetTrace("on") - it does work but it's a bit clunky The registering of the getter/setters was a bit of work - but in the end looks like this in code! DuktapeObjectRegistration* dto_trace = new DuktapeObjectRegistration("OvmsPollerTrace"); dto_trace->RegisterDuktapeProperty(DukOvmsPollerTracePollerGet,DukOvmsPollerTracePollerSet, 0, "Poller"); dto_trace->RegisterDuktapeProperty(DukOvmsPollerTraceTxRxGet,DukOvmsPollerTraceTxRxSet, 0, "TxRx"); dto->RegisterDuktapeObject(dto_trace, "Trace"); I do like the splitting of functionality using 'Trace' and 'Times' to mirror sub-commands. Thoughts? //.ichael On Sat, 6 Jul 2024 at 16:07, Michael Geddes <frog@bunyip.wheelycreek.net> wrote:
I'll change SetUserPaused. I flip flopped a bit on that so happy to go with your suggestion which makes sense.
The order doesn't matter on the dictionary. A lot of JSON serialised like to alphabetise so aware of that. Anyway internally it's a map which doesn't guarantee order afaik. Could be in hash order anyway!
Also That's partly why I had separate total properties on the base object.
Michael.
On Sat, 6 July 2024, 14:54 Michael Balzer via OvmsDev, < ovmsdev@lists.openvehicles.com> wrote:
Michael,
looks good to me.
IMO API calls representing direct shell commands should not be represented as getters/setters in the JS API, so ".Pause()" & ".Resume()" are better. They are also more readable (e.g. "Resume()" vs "SetUserPaused(false)") and leave room for future command specific arguments.
Using an object structure is OK for the times, unless you want/need to make sure the same order as with the other outputs (shell/data) will be kept stable on any object transformation or transfer. Object properties (if they are strings) are normally kept in insertion order, but only within Javascript. When deserializing JS objects into other environments, the order isn't guaranteed.
Regards, Michael
Am 06.07.24 um 03:12 schrieb Michael Geddes via OvmsDev:
please have a good look at the function names.. when I have Get and Set prefixes.. should I have them.. etc to be consistent.
But Just FYI (a couple of silly bugs later) - This is the full output from a test proving that both the 'Times' property works and that at least as a concept- having the "Poll:PRI" as a key works. //. ----8<-------------------
JSON.print(OvmsPoller.Times.GetStatus())
{ "items": { "Poll:PRI": { "count_hz": 1.00600004196167, "avg_util_pm": 0.5598000288009644, "peak_util_pm": 0.6503999829292297, "avg_time_ms": 0.05350000038743019, "peak_time_ms": 0.9779999852180481 }, "Poll:SRX": { "count_hz": 1.1330000162124634, "avg_util_pm": 0.18970000743865967, "peak_util_pm": 0.23240000009536743, "avg_time_ms": 0.015799999237060547, "peak_time_ms": 0.3319999873638153 }, "RxCan1[778]": { "count_hz": 1.8489999771118164, "avg_util_pm": 1.2870999574661255, "peak_util_pm": 1.8909000158309937, "avg_time_ms": 0.06909999996423721, "peak_time_ms": 2.7119998931884766 }, "RxCan1[7bb]": { "count_hz": 0.2240000069141388, "avg_util_pm": 0.10409999638795853, "peak_util_pm": 0.25859999656677246, "avg_time_ms": 0.043800000101327896, "peak_time_ms": 1.50600004196167 }, "RxCan1[7ea]": { "count_hz": 1.0670000314712524, "avg_util_pm": 0.4699000120162964, "peak_util_pm": 0.7283999919891357, "avg_time_ms": 0.04830000177025795, "peak_time_ms": 1.5379999876022339 }, "RxCan1[7ec]": { "count_hz": 1.8669999837875366, "avg_util_pm": 0.8090000152587891, "peak_util_pm": 0.9458000063896179, "avg_time_ms": 0.04639999940991402, "peak_time_ms": 2.2769999504089355 }, "TxCan1[770]": { "count_hz": 0.9240000247955322, "avg_util_pm": 0.039400000125169754, "peak_util_pm": 0.054499998688697815, "avg_time_ms": 0.0038999998942017555, "peak_time_ms": 0.08699999749660492 }, "TxCan1[7b3]": { "count_hz": 0.041999999433755875, "avg_util_pm": 0.0035000001080334187, "peak_util_pm": 0.008299999870359898, "avg_time_ms": 0.008500000461935997, "peak_time_ms": 0.09200000017881393 }, "TxCan1[7e2]": { "count_hz": 0.21199999749660492, "avg_util_pm": 0.01600000075995922, "peak_util_pm": 0.020500000566244125, "avg_time_ms": 0.006800000090152025, "peak_time_ms": 0.08500000089406967 }, "TxCan1[7e4]": { "count_hz": 0.21199999749660492, "avg_util_pm": 0.006899999920278788, "peak_util_pm": 0.009800000116229057, "avg_time_ms": 0.002899999963119626, "peak_time_ms": 0.05299999937415123 }, "Cmd:Thrtl": { "count_hz": 0.014999999664723873, "avg_util_pm": 0.0006000000284984708, "peak_util_pm": 0, "avg_time_ms": 0.004699999932199717, "peak_time_ms": 0.04699999839067459 }, "Cmd:State": { "count_hz": 0.039000000804662704, "avg_util_pm": 0.002300000051036477, "peak_util_pm": 0.007000000216066837, "avg_time_ms": 0.006500000134110451, "peak_time_ms": 0.09000000357627869 } }, "tot_count_hz": 8.59000015258789, "tot_util_pm": 3.488300085067749, "tot_time_ms": 3.1019999980926514 }
On Wed, 3 Jul 2024 at 14:31, Michael Geddes <frog@bunyip.wheelycreek.net> wrote:
OH, and also,
What do you think of treating the OvmsPoller.Times.GetStatus() items as an associative array - or should I treat it as a normal array?
//.ichael
On Wed, 3 Jul 2024 at 14:24, Michael Geddes <frog@bunyip.wheelycreek.net> wrote:
I figured I may as well add an OvmsPoller object to DukTape for Ovms. I'm waiting to get back to my OVMS so that I can test it.. but this is the documentation I have for the stuff I have coded. Thoughts on this?
What do people think of OvmsPoller.Times sub-object? I've added a general mechanism for this.
Also should I have OvmsPoller.Pause() or OvmsPoller.SetUserPaused(true) ? //.
OvmsPoller ^^^^^^^^^^ The Ovms Poller object represents the poller sub-system. It contains the following methods:
- ``ispaused = OvmsPoller.GetPaused()``: Return true if the poller is paused by the system/user. - ``ispaused = OvmsPoller.GetUserPaused()``: Return true if the poller is paused by the user. - ``OvmsPoller.Pause()``: Pause the poller (adds User poller pause) - ``OvmsPoller.Resume()``: Remove the User poller pause.
- ``tracemode = OvmsPoller.GetTrace()``: Return the current trace mode. - ``OvmsPoller.SetTrace(tracemode)``: Set the current trace mode.
The Traces still require that 'Verbose' and 'Debug' levels (depending) for the 'vehicle-poll' debug tag are set. Trace modes for verbose logging can be one of: - ``on``: On for poller loop - ``txrx``: On for txrx queue (this can be hazardous for some cars) - ``all``: On for both poller loop and txrx queuing - ``off``: Logging Off Note that only ``on`` and ``off`` are recommended.
The poller object also contains a ``Times`` property for the OBD Poll-Time tracing which contains the following methods: - ``isrunning = OvmsPoller.Times.GetEnabled()``: Returns true if the time-tracing is enabled - ``OvmsPoller.Times.SetEnabled(isrunning)``: Sets the enabled status of the timer-tracing - ``OvmsPoller.Times.Reset()``: Reset the timers (doesn't affect their current state). - ``OvmsPoller.Times.GetStatus()``: Gets the status of the various times. This returns an object of this format: .. code-block:: javascript return_value = { "items": { "Poll:PRI" : { "count_hz": 1, "avg_util_pm": 0.529, "peak_util_pm":0.652, "avg_time_ms": 0.052, "peak_time_ms":1.516 }, "Poll:SRX": { "count_hz": 1.47, "avg_util_pm": 0.302, "peak_util_pm":0.44, "avg_time_ms": 0.02, "peak_time_ms":0.573 }, "RxCan1[778]": { "count_hz": 0.74, "avg_util_pm": 0.427, "peak_util_pm":0.826, "avg_time_ms": 0.063, "peak_time_ms":1.872 }, "RxCan1[7a8]": { "count_hz": 0.35, "avg_util_pm": 0.183, "peak_util_pm":0.355, "avg_time_ms": 0.052, "peak_time_ms":1.382 }, "TxCan1[7b3]": { "count_hz": 0.07, "avg_util_pm": 0.005, "peak_util_pm":0.01, "avg_time_ms": 0.007, "peak_time_ms":0.099 }, "TxCan1[7c6]": { "count_hz": 0, "avg_util_pm": 0, "peak_util_pm":0.009, "avg_time_ms": 0.004, "peak_time_ms":0.098 }, "Cmd:State": { "count_hz": 0, "avg_util_pm": 0, "peak_util_pm":0, "avg_time_ms": 0.011, "peak_time_ms":0.109 } },
"tot_count_hz": 11.76, "tot_util_pm": 6.247, "tot_time_ms": 4.628 };
_______________________________________________ OvmsDev mailing listOvmsDev@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Think of the tracing control in terms of a UI context: you would normally represent the bits by checkboxes, which could either react immediately on change or combined by a "Configure" button. In either case, you'd curse an API for needing different commands to be called depending on which checkbox combination has been set. Exposing bits directly (sort of) though is new to our API, not sure if I would do that. I'd rather introduce a call with an object argument for readability, resulting in an API call like … OvmsPoller.Trace({ poller: true, txrx: false }); … with defaults false for both members, so both are optional. Accordingly, `OvmsPoller.GetTraceStatus()` would return that very same object. Regards, Michael Am 07.07.24 um 02:43 schrieb Michael Geddes:
Soo.. for the start stop of the Poller itself we still have
OvmsPoller.Pause OvmsPoller.Resume
print(OvmsPoller.GetUserPaused())
then for the timer we now have
OvmsPoller.Times.Start OvmsPoller.Times.Stop print( OvmsPoller.Times.GetStarted())
For the tracing (which is simply setting 2 bits) I'm torn between having the following mirroring the commands:
OvmsPoller.Trace.On(), OvmsPoller.Trace.TxRx() OvmsPoller.Trace.AllOn() OvmsPoller.Trace.Off()
print(OvmsPoller.Trace.GetStatus())
Or to have 2 properties 'Trace.Poller' and 'Trace.TxRx' with "C" getter/setter (which I have implemented successfully)
OvmsPoller.Trace.Poller = true OvmsPoller.Trace.TxRx = false print(OvmsPoller.Trace.Poller)
I don't know about the existing GetTrace() and SetTrace("on") - it does work but it's a bit clunky
The registering of the getter/setters was a bit of work - but in the end looks like this in code!
DuktapeObjectRegistration* dto_trace = new DuktapeObjectRegistration("OvmsPollerTrace"); dto_trace->RegisterDuktapeProperty(DukOvmsPollerTracePollerGet,DukOvmsPollerTracePollerSet, 0, "Poller"); dto_trace->RegisterDuktapeProperty(DukOvmsPollerTraceTxRxGet,DukOvmsPollerTraceTxRxSet, 0, "TxRx"); dto->RegisterDuktapeObject(dto_trace, "Trace");
I do like the splitting of functionality using 'Trace' and 'Times' to mirror sub-commands.
Thoughts?
//.ichael
On Sat, 6 Jul 2024 at 16:07, Michael Geddes <frog@bunyip.wheelycreek.net> wrote:
I'll change SetUserPaused. I flip flopped a bit on that so happy to go with your suggestion which makes sense.
The order doesn't matter on the dictionary. A lot of JSON serialised like to alphabetise so aware of that. Anyway internally it's a map which doesn't guarantee order afaik. Could be in hash order anyway!
Also That's partly why I had separate total properties on the base object.
Michael.
On Sat, 6 July 2024, 14:54 Michael Balzer via OvmsDev, <ovmsdev@lists.openvehicles.com> wrote:
Michael,
looks good to me.
IMO API calls representing direct shell commands should not be represented as getters/setters in the JS API, so ".Pause()" & ".Resume()" are better. They are also more readable (e.g. "Resume()" vs "SetUserPaused(false)") and leave room for future command specific arguments.
Using an object structure is OK for the times, unless you want/need to make sure the same order as with the other outputs (shell/data) will be kept stable on any object transformation or transfer. Object properties (if they are strings) are normally kept in insertion order, but only within Javascript. When deserializing JS objects into other environments, the order isn't guaranteed.
Regards, Michael
Am 06.07.24 um 03:12 schrieb Michael Geddes via OvmsDev:
please have a good look at the function names.. when I have Get and Set prefixes.. should I have them.. etc to be consistent.
But Just FYI (a couple of silly bugs later) - This is the full output from a test proving that both the 'Times' property works and that at least as a concept- having the "Poll:PRI" as a key works. //. ----8<-------------------
JSON.print(OvmsPoller.Times.GetStatus())
{ "items": { "Poll:PRI": { "count_hz": 1.00600004196167, "avg_util_pm": 0.5598000288009644, "peak_util_pm": 0.6503999829292297, "avg_time_ms": 0.05350000038743019, "peak_time_ms": 0.9779999852180481 }, "Poll:SRX": { "count_hz": 1.1330000162124634, "avg_util_pm": 0.18970000743865967, "peak_util_pm": 0.23240000009536743, "avg_time_ms": 0.015799999237060547, "peak_time_ms": 0.3319999873638153 }, "RxCan1[778]": { "count_hz": 1.8489999771118164, "avg_util_pm": 1.2870999574661255, "peak_util_pm": 1.8909000158309937, "avg_time_ms": 0.06909999996423721, "peak_time_ms": 2.7119998931884766 }, "RxCan1[7bb]": { "count_hz": 0.2240000069141388, "avg_util_pm": 0.10409999638795853, "peak_util_pm": 0.25859999656677246, "avg_time_ms": 0.043800000101327896, "peak_time_ms": 1.50600004196167 }, "RxCan1[7ea]": { "count_hz": 1.0670000314712524, "avg_util_pm": 0.4699000120162964, "peak_util_pm": 0.7283999919891357, "avg_time_ms": 0.04830000177025795, "peak_time_ms": 1.5379999876022339 }, "RxCan1[7ec]": { "count_hz": 1.8669999837875366, "avg_util_pm": 0.8090000152587891, "peak_util_pm": 0.9458000063896179, "avg_time_ms": 0.04639999940991402, "peak_time_ms": 2.2769999504089355 }, "TxCan1[770]": { "count_hz": 0.9240000247955322, "avg_util_pm": 0.039400000125169754, "peak_util_pm": 0.054499998688697815, "avg_time_ms": 0.0038999998942017555, "peak_time_ms": 0.08699999749660492 }, "TxCan1[7b3]": { "count_hz": 0.041999999433755875, "avg_util_pm": 0.0035000001080334187, "peak_util_pm": 0.008299999870359898, "avg_time_ms": 0.008500000461935997, "peak_time_ms": 0.09200000017881393 }, "TxCan1[7e2]": { "count_hz": 0.21199999749660492, "avg_util_pm": 0.01600000075995922, "peak_util_pm": 0.020500000566244125, "avg_time_ms": 0.006800000090152025, "peak_time_ms": 0.08500000089406967 }, "TxCan1[7e4]": { "count_hz": 0.21199999749660492, "avg_util_pm": 0.006899999920278788, "peak_util_pm": 0.009800000116229057, "avg_time_ms": 0.002899999963119626, "peak_time_ms": 0.05299999937415123 }, "Cmd:Thrtl": { "count_hz": 0.014999999664723873, "avg_util_pm": 0.0006000000284984708, "peak_util_pm": 0, "avg_time_ms": 0.004699999932199717, "peak_time_ms": 0.04699999839067459 }, "Cmd:State": { "count_hz": 0.039000000804662704, "avg_util_pm": 0.002300000051036477, "peak_util_pm": 0.007000000216066837, "avg_time_ms": 0.006500000134110451, "peak_time_ms": 0.09000000357627869 } }, "tot_count_hz": 8.59000015258789, "tot_util_pm": 3.488300085067749, "tot_time_ms": 3.1019999980926514 }
On Wed, 3 Jul 2024 at 14:31, Michael Geddes <frog@bunyip.wheelycreek.net> wrote:
OH, and also,
What do you think of treating the OvmsPoller.Times.GetStatus() items as an associative array - or should I treat it as a normal array?
//.ichael
On Wed, 3 Jul 2024 at 14:24, Michael Geddes <frog@bunyip.wheelycreek.net> wrote:
I figured I may as well add an OvmsPoller object to DukTape for Ovms. I'm waiting to get back to my OVMS so that I can test it.. but this is the documentation I have for the stuff I have coded. Thoughts on this?
What do people think of OvmsPoller.Times sub-object? I've added a general mechanism for this.
Also should I have OvmsPoller.Pause() or OvmsPoller.SetUserPaused(true) ? //.
OvmsPoller ^^^^^^^^^^ The Ovms Poller object represents the poller sub-system. It contains the following methods:
- ``ispaused = OvmsPoller.GetPaused()``: Return true if the poller is paused by the system/user. - ``ispaused = OvmsPoller.GetUserPaused()``: Return true if the poller is paused by the user. - ``OvmsPoller.Pause()``: Pause the poller (adds User poller pause) - ``OvmsPoller.Resume()``: Remove the User poller pause.
- ``tracemode = OvmsPoller.GetTrace()``: Return the current trace mode. - ``OvmsPoller.SetTrace(tracemode)``: Set the current trace mode.
The Traces still require that 'Verbose' and 'Debug' levels (depending) for the 'vehicle-poll' debug tag are set. Trace modes for verbose logging can be one of: - ``on``: On for poller loop - ``txrx``: On for txrx queue (this can be hazardous for some cars) - ``all``: On for both poller loop and txrx queuing - ``off``: Logging Off Note that only ``on`` and ``off`` are recommended.
The poller object also contains a ``Times`` property for the OBD Poll-Time tracing which contains the following methods: - ``isrunning = OvmsPoller.Times.GetEnabled()``: Returns true if the time-tracing is enabled - ``OvmsPoller.Times.SetEnabled(isrunning)``: Sets the enabled status of the timer-tracing - ``OvmsPoller.Times.Reset()``: Reset the timers (doesn't affect their current state). - ``OvmsPoller.Times.GetStatus()``: Gets the status of the various times. This returns an object of this format: .. code-block:: javascript return_value = { "items": { "Poll:PRI" : { "count_hz": 1, "avg_util_pm": 0.529, "peak_util_pm":0.652, "avg_time_ms": 0.052, "peak_time_ms":1.516 }, "Poll:SRX": { "count_hz": 1.47, "avg_util_pm": 0.302, "peak_util_pm":0.44, "avg_time_ms": 0.02, "peak_time_ms":0.573 }, "RxCan1[778]": { "count_hz": 0.74, "avg_util_pm": 0.427, "peak_util_pm":0.826, "avg_time_ms": 0.063, "peak_time_ms":1.872 }, "RxCan1[7a8]": { "count_hz": 0.35, "avg_util_pm": 0.183, "peak_util_pm":0.355, "avg_time_ms": 0.052, "peak_time_ms":1.382 }, "TxCan1[7b3]": { "count_hz": 0.07, "avg_util_pm": 0.005, "peak_util_pm":0.01, "avg_time_ms": 0.007, "peak_time_ms":0.099 }, "TxCan1[7c6]": { "count_hz": 0, "avg_util_pm": 0, "peak_util_pm":0.009, "avg_time_ms": 0.004, "peak_time_ms":0.098 }, "Cmd:State": { "count_hz": 0, "avg_util_pm": 0, "peak_util_pm":0, "avg_time_ms": 0.011, "peak_time_ms":0.109 } },
"tot_count_hz": 11.76, "tot_util_pm": 6.247, "tot_time_ms": 4.628 };
_______________________________________________ OvmsDev mailing list 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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Sure. That could work. I'll give it a go. //. On Mon, 8 July 2024, 00:30 Michael Balzer via OvmsDev, < ovmsdev@lists.openvehicles.com> wrote:
Think of the tracing control in terms of a UI context: you would normally represent the bits by checkboxes, which could either react immediately on change or combined by a "Configure" button. In either case, you'd curse an API for needing different commands to be called depending on which checkbox combination has been set.
Exposing bits directly (sort of) though is new to our API, not sure if I would do that. I'd rather introduce a call with an object argument for readability, resulting in an API call like …
OvmsPoller.Trace({ poller: true, txrx: false });
… with defaults false for both members, so both are optional. Accordingly, `OvmsPoller.GetTraceStatus()` would return that very same object.
Regards, Michael
Am 07.07.24 um 02:43 schrieb Michael Geddes:
Soo.. for the start stop of the Poller itself we still have
OvmsPoller.Pause OvmsPoller.Resume
print(OvmsPoller.GetUserPaused())
then for the timer we now have
OvmsPoller.Times.Start OvmsPoller.Times.Stop print( OvmsPoller.Times.GetStarted())
For the tracing (which is simply setting 2 bits) I'm torn between having the following mirroring the commands:
OvmsPoller.Trace.On(), OvmsPoller.Trace.TxRx() OvmsPoller.Trace.AllOn() OvmsPoller.Trace.Off()
print(OvmsPoller.Trace.GetStatus())
Or to have 2 properties 'Trace.Poller' and 'Trace.TxRx' with "C" getter/setter (which I have implemented successfully)
OvmsPoller.Trace.Poller = true OvmsPoller.Trace.TxRx = false print(OvmsPoller.Trace.Poller)
I don't know about the existing GetTrace() and SetTrace("on") - it does work but it's a bit clunky
The registering of the getter/setters was a bit of work - but in the end looks like this in code!
DuktapeObjectRegistration* dto_trace = new DuktapeObjectRegistration("OvmsPollerTrace");
dto_trace->RegisterDuktapeProperty(DukOvmsPollerTracePollerGet,DukOvmsPollerTracePollerSet, 0, "Poller");
dto_trace->RegisterDuktapeProperty(DukOvmsPollerTraceTxRxGet,DukOvmsPollerTraceTxRxSet, 0, "TxRx"); dto->RegisterDuktapeObject(dto_trace, "Trace");
I do like the splitting of functionality using 'Trace' and 'Times' to mirror sub-commands.
Thoughts?
//.ichael
On Sat, 6 Jul 2024 at 16:07, Michael Geddes <frog@bunyip.wheelycreek.net> wrote:
I'll change SetUserPaused. I flip flopped a bit on that so happy to go with your suggestion which makes sense.
The order doesn't matter on the dictionary. A lot of JSON serialised like to alphabetise so aware of that. Anyway internally it's a map which doesn't guarantee order afaik. Could be in hash order anyway!
Also That's partly why I had separate total properties on the base object.
Michael.
On Sat, 6 July 2024, 14:54 Michael Balzer via OvmsDev, < ovmsdev@lists.openvehicles.com> wrote:
Michael,
looks good to me.
IMO API calls representing direct shell commands should not be represented as getters/setters in the JS API, so ".Pause()" & ".Resume()" are better. They are also more readable (e.g. "Resume()" vs "SetUserPaused(false)") and leave room for future command specific arguments.
Using an object structure is OK for the times, unless you want/need to make sure the same order as with the other outputs (shell/data) will be kept stable on any object transformation or transfer. Object properties (if they are strings) are normally kept in insertion order, but only within Javascript. When deserializing JS objects into other environments, the order isn't guaranteed.
Regards, Michael
Am 06.07.24 um 03:12 schrieb Michael Geddes via OvmsDev:
please have a good look at the function names.. when I have Get and Set prefixes.. should I have them.. etc to be consistent.
But Just FYI (a couple of silly bugs later) - This is the full output from a test proving that both the 'Times' property works and that at least as a concept- having the "Poll:PRI" as a key works. //. ----8<-------------------
JSON.print(OvmsPoller.Times.GetStatus())
{ "items": { "Poll:PRI": { "count_hz": 1.00600004196167, "avg_util_pm": 0.5598000288009644, "peak_util_pm": 0.6503999829292297, "avg_time_ms": 0.05350000038743019, "peak_time_ms": 0.9779999852180481 }, "Poll:SRX": { "count_hz": 1.1330000162124634, "avg_util_pm": 0.18970000743865967, "peak_util_pm": 0.23240000009536743, "avg_time_ms": 0.015799999237060547, "peak_time_ms": 0.3319999873638153 }, "RxCan1[778]": { "count_hz": 1.8489999771118164, "avg_util_pm": 1.2870999574661255, "peak_util_pm": 1.8909000158309937, "avg_time_ms": 0.06909999996423721, "peak_time_ms": 2.7119998931884766 }, "RxCan1[7bb]": { "count_hz": 0.2240000069141388, "avg_util_pm": 0.10409999638795853, "peak_util_pm": 0.25859999656677246, "avg_time_ms": 0.043800000101327896, "peak_time_ms": 1.50600004196167 }, "RxCan1[7ea]": { "count_hz": 1.0670000314712524, "avg_util_pm": 0.4699000120162964, "peak_util_pm": 0.7283999919891357, "avg_time_ms": 0.04830000177025795, "peak_time_ms": 1.5379999876022339 }, "RxCan1[7ec]": { "count_hz": 1.8669999837875366, "avg_util_pm": 0.8090000152587891, "peak_util_pm": 0.9458000063896179, "avg_time_ms": 0.04639999940991402, "peak_time_ms": 2.2769999504089355 }, "TxCan1[770]": { "count_hz": 0.9240000247955322, "avg_util_pm": 0.039400000125169754, "peak_util_pm": 0.054499998688697815, "avg_time_ms": 0.0038999998942017555, "peak_time_ms": 0.08699999749660492 }, "TxCan1[7b3]": { "count_hz": 0.041999999433755875, "avg_util_pm": 0.0035000001080334187, "peak_util_pm": 0.008299999870359898, "avg_time_ms": 0.008500000461935997, "peak_time_ms": 0.09200000017881393 }, "TxCan1[7e2]": { "count_hz": 0.21199999749660492, "avg_util_pm": 0.01600000075995922, "peak_util_pm": 0.020500000566244125, "avg_time_ms": 0.006800000090152025, "peak_time_ms": 0.08500000089406967 }, "TxCan1[7e4]": { "count_hz": 0.21199999749660492, "avg_util_pm": 0.006899999920278788, "peak_util_pm": 0.009800000116229057, "avg_time_ms": 0.002899999963119626, "peak_time_ms": 0.05299999937415123 }, "Cmd:Thrtl": { "count_hz": 0.014999999664723873, "avg_util_pm": 0.0006000000284984708, "peak_util_pm": 0, "avg_time_ms": 0.004699999932199717, "peak_time_ms": 0.04699999839067459 }, "Cmd:State": { "count_hz": 0.039000000804662704, "avg_util_pm": 0.002300000051036477, "peak_util_pm": 0.007000000216066837, "avg_time_ms": 0.006500000134110451, "peak_time_ms": 0.09000000357627869 } }, "tot_count_hz": 8.59000015258789, "tot_util_pm": 3.488300085067749, "tot_time_ms": 3.1019999980926514 }
On Wed, 3 Jul 2024 at 14:31, Michael Geddes <frog@bunyip.wheelycreek.net> wrote:
OH, and also,
What do you think of treating the OvmsPoller.Times.GetStatus() items as an associative array - or should I treat it as a normal array?
//.ichael
On Wed, 3 Jul 2024 at 14:24, Michael Geddes < frog@bunyip.wheelycreek.net> wrote:
I figured I may as well add an OvmsPoller object to DukTape for Ovms. I'm waiting to get back to my OVMS so that I can test it.. but this is the documentation I have for the stuff I have coded. Thoughts on this?
What do people think of OvmsPoller.Times sub-object? I've added a general mechanism for this.
Also should I have OvmsPoller.Pause() or OvmsPoller.SetUserPaused(true) ? //.
OvmsPoller ^^^^^^^^^^ The Ovms Poller object represents the poller sub-system. It contains the following methods:
- ``ispaused = OvmsPoller.GetPaused()``: Return true if the poller is paused by the system/user. - ``ispaused = OvmsPoller.GetUserPaused()``: Return true if the poller is paused by the user. - ``OvmsPoller.Pause()``: Pause the poller (adds User poller pause) - ``OvmsPoller.Resume()``: Remove the User poller pause.
- ``tracemode = OvmsPoller.GetTrace()``: Return the current trace mode. - ``OvmsPoller.SetTrace(tracemode)``: Set the current trace mode.
The Traces still require that 'Verbose' and 'Debug' levels (depending) for the 'vehicle-poll' debug tag are set. Trace modes for verbose logging can be one of: - ``on``: On for poller loop - ``txrx``: On for txrx queue (this can be hazardous for some cars) - ``all``: On for both poller loop and txrx queuing - ``off``: Logging Off Note that only ``on`` and ``off`` are recommended.
The poller object also contains a ``Times`` property for the OBD Poll-Time tracing which contains the following methods: - ``isrunning = OvmsPoller.Times.GetEnabled()``: Returns true if the time-tracing is enabled - ``OvmsPoller.Times.SetEnabled(isrunning)``: Sets the enabled status of the timer-tracing - ``OvmsPoller.Times.Reset()``: Reset the timers (doesn't affect their current state). - ``OvmsPoller.Times.GetStatus()``: Gets the status of the various times. This returns an object of this format: .. code-block:: javascript return_value = { "items": { "Poll:PRI" : { "count_hz": 1, "avg_util_pm": 0.529, "peak_util_pm":0.652, "avg_time_ms": 0.052, "peak_time_ms":1.516 }, "Poll:SRX": { "count_hz": 1.47, "avg_util_pm": 0.302, "peak_util_pm":0.44, "avg_time_ms": 0.02, "peak_time_ms":0.573 }, "RxCan1[778]": { "count_hz": 0.74, "avg_util_pm": 0.427, "peak_util_pm":0.826, "avg_time_ms": 0.063, "peak_time_ms":1.872 }, "RxCan1[7a8]": { "count_hz": 0.35, "avg_util_pm": 0.183, "peak_util_pm":0.355, "avg_time_ms": 0.052, "peak_time_ms":1.382 }, "TxCan1[7b3]": { "count_hz": 0.07, "avg_util_pm": 0.005, "peak_util_pm":0.01, "avg_time_ms": 0.007, "peak_time_ms":0.099 }, "TxCan1[7c6]": { "count_hz": 0, "avg_util_pm": 0, "peak_util_pm":0.009, "avg_time_ms": 0.004, "peak_time_ms":0.098 }, "Cmd:State": { "count_hz": 0, "avg_util_pm": 0, "peak_util_pm":0, "avg_time_ms": 0.011, "peak_time_ms":0.109 } },
"tot_count_hz": 11.76, "tot_util_pm": 6.247, "tot_time_ms": 4.628 };
_______________________________________________ OvmsDev mailing listOvmsDev@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@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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (2)
-
Michael Balzer -
Michael Geddes