[Ovmsdev] Messages stopped being received on phone
Michael Geddes
frog at bunyip.wheelycreek.net
Fri Jan 26 12:30:42 HKT 2024
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 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>
>> 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
>> >
>> >
>> > --
>> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20240126/e9eb00e0/attachment-0001.htm>
More information about the OvmsDev
mailing list