[Ovmsdev] Messages stopped being received on phone
Michael Geddes
frog at bunyip.wheelycreek.net
Fri Jan 26 21:16:27 HKT 2024
That worked doing it via the command line!
OVMS# notify raise text info usr.anton.welcome "Hello, wonderful person!"
I'm assuming that will work for normal notifications too. Cheers.
Michael
On Fri, 26 Jan 2024, 19:06 Mark Webb-Johnson, <mark at webb-johnson.net> wrote:
> Greg, Frog?,
>
> Can you try again? I tried switching to another key.
>
> But just guessing at this point, because the google APIs are voodoo and
> are seemingly deprecated once a year.
>
> Regards, Mark.
>
> On 26 Jan 2024, at 1:10 PM, Mark Webb-Johnson <mark at webb-johnson.net>
> wrote:
>
> I’m talking about the server key. Need Michael B to check.
>
> Regards, Mark.
>
> On 26 Jan 2024, at 12:47 PM, Greg D. <gregd2350 at gmail.com> wrote:
>
> No (assuming I'm looking in the right place... App Options screen? It's
> oaA6...Nrhy
>
> I'm guessing a revoke and renew is all I need to do, yes?
>
> Greg
>
>
> Mark Webb-Johnson wrote:
>
> 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>
> <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 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
>>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20240126/8a0a3803/attachment-0001.htm>
More information about the OvmsDev
mailing list