From frog at bunyip.wheelycreek.net  Fri Jun  2 12:46:44 2023
From: frog at bunyip.wheelycreek.net (Michael Geddes)
Date: Fri, 2 Jun 2023 12:46:44 +0800
Subject: [Ovmsdev] Proposed changes to IncomingPollReply and
 IncomingPollError - before making a pull request
Message-ID: <CAH0p7uLTBKo0FvmSrqe79+ohuo=myakrgVtu42LRpofHEproKA@mail.gmail.com>

Hi all,

So I have some changes coming that depend heavily on this
function signature change. What it is doing is taking the members of
OvmsVehicle that are specific to the ISOTP (and VWTP) protocols and making
the parameters to both IncomingPollReply and IncomingPollError.

This way of doing it makes all the bits explicit parameters, which means a
bunch more parameters passed on the stack.

*Original*:
-    virtual void IncomingPollReply(canbus* bus, uint16_t type, uint16_t
pid, const uint8_t* data, uint8_t length, uint16_t mlremain);
-    virtual void IncomingPollError(canbus* bus, uint16_t type, uint16_t
pid, uint16_t code);

*New:*
virtual void IncomingPollReply(canbus* bus, uint32_t moduleidsent, uint32_t
moduleid, uint16_t type, uint16_t pid, const uint8_t* data, uint16_t
mloffset, uint8_t length, uint16_t mlremain, uint16_t mlframe, const
OvmsPoller::poll_pid_t &pollentry);
virtual void IncomingPollError(canbus* bus, uint32_t moduleidsent, uint32_t
moduleid, uint16_t type, uint16_t pid, uint16_t code, const
OvmsPoller::poll_pid_t &pollentry);

The other way of achieving the same result would be to create a struct that
contains these elements, and then to pass that as a const reference.

Thoughts?  If I need to make modifications to the signatures, I'd prefer to
do it before I make the pull request.

//.ichael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230602/3ce80b11/attachment.htm>

From mark at webb-johnson.net  Fri Jun  2 14:07:29 2023
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Fri, 2 Jun 2023 14:07:29 +0800
Subject: [Ovmsdev] Proposed changes to IncomingPollReply and
 IncomingPollError - before making a pull request
In-Reply-To: <CAH0p7uLTBKo0FvmSrqe79+ohuo=myakrgVtu42LRpofHEproKA@mail.gmail.com>
References: <CAH0p7uLTBKo0FvmSrqe79+ohuo=myakrgVtu42LRpofHEproKA@mail.gmail.com>
Message-ID: <D3FD8658-5E83-4807-BE83-0BB4E7932531@webb-johnson.net>

Seems to be:

IncomingPollReply: 16 -> 32 bytes
IncomingPollError: 10 -> 22 bytes

Using a pointer to a structure would bring that down to 4 bytes.

Given the single level of function call, I don?t think 10 to 32 bytes is excessive or a problem for the stack.

However, the advantage of using a structure is that in future if we don?t want to add things, we don?t need to change all the function prototypes of all the users. So long as the overhead of populating the structure is not excessive, that does seem a more future-proof way of doing things.

Regards, Mark.

> On 2 Jun 2023, at 12:46 PM, Michael Geddes <frog at bunyip.wheelycreek.net> wrote:
> 
> Hi all,
> 
> So I have some changes coming that depend heavily on this function signature change. What it is doing is taking the members of OvmsVehicle that are specific to the ISOTP (and VWTP) protocols and making the parameters to both IncomingPollReply and IncomingPollError.   
> 
> This way of doing it makes all the bits explicit parameters, which means a bunch more parameters passed on the stack.
> 
> Original:
> -    virtual void IncomingPollReply(canbus* bus, uint16_t type, uint16_t pid, const uint8_t* data, uint8_t length, uint16_t mlremain);
> -    virtual void IncomingPollError(canbus* bus, uint16_t type, uint16_t pid, uint16_t code);
> 
> New:
> virtual void IncomingPollReply(canbus* bus, uint32_t moduleidsent, uint32_t moduleid, uint16_t type, uint16_t pid, const uint8_t* data, uint16_t mloffset, uint8_t length, uint16_t mlremain, uint16_t mlframe, const OvmsPoller::poll_pid_t &pollentry);
> virtual void IncomingPollError(canbus* bus, uint32_t moduleidsent, uint32_t moduleid, uint16_t type, uint16_t pid, uint16_t code, const OvmsPoller::poll_pid_t &pollentry);
> 
> The other way of achieving the same result would be to create a struct that contains these elements, and then to pass that as a const reference.
> 
> Thoughts?  If I need to make modifications to the signatures, I'd prefer to do it before I make the pull request.
> 
> //.ichael 
> _______________________________________________
> 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/20230602/34b523e6/attachment.htm>

From frog at bunyip.wheelycreek.net  Fri Jun  2 15:05:18 2023
From: frog at bunyip.wheelycreek.net (Michael Geddes)
Date: Fri, 2 Jun 2023 15:05:18 +0800
Subject: [Ovmsdev] Proposed changes to IncomingPollReply and
 IncomingPollError - before making a pull request
In-Reply-To: <D3FD8658-5E83-4807-BE83-0BB4E7932531@webb-johnson.net>
References: <CAH0p7uLTBKo0FvmSrqe79+ohuo=myakrgVtu42LRpofHEproKA@mail.gmail.com>
 <D3FD8658-5E83-4807-BE83-0BB4E7932531@webb-johnson.net>
Message-ID: <CAH0p7uLh2+K6NAcwiWRTujHoK5i8_L7D8viUZMucgneYpXerSA@mail.gmail.com>

Yeah, that makes sense about future proofing.

Even if I have the struct on the stack it should be efficient enough to
populate.

I might even consider using the structure to contain those values on the
class itself making it zero cost to populate. That might be a later to do.

Michael

On Fri, 2 June 2023, 2:07 pm Mark Webb-Johnson, <mark at webb-johnson.net>
wrote:

> Seems to be:
>
>
>    - IncomingPollReply: 16 -> 32 bytes
>    - IncomingPollError: 10 -> 22 bytes
>
>
> Using a pointer to a structure would bring that down to 4 bytes.
>
> Given the single level of function call, I don?t think 10 to 32 bytes is
> excessive or a problem for the stack.
>
> However, the advantage of using a structure is that in future if we don?t
> want to add things, we don?t need to change all the function prototypes of
> all the users. So long as the overhead of populating the structure is not
> excessive, that does seem a more future-proof way of doing things.
>
> Regards, Mark.
>
> On 2 Jun 2023, at 12:46 PM, Michael Geddes <frog at bunyip.wheelycreek.net>
> wrote:
>
> Hi all,
>
> So I have some changes coming that depend heavily on this
> function signature change. What it is doing is taking the members of
> OvmsVehicle that are specific to the ISOTP (and VWTP) protocols and making
> the parameters to both IncomingPollReply and IncomingPollError.
>
> This way of doing it makes all the bits explicit parameters, which means a
> bunch more parameters passed on the stack.
>
> *Original*:
> -    virtual void IncomingPollReply(canbus* bus, uint16_t type, uint16_t
> pid, const uint8_t* data, uint8_t length, uint16_t mlremain);
> -    virtual void IncomingPollError(canbus* bus, uint16_t type, uint16_t
> pid, uint16_t code);
>
> *New:*
> virtual void IncomingPollReply(canbus* bus, uint32_t moduleidsent,
> uint32_t moduleid, uint16_t type, uint16_t pid, const uint8_t* data,
> uint16_t mloffset, uint8_t length, uint16_t mlremain, uint16_t mlframe,
> const OvmsPoller::poll_pid_t &pollentry);
> virtual void IncomingPollError(canbus* bus, uint32_t moduleidsent,
> uint32_t moduleid, uint16_t type, uint16_t pid, uint16_t code, const
> OvmsPoller::poll_pid_t &pollentry);
>
> The other way of achieving the same result would be to create a struct
> that contains these elements, and then to pass that as a const reference.
>
> Thoughts?  If I need to make modifications to the signatures, I'd prefer
> to do it before I make the pull request.
>
> //.ichael
> _______________________________________________
> 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/20230602/c1c066b8/attachment.htm>

From ll-ovmsdev at lange.nom.fr  Wed Jun  7 17:15:40 2023
From: ll-ovmsdev at lange.nom.fr (Ludovic LANGE)
Date: Wed, 7 Jun 2023 11:15:40 +0200
Subject: [Ovmsdev] CI ?
Message-ID: <32f5b50d-29f9-3569-efce-99c4f2f212aa@lange.nom.fr>

Dear list,

I've been playing a little with GitHub's automatic builds / CI for a few 
months, and I'm thinking about having it in master.

The advantages I can think of would be:

  * Ability to "catch" early on any incompatibility we could introduce
    in a PR. Still in a transition period between ESP-IDFv3.3 - the
    official builds, and ESP-IDFv5.x (the future, I hope, once all the
    issues are ironed out) ; it can add some value in trying to build
    the firmware for different combinations, and thus with different
    compiler versions / libraries versions.
  * It could also be a backup build system for the nightly / releases
    firmwares. Hosting, compiling there is free of charge for public
    GitHub projects

Possible concerns:

  * Very tied to GitHub's hosting and API - vendor lock-in
    However a) it's completely isolated in its own directory, and b)
    some of GitHub's competitors have a similar mechanism (GitLab, ...)


In my tests, I'm using it to:

  * Ensure that the documentation always compile without any warning.
    Sometime, we have very small issues that can impact the visual
    rendering of the HTML, and this step can trigger when the compiler
    emits a warning (or error)
  * Ensure that the changes I'm doing are building without error for a
    "matrix" of different environments:
      o target: ESP32 (but could also be other processor of the
        Espressif portfolio, as supported by the build chains: -S2, -S3,
        -C2, -C3, -C6, -H2 ...)
      o ESP-IDF version : v3.3.4 (our current), v4.4 branch, v5.0, v5.0,
        v5.0.1, v5.0.2, v5.0 branch (could also use v5.1 branch and
        latest, but compile errors from time to time)
      o Mongoose version: 7.9, 7.10, 6.11 (our current)


If you want to have a look, please check:

  * Some of the automated builds here
    https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions
  * A set of corresponding build recipes here
    https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/build-master/.github/workflows
  * The output of a random build:
      o The log of commands:
        https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions/runs/5193543334/jobs/9364221425
      o The build artefacts:
        https://github.com/llange/Open-Vehicle-Monitoring-System-3/suites/13419490939/artifacts/735285471
        (NB: Do not flash ! Just an example :-))


I'd be happy to have some feedback about the interest (or not) to have 
this in master.

For that the next plans would be:

  * Step1 : a PR (to be written) including all these config files in
    <root>/.github/workflows
  * Step2 : a configuration of our GitHub repo to :
      o activate the CI actions
      o After some time, mark some of these actions as "required" in PRs
        (Can be overriden of course, but will show the creator of the PR
        how to improve the PR and have it work across all the
        combinations of environments we aim to support)


Thanks for your time.


Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230607/b3552f6c/attachment.htm>

From dexter at expeedo.de  Thu Jun  8 15:55:14 2023
From: dexter at expeedo.de (Michael Balzer)
Date: Thu, 8 Jun 2023 09:55:14 +0200
Subject: [Ovmsdev] CI ?
In-Reply-To: <32f5b50d-29f9-3569-efce-99c4f2f212aa@lange.nom.fr>
References: <32f5b50d-29f9-3569-efce-99c4f2f212aa@lange.nom.fr>
Message-ID: <c5f3d713-d20e-dc6a-0940-f5f47b423e37@expeedo.de>

Ludovic,

there actually is a Travis CI workflow defined (see 
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master/.travis.yml), 
but that apparently stopped working due to unknown reasons. My 
impresssion was, these CI tools add some comfort but need continuous 
maintenance.

Your workflows catch/handle a lot more cases than the old Travis 
workflow. This would be quite nice to have, especially with heading 
towards IDF v4/v5 & different hardware platforms to support.

My 2 cents: I don't see a lock-in issue here, it's just a GitHub addon, 
building is always possible without. Github itself is completely 
optional, as are all other Git hosters.

Regards,
Michael


Am 07.06.23 um 11:15 schrieb Ludovic LANGE:
>
> Dear list,
>
> I've been playing a little with GitHub's automatic builds / CI for a 
> few months, and I'm thinking about having it in master.
>
> The advantages I can think of would be:
>
>   * Ability to "catch" early on any incompatibility we could introduce
>     in a PR. Still in a transition period between ESP-IDFv3.3 - the
>     official builds, and ESP-IDFv5.x (the future, I hope, once all the
>     issues are ironed out) ; it can add some value in trying to build
>     the firmware for different combinations, and thus with different
>     compiler versions / libraries versions.
>   * It could also be a backup build system for the nightly / releases
>     firmwares. Hosting, compiling there is free of charge for public
>     GitHub projects
>
> Possible concerns:
>
>   * Very tied to GitHub's hosting and API - vendor lock-in
>     However a) it's completely isolated in its own directory, and b)
>     some of GitHub's competitors have a similar mechanism (GitLab, ...)
>
>
> In my tests, I'm using it to:
>
>   * Ensure that the documentation always compile without any warning.
>     Sometime, we have very small issues that can impact the visual
>     rendering of the HTML, and this step can trigger when the compiler
>     emits a warning (or error)
>   * Ensure that the changes I'm doing are building without error for a
>     "matrix" of different environments:
>       o target: ESP32 (but could also be other processor of the
>         Espressif portfolio, as supported by the build chains: -S2,
>         -S3, -C2, -C3, -C6, -H2 ...)
>       o ESP-IDF version : v3.3.4 (our current), v4.4 branch, v5.0,
>         v5.0, v5.0.1, v5.0.2, v5.0 branch (could also use v5.1 branch
>         and latest, but compile errors from time to time)
>       o Mongoose version: 7.9, 7.10, 6.11 (our current)
>
>
> If you want to have a look, please check:
>
>   * Some of the automated builds here
>     https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions
>   * A set of corresponding build recipes here
>     https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/build-master/.github/workflows
>   * The output of a random build:
>       o The log of commands:
>         https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions/runs/5193543334/jobs/9364221425
>       o The build artefacts:
>         https://github.com/llange/Open-Vehicle-Monitoring-System-3/suites/13419490939/artifacts/735285471
>         (NB: Do not flash ! Just an example :-))
>
>
> I'd be happy to have some feedback about the interest (or not) to have 
> this in master.
>
> For that the next plans would be:
>
>   * Step1 : a PR (to be written) including all these config files in
>     <root>/.github/workflows
>   * Step2 : a configuration of our GitHub repo to :
>       o activate the CI actions
>       o After some time, mark some of these actions as "required" in
>         PRs (Can be overriden of course, but will show the creator of
>         the PR how to improve the PR and have it work across all the
>         combinations of environments we aim to support)
>
>
> Thanks for your time.
>
>
> Regards,
>
>
> _______________________________________________
> 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/20230608/29d0594d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230608/29d0594d/attachment.sig>

From solterra at kezarnet.com  Sun Jun 11 05:11:10 2023
From: solterra at kezarnet.com (Solterra)
Date: Sat, 10 Jun 2023 17:11:10 -0400
Subject: [Ovmsdev] Toyota bZ4X and Subaru Solterra
In-Reply-To: <CAH0p7u+GWcA5SsnPjRkSVacBcDYMq4VSkiLZEaM9LZ8gDi+omA@mail.gmail.com>
References: <8f29ce3db86e25f908b5d5437192ba3c@kezarnet.com>
 <f49b94f0-87b0-a8c8-26e4-a6284621d002@expeedo.de>
 <ce758f07b90f1fec583f35032541cbed@kezarnet.com>
 <7850a5d9-35a1-416e-30e9-6fb70ab0aeed@expeedo.de>
 <8d356c101376d15f27b6dffec2eb2d53@kezarnet.com>
 <CAH0p7u+Epmy4n3MJ6ha7EsrNaR8WXPY6-cxGHBDLNLYFLJGAow@mail.gmail.com>
 <5DC205F6-D536-4B24-BA45-35593E059991@webb-johnson.net>
 <500174b94acd46a71dea5c0093c638dc@kezarnet.com>
 <CAH0p7u+GWcA5SsnPjRkSVacBcDYMq4VSkiLZEaM9LZ8gDi+omA@mail.gmail.com>
Message-ID: <6877c304bdfa50c80df9a3ed94043041@kezarnet.com>



I've decided on a structure, so I'll outline it here.

My major problem is that I don't know how different the vehicles are (I 
just have the Subaru...). So, I created a Toyota e-TNGA class where most 
of the functionality lives. I then created a wrapper for the Subaru (and 
will do the same for bZ4X). The same code likely works for Lexus RZ450e 
as well.

I guess when I (or someone else) finds a difference, at least there's a 
home for the code.

Thanks for your advice.

On 2023-05-29 20:21, Michael Geddes wrote:

> Just FYI on the Ioniq5 I was able to see using the 'valid bits' which 
> of the battery voltages were valid, therefore hopefully what the 
> overall battery capacity is.  I have not got feedback on any different 
> battery configs yet... You can have a look at what I've done there 
> anyway.
> 
> Sounds good anyway.
> 
> Michael
> 
> On Tue, 30 May 2023, 3:29 am Solterra, <solterra at kezarnet.com> wrote:
> 
> It's Toyota's e-TNGA platform. I know the CAN network is the same for 
> Toyota bZ4X and Subaru Solterra, but I'm not sure about the bZ3 (China) 
> and Lexus RZ... One complicating factor is there are two battery 
> configurations for the bZ4X, one of which is shared with the Solterra.
> 
> Probably a detail for down the road a bit. For now, I've just created a 
> bZ4X vehicle module and am tinkering under that.
> 
> On 2023-05-28 21:45, Mark Webb-Johnson wrote:
> 
> Solterra,
> 
> Michael's advice is good.
> 
> If it is just two names for essentially the same vehicle, I think you 
> can refer to vehicle_voltampera (which implemented the Chevy Volt and 
> Open Ampera vehicle support). These were essentially the same vehicle 
> platform, but with minor bodywork differences and labelling.
> 
> If the two vehicles share the same platform (such as BMS, battery, etc) 
> but are otherwise very different, then I suggest you implement a 
> vehicle_<platform> for that platform, and derive two classes from that 
> in the same /src/ directory (one for each vehicle type). That will 
> allow you to put all common support code in the base platform, but have 
> each vehicle type customisable (and individually selectable).
> 
> Looking at images of the cars, it seems they are closest to the Volt 
> Ampera situation. Perhaps BZSS?
> 
> Regards, Mark.
> 
> On 28 May 2023, at 8:23 AM, Michael Geddes 
> <frog at bunyip.wheelycreek.net> wrote:
> 
> Hey Solterra,
> I couldn't say definitively but imho there are various options 
> depending on HOW different.
> 
> 1) They are exactly the same - or differences can be distinguished from 
> responses: Register the name with both in it. Done. (This has happened 
> with some older Kia + Hyundai even)
> 2)  They are mostly the same.  You could probably keep the one 
> directory but have  2 wrapper classes constructing the base class with 
> a parameter and register both in the factory Init. (Not sure if there 
> are examples - ask the other Michael if this is ok).
> 3) They have a lot of commonality.  You can inherit off a base class - 
> or inherit one vehicle impl off the other... But put them in separate 
> directories.  (This happens for Ioniq 5 and a bunch of other Kia + 
> Hyundai cars).
> 
> //.ichael Geddes
> 
> On Sat, 27 May 2023 at 21:19, Solterra <solterra at kezarnet.com> wrote:
> 
> Hello again,
> 
> I've finished my initial vehicle investigation and am not ready to add 
> support to OVMS.
> 
> When creating the vehicle stub, is there guidance for situations like 
> on this vehicle? There are two makes and models that are essentially 
> the same. Can I create a common 'components/vehicle_toyota_bz4x' and 
> point two vehicle selections to it somewhere else?
> 
> Thank you
> 
> _______________________________________________
> 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
_______________________________________________
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/20230610/10dd81b9/attachment.htm>

From solterra at kezarnet.com  Mon Jun 12 08:02:38 2023
From: solterra at kezarnet.com (Solterra)
Date: Sun, 11 Jun 2023 20:02:38 -0400
Subject: [Ovmsdev] Error: can: can1 watchdog inactivity timeout - resetting
 bus
Message-ID: <8bc527d9a667dbc97e4c3b67bbc7dc71@kezarnet.com>

Hello,

I'm getting this error.

However, I don't think I'm using can1... My vehicle uses can2. I don't 
think I've initialized can1.

Any clues to help me debug? Do I need to do something to actively 
disable can1 during vehicle initialization?

Thank you

From solterra at kezarnet.com  Mon Jun 12 09:39:36 2023
From: solterra at kezarnet.com (Solterra)
Date: Sun, 11 Jun 2023 21:39:36 -0400
Subject: [Ovmsdev] Error: can: can1 watchdog inactivity timeout -
 resetting bus
In-Reply-To: <8bc527d9a667dbc97e4c3b67bbc7dc71@kezarnet.com>
References: <8bc527d9a667dbc97e4c3b67bbc7dc71@kezarnet.com>
Message-ID: <3887abf51f92af415e0ac682b782838a@kezarnet.com>

OK. I found it. I had the obdc2ecu enabled for can1.


On 2023-06-11 20:02, Solterra wrote:
> Hello,
> 
> I'm getting this error.
> 
> However, I don't think I'm using can1... My vehicle uses can2. I don't 
> think I've initialized can1.
> 
> Any clues to help me debug? Do I need to do something to actively 
> disable can1 during vehicle initialization?
> 
> Thank you
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

From solterra at kezarnet.com  Sat Jun 17 07:37:03 2023
From: solterra at kezarnet.com (Solterra)
Date: Fri, 16 Jun 2023 19:37:03 -0400
Subject: [Ovmsdev] Recommen
Message-ID: <4279e043398e906f374362dc404b80c8@kezarnet.com>

Hello,

I have a couple of questions on the CAN poll TX framework.

Is there a recommended method for adding a one-time CAN poll to the 
queue with the response to be processed by IncomingPollReply?

What is the recommended method for adding or modifying obdii_polls after 
initialization?

Thank you

From frog at bunyip.wheelycreek.net  Sat Jun 17 09:40:05 2023
From: frog at bunyip.wheelycreek.net (Michael Geddes)
Date: Sat, 17 Jun 2023 09:40:05 +0800
Subject: [Ovmsdev] Recommen
In-Reply-To: <4279e043398e906f374362dc404b80c8@kezarnet.com>
References: <4279e043398e906f374362dc404b80c8@kezarnet.com>
Message-ID: <CAH0p7uLR5spQjsHOmjnDuPZWBwno8ksUixoss0jDyc9e477SRw@mail.gmail.com>

Currently, Not really, however I have some stuff in the pipeline that
permits exactly this kind of thing.

IF you would like, I could push it up to my own branch to my  github
account.  (I've been pushing up bits and pieces and working with the main
devs on the feedback).

One way you _could_ do it, I guess, is to make a copy of your poll struct,
include the one-off poll you wanted, and just temporarily modify the values
to a 1 (you'd want to lock the poll mutex) and change it back to 0 after
receiving the result.

The below example actually calls back on Incoming_Full with the full data
after receiving all the frames.. but you can also make a OnceOffPoll that
just allows it to go into the normal Incoming functions.

This one will even retry 3 times in the case it gets a failure the first
time.

//.ichael


----8<------------------- example --------------------[

bool OvmsHyundaiIoniqEv::PollRequestVIN()
{
  if (!StdMetrics.ms_v_env_awake->AsBool()) {
    ESP_LOGV(TAG, "PollRequestVIN: Not Awake Request not sent");
    return false;
  }
  auto poll_entry = std::shared_ptr<OvmsPoller::OnceOffPoll>(
      new OvmsPoller::OnceOffPoll(
        std::bind(&OvmsHyundaiIoniqEv::Incoming_Full, this, _1, _2, _3, _4,
_5),
        std::bind(&OvmsHyundaiIoniqEv::Incoming_Fail, this, _1, _2, _3, _4,
_5),
        VEHICLE_OBD_BROADCAST_MODULE_TX, VEHICLE_OBD_BROADCAST_MODULE_RX,
        VEHICLE_POLL_TYPE_OBDIIVEHICLE,  2,
        ISOTP_STD, 0, 3/*retries*/ ));
  PollRequest(m_can1, "!xiq.vin", poll_entry);
  return true;
}


On Sat, 17 Jun 2023 at 07:37, Solterra <solterra at kezarnet.com> wrote:

> Hello,
>
> I have a couple of questions on the CAN poll TX framework.
>
> Is there a recommended method for adding a one-time CAN poll to the
> queue with the response to be processed by IncomingPollReply?
>
> What is the recommended method for adding or modifying obdii_polls after
> initialization?
>
> Thank you
> _______________________________________________
> 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/20230617/6f837dfc/attachment.htm>

From frog at bunyip.wheelycreek.net  Sat Jun 17 09:50:10 2023
From: frog at bunyip.wheelycreek.net (Michael Geddes)
Date: Sat, 17 Jun 2023 09:50:10 +0800
Subject: [Ovmsdev] Using the override keyword
Message-ID: <CAH0p7uKtQQOA1JXWzvHaMshaOF5_3T2PBU81m+aCfrY8duYn+w@mail.gmail.com>

Hi all,

So at my work, the main language I use is Delphi  (so Object Pascal), and
one of the things about Delphi is that you are forced to always be explicit
about overriding virtual methods. (Missing out on 'override' directive
indicates that you are Hiding (a warning) rather than overriding the
virtual method).

Since C++ now allows use of the override keyword now to explicitly say a
method is overriding a virtual function, I have been adding that in all the
code I use (or at least trying to).

Firstly, it is a visual indicator that the method is, in fact, overriding a
virtual function (which is not always obvious), but it also means that if a
virtual method changes its signature in any way, you will get an error if
an 'override' marked method no longer matches!

I'm not sure what I'm after except just to bring it to people's attention
in case they might have missed it, and find out how people view this.

My latest pull-request has changed the signature of OvmsVehicle methods and
I have added 'override' to all the places where this is overridden in
derived Vehicle classes.

//.ichael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230617/6c581f99/attachment.htm>

From dexter at expeedo.de  Sat Jun 17 15:01:35 2023
From: dexter at expeedo.de (Michael Balzer)
Date: Sat, 17 Jun 2023 09:01:35 +0200
Subject: [Ovmsdev] Recommen
In-Reply-To: <4279e043398e906f374362dc404b80c8@kezarnet.com>
References: <4279e043398e906f374362dc404b80c8@kezarnet.com>
Message-ID: <04c5cbaa-59aa-4ae3-59dc-b6bdd1ebc125@expeedo.de>

Solterra,

Am 17.06.23 um 01:37 schrieb Solterra:
> Is there a recommended method for adding a one-time CAN poll to the 
> queue with the response to be processed by IncomingPollReply?

For single-shot requests you can either use the synchronous 
`OvmsVehicle::PollSingleRequest()` method(s) or temporarily replace the 
PID list via `OvmsVehicle::PollSetPidList()`.

For the latter, you'd reinstall your standard PID list in the incoming 
handler once you've received the response.

> What is the recommended method for adding or modifying obdii_polls 
> after initialization?

In most situations you only need to switch polls partially or change the 
poll frequency. For this, use the up to four poll state timings per list 
entry, and call `OvmsVehicle::PollSetState()` to switch the current state.

If you need to fully replace a poll list:

 1. Lock the poller mutex
 2. Remove the current PID list
 3. Create / modify your PID list
 4. Install the new / modified PID list
 5. Unlock the poller mutex

For dynamically created PID lists and/or combining predefined with 
dynamic entries, use a C++ std::vector & std::initializer_list.

For a full example of this and also an example for how to do the PID 
list update, see the `vehicle_vweup` OBD module:

  * https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master/vehicle/OVMS.V3/components/vehicle_vweup/src/vehicle_vweup.h#L83
  * https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master/vehicle/OVMS.V3/components/vehicle_vweup/src/vweup_obd.cpp#L217

Regards,
Michael

-- 
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/20230617/566d8dee/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230617/566d8dee/attachment.sig>

From solterra at kezarnet.com  Sat Jun 17 19:45:59 2023
From: solterra at kezarnet.com (Solterra)
Date: Sat, 17 Jun 2023 07:45:59 -0400
Subject: [Ovmsdev] Recommen
In-Reply-To: <04c5cbaa-59aa-4ae3-59dc-b6bdd1ebc125@expeedo.de>
References: <4279e043398e906f374362dc404b80c8@kezarnet.com>
 <04c5cbaa-59aa-4ae3-59dc-b6bdd1ebc125@expeedo.de>
Message-ID: <519bdeeba022001537dfddcb7a219365@kezarnet.com>



Thanks for the tips.

For my first question, I initially copied the what the Ionic5 module did 
for VIN request, but it doesn't really fit with the framework of my 
vehicle module. I'm in the process of refactoring and figured there were 
other instances where I'll just want to send a one-time poll and let the 
framework process the response. Your response points me down the right 
path...

For my second question, I'm considering a command where I need to enter 
a UDS diagnostic session and will need to add a poll to keep the ECU in 
that session. I don't always need the poll, but once I do I need it 
every 2 seconds or so. Then, at the end of the session, I'll return the 
polling back to the 'standard'.

Things are going well with my module, by the way. I'm having trouble 
where the communications gateway ECU goes to sleep when the vehicle is 
'off' and I dont yet know how to wake it up. This might cause some 
charging sessions to be missed. I haven't decided if I care yet or not, 
as my initial use case is most important when the vehicle is on.

I'm going to do some reverse engineering of the Toyota TIS software 
communication today to see how they keep the communications gateway ECU 
awake.

On 2023-06-17 03:01, Michael Balzer wrote:

> Solterra,
> 
> Am 17.06.23 um 01:37 schrieb Solterra:
> 
>> Is there a recommended method for adding a one-time CAN poll to the 
>> queue with the response to be processed by IncomingPollReply?
> 
> For single-shot requests you can either use the synchronous 
> `OvmsVehicle::PollSingleRequest()` method(s) or temporarily replace the 
> PID list via `OvmsVehicle::PollSetPidList()`.
> 
> For the latter, you'd reinstall your standard PID list in the incoming 
> handler once you've received the response.
> 
>> What is the recommended method for adding or modifying obdii_polls 
>> after initialization?
> 
> In most situations you only need to switch polls partially or change 
> the poll frequency. For this, use the up to four poll state timings per 
> list entry, and call `OvmsVehicle::PollSetState()` to switch the 
> current state.
> 
> If you need to fully replace a poll list:
> 
> * Lock the poller mutex
> * Remove the current PID list
> * Create / modify your PID list
> * Install the new / modified PID list
> * Unlock the poller mutex
> 
> For dynamically created PID lists and/or combining predefined with 
> dynamic entries, use a C++ std::vector & std::initializer_list.
> 
> For a full example of this and also an example for how to do the PID 
> list update, see the `vehicle_vweup` OBD module:
> 
> * 
> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master/vehicle/OVMS.V3/components/vehicle_vweup/src/vehicle_vweup.h#L83
> * 
> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master/vehicle/OVMS.V3/components/vehicle_vweup/src/vweup_obd.cpp#L217
> 
> Regards,
> Michael
> 
> --
> 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/20230617/8b9b2480/attachment.htm>

From frog at bunyip.wheelycreek.net  Mon Jun 19 22:02:43 2023
From: frog at bunyip.wheelycreek.net (Michael Geddes)
Date: Mon, 19 Jun 2023 22:02:43 +0800
Subject: [Ovmsdev] Strange issues with Car GPS accuracy.
In-Reply-To: <31b8b4cf-0e19-1688-078c-41c252a97cfb@expeedo.de>
References: <CAH0p7uKXu6L+u1rLOtU55O-7JgaXiG9w=P7SnejqH2UsDW52Hw@mail.gmail.com>
 <CAH0p7uJMSQGs_Gs-USNMGaeytgW16avDMecEcKmjrXtYsE75Xw@mail.gmail.com>
 <31b8b4cf-0e19-1688-078c-41c252a97cfb@expeedo.de>
Message-ID: <CAH0p7uL4yGHfrXtkwXqdgjka-2E1cjeH6DSJsSXpoDw3+3iPeA@mail.gmail.com>

*sigh* I'm now at the point where my OVMS is next to unusable because of
the GPS interference issue.  I switched back to my old ovms unit (no GSM
daughter board and the external power doesn't work)... And the problem went
away. Even with the faster polling. So it seems something is possibly wrong
with the OVMS hardware itself.. Maybe some noise on the can bus is playing
havock? It's most peculiar.

It might also make sense of something I'm seeing on the HUD which is that
it periodically stalls and resets.
I guess I should move the daughter board across to check out that.

Michael


On Mon, 29 May 2023, 4:06 pm Michael Balzer, <dexter at expeedo.de> wrote:

> Michael,
>
> if the module affects your car's builtin navigation system, I think that
> points to some EM interference. While the module has passed the EM tests
> for certification, it still emits some EM noise, and some devices are more
> sensitive to this than others. There also may be a satellite outage
> affecting Australia currently, that adds to the sensitivity.
>
> You could try to selectively switch off Wifi and the modem when the issue
> occurs, to see if one of these cause it.
>
> If not, you could try reorienting and replacing the module in the car,
> especially if it's very close to the nav system's GPS antenna.
>
> Regards,
> Michael
>
>
> Am 27.05.23 um 10:07 schrieb Michael Geddes:
>
> Latest: I changed the startup vehicle to None and turned off the mobile.
> Still getting drifting vehicle GPS until I unplug the OVMS.  Hardware
> issue? Does anybody have any clues?
>
> Michael
>
> On Sun, 21 May 2023, 11:41 am Michael Geddes, <frog at bunyip.wheelycreek.net>
> wrote:
>
>> Hi all,
>> I'm having a bunch of weird things going on which seem correlated to
>> having the OVMS running.  I'm not convinced of causation yet.
>>
>> My car's Nav system is drifting out majorly (like by >100m) and then
>> seems to stay out.  This causes major distractions as the nav system keeps
>> giving me warnings about going down one-way roads and it makes the
>> navigation 'interesting' to use.
>>
>> I also noticed that Android Auto location was frozen in one place, so I
>> assumed this was coming from the car - or meant to be anyway.  I reduced
>> the polling rate (new work I'm doing) slightly and this freezing no longer
>> happens. (To 3 speed queries per second).  But the drifting out on the
>> Navigation  still happens... but then not on AA!? Very very weird.
>>
>> If I unplug the OVMS from the OBD port (as I'm driving) it seems to (but
>> not immediately - after a minute or so) correct itself.  It's hard to
>> confirm this is directly resulting .. but it seems to be?
>>
>> I turned off my ECU2OBD which should mean that it is resorting to 1 per
>> second POLL with a low throttle value.  I'll run with some logs to make
>> sure this is what is happening.. but it still seems that this hasn't
>> stopped this issue from happening.
>>
>> I've tried turning the GSM power off. No result.
>>
>> Another note: I seem to have stopped getting anything near regular
>> updates from the OVMS GPS. Every now and again it gets a successful change
>> come through.  Still working on diagnosing that.. maybe it's related?
>>
>>
>> Any thoughts / help would be useful.
>>
>> //.ichael
>>
>>
>>
>>
> _______________________________________________
> 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/20230619/a3b5c5c0/attachment.htm>

From frog at bunyip.wheelycreek.net  Tue Jun 20 09:49:56 2023
From: frog at bunyip.wheelycreek.net (Michael Geddes)
Date: Tue, 20 Jun 2023 09:49:56 +0800
Subject: [Ovmsdev] Recommen
In-Reply-To: <519bdeeba022001537dfddcb7a219365@kezarnet.com>
References: <4279e043398e906f374362dc404b80c8@kezarnet.com>
 <04c5cbaa-59aa-4ae3-59dc-b6bdd1ebc125@expeedo.de>
 <519bdeeba022001537dfddcb7a219365@kezarnet.com>
Message-ID: <CAH0p7u+dWgYGZJmL3SBe5ZBpatfJpjK5xdA18ihZKDzTbJUFBA@mail.gmail.com>

Oh, I just realised I did not clarify that the example VIN code is where
I'm heading to.. Not what exists now. Presumably you looked at what I have
now in the Ioniq 5 code.

There are keep-alive mechanisms and examples around.


Michael

On Sat, 17 June 2023, 7:46 pm Solterra, <solterra at kezarnet.com> wrote:

> Thanks for the tips.
>
> For my first question, I initially copied the what the Ionic5 module did
> for VIN request, but it doesn't really fit with the framework of my vehicle
> module. I'm in the process of refactoring and figured there were other
> instances where I'll just want to send a one-time poll and let the
> framework process the response. Your response points me down the right
> path...
>
> For my second question, I'm considering a command where I need to enter a
> UDS diagnostic session and will need to add a poll to keep the ECU in that
> session. I don't always need the poll, but once I do I need it every 2
> seconds or so. Then, at the end of the session, I'll return the polling
> back to the 'standard'.
>
> Things are going well with my module, by the way. I'm having trouble where
> the communications gateway ECU goes to sleep when the vehicle is 'off' and
> I dont yet know how to wake it up. This might cause some charging sessions
> to be missed. I haven't decided if I care yet or not, as my initial use
> case is most important when the vehicle is on.
>
> I'm going to do some reverse engineering of the Toyota TIS software
> communication today to see how they keep the communications gateway ECU
> awake.
>
>
> On 2023-06-17 03:01, Michael Balzer wrote:
>
> Solterra,
>
> Am 17.06.23 um 01:37 schrieb Solterra:
>
> Is there a recommended method for adding a one-time CAN poll to the queue
> with the response to be processed by IncomingPollReply?
>
>
> For single-shot requests you can either use the synchronous
> `OvmsVehicle::PollSingleRequest()` method(s) or temporarily replace the PID
> list via `OvmsVehicle::PollSetPidList()`.
>
> For the latter, you'd reinstall your standard PID list in the incoming
> handler once you've received the response.
>
> What is the recommended method for adding or modifying obdii_polls after
> initialization?
>
>
> In most situations you only need to switch polls partially or change the
> poll frequency. For this, use the up to four poll state timings per list
> entry, and call `OvmsVehicle::PollSetState()` to switch the current state.
>
> If you need to fully replace a poll list:
>
>    1. Lock the poller mutex
>    2. Remove the current PID list
>    3. Create / modify your PID list
>    4. Install the new / modified PID list
>    5. Unlock the poller mutex
>
> For dynamically created PID lists and/or combining predefined with dynamic
> entries, use a C++ std::vector & std::initializer_list.
>
> For a full example of this and also an example for how to do the PID list
> update, see the `vehicle_vweup` OBD module:
>
>    -
>    https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master/vehicle/OVMS.V3/components/vehicle_vweup/src/vehicle_vweup.h#L83
>    -
>    https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master/vehicle/OVMS.V3/components/vehicle_vweup/src/vweup_obd.cpp#L217
>
> Regards,
> Michael
>
> --
> 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
>
> _______________________________________________
> 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/20230620/c2ffbba9/attachment.htm>

From solterra at kezarnet.com  Tue Jun 20 18:45:20 2023
From: solterra at kezarnet.com (Solterra)
Date: Tue, 20 Jun 2023 06:45:20 -0400
Subject: [Ovmsdev] Recommen
In-Reply-To: <CAH0p7u+dWgYGZJmL3SBe5ZBpatfJpjK5xdA18ihZKDzTbJUFBA@mail.gmail.com>
References: <4279e043398e906f374362dc404b80c8@kezarnet.com>
 <04c5cbaa-59aa-4ae3-59dc-b6bdd1ebc125@expeedo.de>
 <519bdeeba022001537dfddcb7a219365@kezarnet.com>
 <CAH0p7u+dWgYGZJmL3SBe5ZBpatfJpjK5xdA18ihZKDzTbJUFBA@mail.gmail.com>
Message-ID: <b58a23243b81f05f4b4f1560546e85a8@kezarnet.com>



Thanks for the help. I ended up going with PollSingleRequest for the 
one-off messages (VIN request, Charge Type, and Charge Mode so far...).

It seems like sometimes it inturrupts a poll Tx/Rx cycle (receives the 
Rx from a previous poll and fails), so I added a retry in those 
instances. Code snip below. I'll probably encapsulate that (poll and 
retry) into a function to do a one-off requests.

I saw your post in March about changes to the OBD Poller (paying more 
attention now that I'm writing code...) Is that change still in the 
works? It sounds great.

void OvmsVehicleToyotaETNGA::RequestChargeType()
{
     std::string response;
     int chargeType;
     int maxRetries = 5;
     int retryCount = 0;
     int res;

     while (retryCount < maxRetries && res != POLLSINGLE_OK)
     {
         res = PollSingleRequest(
             m_can2,
             PLUG_IN_CONTROL_SYSTEM_TX,
             PLUG_IN_CONTROL_SYSTEM_RX,
             VEHICLE_POLL_TYPE_READDATA,
             PID_CHARGING_VOLTAGE_TYPE,
             response,
             1000,
             ISOTP_STD
         );

         if (res == POLLSINGLE_OK)
         {
             // Request successful
             chargeType = response[0] & 0xFF;
             SetChargeType(chargeType);
             break;
         }
         else
         {
             retryCount++;
             ESP_LOGW(TAG, "RequestChargeType: Request failed with error 
code %d. Retrying (%d/%d)", res, retryCount, maxRetries);
         }
     }

     if (res != POLLSINGLE_OK)
     {
         ESP_LOGE(TAG, "RequestChargeType: Maximum retries reached. 
Request failed with error code %d", res);
     }
}

On 2023-06-19 21:49, Michael Geddes wrote:

> Oh, I just realised I did not clarify that the example VIN code is 
> where I'm heading to.. Not what exists now. Presumably you looked at 
> what I have now in the Ioniq 5 code.
> 
> There are keep-alive mechanisms and examples around.
> 
> Michael
> 
> On Sat, 17 June 2023, 7:46 pm Solterra, <solterra at kezarnet.com> wrote:
> 
> Thanks for the tips.
> 
> For my first question, I initially copied the what the Ionic5 module 
> did for VIN request, but it doesn't really fit with the framework of my 
> vehicle module. I'm in the process of refactoring and figured there 
> were other instances where I'll just want to send a one-time poll and 
> let the framework process the response. Your response points me down 
> the right path...
> 
> For my second question, I'm considering a command where I need to enter 
> a UDS diagnostic session and will need to add a poll to keep the ECU in 
> that session. I don't always need the poll, but once I do I need it 
> every 2 seconds or so. Then, at the end of the session, I'll return the 
> polling back to the 'standard'.
> 
> Things are going well with my module, by the way. I'm having trouble 
> where the communications gateway ECU goes to sleep when the vehicle is 
> 'off' and I dont yet know how to wake it up. This might cause some 
> charging sessions to be missed. I haven't decided if I care yet or not, 
> as my initial use case is most important when the vehicle is on.
> 
> I'm going to do some reverse engineering of the Toyota TIS software 
> communication today to see how they keep the communications gateway ECU 
> awake.
> 
> On 2023-06-17 03:01, Michael Balzer wrote:
> 
> Solterra,
> 
> Am 17.06.23 um 01:37 schrieb Solterra: Is there a recommended method 
> for adding a one-time CAN poll to the queue with the response to be 
> processed by IncomingPollReply?
> For single-shot requests you can either use the synchronous 
> `OvmsVehicle::PollSingleRequest()` method(s) or temporarily replace the 
> PID list via `OvmsVehicle::PollSetPidList()`.
> 
> For the latter, you'd reinstall your standard PID list in the incoming 
> handler once you've received the response.
> 
> What is the recommended method for adding or modifying obdii_polls 
> after initialization?
> In most situations you only need to switch polls partially or change 
> the poll frequency. For this, use the up to four poll state timings per 
> list entry, and call `OvmsVehicle::PollSetState()` to switch the 
> current state.
> 
> If you need to fully replace a poll list:
> 
> * Lock the poller mutex
> * Remove the current PID list
> * Create / modify your PID list
> * Install the new / modified PID list
> * Unlock the poller mutex
> 
> For dynamically created PID lists and/or combining predefined with 
> dynamic entries, use a C++ std::vector & std::initializer_list.
> 
> For a full example of this and also an example for how to do the PID 
> list update, see the `vehicle_vweup` OBD module:
> 
> * 
> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master/vehicle/OVMS.V3/components/vehicle_vweup/src/vehicle_vweup.h#L83
> * 
> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master/vehicle/OVMS.V3/components/vehicle_vweup/src/vweup_obd.cpp#L217
> 
> Regards,
> Michael
> 
> --
> 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
  _______________________________________________
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/20230620/05d20ec3/attachment.htm>

From solterra at kezarnet.com  Wed Jun 21 00:25:45 2023
From: solterra at kezarnet.com (Solterra)
Date: Tue, 20 Jun 2023 12:25:45 -0400
Subject: [Ovmsdev] Nominal battery pack voltage
Message-ID: <af6607dc12697cd3e6e7f34071856e9d@kezarnet.com>

Howdy,

Is there a standard metric for nominal battery pack voltage?

I'm looking to use it to convert v.b.cac to kWh in a rewrite of the ABRP 
plug-in.

Thank you

From mark at webb-johnson.net  Wed Jun 21 19:19:33 2023
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Wed, 21 Jun 2023 19:19:33 +0800
Subject: [Ovmsdev] Internet outage
Message-ID: <60445486-DD36-4251-8362-BA50107D2019@webb-johnson.net>

We had a nasty internet outage (fibre line break) this afternoon that caused substantial downtime for api.openvehicles.com.

Apologies for this. All is back now, and we will be trying to make some changes in the near future, to make it easier to fall over to the backup link.

Regards, Mark

From dexter at expeedo.de  Wed Jun 21 19:25:52 2023
From: dexter at expeedo.de (Michael Balzer)
Date: Wed, 21 Jun 2023 13:25:52 +0200
Subject: [Ovmsdev] Fwd: [Action Required] Update your apps to the latest
 Firebase Cloud Messaging APIs and SDKs
In-Reply-To: <03f21bfd162f1a23a37e5c020647bc37166570ed-20264762-111332550@google.com>
References: <03f21bfd162f1a23a37e5c020647bc37166570ed-20264762-111332550@google.com>
Message-ID: <410862c2-2d8c-d746-8154-b2911dd47d4d@expeedo.de>

Time for another Google API deprecation.

It seems we'll need to update the Android App & possibly the server now 
to the FCM API for push notifications, the old GCM API will stop working 
in June 2024.

Anyone volunteering to take care of this?

Regards,
Michael


-------- Weitergeleitete Nachricht --------
Betreff: 	[Action Required] Update your apps to the latest Firebase 
Cloud Messaging APIs and SDKs
Datum: 	Tue, 20 Jun 2023 13:26:22 -0700
Von: 	Firebase <firebase-noreply at google.com>
Antwort an: 	Firebase <firebase-noreply at google.com>
An: 	dexter at expeedo.de



Mandatory Service Announcement from Firebase
Take action before June 20, 2024 to continue receiving support.
Firebase Console 
<https://notifications.google.com/g/p/ACUgQrEqj5I8-oiq75nsyLmVgMI_2P_O30pr9ZcpVmk-O8L3G7S5GLuDAQBGbLzVLag80DcGOGlPohe0LlxV3Am7cZNv3WRo1rwY30WWKavJb9NJTk1FmXuKrvFZt8XgZ17HnYFO11bDbl7kSR_82CXEwuwTZU4-udfbmAeK7zzJ3qZft1R_jSAmBvOt677OdR1wfx-Q> 


Hi Michael,

We?re writing to let you know that starting *June 20, 2024* the legacy 
Firebase Cloud Messaging (FCM) APIs will be discontinued.

What do you need to know?

On *June 20, 2024,* we?re reducing the number of Firebase Cloud 
Messaging (FCM) legacy register APIs and legacy send APIs that provide 
similar functionality. This step will allow us to provide you with a 
more consistent experience and align with Google security standards to 
improve security, reliability and performance.

Because of these API decommissions, some already-deprecated SDKs and 
features will stop working after *June 20, 2024.*

Please consult the tables below to find which Firebase Cloud Messaging 
(FCM) APIs and corresponding services/SDKs/features will be discontinued 
and replaced with new alternatives.

*Discontinued Send API*

	

*Decommissioned service*

	

*New alternative*

*Legacy HTTP Protocol*

	

Sending messages via the Legacy HTTP API.

	

Send messages via the HTTP v1 API.

*XMPP Protocol*

	

Sending upstream and downstream messages via the XMPP API.

	

Send downstream messages via the HTTP v1 API.

Send upstream messages via HTTP/gRPC 
<https://notifications.google.com/g/p/ACUgQrFKp0BdXKuz3_mUi3W9wdl6DV3Ib_q0Hn9_rFkVCttPt1pfUS9zAavG0IHLz8EEex1Xah-SSAfcgb2zSplnVRd5kYFwn3MN31jskkUBf1w_RdTqd1tuSW3w6CKsMVdUC9bJHCVT9qvQXy4G6_8J5J-aT-4UFsRnmM4ASLagXT9eO188Q1gAxo7IH3vsHg-U55h8rnJ9zzRdh-DNTbMvJhXav_T7Bw> 
directly from the App to your server.

*Batch send API*

	

Including multiple send requests in a single HTTP request to FCM known 
as Batch Send.

	

Send messages via the HTTP v1 API, which has been optimized for fanout 
performance


*Discontinued Register API*

	

*Decommissioned SDK*

	

*New alternative*

*GCM register API*

	

Google Cloud Messaging(GCM) SDKs (deprecated in 2018).

	

Latest FCM Android SDK.

*Legacy Web register API*

	

FCM JS SDK version<7.0.0 (deprecated in 2019)

	

Latest FCM JS SDK.

*Instance ID Server API for Web*

	

No SDK related to this API.

	

Latest FCM JS SDK.


*Discontinued Feature*

	

*Decommissioned service*

	

*New alternative*

*Server keys*

	

Authenticating requests with server keys.

	

Authenticate requests with access tokens generated from authorized 
service accounts 
<https://notifications.google.com/g/p/ACUgQrE8LxWKrfZvL3R5hoSruQL4An9Vg5kFcDYASULp7A5SyUubGdXnXerewny9Rr8OJNp2fTgybuON0zkL4u2XSRmhn29NBmTFNdbm9q-OXyYQVSFt_ax2KxIYXCYbGR1bTLMqPLoLzMpdTgcuyd6wKJCIJj7ToMCrVJzWqOxbg6QUof0_-BUGyGhtnimrCtd-gb5en_iFRjq5OwpVDzqJex2vhuqgrVoeBvAkg344MePoYgqRrkoO113zUXz9flSPIyevZT6KZ4E>

*iOS Direct Channel*

	

Sending messages via FCM?s direct channel to iOS devices while they are 
running in the foreground.

	

All iOS messages will be sent via APNS channel.


What do you need to do?

Take the following actions before *June 20, 2024*, to ensure that you 
have access to the latest supported features and to reduce the risk of 
future decommissions affecting your usage:

  * *Follow the instructions described in *Firebase FAQ
    <https://notifications.google.com/g/p/ACUgQrF1q42xLDBDWvEr5RHaOfbnfKhv0UdWXB6Vy1kLOjasVBtYD0Wjp4aQJlSaeYnw695zGgel_4mXfwd5JHyH3hmINX1yjPPMSUIxlWcV8-8Af9jmWTRzELbajU3hoHr3k5e8X4QnZaoBBqlKW9ZwgPvaX0SEG_Q761kFR-vQisPxahLO6tzNfIkO3wdWa9b6XDKynfH7tcuSSS5YX3B-wdvH6XeRsMo-Tw>
    to migrate your individual APIs.
  * *Update to the latest versions of Firebase SDKs*.

*Platform*

	

*Recommended FCM SDK version*

Android

	

 >= 23.1.2

iOS

	

 >= 10.10.0

Web (Javascript)

	

 >= 9.22.1

Your Firebase project(s) that use Firebase Cloud Messaging APIs are 
listed below:

  * MyOvmsServer (1043773844049)
    <https://notifications.google.com/g/p/ACUgQrEotRQKxV6LgEoXckEV9bLkUuhj9b1dUEtZwXeBD6i1JG2SipBCU3_-A46djD3KV4k7XrIbasB60E_K8d6_dHHvHD-_2cnyBUix-DEEIJkWkzw6-xrvJDz64B0VJ3FWbNJ4UorZX4uwFpCyKCfCDYM4lMYSuHF4e8JO88lnZyTC_Qa4wW0Kr4YdCa4W7_3w_rq9_-KINgSiodkUhsW7TvTYl1M>

      o /Your recent usage of impacted APIs/features: Server Keys/
      o /Your recent usage of impacted APIs/features: Legacy HTTP protocol/

We?re here to help

If you have any questions, please review the Firebase FAQs 
<https://notifications.google.com/g/p/ACUgQrF1q42xLDBDWvEr5RHaOfbnfKhv0UdWXB6Vy1kLOjasVBtYD0Wjp4aQJlSaeYnw695zGgel_4mXfwd5JHyH3hmINX1yjPPMSUIxlWcV8-8Af9jmWTRzELbajU3hoHr3k5e8X4QnZaoBBqlKW9ZwgPvaX0SEG_Q761kFR-vQisPxahLO6tzNfIkO3wdWa9b6XDKynfH7tcuSSS5YX3B-wdvH6XeRsMo-Tw>.

Thanks,
Todd on behalf of the Firebase team

*Was this information helpful?*

Yes 
<https://notifications.google.com/g/p/ACUgQrG_D9izaxqaPAZL66peR0D-yHGGWiULfqLYNXkYVDs80RnpgeXgBN9m4ZnaHzuqsYlOfmgjFoUOsubDA7WspKOx5stGqGz--VfYcwvRfcyYu8wpw3AGMncVzPV7JAmFxyvmWXSFwq2XGOMXnFc1YZFt5J95Sz9hEaOrLOKX4og8ftEzmGUD6Zmv-OofJZ4g6roE8QdQ4L9DIP_mFpopj6y27eSinWXQTZoUBHhCVQ5hGICPSorDMyXpqbhKCdouUctpgfshicsSM_S8LReB3sRCqkl0PQ6RkgRnaBHi4y82il1Hcp4jv1NiDVxrF1w5kg> 
Neutral 
<https://notifications.google.com/g/p/ACUgQrFnFdXuJ_VF6ChjiUeTeV5elzVrPymaFMqIFMkzFQvDJk1H8Vs9uUUt76f7Xe2hDm2I35eLjYIdq613WGZApFeuZuv4m4_Iubc9fhSe1sG_m67t1b1CFvQaomK_klAYbLBQIHzrxKtOAlmJfr8L8yO2ILSG0RJkj0CqDnrR4UsTtw8LGENRKq7cnyhBaQr7HrQVfvk1LYOYUbJLvrsp-_g3wvDF-VUQbIkwnDoZNG9AAg8mZIze5vUr32smAfDHfLE_2jZ1HpU4d9XVZ8S7Aph1sX6Nh9J9frhzn9tWZ1MKhVXbRbcCocQK8dD47hUA6OWi6R8> 
No 
<https://notifications.google.com/g/p/ACUgQrFb7NDlSkpL4nuGR0g71bgiRuj39SdywVWgFU-V2bmH2sTpWfqP5wOUFG7s8ac6UZHkK2C1YI9ygFwG8W0f4biaJ7NHCvbBCBVpx4qEZWIUe4vPCvT_AtResGaRUZdjcQwchak5V7wjkbCkPSrBwL4_YEg6Clr5tnpkrDQhvxN1uaC2lSKxqNCUYucmV2C-JjRFwjJYG_veUreyuWkV-KiruZVSp7iwhaPvvY2s-mAe9MdTZAwfjeWu6fWjTijb6sMrzS_3z7unUgJg0yFm6lBNaPBINYLBQObetHggsrv5dd2elYGrpoEyQPLuxbU8> 


You have received this mandatory service announcement to update you 
about important changes to Firebase or your account.
	? 2023 Google LLC
1600 Amphitheatre Parkway
Mountain View, CA 94043 USA <#>


-- 
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/20230621/2fc63bae/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230621/2fc63bae/attachment-0001.sig>

From leres at xse.com  Thu Jun 22 10:58:57 2023
From: leres at xse.com (Craig Leres)
Date: Wed, 21 Jun 2023 19:58:57 -0700
Subject: [Ovmsdev] Attempting to ssh in too soon after a reboot causes an
 abort() from esp_sha_read_digest_state()
In-Reply-To: <0e4e391c-c249-4b67-dac3-3ae81ec2e840@xse.com>
References: <89073fa0-bcb3-a685-bb82-9b01fb006a37@lange.nom.fr>
 <0e4e391c-c249-4b67-dac3-3ae81ec2e840@xse.com>
Message-ID: <111d422a-d83a-35d1-b924-cecc33fc2e77@xse.com>

I updated to 3.3.003-518-gb6c10a59 today and noticed if I'm too 
impatient trying to ssh into the module after rebooting, it crashes. I 
suspect this will be easy to reproduce.

		Craig

===============================================================

OVMS# boot
Last boot was 501 second(s) ago
Time at boot: 2023-06-21 19:49:18 PDT
   This is reset #8 since last power cycle
   Detected boot reason: EarlyCrash (12/12)
   Reset reason: Exception/panic (4)
   Crash counters: 1 total, 1 early

Last crash: abort() was called on core 1
   Current task on core 0: IDLE0, 524 stack bytes free
   Current task on core 1: OVMS NetMan, 1208 stack bytes free
   Backtrace:
   0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 0x40240287 
0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 
0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389
   Version: 3.3.003-518-gb6c10a59-dirty/ota_1/main (build idf 
v3.3.4-849-g6e214dc33 Jun 20 2023 21:30:05)

   Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM SIM7600

===============================================================

ice 104 % git describe
3.3.003-518-gb6c10a59
ice 105 % cat backtrace.sh
#!/bin/sh
PATH=/usr/local/xtensa-esp32-elf/bin:${PATH}
export PATH
cd ${HOME}/src/OVMS.V3 || exit 1
dn=`/bin/pwd`
(set -x ; xtensa-esp32-elf-addr2line -e build/ovms3.elf $*) | sed -e 
s,^${dn}/,,
ice 106 % !./
./backtrace.sh 0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 
0x40240287 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 
0x4012d89d 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389
+ xtensa-esp32-elf-addr2line -e build/ovms3.elf 0x400891b7 0x40089451 
0x40268a11 0x40244aea 0x4023e892 0x40240287 0x4024f6bb 0x40240556 
0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 0x4012ddc3 0x4012a2aa 
0x4011e2eb 0x4011e389
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/hwcrypto/sha.c:272
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/port/esp_sha256.c:349
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_cli.c:3894
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
components/mongoose/mongoose/mongoose.c:1701
components/mongoose/mongoose/mongoose.c:1701
components/mongoose/mongoose/mongoose.c:1701
components/mongoose/mongoose/mongoose.c:1701
components/mongoose/mongoose/mongoose.c:1701
main/ovms_netmanager.cpp:1198
main/ovms_netmanager.cpp:1198


From solterra at kezarnet.com  Thu Jun 22 20:07:17 2023
From: solterra at kezarnet.com (Solterra)
Date: Thu, 22 Jun 2023 08:07:17 -0400
Subject: [Ovmsdev] CAN message throughput
Message-ID: <cb82b6b7f6e5781df6e70bf589057c5c@kezarnet.com>

Do we have an idea what the polling throughput is?

I haven't really dug into the poller code yet, but I suspect I might be 
overloading the poller. Responses aren't coming in when I expect them.

Is there any notification when a Ticker takes more than one second?

Is it possible for a ticker to be missed. For example, if ticker#9 takes 
more than one second, does it move on to ticker #11, possibly skipping 
ticker#10?

Thank you


From frog at bunyip.wheelycreek.net  Thu Jun 22 21:26:24 2023
From: frog at bunyip.wheelycreek.net (Michael Geddes)
Date: Thu, 22 Jun 2023 21:26:24 +0800
Subject: [Ovmsdev] CAN message throughput
In-Reply-To: <cb82b6b7f6e5781df6e70bf589057c5c@kezarnet.com>
References: <cb82b6b7f6e5781df6e70bf589057c5c@kezarnet.com>
Message-ID: <CAH0p7uK4QWLYaGNUZoF5=EjCbuDZjgM=dQ0Sr9f1tSw0JxAQxA@mail.gmail.com>

There's a setting for the maximum number of poll entries per second.

The 'poll tick' doesn't miss any entries. It progresses when each run is
finished...  I don't believe there's a notification if it takes more than a
second.

Michael

On Thu, 22 June 2023, 8:07 pm Solterra, <solterra at kezarnet.com> wrote:

> Do we have an idea what the polling throughput is?
>
> I haven't really dug into the poller code yet, but I suspect I might be
> overloading the poller. Responses aren't coming in when I expect them.
>
> Is there any notification when a Ticker takes more than one second?
>
> Is it possible for a ticker to be missed. For example, if ticker#9 takes
> more than one second, does it move on to ticker #11, possibly skipping
> ticker#10?
>
> Thank you
>
> _______________________________________________
> 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/20230622/d89834b8/attachment.htm>

From leres at xse.com  Fri Jun 23 11:50:32 2023
From: leres at xse.com (Craig Leres)
Date: Thu, 22 Jun 2023 20:50:32 -0700
Subject: [Ovmsdev] Attempting to ssh in too soon after a reboot causes an
 abort() from esp_sha_read_digest_state()
In-Reply-To: <0e4e391c-c249-4b67-dac3-3ae81ec2e840@xse.com>
References: <89073fa0-bcb3-a685-bb82-9b01fb006a37@lange.nom.fr>
 <0e4e391c-c249-4b67-dac3-3ae81ec2e840@xse.com>
Message-ID: <2073f058-4eae-63a4-01ae-2c4623a9e29b@xse.com>

[second attempt, my first message never propagated...]

I updated to 3.3.003-518-gb6c10a59 today and noticed if I'm too 
impatient trying to ssh into the module after rebooting, it crashes. I 
suspect this will be easy to reproduce.

		Craig

===============================================================

OVMS# boot
Last boot was 501 second(s) ago
Time at boot: 2023-06-21 19:49:18 PDT
   This is reset #8 since last power cycle
   Detected boot reason: EarlyCrash (12/12)
   Reset reason: Exception/panic (4)
   Crash counters: 1 total, 1 early

Last crash: abort() was called on core 1
   Current task on core 0: IDLE0, 524 stack bytes free
   Current task on core 1: OVMS NetMan, 1208 stack bytes free
   Backtrace:
   0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 0x40240287 
0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 
0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389
   Version: 3.3.003-518-gb6c10a59-dirty/ota_1/main (build idf 
v3.3.4-849-g6e214dc33 Jun 20 2023 21:30:05)

   Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM SIM7600

===============================================================

ice 104 % git describe
3.3.003-518-gb6c10a59
ice 105 % cat backtrace.sh
#!/bin/sh
PATH=/usr/local/xtensa-esp32-elf/bin:${PATH}
export PATH
cd ${HOME}/src/OVMS.V3 || exit 1
dn=`/bin/pwd`
(set -x ; xtensa-esp32-elf-addr2line -e build/ovms3.elf $*) | sed -e 
s,^${dn}/,,
ice 106 % !./
./backtrace.sh 0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 
0x40240287 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 
0x4012d89d 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389
+ xtensa-esp32-elf-addr2line -e build/ovms3.elf 0x400891b7 0x40089451 
0x40268a11 0x40244aea 0x4023e892 0x40240287 0x4024f6bb 0x40240556 
0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 0x4012ddc3 0x4012a2aa 
0x4011e2eb 0x4011e389
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/hwcrypto/sha.c:272
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/port/esp_sha256.c:349
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_cli.c:3894
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
components/mongoose/mongoose/mongoose.c:1701
components/mongoose/mongoose/mongoose.c:1701
components/mongoose/mongoose/mongoose.c:1701
components/mongoose/mongoose/mongoose.c:1701
components/mongoose/mongoose/mongoose.c:1701
main/ovms_netmanager.cpp:1198
main/ovms_netmanager.cpp:1198


From jerome at ceriz.fr  Fri Jun 23 18:36:40 2023
From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=)
Date: Fri, 23 Jun 2023 12:36:40 +0200
Subject: [Ovmsdev] Looking for a twizy battery rebuild
Message-ID: <727dacc4-8dba-6ba4-f8ed-e0df2497fdf1@ceriz.fr>

Hi !

I hope it's OK to post this here. Sorry for the inconvenience if it is not.

I'm looking for updated informations regarding modified batteries for 
the Twizy. Mine is down to about 4.5kWh (fully owned) after 8 years in 
service.

What capacity could we reasonably reach with newer cells ?

With plumetting prices for the cells, would there be anyone (preferably 
close to France) from whom I could buy all the required modules 
(including Twizy Virtual BMS), ready to fit in the battery case, or with 
a new case ?

Thanks !

-- 
J?r?me Nicolle
+33 6 19 31 27 14

From dexter at expeedo.de  Sat Jun 24 16:33:40 2023
From: dexter at expeedo.de (Michael Balzer)
Date: Sat, 24 Jun 2023 10:33:40 +0200
Subject: [Ovmsdev] Looking for a twizy battery rebuild
In-Reply-To: <727dacc4-8dba-6ba4-f8ed-e0df2497fdf1@ceriz.fr>
References: <727dacc4-8dba-6ba4-f8ed-e0df2497fdf1@ceriz.fr>
Message-ID: <9473e490-f3b9-a3be-dbfc-3cf192b4e605@expeedo.de>

J?r?me,

I've lost track of all the Twizy battery projects that have been or are 
currently done. After I sold my Twizy two years ago, quite a lot has 
happened.

Some of the new batteries were based on the edriver BMS, but as Pascal 
no longer maintains that project, most current projects are based on my 
VirtualBMS solution (https://github.com/dexterbg/Twizy-Virtual-BMS) in 
combination with some standard China BMS.

There are also quite some that simply replace the cells and keep using 
the original BMS. That has some downsides but basically works.

Capacity of custom batteries normally is around 10 kWh, that easily fits 
in the original battery box, but you can go higher with the right cells.

The most used Twizy replacement battery is probably the CATL powerblock: 
https://www.power-and-storage.de/shop/CATL-PowerBlock-14S-48-10-48V-10-kWh-p464606239

You really should check out the german Twizy forum for all the battery 
projects: https://www.twizy-forum.de/Alternativ-Akku

And you should get in contact with Martin ("Snorre") and Christian 
("TwizyChrisy") on the forum. Martin was one of the first to rework his 
battery and is up to date with all current projects. Chris owns a lot 
(like: a lot) of Twizys and is continously working on projects.

Chris has also published some videos on his CATL rework: 
https://www.youtube.com/@TwizyChrisy/search?query=akku

Probably these guys can also help you with buying the components needed.

Regards,
Michael


Am 23.06.23 um 12:36 schrieb J?r?me Nicolle:
> Hi !
>
> I hope it's OK to post this here. Sorry for the inconvenience if it is 
> not.
>
> I'm looking for updated informations regarding modified batteries for 
> the Twizy. Mine is down to about 4.5kWh (fully owned) after 8 years in 
> service.
>
> What capacity could we reasonably reach with newer cells ?
>
> With plumetting prices for the cells, would there be anyone 
> (preferably close to France) from whom I could buy all the required 
> modules (including Twizy Virtual BMS), ready to fit in the battery 
> case, or with a new case ?
>
> Thanks !
>

-- 
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
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230624/9911724b/attachment.sig>

From solterra at kezarnet.com  Sun Jun 25 00:25:08 2023
From: solterra at kezarnet.com (Solterra)
Date: Sat, 24 Jun 2023 12:25:08 -0400
Subject: [Ovmsdev] CAN message throughput
In-Reply-To: <CAH0p7uK4QWLYaGNUZoF5=EjCbuDZjgM=dQ0Sr9f1tSw0JxAQxA@mail.gmail.com>
References: <cb82b6b7f6e5781df6e70bf589057c5c@kezarnet.com>
 <CAH0p7uK4QWLYaGNUZoF5=EjCbuDZjgM=dQ0Sr9f1tSw0JxAQxA@mail.gmail.com>
Message-ID: <792240b79b174dace6f0b3bf7fc33752@kezarnet.com>



Thanks for the help.

My confusion was caused by the delay from a delay from a broadcast poll.

m_poll_moduleid_sent != 0x7df

Once I pivoted away from broadcast request, things worked as I expected.

On 2023-06-22 09:26, Michael Geddes wrote:

> There's a setting for the maximum number of poll entries per second.
> 
> The 'poll tick' doesn't miss any entries. It progresses when each run 
> is finished...  I don't believe there's a notification if it takes more 
> than a second.
> 
> Michael
> 
> On Thu, 22 June 2023, 8:07 pm Solterra, <solterra at kezarnet.com> wrote:
> 
>> Do we have an idea what the polling throughput is?
>> 
>> I haven't really dug into the poller code yet, but I suspect I might 
>> be
>> overloading the poller. Responses aren't coming in when I expect them.
>> 
>> Is there any notification when a Ticker takes more than one second?
>> 
>> Is it possible for a ticker to be missed. For example, if ticker#9 
>> takes
>> more than one second, does it move on to ticker #11, possibly skipping
>> ticker#10?
>> 
>> Thank you
>> 
>> _______________________________________________
>> 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/20230624/9bac66da/attachment.htm>

From leres at xse.com  Mon Jun 26 01:24:23 2023
From: leres at xse.com (Craig Leres)
Date: Sun, 25 Jun 2023 10:24:23 -0700
Subject: [Ovmsdev] Attempting to ssh in too soon after a reboot causes an
 abort() from esp_sha_read_digest_state()
In-Reply-To: <0e4e391c-c249-4b67-dac3-3ae81ec2e840@xse.com>
References: <89073fa0-bcb3-a685-bb82-9b01fb006a37@lange.nom.fr>
 <0e4e391c-c249-4b67-dac3-3ae81ec2e840@xse.com>
Message-ID: <73631994-ccd0-608a-e596-9868525ba021@xse.com>

[third attempt, apparently my opendkim sendmail milter was borked and 
needed to be restarted...]

I updated to 3.3.003-518-gb6c10a59 a few days ago and noticed if I'm too 
impatient trying to ssh into the module after rebooting, it crashes. I 
suspect this is easy to reproduce.

		Craig

===============================================================

OVMS# boot
Last boot was 501 second(s) ago
Time at boot: 2023-06-21 19:49:18 PDT
   This is reset #8 since last power cycle
   Detected boot reason: EarlyCrash (12/12)
   Reset reason: Exception/panic (4)
   Crash counters: 1 total, 1 early

Last crash: abort() was called on core 1
   Current task on core 0: IDLE0, 524 stack bytes free
   Current task on core 1: OVMS NetMan, 1208 stack bytes free
   Backtrace:
   0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 0x40240287 
0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 
0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389
   Version: 3.3.003-518-gb6c10a59-dirty/ota_1/main (build idf 
v3.3.4-849-g6e214dc33 Jun 20 2023 21:30:05)

   Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM SIM7600

===============================================================

ice 104 % git describe
3.3.003-518-gb6c10a59
ice 105 % cat backtrace.sh
#!/bin/sh
PATH=/usr/local/xtensa-esp32-elf/bin:${PATH}
export PATH
cd ${HOME}/src/OVMS.V3 || exit 1
dn=`/bin/pwd`
(set -x ; xtensa-esp32-elf-addr2line -e build/ovms3.elf $*) | sed -e 
s,^${dn}/,,
ice 106 % !./
./backtrace.sh 0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 
0x40240287 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 
0x4012d89d 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389
+ xtensa-esp32-elf-addr2line -e build/ovms3.elf 0x400891b7 0x40089451 
0x40268a11 0x40244aea 0x4023e892 0x40240287 0x4024f6bb 0x40240556 
0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 0x4012ddc3 0x4012a2aa 
0x4011e2eb 0x4011e389
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/hwcrypto/sha.c:272
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/port/esp_sha256.c:349
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_cli.c:3894
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
components/mongoose/mongoose/mongoose.c:1701
components/mongoose/mongoose/mongoose.c:1701
components/mongoose/mongoose/mongoose.c:1701
components/mongoose/mongoose/mongoose.c:1701
components/mongoose/mongoose/mongoose.c:1701
main/ovms_netmanager.cpp:1198
main/ovms_netmanager.cpp:1198


From ll-ovmsdev at lange.nom.fr  Mon Jun 26 04:07:06 2023
From: ll-ovmsdev at lange.nom.fr (Ludovic LANGE)
Date: Sun, 25 Jun 2023 22:07:06 +0200
Subject: [Ovmsdev] Attempting to ssh in too soon after a reboot causes
 an abort() from esp_sha_read_digest_state()
In-Reply-To: <73631994-ccd0-608a-e596-9868525ba021@xse.com>
References: <89073fa0-bcb3-a685-bb82-9b01fb006a37@lange.nom.fr>
 <0e4e391c-c249-4b67-dac3-3ae81ec2e840@xse.com>
 <73631994-ccd0-608a-e596-9868525ba021@xse.com>
Message-ID: <9a093f31-cd1e-c617-578d-c7f550c8e1c3@lange.nom.fr>

Hi Craig,

FYI I've received the 3 attempts on the list without any issue... :-)

Le 25/06/2023 ? 19:24, Craig Leres a ?crit?:
> [third attempt, apparently my opendkim sendmail milter was borked and 
> needed to be restarted...]
>
> I updated to 3.3.003-518-gb6c10a59 a few days ago and noticed if I'm 
> too impatient trying to ssh into the module after rebooting, it 
> crashes. I suspect this is easy to reproduce.
>
> ??????? Craig
>
> ===============================================================
>
> OVMS# boot
> Last boot was 501 second(s) ago
> Time at boot: 2023-06-21 19:49:18 PDT
> ? This is reset #8 since last power cycle
> ? Detected boot reason: EarlyCrash (12/12)
> ? Reset reason: Exception/panic (4)
> ? Crash counters: 1 total, 1 early
>
> Last crash: abort() was called on core 1
> ? Current task on core 0: IDLE0, 524 stack bytes free
> ? Current task on core 1: OVMS NetMan, 1208 stack bytes free
> ? Backtrace:
> ? 0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 0x40240287 
> 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 
> 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389
> ? Version: 3.3.003-518-gb6c10a59-dirty/ota_1/main (build idf 
> v3.3.4-849-g6e214dc33 Jun 20 2023 21:30:05)
>
> ? Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM SIM7600
>
> ===============================================================
>
> ice 104 % git describe
> 3.3.003-518-gb6c10a59
> ice 105 % cat backtrace.sh
> #!/bin/sh
> PATH=/usr/local/xtensa-esp32-elf/bin:${PATH}
> export PATH
> cd ${HOME}/src/OVMS.V3 || exit 1
> dn=`/bin/pwd`
> (set -x ; xtensa-esp32-elf-addr2line -e build/ovms3.elf $*) | sed -e 
> s,^${dn}/,,
> ice 106 % !./
> ./backtrace.sh 0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 
> 0x40240287 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 
> 0x4012d89d 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389
> + xtensa-esp32-elf-addr2line -e build/ovms3.elf 0x400891b7 0x40089451 
> 0x40268a11 0x40244aea 0x4023e892 0x40240287 0x4024f6bb 0x40240556 
> 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 0x4012ddc3 0x4012a2aa 
> 0x4011e2eb 0x4011e389
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736 
>
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736 
>
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/hwcrypto/sha.c:272 
>
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/port/esp_sha256.c:349 
>
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 
>
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 
>
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_cli.c:3894 
>
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 
>
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 
>
> components/mongoose/mongoose/mongoose.c:1701
> components/mongoose/mongoose/mongoose.c:1701
> components/mongoose/mongoose/mongoose.c:1701
> components/mongoose/mongoose/mongoose.c:1701
> components/mongoose/mongoose/mongoose.c:1701
> main/ovms_netmanager.cpp:1198
> main/ovms_netmanager.cpp:1198
>
> _______________________________________________
> 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/20230625/53bf557a/attachment.htm>

From mark at webb-johnson.net  Mon Jun 26 09:02:16 2023
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Mon, 26 Jun 2023 09:02:16 +0800
Subject: [Ovmsdev] Attempting to ssh in too soon after a reboot causes
 an abort() from esp_sha_read_digest_state()
In-Reply-To: <73631994-ccd0-608a-e596-9868525ba021@xse.com>
References: <89073fa0-bcb3-a685-bb82-9b01fb006a37@lange.nom.fr>
 <0e4e391c-c249-4b67-dac3-3ae81ec2e840@xse.com>
 <73631994-ccd0-608a-e596-9868525ba021@xse.com>
Message-ID: <EAB7A68F-013E-4D17-98F4-A41F413A9FBE@webb-johnson.net>

Craig,

I tried to repeat this, without success.

Your backtrace seems to implicate sha256 hashing, in the ssl_tls call chain, but that doesn?t make much sense for ssh. Maybe memory corruption? Is anything else using ssl in your config?

Regards, Mark.

> On 26 Jun 2023, at 1:24 AM, Craig Leres <leres at xse.com> wrote:
> 
> [third attempt, apparently my opendkim sendmail milter was borked and needed to be restarted...]
> 
> I updated to 3.3.003-518-gb6c10a59 a few days ago and noticed if I'm too impatient trying to ssh into the module after rebooting, it crashes. I suspect this is easy to reproduce.
> 
> 		Craig
> 
> ===============================================================
> 
> OVMS# boot
> Last boot was 501 second(s) ago
> Time at boot: 2023-06-21 19:49:18 PDT
>  This is reset #8 since last power cycle
>  Detected boot reason: EarlyCrash (12/12)
>  Reset reason: Exception/panic (4)
>  Crash counters: 1 total, 1 early
> 
> Last crash: abort() was called on core 1
>  Current task on core 0: IDLE0, 524 stack bytes free
>  Current task on core 1: OVMS NetMan, 1208 stack bytes free
>  Backtrace:
>  0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 0x40240287 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389
>  Version: 3.3.003-518-gb6c10a59-dirty/ota_1/main (build idf v3.3.4-849-g6e214dc33 Jun 20 2023 21:30:05)
> 
>  Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM SIM7600
> 
> ===============================================================
> 
> ice 104 % git describe
> 3.3.003-518-gb6c10a59
> ice 105 % cat backtrace.sh
> #!/bin/sh
> PATH=/usr/local/xtensa-esp32-elf/bin:${PATH}
> export PATH
> cd ${HOME}/src/OVMS.V3 || exit 1
> dn=`/bin/pwd`
> (set -x ; xtensa-esp32-elf-addr2line -e build/ovms3.elf $*) | sed -e s,^${dn}/,,
> ice 106 % !./
> ./backtrace.sh 0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 0x40240287 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389
> + xtensa-esp32-elf-addr2line -e build/ovms3.elf 0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 0x40240287 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/hwcrypto/sha.c:272
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/port/esp_sha256.c:349
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_cli.c:3894
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
> components/mongoose/mongoose/mongoose.c:1701
> components/mongoose/mongoose/mongoose.c:1701
> components/mongoose/mongoose/mongoose.c:1701
> components/mongoose/mongoose/mongoose.c:1701
> components/mongoose/mongoose/mongoose.c:1701
> main/ovms_netmanager.cpp:1198
> main/ovms_netmanager.cpp:1198
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev


From mark at webb-johnson.net  Mon Jun 26 09:02:16 2023
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Mon, 26 Jun 2023 09:02:16 +0800
Subject: [Ovmsdev] Attempting to ssh in too soon after a reboot causes
 an abort() from esp_sha_read_digest_state()
In-Reply-To: <73631994-ccd0-608a-e596-9868525ba021@xse.com>
References: <89073fa0-bcb3-a685-bb82-9b01fb006a37@lange.nom.fr>
 <0e4e391c-c249-4b67-dac3-3ae81ec2e840@xse.com>
 <73631994-ccd0-608a-e596-9868525ba021@xse.com>
Message-ID: <EAB7A68F-013E-4D17-98F4-A41F413A9FBE@webb-johnson.net>

Craig,

I tried to repeat this, without success.

Your backtrace seems to implicate sha256 hashing, in the ssl_tls call chain, but that doesn?t make much sense for ssh. Maybe memory corruption? Is anything else using ssl in your config?

Regards, Mark.

> On 26 Jun 2023, at 1:24 AM, Craig Leres <leres at xse.com> wrote:
> 
> [third attempt, apparently my opendkim sendmail milter was borked and needed to be restarted...]
> 
> I updated to 3.3.003-518-gb6c10a59 a few days ago and noticed if I'm too impatient trying to ssh into the module after rebooting, it crashes. I suspect this is easy to reproduce.
> 
> 		Craig
> 
> ===============================================================
> 
> OVMS# boot
> Last boot was 501 second(s) ago
> Time at boot: 2023-06-21 19:49:18 PDT
>  This is reset #8 since last power cycle
>  Detected boot reason: EarlyCrash (12/12)
>  Reset reason: Exception/panic (4)
>  Crash counters: 1 total, 1 early
> 
> Last crash: abort() was called on core 1
>  Current task on core 0: IDLE0, 524 stack bytes free
>  Current task on core 1: OVMS NetMan, 1208 stack bytes free
>  Backtrace:
>  0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 0x40240287 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389
>  Version: 3.3.003-518-gb6c10a59-dirty/ota_1/main (build idf v3.3.4-849-g6e214dc33 Jun 20 2023 21:30:05)
> 
>  Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM SIM7600
> 
> ===============================================================
> 
> ice 104 % git describe
> 3.3.003-518-gb6c10a59
> ice 105 % cat backtrace.sh
> #!/bin/sh
> PATH=/usr/local/xtensa-esp32-elf/bin:${PATH}
> export PATH
> cd ${HOME}/src/OVMS.V3 || exit 1
> dn=`/bin/pwd`
> (set -x ; xtensa-esp32-elf-addr2line -e build/ovms3.elf $*) | sed -e s,^${dn}/,,
> ice 106 % !./
> ./backtrace.sh 0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 0x40240287 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389
> + xtensa-esp32-elf-addr2line -e build/ovms3.elf 0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 0x40240287 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/hwcrypto/sha.c:272
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/port/esp_sha256.c:349
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_cli.c:3894
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
> /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
> components/mongoose/mongoose/mongoose.c:1701
> components/mongoose/mongoose/mongoose.c:1701
> components/mongoose/mongoose/mongoose.c:1701
> components/mongoose/mongoose/mongoose.c:1701
> components/mongoose/mongoose/mongoose.c:1701
> main/ovms_netmanager.cpp:1198
> main/ovms_netmanager.cpp:1198
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev


From mark at webb-johnson.net  Thu Jun 29 12:17:42 2023
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Thu, 29 Jun 2023 12:17:42 +0800
Subject: [Ovmsdev] [Action Required] Update your apps to the latest
 Firebase Cloud Messaging APIs and SDKs
In-Reply-To: <410862c2-2d8c-d746-8154-b2911dd47d4d@expeedo.de>
References: <03f21bfd162f1a23a37e5c020647bc37166570ed-20264762-111332550@google.com>
 <410862c2-2d8c-d746-8154-b2911dd47d4d@expeedo.de>
Message-ID: <D9CB214B-7730-465D-9312-CDC90D5AAE54@webb-johnson.net>

Oh, google. They do love to deprecate?

I can handle the server side. But not sure what needs to be done there. Presumably this like the C2DM -> GCM migration we did a while ago (using a new agreed token type apns/c2dm/gcm/etc, if the new approache is not backwards compatible). The current server seems to call:

https://fcm.googleapis.com/fcm/send

Regards, Mark.

> On 21 Jun 2023, at 7:25 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> Signed PGP part
> Time for another Google API deprecation.
> 
> It seems we'll need to update the Android App & possibly the server now to the FCM API for push notifications, the old GCM API will stop working in June 2024.
> 
> Anyone volunteering to take care of this?
> 
> Regards,
> Michael
> 
> 
> -------- Weitergeleitete Nachricht --------
> Betreff:	[Action Required] Update your apps to the latest Firebase Cloud Messaging APIs and SDKs
> Datum: 	Tue, 20 Jun 2023 13:26:22 -0700
> Von: 	Firebase <firebase-noreply at google.com> <mailto:firebase-noreply at google.com>
> Antwort an: 	Firebase <firebase-noreply at google.com> <mailto:firebase-noreply at google.com>
> An: 	dexter at expeedo.de <mailto:dexter at expeedo.de>
> 
>  <https://notifications.google.com/g/p/ACUgQrEqj5I8-oiq75nsyLmVgMI_2P_O30pr9ZcpVmk-O8L3G7S5GLuDAQBGbLzVLag80DcGOGlPohe0LlxV3Am7cZNv3WRo1rwY30WWKavJb9NJTk1FmXuKrvFZt8XgZ17HnYFO11bDbl7kSR_82CXEwuwTZU4-udfbmAeK7zzJ3qZft1R_jSAmBvOt677OdR1wfx-Q>
> Hi Michael <>,
> We?re writing to let you know that starting June 20, 2024 the legacy Firebase Cloud Messaging (FCM) APIs will be discontinued.
> 
> What do you need to know?
> On June 20, 2024, we?re reducing the number of Firebase Cloud Messaging (FCM) legacy register APIs and legacy send APIs that provide similar functionality. This step will allow us to provide you with a more consistent experience and align with Google security standards to improve security, reliability and performance.
> 
> Because of these API decommissions, some already-deprecated SDKs and features will stop working after June 20, 2024.
> 
> Please consult the tables below to find which Firebase Cloud Messaging (FCM) APIs and corresponding services/SDKs/features will be discontinued and replaced with new alternatives.
> 
> Discontinued Send API
> 
> Decommissioned service
> 
> New alternative
> 
> Legacy HTTP Protocol
> 
> Sending messages via the Legacy HTTP API.
> 
> Send messages via the HTTP v1 API.
> 
> XMPP Protocol
> 
> Sending upstream and downstream messages via the XMPP API.
> 
> Send downstream messages via the HTTP v1 API.
> 
> Send upstream messages via HTTP/gRPC <https://notifications.google.com/g/p/ACUgQrFKp0BdXKuz3_mUi3W9wdl6DV3Ib_q0Hn9_rFkVCttPt1pfUS9zAavG0IHLz8EEex1Xah-SSAfcgb2zSplnVRd5kYFwn3MN31jskkUBf1w_RdTqd1tuSW3w6CKsMVdUC9bJHCVT9qvQXy4G6_8J5J-aT-4UFsRnmM4ASLagXT9eO188Q1gAxo7IH3vsHg-U55h8rnJ9zzRdh-DNTbMvJhXav_T7Bw> directly from the App to your server.
> 
> Batch send API
> 
> Including multiple send requests in a single HTTP request to FCM known as Batch Send.
> 
> Send messages via the HTTP v1 API, which has been optimized for fanout performance
> 
> 
> Discontinued Register API
> 
> Decommissioned SDK
> 
> New alternative
> 
> GCM register API
> 
> Google Cloud Messaging(GCM) SDKs (deprecated in 2018).
> 
> Latest FCM Android SDK.
> 
> Legacy Web register API
> 
> FCM JS SDK version<7.0.0 (deprecated in 2019)
> 
> Latest FCM JS SDK.
> 
> Instance ID Server API for Web
> 
> No SDK related to this API.
> 
> Latest FCM JS SDK.
> 
> 
> Discontinued Feature
> 
> Decommissioned service
> 
> New alternative
> 
> Server keys
> 
> Authenticating requests with server keys.
> 
> Authenticate requests with access tokens generated from authorized service accounts <https://notifications.google.com/g/p/ACUgQrE8LxWKrfZvL3R5hoSruQL4An9Vg5kFcDYASULp7A5SyUubGdXnXerewny9Rr8OJNp2fTgybuON0zkL4u2XSRmhn29NBmTFNdbm9q-OXyYQVSFt_ax2KxIYXCYbGR1bTLMqPLoLzMpdTgcuyd6wKJCIJj7ToMCrVJzWqOxbg6QUof0_-BUGyGhtnimrCtd-gb5en_iFRjq5OwpVDzqJex2vhuqgrVoeBvAkg344MePoYgqRrkoO113zUXz9flSPIyevZT6KZ4E>
> iOS Direct Channel
> 
> Sending messages via FCM?s direct channel to iOS devices while they are running in the foreground.
> 
> All iOS messages will be sent via APNS channel.
> 
> 
> What do you need to do?
> Take the following actions before June 20, 2024, to ensure that you have access to the latest supported features and to reduce the risk of future decommissions affecting your usage:
> 
> Follow the instructions described in Firebase FAQ <https://notifications.google.com/g/p/ACUgQrF1q42xLDBDWvEr5RHaOfbnfKhv0UdWXB6Vy1kLOjasVBtYD0Wjp4aQJlSaeYnw695zGgel_4mXfwd5JHyH3hmINX1yjPPMSUIxlWcV8-8Af9jmWTRzELbajU3hoHr3k5e8X4QnZaoBBqlKW9ZwgPvaX0SEG_Q761kFR-vQisPxahLO6tzNfIkO3wdWa9b6XDKynfH7tcuSSS5YX3B-wdvH6XeRsMo-Tw> to migrate your individual APIs.
> Update to the latest versions of Firebase SDKs.
> Platform
> 
> Recommended FCM SDK version
> 
> Android
> 
> >= 23.1.2
> 
> iOS
> 
> >= 10.10.0
> 
> Web (Javascript)
> 
> >= 9.22.1
> 
> Your Firebase project(s) that use Firebase Cloud Messaging APIs are listed below:
> 
> MyOvmsServer (1043773844049) <https://notifications.google.com/g/p/ACUgQrEotRQKxV6LgEoXckEV9bLkUuhj9b1dUEtZwXeBD6i1JG2SipBCU3_-A46djD3KV4k7XrIbasB60E_K8d6_dHHvHD-_2cnyBUix-DEEIJkWkzw6-xrvJDz64B0VJ3FWbNJ4UorZX4uwFpCyKCfCDYM4lMYSuHF4e8JO88lnZyTC_Qa4wW0Kr4YdCa4W7_3w_rq9_-KINgSiodkUhsW7TvTYl1M>
> Your recent usage of impacted APIs/features: Server Keys
> Your recent usage of impacted APIs/features: Legacy HTTP protocol
> We?re here to help
> If you have any questions, please review the Firebase FAQs <https://notifications.google.com/g/p/ACUgQrF1q42xLDBDWvEr5RHaOfbnfKhv0UdWXB6Vy1kLOjasVBtYD0Wjp4aQJlSaeYnw695zGgel_4mXfwd5JHyH3hmINX1yjPPMSUIxlWcV8-8Af9jmWTRzELbajU3hoHr3k5e8X4QnZaoBBqlKW9ZwgPvaX0SEG_Q761kFR-vQisPxahLO6tzNfIkO3wdWa9b6XDKynfH7tcuSSS5YX3B-wdvH6XeRsMo-Tw>.
> 
> Thanks,
> Todd on behalf of the Firebase team
> Was this information helpful?
> 
>  <https://notifications.google.com/g/p/ACUgQrG_D9izaxqaPAZL66peR0D-yHGGWiULfqLYNXkYVDs80RnpgeXgBN9m4ZnaHzuqsYlOfmgjFoUOsubDA7WspKOx5stGqGz--VfYcwvRfcyYu8wpw3AGMncVzPV7JAmFxyvmWXSFwq2XGOMXnFc1YZFt5J95Sz9hEaOrLOKX4og8ftEzmGUD6Zmv-OofJZ4g6roE8QdQ4L9DIP_mFpopj6y27eSinWXQTZoUBHhCVQ5hGICPSorDMyXpqbhKCdouUctpgfshicsSM_S8LReB3sRCqkl0PQ6RkgRnaBHi4y82il1Hcp4jv1NiDVxrF1w5kg>      <https://notifications.google.com/g/p/ACUgQrFnFdXuJ_VF6ChjiUeTeV5elzVrPymaFMqIFMkzFQvDJk1H8Vs9uUUt76f7Xe2hDm2I35eLjYIdq613WGZApFeuZuv4m4_Iubc9fhSe1sG_m67t1b1CFvQaomK_klAYbLBQIHzrxKtOAlmJfr8L8yO2ILSG0RJkj0CqDnrR4UsTtw8LGENRKq7cnyhBaQr7HrQVfvk1LYOYUbJLvrsp-_g3wvDF-VUQbIkwnDoZNG9AAg8mZIze5vUr32smAfDHfLE_2jZ1HpU4d9XVZ8S7Aph1sX6Nh9J9frhzn9tWZ1MKhVXbRbcCocQK8dD47hUA6OWi6R8>      <https://notifications.google.com/g/p/ACUgQrFb7NDlSkpL4nuGR0g71bgiRuj39SdywVWgFU-V2bmH2sTpWfqP5wOUFG7s8ac6UZHkK2C1YI9ygFwG8W0f4biaJ7NHCvbBCBVpx4qEZWIUe4vPCvT_AtResGaRUZdjcQwchak5V7wjkbCkPSrBwL4_YEg6Clr5tnpkrDQhvxN1uaC2lSKxqNCUYucmV2C-JjRFwjJYG_veUreyuWkV-KiruZVSp7iwhaPvvY2s-mAe9MdTZAwfjeWu6fWjTijb6sMrzS_3z7unUgJg0yFm6lBNaPBINYLBQObetHggsrv5dd2elYGrpoEyQPLuxbU8>You have received this mandatory service announcement to update you about important changes to Firebase or your account.
> 	? 2023 Google LLC
> 1600 Amphitheatre Parkway
> Mountain View, CA 94043 USA? <x-msg://206/#>
> --
> 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/20230629/63ba2132/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230629/63ba2132/attachment-0001.sig>