From didier at ernotte.com  Tue Oct  1 00:16:43 2024
From: didier at ernotte.com (didier at ernotte.com)
Date: Mon, 30 Sep 2024 16:16:43 +0000 (UTC)
Subject: [Ovmsdev] Access to a diagnostic session with private access
In-Reply-To: <2bd89258-e936-4043-b348-68464698a38e@xse.com>
References: <1059624650.13849918.1727556874007.ref@mail.yahoo.com>
 <1059624650.13849918.1727556874007@mail.yahoo.com>
 <c2d1dd0a-0891-431a-80ba-673aed406b34@expeedo.de>
 <2bd89258-e936-4043-b348-68464698a38e@xse.com>
Message-ID: <599427341.14385516.1727713003439@mail.yahoo.com>

 Thanks, with the "re obdii tester" command I was able to keep the private session alive and send my data to get the battery cell info hidden in a internal routine of the ECU.
Didier

    Le dimanche 29 septembre 2024 ? 14 h 02 min 49 s HAE, Craig Leres via OvmsDev <ovmsdev at lists.openvehicles.com> a ?crit :  
 
 On 9/29/24 00:50, Michael Balzer via OvmsDev wrote:
> you may need to send a periodic "tester present" signal after entering 
> the diagnostic session via "10 03".

Interesting. In J1850, secondary id 0x03 (state of health/node alive) 
is periodically sent by many modules.

??? ??? Craig
_______________________________________________
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/20240930/ff1ce0e0/attachment.htm>

From didier at ernotte.com  Tue Oct  1 00:21:59 2024
From: didier at ernotte.com (didier at ernotte.com)
Date: Mon, 30 Sep 2024 16:21:59 +0000 (UTC)
Subject: [Ovmsdev] Access to a diagnostic session with private access
In-Reply-To: <599427341.14385516.1727713003439@mail.yahoo.com>
References: <1059624650.13849918.1727556874007.ref@mail.yahoo.com>
 <1059624650.13849918.1727556874007@mail.yahoo.com>
 <c2d1dd0a-0891-431a-80ba-673aed406b34@expeedo.de>
 <2bd89258-e936-4043-b348-68464698a38e@xse.com>
 <599427341.14385516.1727713003439@mail.yahoo.com>
Message-ID: <239814344.3665884.1727713319223@mail.yahoo.com>

 In fact I found that if I am fast enough on the keyboard I can send the "10 03" and "27 03", without any problem, but if I am too slow, I have this "service not supported in active session" error. I guess the ECU put itself back in active mode instead of diag mode if no data is sent within a short timeframe.
Didier

    Le lundi 30 septembre 2024 ? 12 h 16 min 43 s HAE, didier at ernotte.com <didier at ernotte.com> a ?crit :  
 
  Thanks, with the "re obdii tester" command I was able to keep the private session alive and send my data to get the battery cell info hidden in a internal routine of the ECU.
Didier

    Le dimanche 29 septembre 2024 ? 14 h 02 min 49 s HAE, Craig Leres via OvmsDev <ovmsdev at lists.openvehicles.com> a ?crit :  
 
 On 9/29/24 00:50, Michael Balzer via OvmsDev wrote:
> you may need to send a periodic "tester present" signal after entering 
> the diagnostic session via "10 03".

Interesting. In J1850, secondary id 0x03 (state of health/node alive) 
is periodically sent by many modules.

??? ??? Craig
_______________________________________________
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/20240930/b03fbc20/attachment.htm>

From frog at bunyip.wheelycreek.net  Sun Oct  6 07:57:25 2024
From: frog at bunyip.wheelycreek.net (Michael Geddes)
Date: Sun, 6 Oct 2024 07:57:25 +0800
Subject: [Ovmsdev] Duktape Vehicle
In-Reply-To: <2050c27a-f0c1-47b8-8a94-debaa9e21eec@expeedo.de>
References: <CAH0p7uJA--zahURHJ0GoKrM4VPXj=Kbek+ZcD2GNHpczgaVx5g@mail.gmail.com>
 <2050c27a-f0c1-47b8-8a94-debaa9e21eec@expeedo.de>
Message-ID: <CAH0p7uLOkfVNvG+q6T5CUx8EmXSu5jwTdgHytYuL6c-TmzJmSA@mail.gmail.com>

Thanks Michael,
.
That's helped a lot in refocusing my approach

12v Aux Monitor:
-----------------------
I have been looking at the 12v Aux monitor code, in addition to
simplifying the monitor to use 2 smoothed averages (a shorter one and
a longer one), I've also looked at using my smoothing class at the
source of the battery voltage measurement (smoothing the source
integer value).

Interestingly, I notice that there are a couple of vehicle
implementations that are setting that value as well.. which I'm not
sure is a good thing!?

For the 12V monitor I have a version that I'm working on that tries to
match the  other 12V events and messages. It might be worth me just
submitting that as the p/r.

I have the following events:

vehicle.aux.12v.normal
vehicle.aux.12v.charging
vehicle.aux.12v.charging.dip
vehicle.aux.12v.charging.blip
vehicle.aux.12v.blip
vehicle.aux.12v.dip
vehicle.aux.12v.low
.
with these 'dip' is where the voltage has a bit of a trough, and
'blip' indicates there is a spike.

Extended DBC
-----------------------
I take your point about the speed, so I'm working on a better idea).

I have been going over the DBC stuff.. I've been implementing the
extended multiplexers (m98M), which is necessary _if_ the DBC file is
going to interpret the multi-frame reponses. I've also consolidated so
there is only one piece of code (now on the DBC Signal) interpreting
the Muxed data, which handles either going to metrics or to a writer.

Extended Multiplex example (with M,  m98M and m256) and the SG_MUL_VAL
to link and provided extended ranges.

BO_ 1979 Temperature: 54 Vector__XXX
 SG_ IndoorTemperature m256 : 79|8 at 0+ (0.5,-40) [-50|50] "degC" Vector__XXX
 SG_ response m98M : 23|16 at 0+ (1,0) [0|0] "unit" Vector__XXX
 SG_ service M : 15|8 at 0+ (1,0) [0|0] "" Vector__XXX
 SG_ OutdoorTemperature m256 : 87|8 at 0+ (0.5,-40) [-50|50] "degC" Vector__XXX
 SG_ VehicleSpeed m256 : 271|8 at 0+ (1,0) [0|200] "kmh" Vector__XXX

SG_MUL_VAL_ 1979 IndoorTemperature response 256-256;
SG_MUL_VAL_ 1979 response service 98-98;
SG_MUL_VAL_ 1979 OutdoorTemperature response 256-256;
SG_MUL_VAL_ 1979 VehicleSpeed response 256-256;

I have it now that the UNITS specified in the DBC file are used when
setting the value.  If they match our internal unit strings they will
be set using that unit.
I also implemented the VAL_TABLE_  lookup (which seems to have been
partially implemented) to store status strings.

I'm yet to find time to test all this to make sure nothing is broken
and that the new stuff works as intended!!

The interesting part of that is that looking at a DBC implementation I
noticed that there's a difference between how the DBC wants to look at
the multi-frame data and how we look at the data coming in (which is
similar to the Torque+ one), which is that DBC files see the
multi-frame data as all the 8 bytes of frame packet data concatenated
together (which includes the PIDs), whereas the other way looks at it
as a PID plus the concatenation of the payload (5 + 7 + 7 or whatever
it is).  Also the DBC file looks at bits rather than bytes. (Torque+
specification has the ability to get flags out of a byte).

What do you think of the idea of moving the DBC interpreting to the
Poller class away from the DBC vehicle implementation?  The DBC
vehicle can still auto-load the files but the poller would be
responsible for seeing a DBC pointer and interpreting the signals.  It
kind of has to because of the multi-frame data.

For multi-frame data I'm looking at a variation to ObdRequest() call
that would cause the extended packets to be sent to the DBC file to
interpret (sending the concatenated 8 byte packets of payload).

Extending DukTape OdbRequest()
-----------------------
The ObdRequest() duktape calls should probably reside on the Poller
rather than the vehicle.

It might be preferable to be able to call ObdRequest() with a
call-back rather than the blocking call that happens now.  The
non-blocking one-off OBD calls are supported by the new poller
framework.

I'm also thinking that it would be good to have a separate mechanism
that could add entries to the poller list.  I'm also wondering whether
a different way of specifying the data would be useful (via DukTape)..
using the Payload concatenated bytes, the great thing is we could
still use the DBC code to interpret the signals. (we could have a map
of dbcSignal per address + PID).

Thoughts?

//.ichael
-----Original Message-----
From: OvmsDev <ovmsdev-bounces at lists.openvehicles.com> On Behalf Of Michael
Balzer via OvmsDev
Sent: Sunday, 1 September 2024 4:04 PM
To: ovmsdev at lists.openvehicles.com
Cc: Michael Balzer <dexter at expeedo.de>
Subject: Re: [Ovmsdev] Duktape Vehicle

Michael,

detecting 12V indications for ECU operation is generally a framework
candidate, as there have been multiple vehicles that (at least
initially) needed to rely on this. It's in the same category of framework
features as the 12V monitoring. Providing the info to the vehicle can be
done using the same scheme as other vehicle framework hooks do, and if you
include events for crossing the hysteresis boundaries, it's also easy for
scripts to hook into this.

Regarding a full Duktape based vehicle implementation, that needs more
framework support, especially for automated CAN polling with preprocessing &
storing the responses, as Duktape is too slow for high speed low level
operations like this (there's also the single thread limit). The DBC vehicle
is a precursor or possibly a base for this. The DBC approach currently
supports defining a fixed message to metrics translation, which can provide
basic vehicle data decoding. It lacks a way to define polling schemes and
possibly poll state transitions.

Poll state/list transition handling might then be delegated to the Duktape
extension. Duktape can also be used to process CAN data/responses/states
that are too complex for simple metrics translations, it just needs an
intermediate data layer for this, and some event / callback scheme to be
triggered only when there is a relevant change in the respective containers.
I think the DBC vehicle also has some basic data layer support already,
worth taking a look at.

The DBC implementation was done by Mark. I wrote a DBC primer:
https://docs.openvehicles.com/en/latest/components/vehicle_dbc/docs/dbc-primer.html

The initial Fiat 500 support was done using DBC.

We also had some discussion about polling definition standards for DBC.
Ludovic Lange created a kickoff issue for this on github:
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/755

Regards,
Michael


Am 31.08.24 um 11:19 schrieb Michael Geddes via OvmsDev:
> In a recent conversation with Mark we were talking about utilising
> Duktape more for perhaps even vehicle implementations.
>
> I'm wondering if a better approach is to allow any vehicle to be
> extended via hooks in the base vehicle class or would it be better to
> have a duktape vehicle that could be extended.
>
> There would necessarily be many bits to the puzzle.  For example I
> have a class that allows us to know when blips to the 12V battery line
> might mean that somebody is interacting with the car so we should
> start polling the bus..   Should we put this (with a duktape
> interface) at the vehicle.h level?
>
> //.ichael
>
> _______________________________________________
> 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

From mark at webb-johnson.net  Mon Oct  7 08:26:56 2024
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Mon, 7 Oct 2024 08:26:56 +0800
Subject: [Ovmsdev] A forum developer question
Message-ID: <B60D1EEC-C399-4191-8A1F-0ADFB4579553@webb-johnson.net>

A question regarding web dashboard plugin development has been asked on the forums. Grateful if someone could assist.

https://www.openvehicles.com/node/4281

Hi everybody,

Although I am not completely new to JavaScript programming, I am new to the concept of OVMS plugins and read the documentation regarding it several times..

I also got the fog light example up and running on my unit. But I guess I am missing something obviously important (that is not 100% explained in the documentation?) while trying to build a very simple plugin on my own: I don't want any events or updates, but simply extend the dashboard by some additional metrics read just once when initializing the dashboard.

This is what I have created:...

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

From didier at ernotte.com  Thu Oct 31 05:55:58 2024
From: didier at ernotte.com (didier at ernotte.com)
Date: Wed, 30 Oct 2024 21:55:58 +0000 (UTC)
Subject: [Ovmsdev] Can bus error while read canbus
References: <31745481.8237823.1730325358318.ref@mail.yahoo.com>
Message-ID: <31745481.8237823.1730325358318@mail.yahoo.com>

Hi,
I don't know what changed on my OVMS box, but I am no longer abl to read manually (in the shell) any PID with the "obdii can1 request...". I receive the tranmission failure error. But it used to work fine a couple of days ago. Other commands works great like "re obdii scan start...", so the connection with the OMVS box, communication on the OBD2 port, etc works fine. What could go wrong ? I tried to download the lasted image. Same error.

Here is a session that I did : 

OVMS#?re obdii scan start 1 7e4 dd00 de00 -r7ec
Scan started: bus 1, ecu 7e4, rxid 7ec-7ec, polltype 22, PID dd00-de00 (step 1), timeout 3 seconds
I (804831) webcommand: HttpCommandStream[0x3f8d76b0]: 3317288 bytes free, executing: re obdii scan start 1 7e4 dd00 de00 -r7ecI (810981) re-pid: Scan of 7e4 completeI (817271) webserver: HTTP POST /api/executeOVMS#?re obdii scan status
Scan complete (7e4 dd00-de00)Scan started : 2024-10-30 17:46:53 EDTLast response: 2024-10-30 17:46:53 EDT7e4[7ec]:dd00 70 e8 79 bb7e4[7ec]:dd01 01 1c f87e4[7ec]:dd02 3a7e4[7ec]:dd04 3d7e4[7ec]:dd05 3a7e4[7ec]:dd06 e77e4[7ec]:dd08 007e4[7ec]:dd09 00I (817271) webcommand: HttpCommandStream[0x3f8d7350]: 3314968 bytes free, executing: re obdii scan statusI (821941) webserver: HTTP POST /api/executeI (821941) webcommand: HttpCommandStream[0x3f8d7414]: 3318624 bytes free, executing: obdii can1 request device 7E4 7EC 22dd00OVMS#?obdii can1 request device 7E4 7EC 22dd00
7e4[7ec] 22dd00: ERROR: transmission failure (CAN bus error)Didier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20241030/f70dcd4b/attachment.htm>

From dexter at expeedo.de  Thu Oct 31 14:57:39 2024
From: dexter at expeedo.de (Michael Balzer)
Date: Thu, 31 Oct 2024 07:57:39 +0100
Subject: [Ovmsdev] Can bus error while read canbus
In-Reply-To: <31745481.8237823.1730325358318@mail.yahoo.com>
References: <31745481.8237823.1730325358318.ref@mail.yahoo.com>
 <31745481.8237823.1730325358318@mail.yahoo.com>
Message-ID: <8a02f012-95ed-4dd9-a661-063e8b064c0a@expeedo.de>

Didier,

the error message tells the now separated poller isn't started and also 
cannot be started for the request.

Check "poller status":

OVMS# poller status
Poller on Can1
 ? List: active
 ? State: 0
 ? Last Request: 1s (ticks)
Time between polling ticks: 1000ms
Last Poll Received: 0s (ticks) ago
Poll Queue Length: 0
OBD polling is Resumed

Enable logging for tag "vehicle-poll" and issue "poller trace on" or 
possibly "poller trace all" if that doesn't show the cause.

Regards,
Michael


Am 30.10.24 um 22:55 schrieb didier--- via OvmsDev:
> Hi,
>
> I don't know what changed on my OVMS box, but I am no longer abl to 
> read manually (in the shell) any PID with the "obdii can1 request...". 
> I receive the tranmission failure error. But it used to work fine a 
> couple of days ago. Other commands works great like "re obdii scan 
> start...", so the connection with the OMVS box, communication on the 
> OBD2 port, etc works fine. What could go wrong ? I tried to download 
> the lasted image. Same error.
>
> Here is a session that I did :
>
> *OVMS#*  re obdii scan start 1 7e4 dd00 de00 -r7ec
> Scan started: bus 1, ecu 7e4, rxid 7ec-7ec, polltype 22, PID dd00-de00 (step 1), timeout 3 seconds
> I (804831) webcommand: HttpCommandStream[0x3f8d76b0]: 3317288 bytes 
> free, executing: re obdii scan start 1 7e4 dd00 de00 -r7ec
> I (810981) re-pid: Scan of 7e4 complete
> I (817271) webserver: HTTP POST /api/execute
> *OVMS#*  re obdii scan status
> Scan complete (7e4 dd00-de00)
> Scan started : 2024-10-30 17:46:53 EDT
> Last response: 2024-10-30 17:46:53 EDT
> 7e4[7ec]:dd00 70 e8 79 bb
> 7e4[7ec]:dd01 01 1c f8
> 7e4[7ec]:dd02 3a
> 7e4[7ec]:dd04 3d
> 7e4[7ec]:dd05 3a
> 7e4[7ec]:dd06 e7
> 7e4[7ec]:dd08 00
> 7e4[7ec]:dd09 00
> I (817271) webcommand: HttpCommandStream[0x3f8d7350]: 3314968 bytes 
> free, executing: re obdii scan status
> I (821941) webserver: HTTP POST /api/execute
> I (821941) webcommand: HttpCommandStream[0x3f8d7414]: 3318624 bytes 
> free, executing: obdii can1 request device 7E4 7EC 22dd00
> *OVMS#*  obdii can1 request device 7E4 7EC 22dd00
> 7e4[7ec] 22dd00: ERROR: transmission failure (CAN bus error)
> Didier
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20241031/7667c8eb/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20241031/7667c8eb/attachment.sig>