[Ovmsdev] Messages stopped being received on phone
Michael Balzer
dexter at expeedo.de
Fri Jan 26 15:44:35 HKT 2024
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 at 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 at 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 at 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 at lists.openvehicles.com> wrote:
>>>
>>> Send OvmsDev mailing list submissions to
>>> ovmsdev at 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 at lists.openvehicles.com
>>>
>>> You can reach the person managing the list at
>>> ovmsdev-owner at 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 at expeedo.de>
>>> To: ovmsdev at lists.openvehicles.com
>>> Subject: Re: [Ovmsdev] Messages stopped being received on phone
>>> Message-ID: <93610d48-1492-4ca8-b3ff-1adee6c75ee0 at 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 at 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 at bunyip.wheelycreek.net>
>>> To: OVMS Developers <ovmsdev at lists.openvehicles.com>
>>> Cc: "casner at acm.org" <casner at acm.org>
>>> Subject: Re: [Ovmsdev] Working on ESP-IDF5 + Have a question
>>> about
>>> ovms_module 'Name'
>>> Message-ID:
>>>
>>> <CAH0p7u+KC5Nh1+dds4ib3srAnVzMsNP3Lg7JVdrOF1YYpopy4w at mail.gmail.com
>>> <mailto:CAH0p7u%2BKC5Nh1%2Bdds4ib3srAnVzMsNP3Lg7JVdrOF1YYpopy4w at 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 at 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 at 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 at 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 at webb-johnson.net>
>>> To: OVMS Developers <ovmsdev at lists.openvehicles.com>
>>> Subject: Re: [Ovmsdev] Working on ESP-IDF5 + Have a question
>>> about
>>> ovms_module 'Name'
>>> Message-ID:
>>> <E6A7C991-83E1-40E2-9CD1-19C827EA865F at 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 at 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 at 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 at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>>
>>> ------------------------------
>>>
>>> End of OvmsDev Digest, Vol 144, Issue 8
>>> ***************************************
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20240126/524bb4a0/attachment-0001.htm>
-------------- 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/20240126/524bb4a0/attachment-0001.sig>
More information about the OvmsDev
mailing list