August 2024 - OvmsDev - Open Vehicles

Re: [Ovmsdev] OVMS Poller module/singleton
by Michael Balzer 08 Feb '25

08 Feb '25

Michael, (taking this back to the list, as other developers may have helpful ideas or suggestions) from a first check, your new patch (PR #1008) won't help for vehicles that don't use the poller, like the generic DBC vehicle or the Fiat 500 (plus possibly non-public third party vehicles). As the poller is normally compiled in, these would need a run time switch to re-enable the vehicle task, or more suitably default into that configuration and switch to the poller task only when the poller gets initialized. How about moving the task back into the vehicle class, but keeping your task message extensions while doing so, and adding a way for the poller to hook into the task? The dedicated vehicle task is an essential part of the vehicle framework, but I do remember some occasions where a general way to pass custom messages to the vehicle task would have been helpful to use the task for more than CAN processing. If the poller shall become avaible as a separate service that can be used without any vehicle instance (currently not a defined use case), the construct of a CAN processor task that can be extended for custom messages (or a message processor task that can subscribe to CAN frames) could be factored out into a dedicated class or template. The poller could then create his own instance of that class, if it cannot hook into an existing one. Btw, in case you're not aware of this, FreeRTOS also provides queue sets (https://www.freertos.org/RTOS-queue-sets.html) We haven't used them in the OVMS yet, but they could be useful, especially if message unions become large or tasks shall be able to dynamically subscribe to different message sources. Regards, Michael Am 30.04.24 um 01:20 schrieb Michael Geddes: > It might be worth reverting, but, I've got a patch suggestion that > I'll push up which will let me know if I understand everything and > which might provide a solution. > > If this isn't going to work then revert. (P/R coming) > > While the poller was still a part of the vehicle class it was probably > still all ok. The poller had taken over what I assume you are > talking about as the vehicle task. A call-back fromthe poller was > calling IncomingPollRxFrame which was then coming from the (now) > poller task (is that correct?) > > While we have OVMS_COMP_POLLER config defined, we could just use the > poller task to provide the IncomingPollRxFrame call-back from the > poller (was vehicle?) task. > > The problem is when OVMS_COMP_POLLER is undefined, we need an > alternate (maybe we could use the 'Event' loop then) which is when I > hacked that bad solution. > > > //.ichael > > > I was thinking though that because everything is being queued we could > divert some calls into the car > > On Mon, 29 Apr 2024, 18:58 Michael Balzer, <dexter(a)expeedo.de> wrote: > > Michael, > > I've found a severe design flaw with your poller change. Sorry, I > should have seen that before, and shouldn't have merged this. > > You have moved the standard CAN frame processing from the vehicle > task into the CAN task by changing the vehicle from a CAN listener > to a CAN callback processor. That will break all kind of things, > vehicles like the Twizy, Smart and many others rely on frame > processing being done in the dedicated vehicle task. > > This especially induces issues regarding CAN processing capacity, > as the vehicles rely on having a separate context and not needing > to decouple complex processing of incoming frames. So this will > degrade the CAN processing performance seriously in many cases, > where additional steps involving file or network I/O need to be done. > > So this needs to be changed back. > > I assumed you introduced a new dedicated poller task but kept the > vehicle task intact. From your naming > (OvmsVehicle::IncomingPollRxFrame), it seems you misinterpreted > the vehicle task's purpose as only being used for polling. > > I assume this isn't a small change…? If so we should revert the > poller merge, to avoid having a defunctional edge build state > until the fix. > > > Secondly: logging is generally expensive regardless of the log > level control and log channels enabled. Any log message needs to > be queued to the log system, so involves a lock and a potential > wait state (for the queue) & resulting context switch (= minimum > delay of 10 ms). Therefore, logging must be avoided as far as > possible in any time critical context, and is forbidden under some > circumstances, e.g. in a timer callback (see FreeRTOS docs on > this). The log system load multiplies with connected web clients > or enabled file logging and enabled debug / verbose level logging > -- that quickly becomes too much, usually triggering the task > watchdog. > > Your logging of nearly all bus events passing to/from the poller > (especially the log entry in Queue_PollerFrame) becomes an issue > on any vehicle that has high frequency running process data frames > on the bus, like the Twizy or Smart. As a counter measure, I've > just added a runtime control for all the poller's verbose logging > (by default now off), and changed some debug level logs to > verbose. Not sure if I've catched all that may need to be silenced > by default. Please check all your log calls and place them under > the new "trace" control flag wherever appropriate. > > This won't help avoiding issues with process data frame buses though. > > > Shall I revert the poller merge for now? > > Regards, > Michael > > > > Am 29.04.24 um 06:18 schrieb Michael Geddes: >> Btw I included the log changes in the p/r which is a few small >> commits for the poller. >> >> //. >> >> On Mon, 29 Apr 2024, 07:20 Michael Geddes, >> <frog(a)bunyip.wheelycreek.net> wrote: >> >> Hey Michael, >> I've got to work now (it's Monday), but I suspect those >> 'giving up' are from unsolicited messages on the bus. >> I can re-order things so that the message will likely be >> 'dropped (no poll entry)' rather than the time-out message. >> And make it a verbose log. >> >> //.ichael >> >> On Mon, 29 Apr 2024 at 00:25, Michael Balzer >> <dexter(a)expeedo.de> wrote: >> >> Michael, >> >> forwarding the Twizy logs to you directly, as they >> contain the user location. >> >> He has just verified it's the new version, he says the >> module stops responding as soon as he turns on the Twizy. >> >> His description of his actions is a bit ambiguous, and it >> seems he didn't enable logging to the file persistently. >> >> According to the server, these were the version boot times: >> >> 2024-04-28 15:30:56 0 3.3.004-32-g125e0841/ota_0/edge >> (build idf v3.3.4-849-g6e214dc335 Apr 26 2024 19:16:50) >> 2024-04-28 16:21:08 0 3.3.004-32-g125e0841/ota_0/edge >> (build idf v3.3.4-849-g6e214dc335 Apr 26 2024 19:16:50) >> 2024-04-28 16:38:33 0 3.3.004-63-gf3595561/ota_1/edge >> (build idf v3.3.4-849-g6e214dc335 Apr 27 2024 07:44:50) >> 2024-04-28 16:40:57 0 3.3.004-63-gf3595561/ota_1/edge >> (build idf v3.3.4-849-g6e214dc335 Apr 27 2024 07:44:50) >> 2024-04-28 16:43:14 0 3.3.004-63-gf3595561/ota_1/edge >> (build idf v3.3.4-849-g6e214dc335 Apr 27 2024 07:44:50) >> 2024-04-28 16:46:39 0 3.3.004-63-gf3595561/ota_1/edge >> (build idf v3.3.4-849-g6e214dc335 Apr 27 2024 07:44:50) >> 2024-04-28 16:54:44 0 3.3.004-32-g125e0841/ota_0/edge >> (build idf v3.3.4-849-g6e214dc335 Apr 26 2024 19:16:50) >> >> Attached is also his crash debug log -- a2ll doesn't tell >> much about what happened, but maybe you get an idea from >> this. >> >> After the boot at 16:46, there are immediately lots of >> these messages: >> >> 2024-04-28 16:46:33.792 CEST D (39042) vehicle-poll: >> Poller: Queue PollerFrame() >> 2024-04-28 16:46:33.792 CEST D (39042) vehicle-poll: >> [1]Poller: Incoming - giving up >> >> Regards, >> Michael >> >> >> Am 28.04.24 um 16:44 schrieb Michael Geddes: >>> Ah. OK. >>> >>> I could try to fix the vin thing using the new way of >>> doing it and get rid of a semaphore? >>> It would at least identify the problem possibly? >>> >>> Michael >>> >>> >>> On Sun, 28 Apr 2024, 22:32 Michael Balzer via OvmsDev, >>> <ovmsdev(a)lists.openvehicles.com> wrote: >>> >>> Not sure if that's the problem, but I've found a >>> different behaviour with the new PollSetState() >>> implementation. >>> >>> The old version only did anything if the new state >>> actually was different from the previous one. The >>> Twizy relies on this behaviour, calling >>> PollSetState() from the per second ticker (see >>> OvmsVehicleRenaultTwizy::ObdTicker1). >>> >>> The new implementation apparently always sends the >>> PollState command to the task, and that in turn >>> always at least locks the poller mutex. Not sure >>> if/how that could cause the observed issues, but it >>> definitely adds quite some (unnecessary?) >>> lock/unlock operations. >>> >>> >>> >>> Am 28.04.24 um 16:05 schrieb Michael Balzer via OvmsDev: >>>> The Twizy uses the poller to query the VIN (once) >>>> and DTCs (every 10 seconds while driving), see >>>> rt_obd2.cpp. >>>> >>>> It also has its own version of the OBD single >>>> request (OvmsVehicleRenaultTwizy::ObdRequest), >>>> which was the precursor for the generalized >>>> version. This is used by custom/user Twizy plugins >>>> and scripts to access ECU internals. >>>> >>>> The Twizy doesn't use IncomingPollRxFrame, but the >>>> Twizy's IncomingPollReply handler will log any poll >>>> responses it doesn't know about, so that could lead >>>> to a lot of log output if something goes wrong there. >>>> >>>> >>>> Am 28.04.24 um 15:49 schrieb Michael Geddes via >>>> OvmsDev: >>>>> AFAICT the twizzy doesn't use the poller list at >>>>> all. So is it missing a call-back or something?? >>>>> >>>>> I can see a potential problem with >>>>> IncomingPollRxFrame being called twice as much as >>>>> it should be but only when there is a poll list. >>>>> Maybe commenting out this would do it. (I can >>>>> find another away to get this called on the thread >>>>> I want). This might be the problem with the smarted >>>>> >>>>> void >>>>> OvmsVehicle::OvmsVehicleSignal::IncomingPollRxFrame(canbus* >>>>> bus, CAN_frame_t *frame, bool success) >>>>> { >>>>> //if (Ready()) >>>>> // m_parent->IncomingPollRxFrame(frame, success); >>>>> } >>>>> >>>>> //. >>>>> >>>>> >>>>> On Sun, 28 Apr 2024 at 21:10, Michael Balzer via >>>>> OvmsDev <ovmsdev(a)lists.openvehicles.com> wrote: >>>>> >>>>> There may also be an issue with the Renault >>>>> Twizy, I've received a report of a user who is >>>>> using the edge builds, that the latest build >>>>> wouldn't work. >>>>> >>>>> He reports all kinds of errors and warnings >>>>> signaled by the car during driving, and >>>>> switching back to the previous build fixed the >>>>> issues. >>>>> >>>>> I've asked him to provide a debug log excerpt >>>>> if possible. >>>>> >>>>> Regards, >>>>> Michael >>>>> >>>>> >>>>> Am 28.04.24 um 14:29 schrieb Michael Geddes >>>>> via OvmsDev: >>>>>> OK. That's bad. >>>>>> >>>>>> Does the reading work in general? >>>>>> >>>>>> Is it just the writing commands? >>>>>> >>>>>> Raise a ticket on github and tag me in and we >>>>>> can address it that way. >>>>>> >>>>>> Michael >>>>>> >>>>>> On Sun, 28 Apr 2024, 19:49 Thomas Heuer via >>>>>> OvmsDev, <ovmsdev(a)lists.openvehicles.com> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> The new poller code doesn't seem to work >>>>>> properly with the smarted. >>>>>> >>>>>> D (218831) vehicle-poll: >>>>>> [1]PollerNextTick(PRI): cycle complete >>>>>> for ticker=215 >>>>>> >>>>>> V (218831) vehicle-poll: Standard Poll >>>>>> Series: List reset >>>>>> >>>>>> D (218831) vehicle-poll: >>>>>> PollSeriesList::NextPollEntry[!v.standard]: >>>>>> ReachedEnd >>>>>> >>>>>> V (218831) vehicle-poll: [1]PollerSend: >>>>>> Poller Reached End >>>>>> >>>>>> D (219691) vehicle-poll: Poller: Queue >>>>>> PollerFrame() >>>>>> >>>>>> D (219691) vehicle-poll: Poller: Queue >>>>>> PollerFrame() >>>>>> >>>>>> V (219691) vehicle-poll: Pollers: >>>>>> FrameRx(bus=2) >>>>>> >>>>>> D (219691) vehicle-poll: Poller: Queue >>>>>> PollerFrame() >>>>>> >>>>>> V (219691) vehicle-poll: Pollers: >>>>>> FrameRx(bus=2) >>>>>> >>>>>> V (219691) vehicle-poll: Pollers: >>>>>> FrameRx(bus=2) >>>>>> >>>>>> D (219691) vehicle-poll: Poller: Queue >>>>>> PollerFrame() >>>>>> >>>>>> *OVMS#*unlock 22 >>>>>> Vehicle unlocked >>>>>> >>>>>> V (219691) vehicle-poll: Pollers: >>>>>> FrameRx(bus=2) >>>>>> >>>>>> D (219691) vehicle-poll: Poller: Queue >>>>>> PollerFrame() >>>>>> >>>>>> V (219691) vehicle-poll: Pollers: >>>>>> FrameRx(bus=2) >>>>>> >>>>>> D (219701) vehicle-poll: Poller: Queue >>>>>> PollerFrame() >>>>>> >>>>>> V (219701) vehicle-poll: Pollers: >>>>>> FrameRx(bus=2) >>>>>> >>>>>> D (219701) vehicle-poll: Poller: Queue >>>>>> PollerFrame() >>>>>> >>>>>> V (219701) vehicle-poll: Pollers: >>>>>> FrameRx(bus=2) >>>>>> >>>>>> D (219701) vehicle-poll: Poller: Queue >>>>>> PollerFrame() >>>>>> >>>>>> V (219701) vehicle-poll: Pollers: >>>>>> FrameRx(bus=2) >>>>>> >>>>>> D (219701) vehicle-poll: Poller: Queue >>>>>> PollerFrame() >>>>>> >>>>>> V (219701) vehicle-poll: Pollers: >>>>>> FrameRx(bus=2) >>>>>> >>>>>> D (219701) vehicle-poll: Poller: Queue >>>>>> PollerFrame() >>>>>> >>>>>> V (219701) vehicle-poll: Pollers: >>>>>> FrameRx(bus=2) >>>>>> >>>>>> D (219701) vehicle-poll: Poller: Queue >>>>>> PollerFrame() >>>>>> >>>>>> V (219701) vehicle-poll: Pollers: >>>>>> FrameRx(bus=2) >>>>>> >>>>>> D (219701) vehicle-poll: Poller: Queue >>>>>> PollerFrame() >>>>>> >>>>>> V (219701) vehicle-poll: Pollers: >>>>>> FrameRx(bus=2) >>>>>> >>>>>> D (219701) vehicle-poll: Poller: Queue >>>>>> PollerFrame() >>>>>> >>>>>> V (219701) vehicle-poll: Pollers: >>>>>> FrameRx(bus=2) >>>>>> >>>>>> D (219701) vehicle-poll: Poller: Queue >>>>>> PollerFrame() >>>>>> >>>>>> V (219701) vehicle-poll: Pollers: >>>>>> FrameRx(bus=2) >>>>>> >>>>>> D (219701) vehicle-poll: Poller: Queue >>>>>> PollerFrame() >>>>>> >>>>>> V (219701) vehicle-poll: Pollers: >>>>>> FrameRx(bus=2) >>>>>> >>>>>> D (219701) vehicle-poll: Poller: Queue >>>>>> PollerFrame() >>>>>> >>>>>> *Von:*OvmsDev >>>>>> <ovmsdev-bounces(a)lists.openvehicles.com> >>>>>> *Im Auftrag von *Michael Geddes via OvmsDev >>>>>> *Gesendet:* Sonntag, 28. April 2024 12:27 >>>>>> *An:* OVMS Developers >>>>>> <ovmsdev(a)lists.openvehicles.com> >>>>>> *Cc:* Michael Geddes >>>>>> <frog(a)bunyip.wheelycreek.net> >>>>>> *Betreff:* [Ovmsdev] OVMS Poller >>>>>> module/singleton >>>>>> >>>>>> Hey all, >>>>>> >>>>>> The poller singleton code that I've been >>>>>> working on for over a year now is merged >>>>>> in. (Thanks Michael for expediting the >>>>>> final step). >>>>>> >>>>>> This includes separate multi-frame states >>>>>> per bus and multiple poll lists as well >>>>>> as non-blocking one off queries. As well >>>>>> as more 'states'. >>>>>> >>>>>> I have included some programming >>>>>> documentation in the change but am happy >>>>>> to supply more if needed. >>>>>> >>>>>> The ioniq 5 code has some examples of how >>>>>> it can be used. Some examples are: >>>>>> >>>>>> * grabbing the vin as a one shot without >>>>>> blocking >>>>>> >>>>>> * having a short list of queries that are >>>>>> polled quickly for obd2ecu (this also >>>>>> demonstrates using a shorter frame break >>>>>> value and then a break after successful a >>>>>> response) >>>>>> >>>>>> Have a play please! >>>>>> >>>>>> Also interested in hearing what user >>>>>> tools might be worth looking at next for >>>>>> the poller object. >>>>>> >>>>>> //.ichael G. >>>>>> >>>>>> _______________________________________________ >>>>>> OvmsDev mailing list >>>>>> OvmsDev(a)lists.openvehicles.com >>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OvmsDev mailing list >>>>>> OvmsDev(a)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(a)lists.openvehicles.com >>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>>>> >>>>> >>>>> _______________________________________________ >>>>> OvmsDev mailing list >>>>> OvmsDev(a)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(a)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(a)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 >> > > -- > Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal > Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 > -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

7 117

Duktape Vehicle
by Michael Geddes 06 Oct '24

06 Oct '24

In a recent conversation with Mark we were talking about utilising Duktape more for perhaps even vehicle implementations. I'm wondering if a better approach is to allow any vehicle to be extended via hooks in the base vehicle class or would it be better to have a duktape vehicle that could be extended. There would necessarily be many bits to the puzzle. For example I have a class that allows us to know when blips to the 12V battery line might mean that somebody is interacting with the car so we should start polling the bus.. Should we put this (with a duktape interface) at the vehicle.h level? //.ichael

2 2

Fwd: [Action Advised] Test the new Camera control on your maps before the default changes in version 3.60
by Mark Webb-Johnson 22 Aug '24

22 Aug '24

> Begin forwarded message: > > From: Google Maps Platform <google-maps-platform-noreply(a)google.com> > Subject: [Action Advised] Test the new Camera control on your maps before the default changes in version 3.60 > > > > MY CONSOLE <https://notifications.google.com/g/p/ANiao5qSJr9WisFK9IPEfHHsgx5PPGOu-NheAy…> > Hello Google Maps Customer, > > We are changing the Google Maps JavaScript API controls to reduce the space they occupy on maps by default and to improve the accessibility of panning the map. > > We’re reaching out to you because we have observed one or more of the following criteria: > > Your end-users use the Zoom buttons significantly more than the average. > One or more of your maps explicitly disables the Zoom control. > One or more of your maps have customized controls. > We have provided additional information below to guide you through this change. > > What you need to know > > Map controls <https://notifications.google.com/g/p/ANiao5rIzaVVR5OdKhLWoOCo24HOSzaLPZicfR…> are visual elements that allow user interaction with the map, including zooming the map, enabling Street View, and changing the Map Type. > > Version 3.58 adds a new Camera control <https://notifications.google.com/g/p/ANiao5qsyBbh2CYZUmipt7KzVxkZMVFbyTgECd…> in the Google Maps JavaScript API to make panning the map accessible with a single gesture. This feature will be available in the upcoming week. This new Camera control will feature buttons for panning the map and for zooming the map in and out, effectively being a single control to guide the map’s viewport. > > The upcoming changes are listed in the table below. > > Date Available in Channel Changes Implemented > In the upcoming week In the Beta channel The updated default map controls will replace the Zoom control with the Camera control. > In the upcoming week > > In the weekly channel > > Version 3.58 and version 3.59 will offer the Camera control without changing the default map controls. > > In November 2024 > > In the quarterly channel > > In February 2025 > > In the weekly channel > > Version 3.60 will contain the updated changes to the default map controls. > > In May 2025 > > In the quarterly channel > > What you need to do > > Before the default controls are updated > > Test the new Camera control on your maps before the default changes in version 3.60 reach the weekly channel in February 2025 or the quarterly channel in May 2025. > > To test the Camera control: > > If you use default controls in your map options, specify the Beta channel <https://notifications.google.com/g/p/ANiao5rRp4NzBcGc89tsCfGA6CK4KvYIGOlCyM…> to see how the default controls will change. > If you do not use the default controls, or prefer not to change to the Beta channel in your loader, enable the Camera control, and optionally disable the Zoom control, in google.maps.MapOptions <https://notifications.google.com/g/p/ANiao5qsyBbh2CYZUmipt7KzVxkZMVFbyTgECd…>. > After the default controls are updated > > Consider taking one of the following actions after the default controls are updated to include the Camera control instead of the Zoom control in version 3.60 in February 2025 for the weekly channel and May 2025 for the quarterly channel. > > If your code explicitly enables the Zoom control (zoomControl: true), both the Zoom control and the Camera control will be displayed. Consider choosing one to save on map space. > If your code explicitly disables the Zoom control (zoomControl: false), you may also want to disable the Camera control. > If your code explicitly enables the Zoom control (zoomControl: true) while keeping the default controls disabled (disableDefaultUI: true), only the Zoom control will be displayed. For better accessibility, consider enabling the Camera control instead. > If more time is needed > > If you need more time before adopting the default controls, you can specify version 3.59 <https://notifications.google.com/g/p/ANiao5ow4VNUJk__HI4mblHFJfMeJMaw_Finj4…> which will be available until February 2026. > > We’re here to help > > Refer to our Maps Javascript API documentation <https://notifications.google.com/g/p/ANiao5qsyBbh2CYZUmipt7KzVxkZMVFbyTgECd…> for information about how to edit google.maps.MapOptions to enable cameraControl. > > If you have any other questions or need additional support, please contact us at Google Maps Platform Support <https://notifications.google.com/g/p/ANiao5ppIKsOdKNy6_yUpCslMC8BFehp6yTQoj…>. > > Thanks for choosing Google Maps Platform. > > —The Google Maps Platform Team > DOCUMENTATION <https://notifications.google.com/g/p/ANiao5qsyBbh2CYZUmipt7KzVxkZMVFbyTgECd…> > SUPPORT <https://notifications.google.com/g/p/ANiao5ppIKsOdKNy6_yUpCslMC8BFehp6yTQoj…> > Was this information helpful? > > <https://notifications.google.com/g/p/ANiao5pZILQM1b3p6opNvUizjj_NIBTVPe4986…> <https://notifications.google.com/g/p/ANiao5p5GQ9cVrh3bRYpM3QGAM7prqqmLRoGC8…> <https://notifications.google.com/g/p/ANiao5ptPFc-jvMwzY4w1f3sROWRCXcmZPk4Dv…> > > © 2024 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043 > > You have received this mandatory service announcement to update you about important changes to Google Maps Platform or your account. > <https://notifications.google.com/g/p/ANiao5qjT5ACsRSu2ISgsgTeXjLg8cVBs1FM5z…> <https://notifications.google.com/g/p/ANiao5oXaQzr8XIKW10CeDuc-8Yo2aD2yigAqc…> <https://notifications.google.com/g/p/ANiao5qz5afhVYmSAZgoBGCTKEJnBWd8qyS58z…>

1 0

Fwd: [Reminder] Update to latest renderer for the Maps SDK for Android
by Mark Webb-Johnson 22 Aug '24

22 Aug '24

> Begin forwarded message: > > From: Google Maps Platform <google-maps-platform-noreply(a)google.com> > Subject: [Reminder] Update to latest renderer for the Maps SDK for Android > > > > MY CONSOLE <https://notifications.google.com/g/p/ANiao5pYODAVleAYP31YM3qFAqF69deQGAMdNz…> > You may have projects using the legacy renderer that will be decommissioned by March 3, 2025. Apps built with the Maps SDK for Android have been automatically updated to the latest renderer as of June 2024. > Hello Google Maps Platform Customer, > > This is a follow up to the announcements sent in 2021 and 2022 regarding the new renderer for Maps SDK for Android. To provide an improved user experience and app performance, apps built with the Maps SDK for Android have been automatically updated to the latest renderer <https://notifications.google.com/g/p/ANiao5rHUSQmtxQPuR_Hi4TKlXg4tDqZbIsAS4…> as of June 2024. The legacy renderer is scheduled for decommissioning on March 3, 2025. > > What you need to know > > The new renderer was introduced in Maps SDK for Android version 18.0 in an opt-in manner. It is offered as a default starting on version 18.2, with an option to specify the Legacy renderer (Renderer.LEGACY) <https://notifications.google.com/g/p/ANiao5p_sMP-kXkk44kzDTYbQeeigaHx4l8GtY…>. > > Your app may be currently using the legacy renderer in two situations. > > Situation 1. If you use Maps SDK for Android version < 18, or 18.0-18.1 without opting in the new renderer: > We temporarily excluded your apps from the automatic migration because of issues occurring with the new renderer. > Situation 2. If you specify the legacy renderer (on version 18.0 or later): > Your application will continue receiving the legacy renderer until March 2025. Starting in March 2025, you will get the new renderer even if you specify the Legacy renderer. > During the migration period, Google will continue to provide support and fixes to major bugs and outages on the legacy renderer. New features and improvements are only offered on the new renderer. > > The new renderer is currently only available on Android phones. If your app is used on Wear OS or Android Go, the new renderer will be available in Google Play Services at a later time. Please follow the progress on this rollout by starring this issue tracker entry <https://notifications.google.com/g/p/ANiao5qoosfyI3uURXoB160BIBfnMmT3Wjh7DJ…>. > > What you need to do > > No action is recommended if your app already uses Maps SDK for Android v18.2.0 and does not specify a renderer during the initialization process. > > Updating to the latest renderer in the Maps SDK for Android may introduce a slight change to the performance and behavior of the maps in your app. Google does not expect this to cause any operational issues. > > We recommend that developers of mission-critical apps test their application with the new renderer ahead of the automatic update (happening in March 2025), in order to limit risks of potential issues. You can do this by updating the dependencies <https://notifications.google.com/g/p/ANiao5qBoAN36GRHwRebxaRYycpHnxbwxIDE3v…> for your app to the Maps SDK for Android version 18.2.0 or later, without specifying the Legacy renderer (Renderer.LEGACY) <https://notifications.google.com/g/p/ANiao5p_sMP-kXkk44kzDTYbQeeigaHx4l8GtY…>. > > See release notes <https://notifications.google.com/g/p/ANiao5ot7WEas73zIY1L9eGZf9xL-qF7EfBO1U…> for differences between older versions and version 18.2.0. > > We have determined that your projects listed below are using the Legacy renderer on Maps SDK for Android in the past 30 days: > > Project name (project number) Apps using the Legacy renderer on Maps SDK for Android > Open Vehicles (497749188588) <https://notifications.google.com/g/p/ANiao5q77GmjPv3wKlyvYh3WBn5EtLz_YqHp-s…> com.openvehicles.OVMS <> > Open Vehicles (497749188588) <https://notifications.google.com/g/p/ANiao5q77GmjPv3wKlyvYh3WBn5EtLz_YqHp-s…> com.openvehicles.ovms <> > Note: only the top 20 apps that sent the most traffic are listed for each project. > > [CONTACT SUPPORT <https://notifications.google.com/g/p/ANiao5oktol_g2I-H-e_ymHCwCXr9PsKxEjVm_…>] > > Thanks for choosing Google Maps Platform, > > The Google Maps Platform Team > SUPPORT <https://notifications.google.com/g/p/ANiao5oktol_g2I-H-e_ymHCwCXr9PsKxEjVm_…> > Was this information helpful? > > <https://notifications.google.com/g/p/ANiao5q4hF1gbk49JoN7NcZddRt64UPwdZUFqA…> <https://notifications.google.com/g/p/ANiao5r_p5BpareCayaikeW1scnCe4imPnpLwo…> <https://notifications.google.com/g/p/ANiao5pWq7mafh2Vp1omNXh0stCalRpa9e_16L…> > > © 2024 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043 > > You have received this mandatory service announcement to update you about important changes to Google Maps Platform or your account. > <https://notifications.google.com/g/p/ANiao5pPAlGanFkLl3DRh7VEcQxyUHzXACAev_…> <https://notifications.google.com/g/p/ANiao5qDKwxx975-vy0xNbWg8GPyuM2-qb1wO2…> <https://notifications.google.com/g/p/ANiao5oq0Xc_rFn3MLZW5pP3vkR7TuI_aDZ198…>

1 0

Cellular usage, as it applies to OVMS
by Mark Webb-Johnson 16 Aug '24

16 Aug '24

I saw this the other day, and thought it applied perfectly to what we experience. We weren’t even pushing the limits of 2G. Mark

2 2

Warning in Duktape
by Michael Geddes 09 Aug '24

09 Aug '24

There's an unused variable 'dcc' warning in the below code. It seems that the 'Perform the callback' is not being 'performed! Is this deliberate? //.ichael void DukOvmsCommandRegisterRun(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv) { ESP_LOGD(TAG, "DukOvmsCommandRegisterRun(%s)",cmd->GetName()); auto it = MyDuktape.m_cmdmap.find(cmd); if (it == MyDuktape.m_cmdmap.end()) { ESP_LOGE(TAG, "Command '%s' cannot be found in registry",cmd->GetName ()); return; } else { DuktapeConsoleCommand* dcc = it->second; // Perform the callback } }

3 6