[Ovmsdev] Messages stopped being received on phone

Mark Webb-Johnson mark at webb-johnson.net
Fri Jan 26 12:24:31 HKT 2024


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 <mailto:ovmsdev-request at lists.openvehicles.com>> wrote:
>> Send OvmsDev mailing list submissions to
>>         ovmsdev at lists.openvehicles.com <mailto: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 <mailto:ovmsdev-request at lists.openvehicles.com>
>> 
>> You can reach the person managing the list at
>>         ovmsdev-owner at lists.openvehicles.com <mailto: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 <mailto:dexter at expeedo.de>>
>> To: ovmsdev at lists.openvehicles.com <mailto:ovmsdev at lists.openvehicles.com>
>> Subject: Re: [Ovmsdev] Messages stopped being received on phone
>> Message-ID: <93610d48-1492-4ca8-b3ff-1adee6c75ee0 at expeedo.de <mailto: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 <mailto: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 <mailto:frog at bunyip.wheelycreek.net>>
>> To: OVMS Developers <ovmsdev at lists.openvehicles.com <mailto:ovmsdev at lists.openvehicles.com>>
>> Cc: "casner at acm.org <mailto:casner at acm.org>" <casner at acm.org <mailto: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 <mailto: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 <mailto: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 <mailto:mark at webb-johnson.net>>
>> To: OVMS Developers <ovmsdev at lists.openvehicles.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20240126/5c25dcde/attachment-0001.htm>


More information about the OvmsDev mailing list