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_connect... >>> 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@soko.cc >>>>> <mailto:ovms@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@lists.openvehicles.com >>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OvmsDev mailing list >>>>>>>> OvmsDev@lists.openvehicles.com >>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OvmsDev mailing list >>>>>>> OvmsDev@lists.openvehicles.com >>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OvmsDev mailing list >>>>>> OvmsDev@lists.openvehicles.com >>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>>>> _______________________________________________ >>>>> OvmsDev mailing list >>>>> OvmsDev@lists.openvehicles.com >>>>> <mailto:OvmsDev@lists.openvehicles.com> >>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>>> >>>> >>>> _______________________________________________ >>>> OvmsDev mailing list >>>> OvmsDev@lists.openvehicles.com >>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>> >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev@lists.openvehicles.com >>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.openvehicles.com > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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