November 2023 - OvmsDev - Open Vehicles

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

wolfssl has been converted to a git submodule
by Ludovic LANGE 19 Feb '24

19 Feb '24

Dear all, The PR https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/887 which converts wolfssl to a git submodule has been merged to master. For those that build / sync their trees manually, please ensure that you do `git submodule update --init --recursive` after the git pull, so that you can properly retrieve the submodule. You can confirm that everything is OK by doing: $ git submodule status 7b953e7ebb440ce9461ee469159c3759450e7c98 components/mongoose/mongoose (6.2-882-g7b953e7) c05f6c7530a8670e3d0ffdf04ee4cecb2d3b0496 components/wolfssh/wolfssh (v1.4.10-stable) 2d5a0ccae50a2ea32fc933d707b465520cc90011 components/wolfssl/wolfssl (v4.7.0-stable-5-g2d5a0ccae) 7c3878f8302c0e84578a67473e49e60bc6b3ada7 components/zip/libzip (rel-1-5-1-60-g7c3878f) d6bcf4ca4d02479f058fff44cfd171f928148179 components/zip/zlib (v1.2.11-65-gd6bcf4c) It should print (3rd line) a version of v4.7.0-stable-5-g2d5a0ccae. If instead you see: $ git submodule status 7b953e7ebb440ce9461ee469159c3759450e7c98 components/mongoose/mongoose (6.2-882-g7b953e7) c05f6c7530a8670e3d0ffdf04ee4cecb2d3b0496 components/wolfssh/wolfssh (v1.4.10-stable) -2d5a0ccae50a2ea32fc933d707b465520cc90011 components/wolfssl/wolfssl 7c3878f8302c0e84578a67473e49e60bc6b3ada7 components/zip/libzip (rel-1-5-1-60-g7c3878f) d6bcf4ca4d02479f058fff44cfd171f928148179 components/zip/zlib (v1.2.11-65-gd6bcf4c) then you need to use `git submodule update --init --recursive` Let me know if it's not working according to the plan. Regards,

3 3

Fwd: [Action Required] Update your apps to the latest Firebase Cloud Messaging APIs and SDKs
by Michael Balzer 09 Jan '24

09 Jan '24

Time for another Google API deprecation. It seems we'll need to update the Android App & possibly the server now to the FCM API for push notifications, the old GCM API will stop working in June 2024. Anyone volunteering to take care of this? Regards, Michael -------- Weitergeleitete Nachricht -------- Betreff: [Action Required] Update your apps to the latest Firebase Cloud Messaging APIs and SDKs Datum: Tue, 20 Jun 2023 13:26:22 -0700 Von: Firebase <firebase-noreply(a)google.com> Antwort an: Firebase <firebase-noreply(a)google.com> An: dexter(a)expeedo.de Mandatory Service Announcement from Firebase Take action before June 20, 2024 to continue receiving support. Firebase Console <https://notifications.google.com/g/p/ACUgQrEqj5I8-oiq75nsyLmVgMI_2P_O30pr9Z…> Hi Michael, We’re writing to let you know that starting *June 20, 2024* the legacy Firebase Cloud Messaging (FCM) APIs will be discontinued. What do you need to know? On *June 20, 2024,* we’re reducing the number of Firebase Cloud Messaging (FCM) legacy register APIs and legacy send APIs that provide similar functionality. This step will allow us to provide you with a more consistent experience and align with Google security standards to improve security, reliability and performance. Because of these API decommissions, some already-deprecated SDKs and features will stop working after *June 20, 2024.* Please consult the tables below to find which Firebase Cloud Messaging (FCM) APIs and corresponding services/SDKs/features will be discontinued and replaced with new alternatives. *Discontinued Send API* *Decommissioned service* *New alternative* *Legacy HTTP Protocol* Sending messages via the Legacy HTTP API. Send messages via the HTTP v1 API. *XMPP Protocol* Sending upstream and downstream messages via the XMPP API. Send downstream messages via the HTTP v1 API. Send upstream messages via HTTP/gRPC <https://notifications.google.com/g/p/ACUgQrFKp0BdXKuz3_mUi3W9wdl6DV3Ib_q0Hn…> directly from the App to your server. *Batch send API* Including multiple send requests in a single HTTP request to FCM known as Batch Send. Send messages via the HTTP v1 API, which has been optimized for fanout performance *Discontinued Register API* *Decommissioned SDK* *New alternative* *GCM register API* Google Cloud Messaging(GCM) SDKs (deprecated in 2018). Latest FCM Android SDK. *Legacy Web register API* FCM JS SDK version<7.0.0 (deprecated in 2019) Latest FCM JS SDK. *Instance ID Server API for Web* No SDK related to this API. Latest FCM JS SDK. *Discontinued Feature* *Decommissioned service* *New alternative* *Server keys* Authenticating requests with server keys. Authenticate requests with access tokens generated from authorized service accounts <https://notifications.google.com/g/p/ACUgQrE8LxWKrfZvL3R5hoSruQL4An9Vg5kFcD…> *iOS Direct Channel* Sending messages via FCM’s direct channel to iOS devices while they are running in the foreground. All iOS messages will be sent via APNS channel. What do you need to do? Take the following actions before *June 20, 2024*, to ensure that you have access to the latest supported features and to reduce the risk of future decommissions affecting your usage: * *Follow the instructions described in *Firebase FAQ <https://notifications.google.com/g/p/ACUgQrF1q42xLDBDWvEr5RHaOfbnfKhv0UdWXB…> to migrate your individual APIs. * *Update to the latest versions of Firebase SDKs*. *Platform* *Recommended FCM SDK version* Android >= 23.1.2 iOS >= 10.10.0 Web (Javascript) >= 9.22.1 Your Firebase project(s) that use Firebase Cloud Messaging APIs are listed below: * MyOvmsServer (1043773844049) <https://notifications.google.com/g/p/ACUgQrEotRQKxV6LgEoXckEV9bLkUuhj9b1dUE…> o /Your recent usage of impacted APIs/features: Server Keys/ o /Your recent usage of impacted APIs/features: Legacy HTTP protocol/ We’re here to help If you have any questions, please review the Firebase FAQs <https://notifications.google.com/g/p/ACUgQrF1q42xLDBDWvEr5RHaOfbnfKhv0UdWXB…>. Thanks, Todd on behalf of the Firebase team *Was this information helpful?* Yes <https://notifications.google.com/g/p/ACUgQrG_D9izaxqaPAZL66peR0D-yHGGWiULfq…> Neutral <https://notifications.google.com/g/p/ACUgQrFnFdXuJ_VF6ChjiUeTeV5elzVrPymaFM…> No <https://notifications.google.com/g/p/ACUgQrFb7NDlSkpL4nuGR0g71bgiRuj39SdywV…> You have received this mandatory service announcement to update you about important changes to Firebase or your account. © 2023 Google LLC 1600 Amphitheatre Parkway Mountain View, CA 94043 USA <#> -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

3 4

Hologram
by Mark Webb-Johnson 28 Nov '23

28 Nov '23

I’m having a weird issue with Hologram. For years we’ve been buying SIMs from them and including with every OVMS device shipped. No issues, no complaints, and all smooth sailing. Now, a month or so ago I tried to buy a new batch of SIMs, the Hologram shop no longer offers shipping to Hong Kong. I wrote to them using their website contact feature, but no reply. I wrote to their sales contact, but no reply. I wrote to all my contacts there, but no reply. I wrote using both my open vehicles email address and gmail, but no reply. Ghosted. No idea if they are restructuring, or something broken with their email contact system, but it is very frustrating. Anyway, it now looks like the upcoming batch of OVMS won’t be able to include Hologram SIMs as standard. An inconvenience for our users, but not much I can do about it. If anyone has any contacts there, or any way of contacting them, perhaps you would try and ask. I’ve given up. There are plenty of alternatives, but perhaps that given that only a fraction of our users actually use the included Hologram SIM, it is time to stop including it. Regards, Mark.

3 5

A query on vehicle type switch (and failure)
by Michael Geddes 27 Nov '23

27 Nov '23

This code is from OvmsVehicleFactor::SetVehicle m_currentvehicle = NewVehicle(type); if (m_currentvehicle) { m_currentvehicle->m_ready = true; } m_currentvehicletype = std::string(type); StandardMetrics.ms_v_type->SetValue(m_currentvehicle ? type : ""); MyEvents.SignalEvent("vehicle.type.set", (void*)type, strlen(type)+1); My question is about what happens when NewVehicle() returns NULL. Should m_currecntvehicletype, v.type and the SignalEvent all be set as blank? Any particular reason why only the v.type is set as blank? //.ichael

2 5

Tesla Roadster Diagnostics
by Mark Webb-Johnson 23 Nov '23

23 Nov '23

Just got told about this… Tesla releases DBC and diagnostic tools for Tesla Roadster: https://github.com/teslamotors/roadster Can you imagine a world where every vehicle manufacturer did this for all their models (both past and current)? Regards, Mark.

1 0

Ongoing Poll system factoring
by Michael Geddes 18 Nov '23

18 Nov '23

Hi all , I have a whole bunch of commits that I'm quite keen to get put forward that are aimed at defining a better interface between the vehicle implementations and the base ISOTP/VWtp polling implementations. Next up is this one: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/914 There's no real functional change with this, but it is moving Vehicle implementations away from using the member variables and working with passed-in state information. I'm really hoping I can get this one moved forward and I want to be able to address any concerns people have with this code.. either as responses or as changes to the code. //.ichael

1 0

Implementing time printing/parsing and 32bit time_t values!
by Michael Geddes 05 Nov '23

05 Nov '23

I've added a p/r that implements a 'date+time' metric https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/946 I've also added a comment that reads as follows: One discovery I made while implementing this was that time_t is a 32bit number. It seems when we move to the 5.0+ framework this will be fixed in the esp32 libraries, but we will still need to implement a separate metric class for 64 bit time_t values. I'm thinking that an easy way to do it, since the underlying persist mechanism is 32bit, would be to have "_high" suffix a store the high bit as a "separate" metric. Should I do it with this patchset? I can implement the separate metric class and put in #ifdefs for when the time_t value is 64bit. Thoughts on this?? It also highlights the importance of pushing forwards with the new frameworks and filling in the gaps for that. //.

1 0