Vehicle poller: PollSingleRequest speed & VWTP protocol regressions

[dexterbg]

Since PR #1010, multiple single poll requests in series are limited to one request per second, making Javascript toolkits like the UpMiiGo ECU plugin unusably slow or causing crashes.

Since PR #1012, the VWTP protocol is broken.

Examples + Logs, all with the same ECU scans (querying HW & SW info, Coding, Subroutines, DTCs etc.):

a) Pre-bug normal/expected behaviour; HEAD at bd4e719 Merge pull request #1008 from frogonwheels/poller-task-fix:

• Scanning the ISOTP ECU takes ~1 second, with complete & correct results
• Scanning the VWTP ECU takes ~5 seconds, with complete & correct results
  pollerbug-251101-scanlog-a.txt

b) Slowdown of all single polls; HEAD at b125dfe Merge pull request #1010 from frogonwheels/fix-obey-throttle:

• Scanning the ISOTP ECU takes ~20 seconds, still complete & correct results
• Scanning the VWTP ECU takes ~35 seconds, still complete & correct results
  pollerbug-251101-scanlog-b.txt

c) Partial ISOTP failure + complete VWTP failure; HEAD at 53713d9 Merge pull request #1012 from frogonwheels/fix-shutdown

• Scanning the ISOTP ECU takes ~20 seconds, incomplete results (some queries failed)
• Scannning tht VWTP ECU fails within 1 second with ERROR: Login failed: Timeout waiting for poller/response
  pollerbug-251101-scanlog-c.txt

Meanwhile (current master HEAD) ISOTP again delivers complete results, but still takes more than 20 seconds, VWTP still is totally broken.

@frogonwheels Michael, any idea? It seems single polls now also are throttled, which may be wrong in the first place. If they should be throttled, the API needs some method to control default throttling from JS. Throttling doesn't seem to be the VWTP issue though. Sorry this hasn't been detected earlier, I only use the ECU toolkit about once a year to check for annual service and retrieve DTCs.

The ECU toolkit's scan method is here:
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master/plugin/v-vweup/ecutoolkit/xvu-ecu.js#L441

[dexterbg]

@frogonwheels Michael, the VWTP issue was caused by an incorrect change to the "done" detection in combination with resetting the m_poll.type. As VWTP requests consist of multiple transmissions also during the channel setup, the correct test is for m_poll_wait becoming zero. You first removed this test in commit a37b689 and later added the test for the remaining frame count instead, which only applies to an actual pending response, not to channel management.

The throttling control still needs to be addressed, but isn't an issue when loading the VWUP vehicle before, as that disables the throttling, so no priority.

I found another issue with the Duktape API: OvmsVehicle.ObdRequest() does not return an error on request timeout. The shell command does this though:

OVMS# obd can1 req dev 7e0 7e8 22f191
7e0[7e8] 22f191: ERROR: timeout waiting for poller/response

OVMS# sc ev 'JSON.print(OvmsVehicle.ObdRequest({txid: 0x7e0, rxid: 0x7e8, request: "22f191"}))'
{
  "error": 0,
  "errordesc": "",
  "response": {
  },
  "response_hex": ""
}

This seems to be somehow caused by using the other API that was meant for simple PID reads. The shell command always uses the hex request string API, which the Duktape call previously also did. You extended that by the type and pid option, but apparently now translate all calls to that style -- maybe timeouts get lost somewhere down that chain?

[frogonwheels]

Thanks Michael Ive been a little caught up with things. I'll try and have a think about the throttling and follow through with the error issue. //.ichael

…

On Thu, 13 Nov 2025, 01:40 Michael Balzer, ***@***.***> wrote: *dexterbg* left a comment (openvehicles/Open-Vehicle-Monitoring-System-3#1232) <#1232 (comment)> @frogonwheels <https://github.com/frogonwheels> Michael, the VWTP issue was caused by an incorrect change to the "done" detection in combination with resetting the m_poll.type. As VWTP requests consist of multiple transmissions also during the channel setup, the correct test is for m_poll_wait becoming zero. You first removed this test in commit a37b689 <a37b689> and later added the test for the remaining frame count instead, which only applies to an actual pending response, not to channel management. The throttling control still needs to be addressed, but isn't an issue when loading the VWUP vehicle before, as that disables the throttling, so no priority. I found another issue with the Duktape API: OvmsVehicle.ObdRequest() does not return an error on request timeout. The shell command does this though: OVMS# obd can1 req dev 7e0 7e8 22f191 7e0[7e8] 22f191: ERROR: timeout waiting for poller/response OVMS# sc ev 'JSON.print(OvmsVehicle.ObdRequest({txid: 0x7e0, rxid: 0x7e8, request: "22f191"}))' { "error": 0, "errordesc": "", "response": { }, "response_hex": "" } This seems to be somehow caused by using the other API that was meant for simple PID reads. The shell command always uses the hex request string API, which the Duktape call previously also did. You extended that by the type and pid option, but apparently now translate all calls to that style -- maybe timeouts get lost somewhere down that chain? — Reply to this email directly, view it on GitHub <#1232 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABNANSAAK7VEJAN5TFWXHD34NWHDAVCNFSM6AAAAACK3IJKQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMRTGEYTSMJRGM> . You are receiving this because you were mentioned.Message ID: <openvehicles/Open-Vehicle-Monitoring-System-3/issues/1232/3523119113@ github.com>

[dexterbg]

The issue wasn't related to the different API methods used, in fact the outcome was pure chance. The rx_error variable lacked an initialization, so could have any value after a timeout, depending only on the stack situation on entry.

The other issue solved by commit 5d624c4 may need some more reconsideration: as the IncomingError() method now also transports internal errors (negative values), using uint16_t for the error code isn't really correct anymore. Changing this to int would reflect it's now combined purpose and be cleaner than casting to int16_t in the single poll case.

When testing I found & fixed another issue causing crashes from erasing the poll list (passing NULL). See commit 552e435.

And I found yet another issue arising from the now asynchronous primary ticker, that might also affect ISOTP requests, see commit 614e406.

The VWTP protocol ticker assumed to be called not earlier than roughly one second after the last TX operation, so m_poll_wait == 1 could be assumed as "1 second passed". That's no longer the case, as the now independent poller ticker primary tick can now come immediately after the TX operation.

This also means the actual waiting time from setting m_poll_wait = 2 can now be anything from 1…2 seconds, potentially causing other issues as well. I thought about resetting the timer for a single poll, but that would interfere with a running standard poll list relying on a consistent timer interval. (Do we do that somewhere?)

The timeout hasn't been exact since we allowed multiple polls per second, but these normally were done within 50-100 ms, leaving enough headroom for the ticker to work as a timeout counter. Maybe we should raise the m_poll_wait resolution to ms and use a 100 ms minimum ticker interval generally? Or by default enable secondary ticks at minimum 10 per second, and extend the m_poll_wait decrement to the secondary runs as well?

[frogonwheels]

OH wow. This is soo good, thankyou. (I mean bad .. but good that you've found these). Comments inline below: //.ichael G

On Fri, 14 Nov 2025 at 21:30, Michael Balzer ***@***.***> wrote: *dexterbg* left a comment (openvehicles/Open-Vehicle-Monitoring-System-3#1232) <#1232 (comment)> The issue wasn't related to the different API methods used, in fact the outcome was pure chance. The rx_error variable lacked an initialization, so

Damn, I thought I had got all the initialisations (I had checked at one point) so I'm disappointed I missed one, thanks.

could have any value after a timeout, depending only on the stack situation on entry. The other issue solved by commit 5d624c4 <5d624c4> may need some more reconsideration: as the IncomingError() method now also transports internal errors (negative values), using uint16_t for the error code isn't really correct anymore. Changing this to int would reflect it's now combined purpose and be cleaner than casting to int16_t in the single poll case.

Yeah - let's not lose the sign. I can do this. I'll pass it as an int32_t.

When testing I found & fixed another issue causing crashes from erasing the poll list (passing NULL). See commit 552e435 <552e435> .

Ah.. this kind of null check is the kind of thing I'd been searching for but just wasn't seeing... so thanks.. I'd been assuming/worried that something like this was still happening.

And I found yet another issue arising from the now asynchronous primary ticker, that might also affect ISOTP requests, see commit 614e406 <614e406> . The VWTP protocol ticker assumed to be called not earlier than roughly one second after the last TX operation, so m_poll_wait == 1 could be assumed as "1 second passed". That's no longer the case, as the now independent poller ticker primary tick can now come immediately after the TX operation. This also means the actual waiting time from setting m_poll_wait = 2 can now be anything from 1…2 seconds, potentially causing other issues as well. I thought about resetting the timer for a single poll, but that would interfere with a running standard poll list relying on a consistent timer interval. (Do we do that somewhere?) The timeout hasn't been exact since we allowed multiple polls per second, but these normally were done within 50-100 ms, leaving enough headroom for the ticker to work as a timeout counter. Maybe we should raise the m_poll_wait resolution to ms and use a 100 ms minimum ticker interval generally? Or by default enable secondary ticks at minimum 10 per second, and extend the m_poll_wait decrement to the secondary runs as well?

Hmm. I like the idea of increasing the granularity of m_poll_wait. I also don't mind the idea of changing the subtick default. For the ioniq 5, I have 3 per second but only when the ECU is enabled. There are a few ideas in what I use then: PollSetTimeBetweenSuccess(80); // 80ms Gap between each successful poll. PollSetResponseSeparationTime(5); // Faster bursts of messages. PollSetTicker(300, 3); // 3 per second. So I'm happy to consider some different defaults. We could also make them different based on whether the car is running. We could hide what poll_wait is doing behind a couple of functions bool get_poll_waiting() and set_poll_wait(int ms). Then we could use the clock time.. or some other timer to gate that. set_poll_wait( ) could just set the current timestamp + ms and then get_poll_waiting() just sees if the current time is >= that? How does that seem?

…

— Reply to this email directly, view it on GitHub <#1232 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABNANVUGWGLELFUWKVDRBD34XKORAVCNFSM6AAAAACK3IJKQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMZSHAYDQOJTGM> . You are receiving this because you were mentioned.Message ID: <openvehicles/Open-Vehicle-Monitoring-System-3/issues/1232/3532808933@ github.com>

[dexterbg]

Yes, something like that.

Higher ticker resolution needs to work without a car (more precisely the NONE car) as well, so shouldn't need or apply the vehicle state. It also shouldn't depend on PollSetTicker() being called, as that would add a required preparation for the use of the single request commands (shell & JS).

[frogonwheels]

Im working on the issue of the poller throttle. Im going to add a separate throttle for blocking polls. Should I default to something like 10/s? Or 0 (unthrottled). Michael

…

On Sat, 15 Nov 2025, 18:54 Michael Balzer, ***@***.***> wrote: *dexterbg* left a comment (openvehicles/Open-Vehicle-Monitoring-System-3#1232) <#1232 (comment)> Yes, something like that. Higher ticker resolution needs to work without a car (more precisely the NONE car) as well, so shouldn't need or apply the vehicle state. It also shouldn't depend on PollSetTicker() being called, as that would add a required preparation for the use of the single request commands (shell & JS). — Reply to this email directly, view it on GitHub <#1232 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABNANWUZGPCFOWDM645UHL344A6ZAVCNFSM6AAAAACK3IJKQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMZWGMZTENBVGY> . You are receiving this because you were mentioned.Message ID: <openvehicles/Open-Vehicle-Monitoring-System-3/issues/1232/3536332456@ github.com>

[dexterbg]

That should be unthrottled then, as throttling adds to blocking time, which is generally bad with complex queries like ECU scans. If necessary, the application using blocking requests can/shall take care for the throttling itself.

[frogonwheels]

I have some commits that I thought I'd just run live for a bit for: * Expand error to int32_t * Going to time-based hold. (I've gone for 1000ms and then additional 500ms... and I'm a bit unsure of some of that without knowing what the base requirements are. * Defaulting to no throttling for blocking once-offs. If you wanted to, I can push it up to my account (and make a draft if necessary). //.ichael

…

On Sun, 16 Nov 2025 at 15:17, Michael Balzer ***@***.***> wrote: *dexterbg* left a comment (openvehicles/Open-Vehicle-Monitoring-System-3#1232) <#1232 (comment)> That should be unthrottled then, as throttling adds to blocking time, which is generally bad with complex queries like ECU scans. If necessary, the application using blocking requests can/shall take care for the throttling itself. — Reply to this email directly, view it on GitHub <#1232 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABNANXWITCX4Q6QNWBZNRL35AQHXAVCNFSM6AAAAACK3IJKQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMZYGE4TQMBXG4> . You are receiving this because you were mentioned.Message ID: <openvehicles/Open-Vehicle-Monitoring-System-3/issues/1232/3538198077@ github.com>

[frogonwheels]

Michael, I took it for a spin last night and at the least it seems stable and functional, so I've pushed this up as a draft p/r here: #1262 I'd like some feedback on the timings for the time-out, and confirmation that the once-offs are no longer throttled. You could also play around with defaulting to a secondary timer and maybe a poll-success separation. PollSetTimeBetweenSuccess(80); // 80ms Gap between each successful poll PollSetTicker(250, 4); //? Suggestion?? The poll success separation just uses a timer to go to the next poll, rather than going straight to it. This is the value I use in Ioniq 5 when it is in 'ECU' mode. //.ichael On Mon, 17 Nov 2025 at 18:31, Michael Geddes ***@***.***> wrote:

…

I have some commits that I thought I'd just run live for a bit for: * Expand error to int32_t * Going to time-based hold. (I've gone for 1000ms and then additional 500ms... and I'm a bit unsure of some of that without knowing what the base requirements are. * Defaulting to no throttling for blocking once-offs. If you wanted to, I can push it up to my account (and make a draft if necessary). //.ichael On Sun, 16 Nov 2025 at 15:17, Michael Balzer ***@***.***> wrote: > *dexterbg* left a comment > (openvehicles/Open-Vehicle-Monitoring-System-3#1232) > <#1232 (comment)> > > That should be unthrottled then, as throttling adds to blocking time, > which is generally bad with complex queries like ECU scans. If necessary, > the application using blocking requests can/shall take care for the > throttling itself. > > — > Reply to this email directly, view it on GitHub > <#1232 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AABNANXWITCX4Q6QNWBZNRL35AQHXAVCNFSM6AAAAACK3IJKQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMZYGE4TQMBXG4> > . > You are receiving this because you were mentioned.Message ID: > <openvehicles/Open-Vehicle-Monitoring-System-3/issues/1232/3538198077@ > github.com> >

[dexterbg]

I needed to change the timeouts to 2000 and remove the added get_waiting_ms() test in the VWTP module to make this work for VWTP devices.

On ISOTP devices I found a previously undetected issue: a race condition when injecting single requests (via shell or JS) while a standard polling list is active, that occasionally leads to a wrong result being returned. It looks like some partial response from a request on the standard polling list gets interpreted as the response for the single request.

The issue isn't new here but present on the master branch as well, but I had the (possibly unfounded) impression it happens more often with this change.

Example: this ISOTP read on the VW e-Up should always return error code 31 requestOutOfRange on this device (it's present on other ECUs, so needs to be tested by the scan).

OVMS# obd can1 req dev 744 7ae 220608
744[7ae] 220608: ERROR: request failed with response error code 31 requestOutOfRange
OVMS# obd can1 req dev 744 7ae 220608
744[7ae] 220608: ERROR: request failed with response error code 31 requestOutOfRange
OVMS# obd can1 req dev 744 7ae 220608
744[7ae] 220608: ERROR: request failed with response error code 31 requestOutOfRange
OVMS# obd can1 req dev 744 7ae 220608
744[7ae] 220608: Response:
04                                              | .               
OVMS# obd can1 req dev 744 7ae 220608
744[7ae] 220608: ERROR: request failed with response error code 31 requestOutOfRange
OVMS# obd can1 req dev 744 7ae 220608
744[7ae] 220608: ERROR: request failed with response error code 31 requestOutOfRange
OVMS# obd can1 req dev 744 7ae 220608
744[7ae] 220608: ERROR: request failed with response error code 31 requestOutOfRange
OVMS# obd can1 req dev 744 7ae 220608
744[7ae] 220608: ERROR: request failed with response error code 31 requestOutOfRange

OVMS# sc ev 'xvu.ecu.$select("C6")'
OK
# xvu.ecu.get 220608: Request failed with response error code 31 requestOutOfRange
ERROR: Request failed with response error code 31 requestOutOfRange
OVMS# sc ev 'xvu.ecu.$get("220608")'
# xvu.ecu.get 220608: Request failed with response error code 31 requestOutOfRange
ERROR: Request failed with response error code 31 requestOutOfRange
OVMS# sc ev 'xvu.ecu.$get("220608")'
# xvu.ecu.get 220608: Request failed with response error code 31 requestOutOfRange
ERROR: Request failed with response error code 31 requestOutOfRange
OVMS# sc ev 'xvu.ecu.$get("220608")'
# xvu.ecu.get 220608: 02c3
{
  "error": 0,
  "errordesc": "",
  "response": {
    "0": 2,
    "1": 195
  },
  "response_hex": "02c3"
}
OVMS# sc ev 'xvu.ecu.$get("220608")'
# xvu.ecu.get 220608: 3ed5
{
  "error": 0,
  "errordesc": "",
  "response": {
    "0": 62,
    "1": 213
  },
  "response_hex": "3ed5"
}
OVMS# sc ev 'xvu.ecu.$get("220608")'
# xvu.ecu.get 220608: Request failed with response error code 31 requestOutOfRange
ERROR: Request failed with response error code 31 requestOutOfRange
OVMS# sc ev 'xvu.ecu.$get("220608")'
# xvu.ecu.get 220608: 04
{
  "error": 0,
  "errordesc": "",
  "response": {
    "0": 4
  },
  "response_hex": "04"
}
OVMS# sc ev 'xvu.ecu.$get("220608")'
# xvu.ecu.get 220608: Request failed with response error code 31 requestOutOfRange
ERROR: Request failed with response error code 31 requestOutOfRange
OVMS# sc ev 'xvu.ecu.$get("220608")'
# xvu.ecu.get 220608: Request failed with response error code 31 requestOutOfRange
ERROR: Request failed with response error code 31 requestOutOfRange

So in case of the error, this looks like a totally valid response to the application… :-/

With the e-Up polling paused (xvu polling pause), the request apparently always returns the error code 31 correctly.

[frogonwheels]

Did you try increasing the timeout for the isotp? To 1500 or 2000? (Probably should make it a const :)). You always got the same kind of crossed wires when running the RE Tools when a vehicle was loaded (before the poller changes). However, since the pollers do one call at a time per bus, then it _should_ be that the only way this could happen is if a response is delayed and the poller times out, then sends the once-off (to the same module id) and then the delayed response comes back, matching on the rx module id since from what I remember we don't get the PID in the response. Am I mistaken on this? Did I leave some loophole? //.ichael

…

On Fri, 21 Nov 2025 at 22:06, Michael Balzer ***@***.***> wrote: *dexterbg* left a comment (openvehicles/Open-Vehicle-Monitoring-System-3#1232) <#1232 (comment)> I needed to change the timeouts to 2000 and remove the added get_waiting_ms() test in the VWTP module to make this work for VWTP devices. On ISOTP devices I found a previously undetected issue: a race condition when injecting single requests (via shell or JS) while a standard polling list is active, that occasionally leads to a wrong result being returned. It looks like some partial response from a request on the standard polling list gets interpreted as the response for the single request. The issue isn't new here but present on the master branch as well, but I had the (possibly unfounded) impression it happens more often with this change. *Example*: this ISOTP read on the VW e-Up should always return error code 31 requestOutOfRange on this device (it's present on other ECUs, so needs to be tested by the scan). OVMS# obd can1 req dev 744 7ae 220608 744[7ae] 220608: ERROR: request failed with response error code 31 requestOutOfRange OVMS# obd can1 req dev 744 7ae 220608 744[7ae] 220608: ERROR: request failed with response error code 31 requestOutOfRange OVMS# obd can1 req dev 744 7ae 220608 744[7ae] 220608: ERROR: request failed with response error code 31 requestOutOfRange OVMS# obd can1 req dev 744 7ae 220608 744[7ae] 220608: Response: 04 | . OVMS# obd can1 req dev 744 7ae 220608 744[7ae] 220608: ERROR: request failed with response error code 31 requestOutOfRange OVMS# obd can1 req dev 744 7ae 220608 744[7ae] 220608: ERROR: request failed with response error code 31 requestOutOfRange OVMS# obd can1 req dev 744 7ae 220608 744[7ae] 220608: ERROR: request failed with response error code 31 requestOutOfRange OVMS# obd can1 req dev 744 7ae 220608 744[7ae] 220608: ERROR: request failed with response error code 31 requestOutOfRange OVMS# sc ev 'xvu.ecu.$select("C6")' OK # xvu.ecu.get 220608: Request failed with response error code 31 requestOutOfRange ERROR: Request failed with response error code 31 requestOutOfRange OVMS# sc ev 'xvu.ecu.$get("220608")' # xvu.ecu.get 220608: Request failed with response error code 31 requestOutOfRange ERROR: Request failed with response error code 31 requestOutOfRange OVMS# sc ev 'xvu.ecu.$get("220608")' # xvu.ecu.get 220608: Request failed with response error code 31 requestOutOfRange ERROR: Request failed with response error code 31 requestOutOfRange OVMS# sc ev 'xvu.ecu.$get("220608")' # xvu.ecu.get 220608: 02c3 { "error": 0, "errordesc": "", "response": { "0": 2, "1": 195 }, "response_hex": "02c3" } OVMS# sc ev 'xvu.ecu.$get("220608")' # xvu.ecu.get 220608: 3ed5 { "error": 0, "errordesc": "", "response": { "0": 62, "1": 213 }, "response_hex": "3ed5" } OVMS# sc ev 'xvu.ecu.$get("220608")' # xvu.ecu.get 220608: Request failed with response error code 31 requestOutOfRange ERROR: Request failed with response error code 31 requestOutOfRange OVMS# sc ev 'xvu.ecu.$get("220608")' # xvu.ecu.get 220608: 04 { "error": 0, "errordesc": "", "response": { "0": 4 }, "response_hex": "04" } OVMS# sc ev 'xvu.ecu.$get("220608")' # xvu.ecu.get 220608: Request failed with response error code 31 requestOutOfRange ERROR: Request failed with response error code 31 requestOutOfRange OVMS# sc ev 'xvu.ecu.$get("220608")' # xvu.ecu.get 220608: Request failed with response error code 31 requestOutOfRange ERROR: Request failed with response error code 31 requestOutOfRange So in case of the error, this looks like a totally valid response to the application… :-/ With the e-Up polling paused (xvu polling pause), the request apparently always returns the error code 31 correctly. — Reply to this email directly, view it on GitHub <#1232 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABNANSIZTGNQOHR45KV2CT354L7LAVCNFSM6AAAAACK3IJKQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNRTGE3DOMZQHE> . You are receiving this because you were mentioned.Message ID: <openvehicles/Open-Vehicle-Monitoring-System-3/issues/1232/3563167309@ github.com>

[dexterbg]

There are running standard polls to that ECU, yes. I'll try to catch some debug logs of what's happening, but I'll need to create a reduced polling scheme for that, as the VWUP polling list is quite complex and will flood my log channels easily.

[frogonwheels]

Did you try increasing the ISOTP wait to 2000ms? That may be enough to fix it since the poller should serialise the calls including the once-off polls. //.ichael

…

On Fri, 21 Nov 2025 at 23:03, Michael Balzer ***@***.***> wrote: *dexterbg* left a comment (openvehicles/Open-Vehicle-Monitoring-System-3#1232) <#1232 (comment)> There are running standard polls to that ECU, yes. I'll try to catch some debug logs of what's happening, but I'll need to create a reduced polling scheme for that, as the VWUP polling list is quite complex and will flood my log channels easily. — Reply to this email directly, view it on GitHub <#1232 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABNANVGF3CDAY67FWBDRED354SVJAVCNFSM6AAAAACK3IJKQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNRTGM4TENJUGE> . You are receiving this because you were mentioned.Message ID: <openvehicles/Open-Vehicle-Monitoring-System-3/issues/1232/3563392541@ github.com>