Soo.. for the start stop of the Poller itself we still haveOvmsPoller.PauseOvmsPoller.Resumeprint(OvmsPoller.GetUserPaused())then for the timer we now haveOvmsPoller.Times.StartOvmsPoller.Times.Stopprint( 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 = trueOvmsPoller.Trace.TxRx = falseprint(OvmsPoller.Trace.Poller)
I don't know about the existing GetTrace() and SetTrace("on") - it does work but it's a bit clunkyThe 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