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@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.
Hmm. Im using that server and I Just started
charging again and no message.
Michael
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
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.
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>
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
>
>
> --
> 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
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev