July 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

Modem - Last Error: User Interrupt
by Chris van der Meijden 03 Aug '23

03 Aug '23

After I upgraded my modem to a SIM7600 (and replaced my SIM card) I hoped the GSM would be running well again. I'm sorry to say that I still have issues. Every few days GSM will disconnect with "Last Error: User Interrupt". When it disconnects this way it won't connect anymore. Not even when I change location. Only after a "module reset" the connection comes back for another few days. The antenna I use is the internal antenna of the car. I had no issues like this last year. Same antenna then. Am I alone with this behauviour? Any ideas? Thanx Chris cellular status MODEM Status Model: SIM7600 Network Registration: RegisteredHome Provider: congstar Signal: -77 dBm Mode: GSM;Online State: NetLoss Mux: Status up PPP: Not connected Last Error: User Interrupt GPS: Not running module reset cellular status MODEM Status Model: SIM7600 Network Registration: RegisteredHome Provider: congstar Signal: -79 dBm Mode: LTE;Online State: NetMode Mux: Status up PPP: Connected on channel: #2 GPS: Not running

4 7

Current Work in progress - where I'm at for those interested
by Michael Geddes 31 Jul '23

31 Jul '23

Hi all, I'm pushing up my current progress on a reworking of the polling loop. I'm not doing a pull request of this as it absolutely needs to be incorporated in manageable chunks, and I understand that requires time that the devs currently don't have. In broad strokes, this: * Reduces the amount of word done in the Scheduler thread, which under routeros should be kept as lite as possible. This work is done on the (beefed up) Polling thread. * Allows keeping separate OBD state for each polling bus (while maintaining a single thread). * Better compartmentalises the poller operations. * Allows once-off poller actions that don't require blocking the thread. (Which particularly if this is the Scheduler thread - the one that provides the 1s ticks- is not recommended) * Effectively Extends the number of poll 'states' available without changing the base structure. https://github.com/frogonwheels/Open-Vehicle-Monitoring-System-3/tree/polle… I'm still very much interested in feedback and in making this available. In a practical sense, this is what I run on my OVMS and in particular for the OBD2ECU it is working very nicely! //.ichael Geddes

1 0

New module for BYD Atto 3
by Alan Harper 31 Jul '23

31 Jul '23

Hi All, Just sharing that I’m currently working on a vehicle module for the BYD Atto 3. Have basics like SOC, moment in time battery current usage, odometer and speed, but still testing out that I have captured the states correctly when charging with an EVSE and haven’t yet tested at all with DC fast charging. Any particular modules I should be using as a guide for the best way of developing a module?

2 1

Strange issues with Car GPS accuracy.
by Michael Geddes 14 Jul '23

14 Jul '23

Hi all, I'm having a bunch of weird things going on which seem correlated to having the OVMS running. I'm not convinced of causation yet. My car's Nav system is drifting out majorly (like by >100m) and then seems to stay out. This causes major distractions as the nav system keeps giving me warnings about going down one-way roads and it makes the navigation 'interesting' to use. I also noticed that Android Auto location was frozen in one place, so I assumed this was coming from the car - or meant to be anyway. I reduced the polling rate (new work I'm doing) slightly and this freezing no longer happens. (To 3 speed queries per second). But the drifting out on the Navigation still happens... but then not on AA!? Very very weird. If I unplug the OVMS from the OBD port (as I'm driving) it seems to (but not immediately - after a minute or so) correct itself. It's hard to confirm this is directly resulting .. but it seems to be? I turned off my ECU2OBD which should mean that it is resorting to 1 per second POLL with a low throttle value. I'll run with some logs to make sure this is what is happening.. but it still seems that this hasn't stopped this issue from happening. I've tried turning the GSM power off. No result. Another note: I seem to have stopped getting anything near regular updates from the OVMS GPS. Every now and again it gets a successful change come through. Still working on diagnosing that.. maybe it's related? Any thoughts / help would be useful. //.ichael

4 9

Re: [Ovmsdev] simcom 7600 board not responding
by Derek Caudwell 05 Jul '23

05 Jul '23

I had set the driver to SIM7600 with the config set modem driver to speed up connecting. It could be handy to set this from the cellular config page.

1 0

Netmanager priority issue solved
by Michael Balzer 05 Jul '23

05 Jul '23

TL;DR: you need to pull my latest esp-idf changes. I've finally found & solved the strange priority changes for our netmanager task (i.e. being raised suddenly from origin 5 to 18/22): the bug was in the esp-idf posix threads mutex implementation. I had suspected the mutex priority inheritance for a while, so added a way to retrieve the internal mutex hold count for our task list. Using this I noticed the hold count would always & only raise by 2 whenever any kind of mongoose connection was closed. That lead me to checking the thread concurrency protection for mongoose mbufs, because every mongoose connection has two mbufs associated (rx & tx), each having a posix mutex. The bug was: posix mutexes were deleted after locking (taking) them. FreeRTOS mutexes must not be deleted while being taken, that breaks the priority inheritance (more precisely the disinheritance), with the visible effect being the mutex hold count not returning to zero. As a side effect, this may also solve the strange event task starvations (hope so…). I was investigating this as I suspected some busy loop in the netmanager context. With the netman running at prio 22, that would effectively block almost all other processing including the timer service. I've found & fixed one potential busy loop trigger in the netman that would have been caused by the netman task still running while all interfaces had been lost -- not sure if that could happen, but it would explain the effects. So please watch your crash debug info & report if the issue still turns up. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

5 19

Re: [Ovmsdev] simcom 7600 board not responding
by Derek Caudwell 05 Jul '23

05 Jul '23

Thanks Mark, I am on the "edge" firmware and have the verbose logging already enabled. The tx is being logged ok but no rx back. Another anomaly is it will sometimes go from PoweringOn to PoweredOn with no apparent response to the AT command being sent, then times out back to PoweringOn. So there may be a hardware failure, voltage level shifter perhaps? I will try putting an oscilloscope on both ends of transmission next. In testing I simply modified the simcom 7600 driver code to override the default modem driver so as not to effect the 5360 pulse logic. The spec sheet also mentioned it takes the UART around 11s to respond after power up. Using the spec sheet timing with a delay after turning on appears very reliable on mine in powering up and down the module. Whereas the 2s and 6s pulse turned it on and the 4s pulse turned it off going by the led status.

2 1