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

[Michael Balzer]

The vehicle type name is no configuration parameter, it's a fixed
property of the vehicle class.

The vehicle to use is configured by the vehicle type only.

Regards,
Michael



Am 12.08.20 um 20:24 schrieb Chris van der Meijden:
> Sorry, I'm just not sure if we are talking about the same param ...
>
> We now define VWUP.T26A like this
>
> MyVehicleFactory.RegisterVehicle<VWeUpT26>("VWUP.T26", "VW e-Up
> (Komfort CAN)");
>
> Before the splitting we had ("VWUP", "VW e-Up") at RegisterVehicle.
>
> My question is do I need to change "VW e-Up" to "VW e-Up (Komfort
> CAN)") in the upgrade function or is this done automaticly when I
> change "VWUP" to "VWUP.T26".
>
> Thanx
>
> Chris
>
> Am Mittwoch, den 12.08.2020, 19:57 +0200 schrieb Michael Balzer:
>> Config → Vehicle → Vehicle name
>>
>> It doesn't have a technical use yet, it won't get filled
>> automatically. It's just a free vehicle name (as the placeholder says).
>>
>> Regards,
>> Michael
>>
>> Am 12.08.20 um 19:34 schrieb Chris van der Meijden:
>>> Hey Michael
>>>
>>> Thanx.
>>>
>>> Does the human readable vehicle ID description ("VW e-Up (Komfort
>>> CAN)") matter at all, or will it be filled out automaticly by the
>>> new vehicle ID configuration? If not, how do I set that param?
>>>
>>> Regards
>>>
>>> Chris
>>>
>>> Am Mittwoch, den 12.08.2020, 19:18 +0200 schrieb Michael Balzer:
>>>> 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
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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 <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
>> _______________________________________________
>> 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/e5274b58/attachment.htm>