Mark, ovms.dexters-web.de doesn't use the OpenVehicles cloud account. I've always been using my own account, as part of developing the messaging option for any custom server operator (that's also why it uses a different GCM sender ID). But I've done the same FCM preparation steps with my account, and on the live server I also still use the GCM API, yet notifications work with both GCM and FCM clients. My guess is something got messed up in the Google account from deleting that assumed unused second service account, maybe that was somehow associated with the GCM API key? Regards, Michael PS: the API key shown & managed in the App's option menu has no connection to the cloud messaging, that's the auth key for App scripting & bookmarks. Am 26.01.24 um 05:39 schrieb Mark Webb-Johnson:
I’m seeing a lot of:
INVALID_KEY
messages from PushGCM on the server.
@Michael the API key I have is AIz…yew - is that the same as yours?
Regards, Mark.
On 26 Jan 2024, at 12:30 PM, Michael Geddes <frog@bunyip.wheelycreek.net> wrote:
Hmm. Im using that server and I Just started charging again and no message. Michael
On Fri, 26 Jan 2024, 12:25 Mark Webb-Johnson, <mark@webb-johnson.net> wrote:
Not sure which server you guys are using.
Note: In case it is a problem with the api.openvehicles.com <http://api.openvehicles.com/> server, I have pro-actively restarted it.
Regards, Mark
On 26 Jan 2024, at 10:49 AM, Derek Caudwell <d.caudwell@gmail.com> wrote:
Hi Michael, Greg
Fyi, it looks like my messages also stopped on the 8 Jan GMT, I'm on Android 12 OVMS app version 4.1.2.
On Fri, 26 Jan 2024 at 14:35, <ovmsdev-request@lists.openvehicles.com> wrote:
Send OvmsDev mailing list submissions to ovmsdev@lists.openvehicles.com
To subscribe or unsubscribe via the World Wide Web, visit http://lists.openvehicles.com/mailman/listinfo/ovmsdev or, via email, send a message with subject or body 'help' to ovmsdev-request@lists.openvehicles.com
You can reach the person managing the list at ovmsdev-owner@lists.openvehicles.com
When replying, please edit your Subject line so it is more specific than "Re: Contents of OvmsDev digest..."
Today's Topics:
1. Re: Messages stopped being received on phone (Michael Balzer) 2. Re: Working on ESP-IDF5 + Have a question about ovms_module 'Name' (Michael Geddes) 3. Re: Working on ESP-IDF5 + Have a question about ovms_module 'Name' (Mark Webb-Johnson)
----------------------------------------------------------------------
Message: 1 Date: Thu, 25 Jan 2024 19:55:40 +0100 From: Michael Balzer <dexter@expeedo.de> To: ovmsdev@lists.openvehicles.com Subject: Re: [Ovmsdev] Messages stopped being received on phone Message-ID: <93610d48-1492-4ca8-b3ff-1adee6c75ee0@expeedo.de> Content-Type: text/plain; charset="utf-8"; Format="flowed"
Greg,
8th of January matches our preparation steps for the Firebase messaging migration.
But that to my knowledge didn't involve any change to the server yet, and should only have added the Firebase instance to the Google cloud account without disabling the old GCM.
Also? if it was an issue of the server / Google cloud, there certainly would be other users affected.
I assume you didn't install the beta test App build yet? That could be worth a try. The new build works with both the old & new server API. Google wrote the old Android APIs would continue to work until June, but maybe that was too optimistic?
Regards, Michael
Am 25.01.24 um 00:22 schrieb Greg D.: > Hi folks, > > I recently noticed that Alerts (Messages) have stopped coming to my > phone.? The last one was on 8-January '24.? The car is still operating > / charging normally, and has been driven since then. The Battery, Car, > and Location screens are up to date and live. The OVMS module is > connected to the home Wi-Fi, as normal, and I can access it through > the internal web server (dashboard, status, etc.).? But the phone > app's Messages page stops at 8-January. > > I've not messed with the module in a long time.? Last boot, in fact, > was a crash back in July 2023, from which it recovered normally. (So > lovely seeing an uptime in excess of 17 million seconds.) > > So, what happened back on 8-January?? The only thing I can think of > was that Android is being more aggressive about shutting down > background processing (in the name of increased battery life), but > leaving the app running in foreground and triggering an event still > wasn't seen on the phone.? I can see them on the Web's Dashboard, so > the events are being generated and processed otherwise normally. > > The phone is a Pixel 7a, Android 14.? OVMS firmware is > 3.3.003/ota_1/eap (build idf v3.3.4-848-g1ff5e24b1 Sep 1 2022 08:40:30). > > Any ideas? > > Thanks, > > Greg > _______________________________________________ > OvmsDev mailing list > OvmsDev@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
-------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20240125/7996b03f/attachment-0001.sig>
------------------------------
Message: 2 Date: Fri, 26 Jan 2024 09:23:42 +0800 From: Michael Geddes <frog@bunyip.wheelycreek.net> To: OVMS Developers <ovmsdev@lists.openvehicles.com> Cc: "casner@acm.org" <casner@acm.org> Subject: Re: [Ovmsdev] Working on ESP-IDF5 + Have a question about ovms_module 'Name' Message-ID: <CAH0p7u+KC5Nh1+dds4ib3srAnVzMsNP3Lg7JVdrOF1YYpopy4w@mail.gmail.com <mailto:CAH0p7u%2BKC5Nh1%2Bdds4ib3srAnVzMsNP3Lg7JVdrOF1YYpopy4w@mail.gmail.com>> Content-Type: text/plain; charset="utf-8"
Thanks Michael, I hadn't considered there would be an essay in the commit, thanks for that - though it doesn't shed a lot of light on the situation
There seems to be 2 places that mark a Name using the high bit, and only one place that kinda-sorta reads it.
The Name is 'marked' during populate() which seems to be to mark each name with a '*' and the high-bit, before going through and getting the current names for the processes - adding new ones and replacing the old ones without '*' and high-bit mark. So items which are double marked are effectively stale/historic.
It is also 'marked' during the find call .. which basically marks the 'found' name if it was not found and then constructed. The does not appear to be any purpose to this that I can ascertain.
The one place (afaict) it reads the value is in zero() below - the problem is that it looks at the entire top uint32 rather than just that high byte!! It's hard to work out whether this is just a long-standing bug or whether it is weeding out names > 12 characters as well from being removed. So this seems to remove an item from the map, but only if it isn't marked (or long) ie if it isn't stale - or been 'seen' I guess?
bool zero(TaskHandle_t taskid) { for (int i = 0; i < count; ++i) { if (map[i].id == taskid) { * if (map[i].name.words[NAMELEN/4-1] > 0)* return false; for (++i ; i < count; ++i) { map[i-1] = map[i]; } --count; return true; } } return false; }
Does this help? Any thoughts on what this was meant to do ? I've CCd Stephen with a hope he might chip in?
//.
On Wed, 24 Jan 2024 at 15:09, Michael Balzer <dexter@expeedo.de> wrote:
> Michael, > > Am 21.01.24 um 02:54 schrieb Michael Geddes: > > Hey, In working trying to get ESP-IDF 5+ Working, I came across the > following fun thing that I'm trying to work out what is going on!! > This is from main/ovms_module.cpp > I'm not sure why we don't just go through all the words and compare - why > the masked compare for the last entry! And why that value?? It might make > sense if you masked out the final byte ... I'm just struggling to > understand. > > > From the further accesses to the last word/byte in TaskMap, I'd guess > Steve intended using the sign bit on the last byte as some special > indicator, but it's not clear to me for what purpose. It also doesn't seem > to be relevant anymore. > > Steve's commit message is verbose > (30d0a403a380e797f9b222b01dab8da791ab388c), and maybe you can find some > more explanation in the list archives. > > Regards, > Michael > > Why am I looking at it?? Well there's a new warning about copy > constructors.. and then I ran into a problem where 'Name' is sometimes in > memory that can only be accessed 32bit int aligned (which is why the > strange implementation in the first place - I get that). > > Can anybody shed any light on this? > > > class Name > {....... > inline bool operator==(const Name& a) const > { > for (int i = 0; i < NAMELEN/4 - 1; ++i) > if (a.words[i] != words[i]) return false; > i*f (a.words[NAMELEN/4-1] != (words[NAMELEN/4-1] & 0x7FFFFFFF)) > return false;* > return true; > } > > _______________________________________________ > OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev <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@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/20240126/5ca8f078/attachment-0001.htm>
------------------------------
Message: 3 Date: Fri, 26 Jan 2024 09:34:09 +0800 From: Mark Webb-Johnson <mark@webb-johnson.net> To: OVMS Developers <ovmsdev@lists.openvehicles.com> Subject: Re: [Ovmsdev] Working on ESP-IDF5 + Have a question about ovms_module 'Name' Message-ID: <E6A7C991-83E1-40E2-9CD1-19C827EA865F@webb-johnson.net> Content-Type: text/plain; charset="utf-8"
Michael,
Unfortunately, Steve passed away in 2022 so is unlikely to reply :-(
He did work on some of the lower level and more complex parts of OVMS, as well as the command processing framework, and is sorely missed.
I can?t help much with the code you are working on, other than to ask if this functionality is still required in the v5 IDF framework? A lot of stuff we did back then was to address inadequacies in the very new early buggy frameworks coming out of Espressif for the just released ESP-32.
Regards, Mark.
-------------- next part -------------- An embedded message was scrubbed... From: Mark Webb-Johnson <mark@webb-johnson.net> Subject: Passing of Steve Casner Date: Fri, 8 Jul 2022 08:19:25 +0800 Size: 507168 URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20240126/251d3df8/attachment.eml> -------------- next part --------------
> On 26 Jan 2024, at 9:23 AM, Michael Geddes <frog@bunyip.wheelycreek.net> wrote: > > Does this help? Any thoughts on what this was meant to do ? I've CCd Stephen with a hope he might chip in? > > //.
------------------------------
Subject: Digest Footer
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
------------------------------
End of OvmsDev Digest, Vol 144, Issue 8 ***************************************
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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