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

Thu Aug 13 01:18:25 HKT 2020

Chris,

yes, that would do. But…

a) you shouldn't overwrite the vehicle name, that's a user
configuration, and

b) if you would overwrite the vehicle name, you would set "name" in
"vehicle", not "vehicle.name" in "auto" (which doesn't exist).

Regards,
Michael

Am 12.08.20 um 18:59 schrieb Chris van der Meijden:
> 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.T26
> if (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
>>>>> https://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 <https://www.savvycan.com/> 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 soko.cc
>>>>>>> <mailto:ovms at soko.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-der-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/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
>>>>>>> <mailto: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
>>>>
>>>> -- 
>>>> 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 <mailto: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 <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200812/52324e8a/attachment.htm>