[Ovmsdev] Adding Pollers object to Duktape
Michael Geddes
frog at bunyip.wheelycreek.net
Mon Jul 8 10:48:27 HKT 2024
Sure.
That could work. I'll give it a go.
//.
On Mon, 8 July 2024, 00:30 Michael Balzer via OvmsDev, <
ovmsdev at 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 at 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 at 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 at 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 at 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 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
>>>
>>
> --
> 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/20240708/67b72a91/attachment-0001.htm>
More information about the OvmsDev
mailing list