[Ovmsdev] VW e-Up read/poll via OBD is working

Chris van der Meijden chris at arachnon.de
Thu Aug 13 00:59:50 HKT 2020


Hi Michael
I found some time for the "hanging upgrade" issue since we splitted the
vehicle ID from VWUP to VWUP.T26 and VWUP.OBD.
Would this code in ovms_config.cpp within OvmsConfig::upgrade() prevent
the "hanging" after an upgrade?
// Migrate vehicle ID VWUP to VWUP.T26if (GetParamValue("auto",
"vehicle.type") == "VWUP")   {   SetParamValue("auto", "vehicle.type",
"VWUP.T26");   SetParamValue("auto", "vehicle.name", "VW e-Up (Komfort
CAN)");   }
If so, I would put that in a pull request as soon as we have a new
"release worthy" version?
Thanx for checking.
Greetinx
Chris
Am Freitag, den 31.07.2020, 11:34 +0200 schrieb Michael Balzer:
>     Chris,
> 
>     
> 
>     the framework shouldn't get stuck if a vehicle cannot be loaded,
> it
>     should fall back to booting without a vehicle. I'll have a look
> at
>     that.
> 
>     
> 
>     Btw, to automatically update user configurations, you can extend
>     OvmsConfig::upgrade(). Users shouldn't need to take care of
> special
>     update preparations.
> 
>     
> 
>     Regards,
> 
>     Michael
> 
>     
> 
>     
> 
>     Am 31.07.20 um 11:05 schrieb Chris van
>       der Meijden:
> 
>     
> 
>     
> >       
> >       Welcome to my trial and error T26A world :-))
> >       
> > 
> >       
> >       This morning I flashed the new T26A/OBD version to my OVMS.
> >         After the OTA flash the device did not come back to the
> >         networks. Only USB terminal access was left.
> >       
> > 
> >       
> >       The reason was, that I did no remove the old vehicle config
> >         "VWUP" before flashing and rebooting. The new image has
> >         "VWUP.T26" and "VWUP.OBD" as vehicle config, but no more
> > "VWUP".
> >         So the device could not find its vehicle config and got
> > stuck.
> >       
> > 
> >       
> >       From the USB terminal I bootet back to OTA_0, said in the
> >         vehicle config that my vehicle was a Nissan Leaf and then
> > booted
> >         back to OTA_1. The device came up with the new firmware and
> > I
> >         could change the vehicle config to "VWUP (Komfort CAN)".
> >       
> > 
> >       
> >       Everything is now running fine ...
> >       
> > 
> >       
> >       I will write this down in the documentation for the e-Up.
> >       
> > 
> >       
> >       Greetinx
> >       
> > 
> >       
> >       Chris
> >       
> > 
> >       
> >       
> > 
> >       
> >       Am Freitag, den 31.07.2020, 09:50 +0200 schrieb Michael
> >         Balzer:
> >       
> > >  Soko,
> > > 
> > >         
> > > 
> > >         you only had the door open, but not turned on the car? If
> > > there
> > >         are additional buses, they may be switched off until the
> > > car is
> > >         turned on…
> > > 
> > >         
> > > 
> > >         The OBD connector scheme is the general pin assignment, I
> > > meant
> > >         the specific VW e-Up schematics. But if you don't see any
> > >         voltages with the car turned on, that's bad news.
> > > 
> > >         
> > > 
> > >         There may still be some command interface for the OBD
> > > gateway to
> > >         enable live data, but without any info about the gateway,
> > > it
> > >         will be hard to even find out how to address it.
> > > 
> > >         
> > > 
> > >         Regards,
> > > 
> > >         Michael
> > > 
> > >         
> > > 
> > >         
> > > 
> > >         Am 31.07.20 um 09:06 schrieb Soko:
> > > 
> > >         
> > >         
> > > >           
> > > >           Hey guys,
> > > >           If I did nothing wrong I have bad news:
> > > >           @Michael:
> > > > 
> > > >             With OBD port schematics I think you mean this http
> > > > s://en.wikipedia.org/wiki/On-board_diagnostics#OBD-
> > > > II_diagnostic_connector
> > > > 
> > > >             Specifically if there are some other pins used than
> > > > the
> > > >             standard CAN pins 6 and 14.
> > > > 
> > > >             So I had the drivers door open, no key in ignition
> > > > and
> > > >             measured the voltages of all pins in relation to
> > > > pin 5
> > > >             (signal ground). There is no voltage on any pin
> > > > besides 2.5V
> > > >             on 6 and 14, and 12V on 16 of course. So there are
> > > > no hidden
> > > >             CAN buses (or any other signals) afaict.
> > > >           @Mark:
> > > > 
> > > >             Thanks for the hint with the can log. It's way
> > > > easier than
> > > >             RE Tools for just checking if there is any traffic.
> > > > 
> > > >             Having said that... there is no traffic whatsoever
> > > > besides
> > > >             what I am polling and the reply. Even when ignition
> > > > is on I
> > > >             only see the poll and the reply on the can log
> > > >           So it seems devmarxx was right: The gateway shields
> > > >             everything and there are even no other hidden
> > > > signals on the
> > > >             OBD port.
> > > >           I'm happy to try any other ideas you guys have. Just
> > > > let me
> > > >             know!
> > > >           Soko
> > > > 
> > > >           
> > > >           
> > > > 
> > > >           
> > > >           On 31.07.2020 02:11, Mark
> > > >             Webb-Johnson wrote:
> > > > 
> > > >           
> > > >           
> > > > >             
> > > > >             If you are just looking for traffic on the CAN
> > > > > bus, a simple
> > > > >             can log would be the easiest. Assuming you are on
> > > > > USB
> > > > >             console, it is:
> > > > >             
> > > > > 
> > > > >             
> > > > >             
> > > > >               OVMS# log level verbose canlog-monitor
> > > > >               OVMS# can log start monitor crtd
> > > > >             
> > > > >             
> > > > >               
> > > > > 
> > > > >               
> > > > >               If you are using ssh, you need to add a:
> > > > >               
> > > > > 
> > > > >               
> > > > >             
> > > > >             
> > > > >               
> > > > >                 OVMS# log monitor yes
> > > > >               
> > > > >             
> > > > >             
> > > > >               
> > > > > 
> > > > >               
> > > > >               To stop the logging:
> > > > >               
> > > > > 
> > > > >               
> > > > >             
> > > > >             
> > > > >               
> > > > >                 OVMS# can log stop
> > > > >               
> > > > >             
> > > > >             
> > > > >               
> > > > > 
> > > > >               
> > > > >               Documentation here:
> > > > >               
> > > > > 
> > > > >               
> > > > >             
> > > > >             
> > > > >               
> > > > >                 https://docs.openvehicles.com/en/latest/crtd/
> > > > > can_logging.html
> > > > >               
> > > > >             
> > > > >             
> > > > >               
> > > > > 
> > > > >               
> > > > >               
> > > > >                 
> > > > >                   For my work, I personally prefer this
> > > > >                     arrangement:
> > > > >                   
> > > > > 
> > > > >                   
> > > > >                 
> > > > >                 
> > > > >                   OVMS# can log start tcpserver transmit
> > > > > gvret-b
> > > > >                     :23
> > > > >                 
> > > > >                 
> > > > >                   
> > > > > 
> > > > >                   
> > > > >                 
> > > > >                 And then I use SavvyCAN on a laptop to
> > > > >                   connect over wifi and work.
> > > > >                 
> > > > > 
> > > > >                 
> > > > >               
> > > > >               Regarding the ‘re’ system, it is a work-in-
> > > > > progress,
> > > > >                 and not currently documented. It is still
> > > > > kind of a mess
> > > > >                 at the moment (particularly for multiplexed
> > > > > message
> > > > >                 IDs), as I continue to work on DBC
> > > > > integration. That
> > > > >                 said, it is basically functional.
> > > > >               
> > > > > 
> > > > >               
> > > > >             
> > > > >             To start it:
> > > > >             
> > > > > 
> > > > >             
> > > > >             
> > > > >               
> > > > >                 OVMS# re start
> > > > >               
> > > > >             
> > > > >             
> > > > >               
> > > > > 
> > > > >               
> > > > >               To stop it:
> > > > >               
> > > > > 
> > > > >               
> > > > >             
> > > > >             
> > > > >               
> > > > >                 OVMS# re stop
> > > > >               
> > > > >             
> > > > >             
> > > > >               
> > > > > 
> > > > >               
> > > > >               To see discovered IDs:
> > > > >               
> > > > > 
> > > > >               
> > > > >             
> > > > >             
> > > > >               
> > > > >                 OVMS# re list
> > > > >               
> > > > >             
> > > > >             
> > > > >               
> > > > > 
> > > > >               
> > > > >               It will (by default) listen on all open CAN
> > > > > buses,
> > > > >                 and show you the discovered ID, message
> > > > > count, interval
> > > > >                 (in ms), and last message seen.
> > > > >               
> > > > > 
> > > > >               
> > > > >               It has some rudimentary ability to monitor
> > > > > active
> > > > >                 polling protocols with ‘re obdii extended
> > > > > <min>
> > > > >                 <max>’ (or standard), specifying the range of
> > > > > IDs
> > > > >                 used by the ECUs.
> > > > >               
> > > > > 
> > > > >               
> > > > >             
> > > > >             
> > > > >               Regards, Mark
> > > > >               
> > > > > 
> > > > >                 
> > > > > >                   On 30 Jul 2020, at 11:56 PM, Soko <ovms at s
> > > > > > oko.cc> wrote:
> > > > > >                   
> > > > > >                   
> > > > > >                     
> > > > > >                     
> > > > > >                       @devmarxx: Is there any doc/guide on
> > > > > >                         how to use this RE Tools?
> > > > > >                       @Michael: Yeah, I know. You would
> > > > > > have
> > > > > >                         done my 1-day work in 5 mins. I
> > > > > > know C++ but I
> > > > > >                         don't know the OVMS framework. But
> > > > > > its like with
> > > > > >                         any project: The issue is not the
> > > > > > language, its
> > > > > >                         the framework.
> > > > > >                       Until you have yours you have to
> > > > > >                         settle with me unfortunately ;)
> > > > > >                       My cousin has a working VCDS HEX
> > > > > >                         interface and I have an y-adapter
> > > > > > so I can
> > > > > >                         listen with an ELM327 adapter to
> > > > > > the commands
> > > > > >                         VCDS is sending. Maybe I can find
> > > > > > any car status
> > > > > >                         there. Device 09 is a good hint. 
> > > > > > 
> > > > > >                       
> > > > > >                       But as you said: I have still have to
> > > > > >                         poll this, even if I find a status.
> > > > > >                       I can't say (of course) if there's
> > > > > >                         another CAN bus @ OBD port. All
> > > > > > this CAN/OBD/Bus
> > > > > >                         stuff is completely new to me..
> > > > > > ModBus RTU/TCP,
> > > > > >                         MBus etc. I would know ;)
> > > > > >                       So if you can point me in any
> > > > > >                         direction what to try - or what you
> > > > > > would do - I
> > > > > >                         happy to dig into it.
> > > > > >                       Soko
> > > > > >                       PS: Any idea when you'll get your
> > > > > > Mii?
> > > > > > 
> > > > > >                       
> > > > > >                       On 30.07.2020 17:14,
> > > > > >                         Michael Balzer wrote:
> > > > > > 
> > > > > >                       
> > > > > >                       
> > > > > > >                         
> > > > > > >                         If only I had my Mii already…
> > > > > > > 
> > > > > > >                         
> > > > > > > 
> > > > > > >                         If the OBD port is shielded from
> > > > > > > the CAN
> > > > > > >                         traffic, you need to poll some
> > > > > > > device. ECU =
> > > > > > >                         Engine Control Unit = device 01.
> > > > > > > 
> > > > > > >                         
> > > > > > > 
> > > > > > >                         I would suspect the basic car
> > > > > > > status info to be
> > > > > > >                         available from device 09 (central
> > > > > > > electrics),
> > > > > > >                         but it seems no PIDs have been
> > > > > > > RE'd from there
> > > > > > >                         yet. So maybe you need to derive
> > > > > > > the info from
> > > > > > >                         some other mode/status register.
> > > > > > > 
> > > > > > >                         
> > > > > > > 
> > > > > > >                         It's bad needing to continuosly
> > > > > > > poll to get the
> > > > > > >                         live status data. Is possibly
> > > > > > > another,
> > > > > > >                         unfiltered CAN bus available at
> > > > > > > the OBD port?
> > > > > > > 
> > > > > > >                         
> > > > > > > 
> > > > > > >                         Regards,
> > > > > > > 
> > > > > > >                         Michael
> > > > > > > 
> > > > > > >                         
> > > > > > > 
> > > > > > >                         
> > > > > > > 
> > > > > > >                         Am 30.07.20 um
> > > > > > >                           16:43 schrieb Soko:
> > > > > > > 
> > > > > > >                         
> > > > > > >                         
> > > > > > > >                           
> > > > > > > >                           Ahhh OK, I've found
> > > > > > > >                             OvmsVehicle::virtual void
> > > > > > > > TickerXXX(uint32_t
> > > > > > > >                             ticker);
> > > > > > > > 
> > > > > > > >                             Got it! This was exactly my
> > > > > > > > issue as I
> > > > > > > >                             didn't know about any
> > > > > > > > function which gets
> > > > > > > >                             called regularly so I could
> > > > > > > > check something
> > > > > > > >                             like this...
> > > > > > > > 
> > > > > > > >                             It's not an ideal situation
> > > > > > > > though: I just
> > > > > > > >                             can slow down the poll
> > > > > > > > after my fail-counter
> > > > > > > >                             gets too high as I need to
> > > > > > > > check when the
> > > > > > > >                             car gets powered again. So
> > > > > > > > all I can do is
> > > > > > > >                             polling, lets say every 60
> > > > > > > > secs when the car
> > > > > > > >                             is off, and increase it
> > > > > > > > once its on. But
> > > > > > > >                             there is now way around
> > > > > > > > this 60-sec polling
> > > > > > > >                             if the only thing I can do
> > > > > > > > is poll :(
> > > > > > > > 
> > > > > > > >                           
> > > > > > > >                           Afaik there is only the
> > > > > > > > sharkcow's
> > > > > > > >                             list below, reverse
> > > > > > > > engineered by him from
> > > > > > > >                             ODBeleven.
> > > > > > > >                           (dev)marxx exlpained to me:
> > > > > > > > There
> > > > > > > >                             is a gateway between the
> > > > > > > > CAN-Buses and the
> > > > > > > >                             OBD Connector in all VW-AG
> > > > > > > > vehicles which
> > > > > > > >                             only replies to polls and
> > > > > > > > also acts as
> > > > > > > >                             security gateway if you
> > > > > > > > want to write to the
> > > > > > > >                             buses.
> > > > > > > >                           So I think I cannot really do
> > > > > > > > a
> > > > > > > >                             can log or use re tool as
> > > > > > > > the OBD interface
> > > > > > > >                             stays quiet if I'm not
> > > > > > > > polling it...
> > > > > > > >                           And as there is no other
> > > > > > > > vehicle
> > > > > > > >                             from
> > > > > > > > VW,Seat,Skoda,Audi,etc. in OVMS. So I
> > > > > > > >                             have no cheat-sheet :(
> > > > > > > >                           Anyhow... I would need to
> > > > > > > > poll one
> > > > > > > >                             ECU (is this the correct
> > > > > > > > therm?) which
> > > > > > > >                             doesn't shuts down... or
> > > > > > > > maybe the issue is
> > > > > > > >                             the OBD-gateway shutting
> > > > > > > > down.
> > > > > > > > 
> > > > > > > >                           
> > > > > > > >                           What do you think?
> > > > > > > >                           Soko
> > > > > > > > 
> > > > > > > >                           
> > > > > > > >                           On 30.07.2020
> > > > > > > >                             16:17, Michael Balzer
> > > > > > > > wrote:
> > > > > > > > 
> > > > > > > >                           
> > > > > > > >                           
> > > > > > > > >                             
> > > > > > > > >                             Soko,
> > > > > > > > > 
> > > > > > > > >                             
> > > > > > > > > 
> > > > > > > > >                             nice progress :-)
> > > > > > > > > 
> > > > > > > > >                             
> > > > > > > > > 
> > > > > > > > >                             If you can't detect
> > > > > > > > > vehicle state by
> > > > > > > > >                             listening to regular
> > > > > > > > > status CAN frames, you
> > > > > > > > >                             can check the time since
> > > > > > > > > the last poll reply
> > > > > > > > >                             in the per second ticker.
> > > > > > > > > 
> > > > > > > > >                             
> > > > > > > > > 
> > > > > > > > >                             As poll replies normally
> > > > > > > > > come in fast, you
> > > > > > > > >                             should be able to detect
> > > > > > > > > a switch-off by a
> > > > > > > > >                             small timeout, say 3
> > > > > > > > > seconds… probably need
> > > > > > > > >                             to add a counter, as a
> > > > > > > > > single poll may get
> > > > > > > > >                             lost / ignored.
> > > > > > > > > 
> > > > > > > > >                             
> > > > > > > > > 
> > > > > > > > >                             CAN tx errors can be
> > > > > > > > > caused by other issues
> > > > > > > > >                             as well, so should
> > > > > > > > > generally not be
> > > > > > > > >                             interpreted that way.
> > > > > > > > > 
> > > > > > > > >                             
> > > > > > > > > 
> > > > > > > > >                             But… are you sure there
> > > > > > > > > are no status frames
> > > > > > > > >                             on the bus? Have you done
> > > > > > > > > a can log or tried
> > > > > > > > >                             the re tool?
> > > > > > > > > 
> > > > > > > > >                             
> > > > > > > > > 
> > > > > > > > >                             Regards,
> > > > > > > > > 
> > > > > > > > >                             Michael
> > > > > > > > > 
> > > > > > > > >                             
> > > > > > > > > 
> > > > > > > > >                             
> > > > > > > > > 
> > > > > > > > >                             Am 30.07.20 um
> > > > > > > > >                               14:43 schrieb Soko:
> > > > > > > > > 
> > > > > > > > >                             
> > > > > > > > >                             
> > > > > > > > > > Hi guys, 
> > > > > > > > > > 
> > > > > > > > > >                               
> > > > > > > > > > 
> > > > > > > > > >                               Want to report
> > > > > > > > > > success on connecting and
> > > > > > > > > >                               reading my VW e-Up
> > > > > > > > > > via OBD cable using the
> > > > > > > > > >                               Poller. As you can
> > > > > > > > > > see in the screenshot
> > > > > > > > > >                               of the log attached I
> > > > > > > > > > get an
> > > > > > > > > >                               IncomingPollReply(..)
> > > > > > > > > > call and an SoC
> > > > > > > > > >                               value of 33.333% 
> > > > > > > > > > 
> > > > > > > > > >                               
> > > > > > > > > > 
> > > > > > > > > >                               Once I turn of the
> > > > > > > > > > ignition and lock the
> > > > > > > > > >                               car though I don't
> > > > > > > > > > get any replies no more
> > > > > > > > > >                               (line D 793813) and
> > > > > > > > > > then I get can1
> > > > > > > > > >                               errors... I'm polling
> > > > > > > > > > with 10 seconds
> > > > > > > > > >                               intervall. 
> > > > > > > > > > 
> > > > > > > > > >                               
> > > > > > > > > > 
> > > > > > > > > >                               I know that this is
> > > > > > > > > > as it should be... but
> > > > > > > > > >                               my issue is: I don't
> > > > > > > > > > have any way to know
> > > > > > > > > >                               if the ignition is
> > > > > > > > > > on, the key is in, the
> > > > > > > > > >                               car is running, the
> > > > > > > > > > car is charging as the
> > > > > > > > > >                               PIDs are not known
> > > > > > > > > > for such values (afaik
> > > > > > > > > >                               by the lists of
> > > > > > > > > > sharkcow https://www.goingelectric.de/wiki/Liste-de
> > > > > > > > > > r-OBD2-Codes/).
> > > > > > > > > >                               
> > > > > > > > > > 
> > > > > > > > > >                               
> > > > > > > > > > 
> > > > > > > > > >                               So what would be the
> > > > > > > > > > best approach to
> > > > > > > > > >                               change the different
> > > > > > > > > > polling states? Can I
> > > > > > > > > >                               somehow get called
> > > > > > > > > > (in my vehicle-class)
> > > > > > > > > >                               if an can-error is
> > > > > > > > > > thrown? Then I would
> > > > > > > > > >                               increase the poll
> > > > > > > > > > frequency. 
> > > > > > > > > > 
> > > > > > > > > >                               
> > > > > > > > > > 
> > > > > > > > > >                               Any suggestions? 
> > > > > > > > > > 
> > > > > > > > > >                               
> > > > > > > > > > 
> > > > > > > > > >                               thanks 
> > > > > > > > > > 
> > > > > > > > > >                               
> > > > > > > > > > 
> > > > > > > > > >                               Soko 
> > > > > > > > > > 
> > > > > > > > > >                               
> > > > > > > > > > 
> > > > > > > > > >                               
> > > > > > > > > > 
> > > > > > > > > >                               
> > > > > > > > > >                               _____________________
> > > > > > > > > > __________________________
> > > > > > > > > > OvmsDev mailing list
> > > > > > > > > > OvmsDev at lists.openvehicles.com
> > > > > > > > > > http://lists.openvehicles.com/mailman/listinfo/ovms
> > > > > > > > > > dev
> > > > > > > > > > 
> > > > > > > > > >                             
> > > > > > > > > 
> > > > > > > > >                             
> > > > > > > > > 
> > > > > > > > >                             
> > > > > > > > > 
> > > > > > > > >                             
> > > > > > > > >                             _________________________
> > > > > > > > > ______________________
> > > > > > > > > OvmsDev mailing list
> > > > > > > > > OvmsDev at lists.openvehicles.com
> > > > > > > > > http://lists.openvehicles.com/mailman/listinfo/ovmsde
> > > > > > > > > v
> > > > > > > > > 
> > > > > > > > >                           
> > > > > > > > 
> > > > > > > >                           
> > > > > > > > 
> > > > > > > >                           
> > > > > > > >                           _____________________________
> > > > > > > > __________________
> > > > > > > > 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/l
> > > > > > istinfo/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
> > > > 
> > > >         
> > > 
> > >         
> > > 
> > >         -- 
> > > 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
> > 
> >     
> 
>     
> 
>     -- 
> 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/20200812/420dbc74/attachment-0001.html>


More information about the OvmsDev mailing list