Hello, Thanks heaps. There is now way I could have figured this out by myself. I will give your values a try asap. You did only 3 entries for the polltime though... As far as I could see there are 4 which correspond to the possible parameter values for PollSetState(...); Looking at the other vehicles I haven't seen any automatism the PollState is set by the framework. One vehicle uses 0-3 for (off, on, moving, charging). So I have to change the Poll-State manually in my vehicle implementation, correct? In different words: When I only call PollSetState(0); (for early stage testing) the polling uses only the first polltime-value. Doesn't matter if the car os off/on/...? thx again Soko On 25.07.2020 20:45, Michael Balzer wrote:

Soko,

0x22028C isn't a PID, it's an OBD2 command (0x22 = poll extended ID) + the actual register address 0x028C to be polled.

And 0x7E5 isn't a header, it's probably the address of the OBD2 device you're polling (txmoduleid) OBD2 is a subset of ISO-TP, in ISO-TP devices can be addressed at any ID and respond at any ID. The OBD2 base protocol defines a broadcast address at 0x7DF, and assigned device addresses in the range 0x7E0 - 0x7E7. Replies shall be sent at the device address + 8, so the reply for a poll to 0x7E5 would normally be coming from 0x7ED (rxmoduleid).

That are the basic principles of the OBD2 protocol, see https://en.wikipedia.org/wiki/OBD-II_PIDs#CAN_(11-bit)_bus_format .

So your poll could for example be defined as:

const OvmsVehicle::poll_pid_t vwup_poll[] = {   // Note: poller ticker cycles at 3600 seconds = max period   // { txid, rxid, type, pid, { period_off, period_drive, period_charge } }   { 0x7E5, 0x7ED, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x028C, { 0, 10, 60 } },   { 0, 0, 0, 0, { 0, 0, 0 } } };

See vehicle.h for OBD2 commands (poll types) currently supported. See the other vehicles for examples of complex poll definitions.

Regards, Michael

Am 25.07.20 um 20:09 schrieb Soko:

...

Heya,

Another thing I can't figure out at the moment. I have to poll the VWeUp and I figured out (hopefully) how to do that. But I have no clue how to translate the "usual" ELM327 Header+PID to one entry for the OvmsVehicle::poll_pid_t

The only value I've understood is the polltime. On my OBD2 interfaces I use a PID of 0x22028C for SoC. But PID is here only 16 bit! Where do I put the header 7E5? What is txmoduleid and rxmoduleid?

I can't believe that I'm the first one with this issue ;) Couldn't find any doc though :(

So I'm very thankful for any pointing in the correct direction/doc/example.

thanks

Soko

_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

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

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

_______________________________________________ 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

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

"@devmarxx: Is there any doc/guide on how to use this RE Tools?" Here is a link: https://docs.openvehicles.com/en/latest/plugin/retools/README.html Not much I'm afraid, but it can bring you on track ... Chris Am Donnerstag, den 30.07.2020, 17:56 +0200 schrieb Soko:

    @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-Cod es/).             

            

            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

      

      

      --  Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

      

             _______________________________________________ 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

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 <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> 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/ <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 <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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 <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 <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 <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>

---

OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

_______________________________________________ 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

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

_______________________________________________ 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

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

You can first try to scan the ID range 700 - 7FF, as all currently known e-Up devices are in that range. If you scan for unknown devices, you need to try different standard requests and check for responses on all CAN IDs, as ISO-TP allows devices to respond with arbitrary IDs. In case of no unknown OBD/ISO-TP responses you may also try doing a CANopen scan: https://docs.openvehicles.com/en/latest/components/canopen/docs/Howto-detect... …but chances are possibly low VW mixes ISO-TP with CANopen devices (Renault does). Regards, Michael Am 31.07.20 um 10:54 schrieb Mark Webb-Johnson:

The other suggestion I have is to see if the gateway itself is alive for query. If you know the gateway ECU can bus arbitration ID (assuming you are not already doing that for polling). Perhaps it responds to a normal OBDII standard poll (for things like speed, etc), or a UDS style diagnostic query.

Regards, Mark.

...

On 31 Jul 2020, at 3:50 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:

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 >> >> -- >> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >> >> _______________________________________________ >> 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

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

_______________________________________________ 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

-- 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

Soko, you don't need to use the poller to scan for OBD devices. You can simply do manual transmissions and look for responses. To send a manual request, simply use the can tx command. Example: OVMS# can can1 tx standard 79b 02 01 00 00 00 00 00 00 This means: 2 byte OBD request sent to ID 700, type 01 = get current data, from PID 00. PID 00 is supposed (OBD-II) to reply with a four byte bitset of the device's PIDs 01-20 (hex) support. Send this with can logging enabled without filters, so you can see all responses. A response could look like this: V (591792) canlog-monitor: 1596194327.716686 1R11 7BB 03 7f 01 11 00 00 00 00 This tells you: * there is a device listening at 79b, which answers at 7bb -- nice! * it probably talks ISO-TP -- nice! * it  won't allow you to do this request in it's default session: 7F = serviceNotSupportedInActiveSession OK, let's try to change the session (command 10) to the ISO 14229 standard "extendedDiagnosticSession" (value 03): V (2085712) canlog-monitor: 1596195821.642256 1T11 79B 02 10 03 00 00 00 00 00 V (2085722) canlog-monitor: 1596195821.659737 1R11 7BB 03 7f 10 12 00 00 00 00 No luck. You can now begin trying all possible session codes. Or, in my case, I already know the device uses C0 ;-) V (2095662) canlog-monitor: 1596195831.598560 1T11 79B 02 10 c0 00 00 00 00 00 V (2095672) canlog-monitor: 1596195831.609308 1R11 7BB 02 50 c0 00 00 00 00 00 We're logged in -- nice! :-) Let's try the PID read again (do this within 60 seconds or the session will log out, unless you send a "tester present" frame): V (2530842) canlog-monitor: 1596196266.780867 1T11 79B 02 01 00 00 00 00 00 00 V (2530862) canlog-monitor: 1596196266.797961 1R11 7BB 03 7f 01 11 00 00 00 00 Still no luck. So this tells you, the device does not support standard OBD-II PIDs. How about a UDS DTC request (19)? V (3034142) canlog-monitor: 1596196770.085839 1T11 79B 02 19 01 ff 00 00 00 00 V (3034162) canlog-monitor: 1596196770.103517 1R11 7BB 03 7f 19 12 00 00 00 00 No luck. Let's try command 21 (read enhanced data by 8 bit PID) at PID 00 next: V (2737632) canlog-monitor: 1596196473.567437 1T11 79B 02 21 00 00 00 00 00 00 V (2737712) canlog-monitor: 1596196473.649927 1R11 7BB 03 7f 21 12 00 00 00 00 Nope… maybe PID 01? V (2744182) canlog-monitor: 1596196480.120911 1T11 79B 02 21 01 00 00 00 00 00 V (2744262) canlog-monitor: 1596196480.203461 1R11 7BB 10 34 61 01 13 88 13 83 Houston, we've got a response :-) You would now check if this response is a single or multi frame type, then try to get all data and then try to map the data to something you would expect to be stored in that device. For the standard UDF commands, you will need a copy of the ISO 14229 standard. Regards, Michael Am 31.07.20 um 12:57 schrieb Soko:

@Chris: Thanks for taking care of the upgrade process for the new vehicle IDs

@Mark: I will have a 1 hour session with VCDS today to find any other ECU/PIDs we can maybe use to see if the car is on/off/charging/etc. So maybe I find the ID of the gateway as well

@Michael: I had the ignition off because I wanted to see if there is anything I can query in that state. I've measured the voltages again with ignition on: No change besides pin 1 becoming +12V (as already mentioned @ wikipedia). I've tried to find (via Google) any (e)Up, or even general-VW, specific pin schematics of the OBD connector... no luck. Maybe there are some special gateway commands to put a specific CAN directly to i.e. pin 3+11. But without getting hands on VW internal docs I don't see how to get this info with try&error. I will give the CANopen scan a try.

On how to to a range scan (700-7FF): A little bit of more input would be great. You can find my current class here: https://github.com/devmarxx/Open-Vehicle-Monitoring-System-3/blob/master/veh...

I thought of generating one entry for each of the txids (700-7FF) in the vwup_polls[] array. But how do I tell the poller to accept any respond Id? And which type and PID should I try?

Imho the most promising approach is to log what VCDS is doing and which ECUs are in there and which PIDs each has. VCDS should know all possible ECUs+PIDs for the new eUp. It has the newest USB-interface and the software was just updated 2 weeks ago.

Soko

On 31.07.2020 11:29, Michael Balzer wrote:

...

You can first try to scan the ID range 700 - 7FF, as all currently known e-Up devices are in that range.

If you scan for unknown devices, you need to try different standard requests and check for responses on all CAN IDs, as ISO-TP allows devices to respond with arbitrary IDs.

In case of no unknown OBD/ISO-TP responses you may also try doing a CANopen scan: https://docs.openvehicles.com/en/latest/components/canopen/docs/Howto-detect...

…but chances are possibly low VW mixes ISO-TP with CANopen devices (Renault does).

Regards, Michael

Am 31.07.20 um 10:54 schrieb Mark Webb-Johnson:

...

The other suggestion I have is to see if the gateway itself is alive for query. If you know the gateway ECU can bus arbitration ID (assuming you are not already doing that for polling). Perhaps it responds to a normal OBDII standard poll (for things like speed, etc), or a UDS style diagnostic query.

Regards, Mark.

...

On 31 Jul 2020, at 3:50 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:

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 >>>> >>>> -- >>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >>>> >>>> _______________________________________________ >>>> 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 >> >> -- >> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >> >> _______________________________________________ >> 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

-- 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 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

Soko, not sure if the standard cable connects pin 1 on the OBD port side, but the DB9 connector has GEP_7 on pin 1 (see OVMS schematics). So you can route that to an EGPIO input (take care to add a voltage divider on the way). So that would need a simple hardware extension / modification, but is an option. Sorry, can't help you on the VCDS stuff. In my scan example, I initially was going to make an artificial example, then changed to using my Twizy live responses as an example. So that should have been 79b instead of 700. Regarding typing the command 256 times… you know we've got a powerful scripting system on board? ;-) Of course you can also write a C++ function to do the same by calling the CAN API directly. You just cannot use the polling framework, as that's bound to specific rx IDs. But you can simply read all CAN frames and look for responses without filtering by ID first. A general purpose OBD scanner working that way could well be a valuable extension to the RE toolkit. Regards, Michael Am 31.07.20 um 17:40 schrieb Soko:

Heya,

I'm back from my 2 hr VCDS session... not satisfying at all...

*Car-off polling issue:* VCDS lists me 19 ECUs (with the ignition on) which includes 09 "Zentralelektrik" (which Michael recommended), 19 "Diagnosteinterface" and 61 "Batterieregelung" which stay responsive for a period of time after ignition is off. All other are not responsive no more with no ignition... But: Once the car is locked not a single ECU is responding :( . So there is nothing to poll which will respond in any state of the car. The only option is the +12V on pin 1. _Is pin 1 somehow connected to OVMS via the standard OBD adapter?_

*Sniffing VCDS (+CarScanner App) commands:* Here I'm somehow confused now. I've tried to sniff the header/txid of ECU 61 (Betterieregelung) as the list of sharkcow hasn't it listed yet. It seems that the header is not transmitted, neither in VCDS nor in CarScanner. Only the PID goes to the OBD port. To understand the transmissions I've tried in CarScanner to swap between two dashboards/value-readings. One for SoC (=22 02 8C) of ECU 8C (header=7E5) outside-temp (=22 F4 46) of ECU 01 (header=7E0). I couldn't find any 7E5 or 7E0 in the sniffed data!? Why? How is the ECU addressed then? I've also think of any rule to get from the ECU number (i.e. 8C, 01) to the header, but couldn't find any...

*Scan for OBD devices:* Thanks for the info & details Michael. But is there a chance that I'll find an OBD device which VCDS doesn't know about (or doesn't list in the software)? If yes: Can I somehow put this manual request in C++ code instead of using the shell? Then I don't have to type this manually 256 times (by using a loop) ;) Also, is there a typo in your email? You write "...sent to ID 700, type..." but the command says "79b" and later you write "...there is a device listening at 79b...". So is ID 700 the device 79b or did you mean ID 79B?

thx for you patience with me

Soko

On 31.07.2020 14:09, Michael Balzer wrote:

...

Soko,

you don't need to use the poller to scan for OBD devices. You can simply do manual transmissions and look for responses.

To send a manual request, simply use the can tx command. Example:

OVMS# can can1 tx standard 79b 02 01 00 00 00 00 00 00

This means: 2 byte OBD request sent to ID 700, type 01 = get current data, from PID 00. PID 00 is supposed (OBD-II) to reply with a four byte bitset of the device's PIDs 01-20 (hex) support.

Send this with can logging enabled without filters, so you can see all responses. A response could look like this:

V (591792) canlog-monitor: 1596194327.716686 1R11 7BB 03 7f 01 11 00 00 00 00

This tells you:

* there is a device listening at 79b, which answers at 7bb -- nice! * it probably talks ISO-TP -- nice! * it  won't allow you to do this request in it's default session: 7F = serviceNotSupportedInActiveSession

OK, let's try to change the session (command 10) to the ISO 14229 standard "extendedDiagnosticSession" (value 03):

V (2085712) canlog-monitor: 1596195821.642256 1T11 79B 02 10 03 00 00 00 00 00 V (2085722) canlog-monitor: 1596195821.659737 1R11 7BB 03 7f 10 12 00 00 00 00

No luck. You can now begin trying all possible session codes. Or, in my case, I already know the device uses C0 ;-)

V (2095662) canlog-monitor: 1596195831.598560 1T11 79B 02 10 c0 00 00 00 00 00 V (2095672) canlog-monitor: 1596195831.609308 1R11 7BB 02 50 c0 00 00 00 00 00

We're logged in -- nice! :-)

Let's try the PID read again (do this within 60 seconds or the session will log out, unless you send a "tester present" frame):

V (2530842) canlog-monitor: 1596196266.780867 1T11 79B 02 01 00 00 00 00 00 00 V (2530862) canlog-monitor: 1596196266.797961 1R11 7BB 03 7f 01 11 00 00 00 00

Still no luck. So this tells you, the device does not support standard OBD-II PIDs. How about a UDS DTC request (19)?

V (3034142) canlog-monitor: 1596196770.085839 1T11 79B 02 19 01 ff 00 00 00 00 V (3034162) canlog-monitor: 1596196770.103517 1R11 7BB 03 7f 19 12 00 00 00 00

No luck. Let's try command 21 (read enhanced data by 8 bit PID) at PID 00 next:

V (2737632) canlog-monitor: 1596196473.567437 1T11 79B 02 21 00 00 00 00 00 00 V (2737712) canlog-monitor: 1596196473.649927 1R11 7BB 03 7f 21 12 00 00 00 00

Nope… maybe PID 01?

V (2744182) canlog-monitor: 1596196480.120911 1T11 79B 02 21 01 00 00 00 00 00 V (2744262) canlog-monitor: 1596196480.203461 1R11 7BB 10 34 61 01 13 88 13 83

Houston, we've got a response :-)

You would now check if this response is a single or multi frame type, then try to get all data and then try to map the data to something you would expect to be stored in that device.

For the standard UDF commands, you will need a copy of the ISO 14229 standard.

Regards, Michael

_______________________________________________ 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

Soko, reading the source is always a good thing :-), but there's actually also documentation on scripting: https://docs.openvehicles.com/en/latest/userguide/scripting.html Scripts are run by their name, not path. So you would simply do… OVMS# script run vfstest …or shorter… OVMS# . vfstest Oops… having tried a command (non-javascript) script from the web console just now: apparently there is a bug in the output processing, that currently only works on the USB console. I'll have a look at that. But command scripts really can only execute commands, you'll be using javascript for almost everything except most basic tasks, and those work remotely, via web & ssh. Regards, Michael Am 01.08.20 um 10:51 schrieb Soko:

Hey guys,

I've tried to use the script engine and created some files. But when I run the files nothing happens. No output at all. Here is my webc onsole trys:

OVMS# vfs ls /store [DIR]     01-Jan-1980 00:00  ovms_config/ [DIR]     01-Aug-2020 10:12  scripts/ OVMS# vfs ls /store/scripts      35   01-Aug-2020 10:27  vfstest.bat      35   01-Aug-2020 10:29  vfstest.js      35   01-Aug-2020 10:29  vfstest      35   01-Aug-2020 10:31  vfstest.cm      35   01-Aug-2020 10:31  vfstest.cmd      35   01-Aug-2020 10:33  vfstest.py OVMS# vfs head /store/scripts/vfstest vfs ls /store vfs ls /store/scripts OVMS# script run /store/scripts/vfstest

I would expect the output of the two first commands after running the script! What am I doing wrong here? I've also tried some different file extensions as you can see. I've also had a look into the source (static void script_ovms(...)) to find the special file extension that is needed. But apparently everything besides .js is handled as command script.

Soko

PS: I've created the files via the web editor. Do they need any special termination character after each line?

_______________________________________________ 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

Hi, It looks like the PubSub.js is no longer working reliably. I have opened an issue: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/474 This means that my climate control plugin will not work until this is fixed. Regards, Jaunius Sent using the GMX mail app On 2020-08-01 at 12:58, Michael Balzer wrote:

Correction: you may also run a script by an absolute path. If giving just a name (or relative path), script_run() looks for the file in the scripts directory.

Am 01.08.20 um 11:45 schrieb Michael Balzer:

...

Soko,

reading the source is always a good thing :-), but there's actually also documentation on scripting: https://docs.openvehicles.com/en/latest/userguide/scripting.html

Scripts are run by their name, not path. So you would simply do…

OVMS# script run vfstest …or shorter… OVMS# . vfstest

Oops… having tried a command (non-javascript) script from the web console just now: apparently there is a bug in the output processing, that currently only works on the USB console. I'll have a look at that. But command scripts really can only execute commands, you'll be using javascript for almost everything except most basic tasks, and those work remotely, via web & ssh.

Regards, Michael

Am 01.08.20 um 10:51 schrieb Soko:

...

Hey guys,

I've tried to use the script engine and created some files. But when I run the files nothing happens. No output at all. Here is my webc onsole trys:

OVMS# vfs ls /store [DIR]     01-Jan-1980 00:00  ovms_config/ [DIR]     01-Aug-2020 10:12  scripts/ OVMS# vfs ls /store/scripts      35   01-Aug-2020 10:27  vfstest.bat      35   01-Aug-2020 10:29  vfstest.js      35   01-Aug-2020 10:29  vfstest      35   01-Aug-2020 10:31  vfstest.cm      35   01-Aug-2020 10:31  vfstest.cmd      35   01-Aug-2020 10:33  vfstest.py OVMS# vfs head /store/scripts/vfstest vfs ls /store vfs ls /store/scripts OVMS# script run /store/scripts/vfstest

I would expect the output of the two first commands after running the script! What am I doing wrong here? I've also tried some different file extensions as you can see. I've also had a look into the source (static void script_ovms(...)) to find the special file extension that is needed. But apparently everything besides .js is handled as command script.

Soko

PS: I've created the files via the web editor. Do they need any special termination character after each line?

_______________________________________________ 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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev

Thanx. Merged. Greetinx Chris Am Samstag, den 01.08.2020, 12:49 +0200 schrieb Michael Balzer:

Fixed.

Regards, Michael

Am 01.08.20 um 11:45 schrieb Michael Balzer:

...

Oops… having tried a command (non-javascript) script from the web console just now: apparently there is a bug in the output processing, that currently only works on the USB console. I'll have a look at that.

Heya again, I'm trying to develop a detection for when the car is off/locked but I'm encountering a weird phenomena: * Car is shut down and locked * OVMS connected * CAN poll for voltage (only one poll value active) with 30 secs fails with error (so far nothing weird) * Unlock the car via car-key remote * Poll succeeds and I'm switching from PollState=0 to PollState=1 where I poll every 2 secs * Lock the car via car-key remote * _After 1 hour the polls still work and the car is active_ Is something like this known from other vehicles? So basically my car never shuts down :( Another secondary weird thing: When increasing the time to 5 secs for PollState=1 the polls get no reply and after 20 secs I swap back to PollState=0. BUT the second the PollState changes the car replies again... Even more weirdness: When PollState=1 time is 10 secs and I swap back to Pollstate=0 after 40 secs the same thing happens! Immediately I swap to PollState=0 the car replies again. As if the PollState switching somehow wakes the car up??! Any ideas? Soko

As mentioned previously, another thing to check would be the 12v reading: metric list v.b.12v.voltage See if there is any difference in that between the car awake vs sleeping (probably safest to do this test with no car module loaded, so no polling at all). Regards, Mark.

On 3 Aug 2020, at 12:19 PM, Soko <ovms@soko.cc> wrote:

Mornin,

Source is here: https://github.com/devmarxx/Open-Vehicle-Monitoring-System-3/tree/master/veh... <https://github.com/devmarxx/Open-Vehicle-Monitoring-System-3/tree/master/vehicle/OVMS.V3/components/vehicle_vweup/src> Attached are two logs. I haven't had the can-monitor active unfortuantely..

VWUP_OFF_TICKER_THRESHOLD 5 with 4 trys.log As the name says it polls every 5 seconds in PollState=1 and swaps back to PollState=0 after 5*4=20 seconds. Until line 35 you see the CAN errors as the vehicle is OFF. Then I unlocked the car and in line 38 I get the first reply. Around line 90 I locked the car again. It polls, but gets no reply, but not error either (?!). Line 118 sets the PollState=0 and suddenly a response comes in. So in Line 123 I set the PollState=1 again. The the game starts again: Polls get send, no reply but no error either. After 21 CarOffTickers I switch to PollState=0 and suddenly a reply comes in...

VWUP_OFF_TICKER_THRESHOLD 10 with 4 trys.log Here I unlocked at line 57 and locked around line 100. After that polls get send, no reply, but errors happen. And the car is finally off. Although I've tried the same thing later that day and the car didn't even go to sleep with Threshold=30!?!? So the behavior is not 100% reproducible (yet)...

@gateway throttling: In VCDS (which - hopefully - does only polling too) I have a little number showing me the refresh rates of the values. It indicates ~8 refreshes per second. So with 1 second shouldn't be any throttling.

@OBD "tester": I have no clue what this is ;) So if the polling framework doesn't do it, I don't do it. All I do is in the obd_eup.* files.

Soko

On 02.08.2020 20:12, Michael Balzer wrote:

...

Soko,

polling may keep the car awake, that's also an issue on the Kia e-Niro IIRC.

Changing the PollState can only affect the car indirectly via the changed polls. Maybe you could add your code & a log?

Regarding the poll replies stopping, is that also reflected in a CAN log? Maybe the OBD gateway throttles if it sees too many requests? (Hopefully not…)

If the gateway does throttling: do you login to the OBD as a "tester" and keep the session active by periodically sending the "tester present" frame?

Regards, Michael

Am 02.08.20 um 19:30 schrieb Soko:

...

Heya again,

I'm trying to develop a detection for when the car is off/locked but I'm encountering a weird phenomena:

Car is shut down and locked OVMS connected CAN poll for voltage (only one poll value active) with 30 secs fails with error (so far nothing weird) Unlock the car via car-key remote Poll succeeds and I'm switching from PollState=0 to PollState=1 where I poll every 2 secs Lock the car via car-key remote After 1 hour the polls still work and the car is active Is something like this known from other vehicles? So basically my car never shuts down :(

Another secondary weird thing: When increasing the time to 5 secs for PollState=1 the polls get no reply and after 20 secs I swap back to PollState=0. BUT the second the PollState changes the car replies again... Even more weirdness: When PollState=1 time is 10 secs and I swap back to Pollstate=0 after 40 secs the same thing happens! Immediately I swap to PollState=0 the car replies again. As if the PollState switching somehow wakes the car up??!

Any ideas?

Soko

_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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 <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <VWUP_OFF_TICKER_THRESHOLD 10 with 4 trys.log><VWUP_OFF_TICKER_THRESHOLD 5 with 4 trys.log>_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

Soooo.... I've finally found time to test this again. Basically the same behaviour as described below. *VWUP_OFF_TICKER_THRESHOLD 5 with 4 trys.log* Car was locked initially. Unlocked the car before line 21 (around time mark 60.000). Locked around time mark 80.000. Car stayed responsive until line 108 (time mark 100.000). At line 130 (tm=116.814) I swap back to PollState=0. The poll for PollState=0 gets an immediate reply (line 131-133) and therefore I swap back to PollState=1. The weird thing is that line 132 (which got a reply) is exactly the same as 126 (or 118 or 110) which didn't get a reply!?!? So the car has no idea of the poll states as the data is the same? There must be some issue/bug/behavior inside OVMS (maybe even in the hardware buffer) which gets triggered by a PollState change. Or the canlog-monitor uses somehow a cache and doesn't show the messages immediately. *VWUP_OFF_TICKER_THRESHOLD 10 with 4 trys.log* Same as below. One thing I've noticed though: Car was locked until line 32 (tm=63.814). Then I've unlocked it and the lines 33 and 34 showed up immediately. This indicates a buffer/cache/etc. issue with the canlog-monitor as well (imho). Soko On 03.08.2020 13:10, Michael Balzer wrote:

Soko,

I don't see any obvious mistakes on a first check.

Please do the tests again with CAN monitoring, so we can see what's actually going on on the bus.

An OBD device normally logs into the device sending a UDS diag session command (0x10), then keeps that session alive by sending tester present (0x3E) evers 30-60 seconds. See the UDS documentation I sent you, or for an overview, see https://de.wikipedia.org/wiki/Unified_Diagnostic_Services

You should be able to get the session type and protocol by logging what your VCDS does on the bus.

Regards, Michael

Am 03.08.20 um 06:19 schrieb Soko:

...

Mornin,

Source is here: https://github.com/devmarxx/Open-Vehicle-Monitoring-System-3/tree/master/veh...

Attached are two logs. I haven't had the can-monitor active unfortuantely..

*VWUP_OFF_TICKER_THRESHOLD 5 with 4 trys.log* As the name says it polls every 5 seconds in PollState=1 and swaps back to PollState=0 after 5*4=20 seconds. Until line 35 you see the CAN errors as the vehicle is OFF. Then I unlocked the car and in line 38 I get the first reply. Around line 90 I locked the car again. It polls, but gets no reply, _but not error either_ (?!). Line 118 sets the PollState=0 and suddenly a response comes in. So in Line 123 I set the PollState=1 again. The the game starts again: Polls get send, no reply but no error either. After 21 CarOffTickers I switch to PollState=0 and suddenly a reply comes in...

*VWUP_OFF_TICKER_THRESHOLD 10 with 4 trys.log *Here I unlocked at line 57 and locked around line 100. After that polls get send, no reply, _but errors happen_. And the car is finally off. Although I've tried the same thing later that day and the car didn't even go to sleep with Threshold=30!?!? So the behavior is not 100% reproducible (yet)...

@gateway throttling: In VCDS (which - hopefully - does only polling too) I have a little number showing me the refresh rates of the values. It indicates ~8 refreshes per second. So with 1 second shouldn't be any throttling.

@OBD "tester": I have no clue what this is ;) So if the polling framework doesn't do it, I don't do it. All I do is in the obd_eup.* files.

Soko

On 02.08.2020 20:12, Michael Balzer wrote:

...

Soko,

polling may keep the car awake, that's also an issue on the Kia e-Niro IIRC.

Changing the PollState can only affect the car indirectly via the changed polls. Maybe you could add your code & a log?

Regarding the poll replies stopping, is that also reflected in a CAN log? Maybe the OBD gateway throttles if it sees too many requests? (Hopefully not…)

If the gateway does throttling: do you login to the OBD as a "tester" and keep the session active by periodically sending the "tester present" frame?

Regards, Michael

Am 02.08.20 um 19:30 schrieb Soko:

...

Heya again,

I'm trying to develop a detection for when the car is off/locked but I'm encountering a weird phenomena:

* Car is shut down and locked * OVMS connected * CAN poll for voltage (only one poll value active) with 30 secs fails with error (so far nothing weird) * Unlock the car via car-key remote * Poll succeeds and I'm switching from PollState=0 to PollState=1 where I poll every 2 secs * Lock the car via car-key remote * _After 1 hour the polls still work and the car is active_

Is something like this known from other vehicles? So basically my car never shuts down :(

Another secondary weird thing: When increasing the time to 5 secs for PollState=1 the polls get no reply and after 20 secs I swap back to PollState=0. BUT the second the PollState changes the car replies again... Even more weirdness: When PollState=1 time is 10 secs and I swap back to Pollstate=0 after 40 secs the same thing happens! Immediately I swap to PollState=0 the car replies again. As if the PollState switching somehow wakes the car up??!

Any ideas?

Soko

_______________________________________________ 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 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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev

Hmmm... ok lets forget the 2nd log and talk about the first one. It must somehow be related to OVMS though as the replies get in immediately I swap the poll states. If I change the threshold from 5 secs to 3 or to 6 its always the same: once the poll state swaps the replies come in. So it must be related to the poll stat switch. The canlog shows all polls look the same... so the gateway must get confused every time exactly when the threshold*4 is over? Hmmm... or maybe the gateway gets confused after a certain number of polls. So the threshold doesnt matter. When I change the factor 4 to i.e. 6 I could validate this hypothesis. Havent had time for session implementation yet. Is there a OVMS framework for a tester session? Or at least a vehicle implementation which does it? On 8 August 2020 16:58:25 CEST, Michael Balzer <dexter@expeedo.de> wrote:

Soko,

lines 33 and 34 of your second log are due to the CAN TX buffer, which seems to have held back the frame until the bus became available.

Besides that, I don't see an RX in that log after switching the polling state. So I assume the RX in your first log also isn't related to the poll state switch.

There is an RX buffer, but that's just the internal queue of the vehicle CAN listener task. There is no delay on the processing unless you block the task somehow, for example by doing long term loops / communication in that context (which you shouldn't do).

You still don't send a session login or tester presence, so maybe the gateway is simply confused by the requests, runs into some timeout, then restarts… something like that.

Regards, Michael

Am 08.08.20 um 13:20 schrieb Soko:

...

Soooo....

I've finally found time to test this again.

Basically the same behaviour as described below.

*VWUP_OFF_TICKER_THRESHOLD 5 with 4 trys.log* Car was locked initially. Unlocked the car before line 21 (around

time

...

mark 60.000). Locked around time mark 80.000. Car stayed responsive until line 108 (time mark 100.000). At line 130 (tm=116.814) I swap back to PollState=0. The poll for PollState=0 gets an immediate reply (line 131-133) and therefore I swap back to PollState=1. The weird thing is that line 132 (which got a reply) is exactly the same as 126 (or 118 or 110) which didn't get a reply!?!? So the car has no idea of the poll states as the data is the same? There must be some issue/bug/behavior inside OVMS (maybe even in the hardware buffer) which gets triggered by a PollState change. Or the canlog-monitor uses somehow a cache and doesn't show the messages immediately.

*VWUP_OFF_TICKER_THRESHOLD 10 with 4 trys.log* Same as below. One thing I've noticed though: Car was locked until line 32 (tm=63.814). Then I've unlocked it and the lines 33 and 34 showed up immediately. This indicates a buffer/cache/etc. issue with the canlog-monitor as well (imho).

Soko

On 03.08.2020 13:10, Michael Balzer wrote:

...

Soko,

I don't see any obvious mistakes on a first check.

Please do the tests again with CAN monitoring, so we can see what's actually going on on the bus.

An OBD device normally logs into the device sending a UDS diag session command (0x10), then keeps that session alive by sending tester present (0x3E) evers 30-60 seconds. See the UDS documentation I sent you, or for an overview, see https://de.wikipedia.org/wiki/Unified_Diagnostic_Services

You should be able to get the session type and protocol by logging what your VCDS does on the bus.

Regards, Michael

Am 03.08.20 um 06:19 schrieb Soko:

...

Mornin,

Source is here:

https://github.com/devmarxx/Open-Vehicle-Monitoring-System-3/tree/master/veh...

...

Attached are two logs. I haven't had the can-monitor active unfortuantely..

*VWUP_OFF_TICKER_THRESHOLD 5 with 4 trys.log* As the name says it polls every 5 seconds in PollState=1 and swaps back to PollState=0 after 5*4=20 seconds. Until line 35 you see the CAN errors as the vehicle is OFF. Then I unlocked the car and in line 38 I get the first reply. Around line 90 I locked the car again. It polls, but gets no reply, _but not error either_ (?!). Line 118 sets the PollState=0 and suddenly a response comes in. So in Line 123 I set the PollState=1 again. The the game starts again: Polls get send, no reply but no error either. After 21 CarOffTickers I switch to PollState=0 and suddenly a reply comes in...

*VWUP_OFF_TICKER_THRESHOLD 10 with 4 trys.log *Here I unlocked at line 57 and locked around line 100. After that polls get send, no reply, _but errors happen_. And the car is finally off. Although I've tried the same thing later that day and the car

didn't

...

even go to sleep with Threshold=30!?!? So the behavior is not 100% reproducible (yet)...

@gateway throttling: In VCDS (which - hopefully - does only polling too) I have a little number showing me the refresh rates of the values. It indicates ~8 refreshes per second. So with 1 second shouldn't be any throttling.

@OBD "tester": I have no clue what this is ;) So if the polling framework doesn't do it, I don't do it. All I do is in the obd_eup.* files.

Soko

On 02.08.2020 20:12, Michael Balzer wrote:

...

Soko,

polling may keep the car awake, that's also an issue on the Kia e-Niro IIRC.

Changing the PollState can only affect the car indirectly via the changed polls. Maybe you could add your code & a log?

Regarding the poll replies stopping, is that also reflected in a CAN log? Maybe the OBD gateway throttles if it sees too many requests? (Hopefully not…)

If the gateway does throttling: do you login to the OBD as a "tester" and keep the session active by periodically sending the "tester present" frame?

Regards, Michael

Am 02.08.20 um 19:30 schrieb Soko:

...

Heya again,

I'm trying to develop a detection for when the car is off/locked but I'm encountering a weird phenomena:

* Car is shut down and locked * OVMS connected * CAN poll for voltage (only one poll value active) with 30

secs

...

fails with error (so far nothing weird) * Unlock the car via car-key remote * Poll succeeds and I'm switching from PollState=0 to PollState=1 where I poll every 2 secs * Lock the car via car-key remote * _After 1 hour the polls still work and the car is active_

Is something like this known from other vehicles? So basically my car never shuts down :(

Another secondary weird thing: When increasing the time to 5 secs for PollState=1 the polls get no reply and after 20 secs I swap back to PollState=0. BUT the second the PollState changes the car replies again... Even more weirdness: When PollState=1 time is 10 secs and I swap back to Pollstate=0 after 40 secs the same thing happens! Immediately I swap to PollState=0 the car replies again. As if the PollState switching somehow wakes the car up??!

Any ideas?

Soko

_______________________________________________ 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 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 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

OK, thanks heaps. Just to clarify: So if I know my session code I replace your 0xC0 with it, correct? Is this session code global for all ECUs and static? The wiki link for UDS speaks about different sessions... Does this one source code line also take care about the "tester present" message? Your pacience with me is highly appreciated :) Soko On 8 August 2020 19:47:45 CEST, Michael Balzer <dexter@expeedo.de> wrote:

Soko,

https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master...

as simple as that. But you need to know the session code you need to use for the gateway. 0xC0 is in the manufacturer specific range.

I would test the gateway behaviour using manual CAN commands, a script or a web plugin. That way you're much more flexible.

Regards, Michael

Am 08.08.20 um 19:09 schrieb Soko:

...

Hmmm... ok lets forget the 2nd log and talk about the first one. It must somehow be related to OVMS though as the replies get in immediately I swap the poll states. If I change the threshold from 5 secs to 3 or to 6 its always the same: once the poll state swaps the replies come in. So it must be related to the poll stat switch. The canlog shows all polls look the same... so the gateway must get confused every time exactly when the threshold*4 is over? Hmmm... or maybe the gateway gets confused after a certain number of polls. So the threshold doesnt matter. When I change the factor 4 to i.e. 6 I could validate this hypothesis.

Havent had time for session implementation yet. Is there a OVMS framework for a tester session? Or at least a vehicle implementation which does it?

On 8 August 2020 16:58:25 CEST, Michael Balzer <dexter@expeedo.de> wrote:

Soko,

lines 33 and 34 of your second log are due to the CAN TX buffer, which seems to have held back the frame until the bus became available.

Besides that, I don't see an RX in that log after switching the polling state. So I assume the RX in your first log also isn't related to the poll state switch.

There is an RX buffer, but that's just the internal queue of the vehicle CAN listener task. There is no delay on the processing unless you block the task somehow, for example by doing long term loops / communication in that context (which you shouldn't do).

You still don't send a session login or tester presence, so maybe the gateway is simply confused by the requests, runs into some timeout, then restarts… something like that.

Regards, Michael

Am 08.08.20 um 13:20 schrieb Soko:

...

Soooo....

I've finally found time to test this again.

Basically the same behaviour as described below.

*VWUP_OFF_TICKER_THRESHOLD 5 with 4 trys.log* Car was locked initially. Unlocked the car before line 21

(around

...

time mark 60.000). Locked around time mark 80.000. Car stayed responsive until line 108 (time mark 100.000). At line 130 (tm=116.814) I swap back to PollState=0. The poll

for

...

PollState=0 gets an immediate reply (line 131-133) and therefore I swap back to PollState=1. The weird thing is that line 132 (which got a reply) is exactly the same as 126 (or 118 or 110) which didn't get a reply!?!? So the car has no idea of the poll states as the data is the same? There must be some issue/bug/behavior inside OVMS (maybe even in the hardware buffer) which gets triggered by a PollState change. Or the canlog-monitor uses somehow a cache and doesn't show the messages immediately.

*VWUP_OFF_TICKER_THRESHOLD 10 with 4 trys.log* Same as below. One thing I've noticed though: Car was locked until line 32 (tm=63.814). Then I've unlocked it and the lines

33

...

and 34 showed up immediately. This indicates a buffer/cache/etc. issue with the canlog-monitor as well (imho).

Soko

On 03.08.2020 13:10, Michael Balzer wrote:

...

Soko,

I don't see any obvious mistakes on a first check.

Please do the tests again with CAN monitoring, so we can see what's actually going on on the bus.

An OBD device normally logs into the device sending a UDS diag session command (0x10), then keeps that session alive by

sending

...

...

tester present (0x3E) evers 30-60 seconds. See the UDS documentation I sent you, or for an overview, see https://de.wikipedia.org/wiki/Unified_Diagnostic_Services

You should be able to get the session type and protocol by logging what your VCDS does on the bus.

Regards, Michael

Am 03.08.20 um 06:19 schrieb Soko:

...

Mornin,

Source is here:

https://github.com/devmarxx/Open-Vehicle-Monitoring-System-3/tree/master/veh...

...

...

Attached are two logs. I haven't had the can-monitor active unfortuantely..

*VWUP_OFF_TICKER_THRESHOLD 5 with 4 trys.log* As the name says it polls every 5 seconds in PollState=1 and swaps back to PollState=0 after 5*4=20 seconds. Until line 35 you see the CAN errors as the vehicle is OFF. Then I unlocked the car and in line 38 I get the first reply. Around line 90 I locked the car again. It polls, but gets no reply, _but not error either_ (?!). Line 118 sets the PollState=0 and suddenly a response comes

in.

...

So in Line 123 I set the PollState=1 again. The the game starts again: Polls get send, no reply but no error either. After 21 CarOffTickers I switch to PollState=0 and suddenly a reply comes in...

*VWUP_OFF_TICKER_THRESHOLD 10 with 4 trys.log *Here I unlocked at line 57 and locked around line 100. After that polls get send, no reply, _but errors happen_. And the

car

...

is finally off. Although I've tried the same thing later that day and the car didn't even go to sleep with Threshold=30!?!? So the behavior is not 100% reproducible (yet)...

@gateway throttling: In VCDS (which - hopefully - does only polling too) I have a little number showing me the refresh rates of the values. It indicates ~8 refreshes per second. So with 1 second shouldn't be any throttling.

@OBD "tester": I have no clue what this is ;) So if the

polling

...

framework doesn't do it, I don't do it. All I do is in the obd_eup.* files.

Soko

On 02.08.2020 20:12, Michael Balzer wrote:

...

Soko,

polling may keep the car awake, that's also an issue on the Kia e-Niro IIRC.

Changing the PollState can only affect the car indirectly via the changed polls. Maybe you could add your code & a log?

Regarding the poll replies stopping, is that also reflected

in

...

...

a CAN log? Maybe the OBD gateway throttles if it sees too

many

...

requests? (Hopefully not…)

If the gateway does throttling: do you login to the OBD as a "tester" and keep the session active by periodically sending the "tester present" frame?

Regards, Michael

Am 02.08.20 um 19:30 schrieb Soko: > > Heya again, > > I'm trying to develop a detection for when the car is > off/locked but I'm encountering a weird phenomena: > > * Car is shut down and locked > * OVMS connected > * CAN poll for voltage (only one poll value active) with

30

...

> secs fails with error (so far nothing weird) > * Unlock the car via car-key remote > * Poll succeeds and I'm switching from PollState=0 to > PollState=1 where I poll every 2 secs > * Lock the car via car-key remote > * _After 1 hour the polls still work and the car is active_ > > Is something like this known from other vehicles? So > basically my car never shuts down :( > > Another secondary weird thing: > When increasing the time to 5 secs for PollState=1 the polls > get no reply and after 20 secs I swap back to PollState=0. > BUT the second the PollState changes the car replies again... > Even more weirdness: When PollState=1 time is 10 secs and I > swap back to Pollstate=0 after 40 secs the same thing > happens! Immediately I swap to PollState=0 the car replies again. > As if the PollState switching somehow wakes the car up??! > > Any ideas? > > Soko > > > _______________________________________________ > 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 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 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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

Hi, Last time I investigated this as I will use the 12V to determine if the car is running (>13.5V means on. Also true for charging). So out of curiosity and so we have my tests in one email combined. In addition I felt I've mixed up some tests & results so I wanted to do it one more time to make sure... I've tried the same source again. Just polling the HV-Battery voltage. In Pollstate=0 every 30 seconds. Once a Poll gets an reply I swap to Pollstate=1 with polling every "threshold" seconds. Tries=X mean how many counts do I wait until I swap the PollState back to 0. Tries=4 means 4 times the threshold. The test workflow is: 1. Car is locked and shut down (no fan noise heard) 2. Wait until I get an CAN error 3. Unlock car 4. Wait until I get the first Poll reply 5. Lock car There are 3 possible outcomes after step 5: 1. The car stays on, fan noise heard, it replies to every poll, never swap back to PollState=0 2. The car stays on, fan noise heard, it doesn't reply to the polls, swap back to PollState=0 happens, but immediately after I get one reply 3. The car shuts down, no fan noise, CAN errors happen for polls, swap back to PollState=0 happens I really don't understand whats going on here, but here is the table. Columns=tries, Rows=threshold, cell=outcome threshold/tries 3 4 5 6 8 3 1 4 1 5 3 2 2 2 2 6 3 7 3 10 3 What I really don't get is why with shorter tries the car shuts off (as it should) and longer tries keep it awake so long Soko On 08.08.2020 16:58, Michael Balzer wrote:

Soko,

lines 33 and 34 of your second log are due to the CAN TX buffer, which seems to have held back the frame until the bus became available.

Besides that, I don't see an RX in that log after switching the polling state. So I assume the RX in your first log also isn't related to the poll state switch.

There is an RX buffer, but that's just the internal queue of the vehicle CAN listener task. There is no delay on the processing unless you block the task somehow, for example by doing long term loops / communication in that context (which you shouldn't do).

You still don't send a session login or tester presence, so maybe the gateway is simply confused by the requests, runs into some timeout, then restarts… something like that.

Regards, Michael

Am 08.08.20 um 13:20 schrieb Soko:

...

Soooo....

I've finally found time to test this again.

Basically the same behaviour as described below.

*VWUP_OFF_TICKER_THRESHOLD 5 with 4 trys.log* Car was locked initially. Unlocked the car before line 21 (around time mark 60.000). Locked around time mark 80.000. Car stayed responsive until line 108 (time mark 100.000). At line 130 (tm=116.814) I swap back to PollState=0. The poll for PollState=0 gets an immediate reply (line 131-133) and therefore I swap back to PollState=1. The weird thing is that line 132 (which got a reply) is exactly the same as 126 (or 118 or 110) which didn't get a reply!?!? So the car has no idea of the poll states as the data is the same? There must be some issue/bug/behavior inside OVMS (maybe even in the hardware buffer) which gets triggered by a PollState change. Or the canlog-monitor uses somehow a cache and doesn't show the messages immediately.

*VWUP_OFF_TICKER_THRESHOLD 10 with 4 trys.log* Same as below. One thing I've noticed though: Car was locked until line 32 (tm=63.814). Then I've unlocked it and the lines 33 and 34 showed up immediately. This indicates a buffer/cache/etc. issue with the canlog-monitor as well (imho).

Soko

On 03.08.2020 13:10, Michael Balzer wrote:

...

Soko,

I don't see any obvious mistakes on a first check.

Please do the tests again with CAN monitoring, so we can see what's actually going on on the bus.

An OBD device normally logs into the device sending a UDS diag session command (0x10), then keeps that session alive by sending tester present (0x3E) evers 30-60 seconds. See the UDS documentation I sent you, or for an overview, see https://de.wikipedia.org/wiki/Unified_Diagnostic_Services

You should be able to get the session type and protocol by logging what your VCDS does on the bus.

Regards, Michael

Am 03.08.20 um 06:19 schrieb Soko:

...

Mornin,

Source is here: https://github.com/devmarxx/Open-Vehicle-Monitoring-System-3/tree/master/veh...

Attached are two logs. I haven't had the can-monitor active unfortuantely..

*VWUP_OFF_TICKER_THRESHOLD 5 with 4 trys.log* As the name says it polls every 5 seconds in PollState=1 and swaps back to PollState=0 after 5*4=20 seconds. Until line 35 you see the CAN errors as the vehicle is OFF. Then I unlocked the car and in line 38 I get the first reply. Around line 90 I locked the car again. It polls, but gets no reply, _but not error either_ (?!). Line 118 sets the PollState=0 and suddenly a response comes in. So in Line 123 I set the PollState=1 again. The the game starts again: Polls get send, no reply but no error either. After 21 CarOffTickers I switch to PollState=0 and suddenly a reply comes in...

*VWUP_OFF_TICKER_THRESHOLD 10 with 4 trys.log *Here I unlocked at line 57 and locked around line 100. After that polls get send, no reply, _but errors happen_. And the car is finally off. Although I've tried the same thing later that day and the car didn't even go to sleep with Threshold=30!?!? So the behavior is not 100% reproducible (yet)...

@gateway throttling: In VCDS (which - hopefully - does only polling too) I have a little number showing me the refresh rates of the values. It indicates ~8 refreshes per second. So with 1 second shouldn't be any throttling.

@OBD "tester": I have no clue what this is ;) So if the polling framework doesn't do it, I don't do it. All I do is in the obd_eup.* files.

Soko

On 02.08.2020 20:12, Michael Balzer wrote:

...

Soko,

polling may keep the car awake, that's also an issue on the Kia e-Niro IIRC.

Changing the PollState can only affect the car indirectly via the changed polls. Maybe you could add your code & a log?

Regarding the poll replies stopping, is that also reflected in a CAN log? Maybe the OBD gateway throttles if it sees too many requests? (Hopefully not…)

If the gateway does throttling: do you login to the OBD as a "tester" and keep the session active by periodically sending the "tester present" frame?

Regards, Michael

Am 02.08.20 um 19:30 schrieb Soko:

...

Heya again,

I'm trying to develop a detection for when the car is off/locked but I'm encountering a weird phenomena:

* Car is shut down and locked * OVMS connected * CAN poll for voltage (only one poll value active) with 30 secs fails with error (so far nothing weird) * Unlock the car via car-key remote * Poll succeeds and I'm switching from PollState=0 to PollState=1 where I poll every 2 secs * Lock the car via car-key remote * _After 1 hour the polls still work and the car is active_

Is something like this known from other vehicles? So basically my car never shuts down :(

Another secondary weird thing: When increasing the time to 5 secs for PollState=1 the polls get no reply and after 20 secs I swap back to PollState=0. BUT the second the PollState changes the car replies again... Even more weirdness: When PollState=1 time is 10 secs and I swap back to Pollstate=0 after 40 secs the same thing happens! Immediately I swap to PollState=0 the car replies again. As if the PollState switching somehow wakes the car up??!

Any ideas?

Soko

_______________________________________________ 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 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 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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev

Mark, I remember the current Leaf also has the issue of the OBD port being filtered by a gateway to only support polling. I think we should generally add a +12V ignition signal detection to the next OVMS hardware revision, i.e. without the need to add extra hardware. There is no standard for the ignition / switched +12V being available at the OBD port, but I think most cars will have that. If a car doesn't, it should still be easy to get from around the OBD port (e.g. fuses). Regards, Michael Am 02.08.20 um 11:03 schrieb Soko:

Meaning: We need a special VW-cable (like for the NIssan or Kia Soul) with OBD Pin1 gets into a pin on the DB9 connector and into a Digital-In-Pin on the OVMS. A voltage divider is needed as well as +12V on OBD-Pin1 signals "ignition on".

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

The re-certification requirement is a PITA for hardware evolution. But I'm ok with extending the K-line board, many OBD vehicles will still have K-line devices (even the Twizy's UCH and airbag modules are on K-line / KWP2000). Regarding the DB9, can't we use pin 1 (GEP_7) for this? Regards, Michael Am 03.08.20 um 04:21 schrieb Mark Webb-Johnson:

It is hard to modify the main board, without voiding the certifications we have (and going through the expense of re-certifying).

Simplest would be to implement this on an expansion board. Perhaps extend the K-line board we have to do other functions (12v switched status, relay control, etc)?

The DB9 is full (all 9 pins assigned), so this would have to be via DA26.

We have been using the EGPIO lines for system use, starting at #0 and working upwards:

* #0 MDM_EN (modem enable) * #1 SW_CTL (external 12v control) * #2 CAN1_EN (can#1 enable) * #3 MDM_DTR (modem DTR)

Then expansion boards should start at #9 and work downwards:

* #9 K-line enable (on k-line expansion board)

I guess we need just a simple voltage divider, and pull down, to determine on/off state of switched 12v?

Regards, Mark.

P.S. I have been hoping that Espressif would release a successor to the ESP32 with more RAM and GPIO pins, but it looks like the prefer to go lower performance/spec, rather than up.

...

On 2 Aug 2020, at 5:47 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:

Mark,

I remember the current Leaf also has the issue of the OBD port being filtered by a gateway to only support polling.

I think we should generally add a +12V ignition signal detection to the next OVMS hardware revision, i.e. without the need to add extra hardware.

There is no standard for the ignition / switched +12V being available at the OBD port, but I think most cars will have that. If a car doesn't, it should still be easy to get from around the OBD port (e.g. fuses).

Regards, Michael

Am 02.08.20 um 11:03 schrieb Soko:

...

Meaning: We need a special VW-cable (like for the NIssan or Kia Soul) with OBD Pin1 gets into a pin on the DB9 connector and into a Digital-In-Pin on the OVMS. A voltage divider is needed as well as +12V on OBD-Pin1 signals "ignition on".

-- 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

One more thought from a newbie to this issue which just came to my mind... Where is the added value of this expensive solution compared to just reading the 12V voltage. My eUp measures 12.6V when its shut down and 14.4V when its ready-to-drive/driving or charging. Soko On 03.08.2020 08:31, Mark Webb-Johnson wrote:

DB9 pin #1 is used for k-line. I guess it could be re-used for two purposes (on an expansion card).

That said, it would make the cabling a little tricky. The DB9 12V is permanent. Having a 12v switched supply as well would presumably mean a loose wire coming out of the cable? Seems easier to just make a simple DA26 cable with just 1 pin connected to a loose wire (or other wire outputs for relay, and general inputs, etc) - kind of why I was thinking of making this a more sophisticated board.

Regards, Mark.

...

On 3 Aug 2020, at 1:26 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:

The re-certification requirement is a PITA for hardware evolution. But I'm ok with extending the K-line board, many OBD vehicles will still have K-line devices (even the Twizy's UCH and airbag modules are on K-line / KWP2000).

Regarding the DB9, can't we use pin 1 (GEP_7) for this?

Regards, Michael

Am 03.08.20 um 04:21 schrieb Mark Webb-Johnson:

...

It is hard to modify the main board, without voiding the certifications we have (and going through the expense of re-certifying).

Simplest would be to implement this on an expansion board. Perhaps extend the K-line board we have to do other functions (12v switched status, relay control, etc)?

The DB9 is full (all 9 pins assigned), so this would have to be via DA26.

We have been using the EGPIO lines for system use, starting at #0 and working upwards:

* #0 MDM_EN (modem enable) * #1 SW_CTL (external 12v control) * #2 CAN1_EN (can#1 enable) * #3 MDM_DTR (modem DTR)

Then expansion boards should start at #9 and work downwards:

* #9 K-line enable (on k-line expansion board)

I guess we need just a simple voltage divider, and pull down, to determine on/off state of switched 12v?

Regards, Mark.

P.S. I have been hoping that Espressif would release a successor to the ESP32 with more RAM and GPIO pins, but it looks like the prefer to go lower performance/spec, rather than up.

...

On 2 Aug 2020, at 5:47 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:

Mark,

I remember the current Leaf also has the issue of the OBD port being filtered by a gateway to only support polling.

I think we should generally add a +12V ignition signal detection to the next OVMS hardware revision, i.e. without the need to add extra hardware.

There is no standard for the ignition / switched +12V being available at the OBD port, but I think most cars will have that. If a car doesn't, it should still be easy to get from around the OBD port (e.g. fuses).

Regards, Michael

Am 02.08.20 um 11:03 schrieb Soko:

...

Meaning: We need a special VW-cable (like for the NIssan or Kia Soul) with OBD Pin1 gets into a pin on the DB9 connector and into a Digital-In-Pin on the OVMS. A voltage divider is needed as well as +12V on OBD-Pin1 signals "ignition on".

-- 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

Hey guys, I'm wondering how the poller ticker works as it seems it doesn't poll as frequently as expected. Here are my (simplified) polls: const OvmsVehicle::poll_pid_t vwup_polls[] = {     {VWUP_CHARGER_TX, VWUP_CHARGER_RX, VEHICLE_POLL_TYPE_OBDIIEXTENDED, VWUP_CHARGER_AC_U, {0, 0, 5}},     {VWUP_CHARGER_TX, VWUP_CHARGER_RX, VEHICLE_POLL_TYPE_OBDIIEXTENDED, VWUP_CHARGER_AC_I, {0, 0, 5}},     {VWUP_BAT_MGMT_TX, VWUP_BAT_MGMT_RX, VEHICLE_POLL_TYPE_OBDIIEXTENDED, VWUP_BAT_MGMT_U, {0, 1, 5}},     {VWUP_BAT_MGMT_TX, VWUP_BAT_MGMT_RX, VEHICLE_POLL_TYPE_OBDIIEXTENDED, VWUP_BAT_MGMT_I, {0, 1, 5}},     {VWUP_BAT_MGMT_TX, VWUP_BAT_MGMT_RX, VEHICLE_POLL_TYPE_OBDIIEXTENDED, VWUP_BAT_MGMT_SOC, {0, 20, 20}},     {0, 0, 0, 0, {0, 0, 0}}}; I was expecting to get both voltages and currents every 5 seconds and just milliseconds apart from each other. And (of course) every 20 seconds the SoC. But I get one of the first four every seconds (taking 4 seconds in total until a I have all) and SoC only ~40 seconds. Is there some way to change the poller to the expected behavior? I would like the first 4 very close to each other so I can calculate AC power, DC power and therefore the efficiency of the charging process. thx Soko

Okeydokey, I'll give it a try and let you know On 12.08.2020 17:36, Michael Balzer wrote:

Soko,

by history of it's origin in the V2 module, the poller currently is only called by the ticker, so runs once per second, and is limited to processing one request at a time. A response may consist of multiple frames (automatically requested by the receiver). The poller doesn't know when/if a request is completed / cancelled.

It should be pretty simple to allow PollerSend() to be called anytime, e.g. by the IncomingPollReply() handler as soon as it detects a completed response.

From a quick glance, the only change necessary for this should be adding a control argument to PollerSend() that inhibits the m_poll_ticker increment & cycling.

You would e.g. call PollerSend(false) in IncomingPollReply() to check for any more polls to be done in the current poller second (m_poll_ticker value). If none is found, the poller exits and leaves the next call to the ticker again. The default (ticker) PollerSend() behaviour remains the same as now.

Do you want to try implementing that change? You can test it on your polls directly. If you submit the change, please keep it in a separate commit / pull request, don't mix it with some UpMiiGo changes.

Regards, Michael

Am 12.08.20 um 15:47 schrieb Soko:

...

Hey guys,

I'm wondering how the poller ticker works as it seems it doesn't poll as frequently as expected. Here are my (simplified) polls:

const OvmsVehicle::poll_pid_t vwup_polls[] = {     {VWUP_CHARGER_TX, VWUP_CHARGER_RX, VEHICLE_POLL_TYPE_OBDIIEXTENDED, VWUP_CHARGER_AC_U, {0, 0, 5}},     {VWUP_CHARGER_TX, VWUP_CHARGER_RX, VEHICLE_POLL_TYPE_OBDIIEXTENDED, VWUP_CHARGER_AC_I, {0, 0, 5}},     {VWUP_BAT_MGMT_TX, VWUP_BAT_MGMT_RX, VEHICLE_POLL_TYPE_OBDIIEXTENDED, VWUP_BAT_MGMT_U, {0, 1, 5}},     {VWUP_BAT_MGMT_TX, VWUP_BAT_MGMT_RX, VEHICLE_POLL_TYPE_OBDIIEXTENDED, VWUP_BAT_MGMT_I, {0, 1, 5}},     {VWUP_BAT_MGMT_TX, VWUP_BAT_MGMT_RX, VEHICLE_POLL_TYPE_OBDIIEXTENDED, VWUP_BAT_MGMT_SOC, {0, 20, 20}},     {0, 0, 0, 0, {0, 0, 0}}};

I was expecting to get both voltages and currents every 5 seconds and just milliseconds apart from each other. And (of course) every 20 seconds the SoC.

But I get one of the first four every seconds (taking 4 seconds in total until a I have all) and SoC only ~40 seconds.

Is there some way to change the poller to the expected behavior?

I would like the first 4 very close to each other so I can calculate AC power, DC power and therefore the efficiency of the charging process.

thx

Soko

_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

Hey guys, Just want to let you know on this way as well about the two pull requests I have opened yesterday. Let me know your thoughts. Would be cool if they will be merged very soon so I can continue my work on the VW e-Up. regards, Soko

I'm not quite sure if we should discuss this here or in the pull request itself. Maybe Mark or Michael should say whats best. Anyhow... Let me put you to ease with my /answers below.../ On 14.08.2020 09:18, Chris van der Meijden wrote:

Hey Soko,

sorry I don't agree on this pull request. /Just to make things clear with the other guys: You are talking about one of the pull requests, the one with the source split./

We have already discussed this.

Lets put this straight. My code for the T26A part is not ready yet. Climate control is still very buggy and it would confuse the user to have such a buggy feature within a possible OVMS release. It will take me probably a week or two, maybe longer, to get the climate control fixed. Then we can do a pull request to the master.

/The T26A code in my pull request is not the one from your fork. It's the one that is officially in the master branch of openvehicles. So nothing changes for the user and not one source line is different then before./

An other point we also talked about, is that you have not documented your OBD part at all. This is also not acceptable. You can't put features with in the official OVMS repository that are not documented at all. How does the user use your VW e-Up OBD part? What hardware is needed? Where does the user see the results in the webfrontend? Does the app work with your code? ...

/The user is not able to use any of the OBD code as pointed out in the pull request description. This is more an esthetic question as the code is not active. If the others feel the same I can remove my obd_*.* files from the pull request. The outcome is the same... /

You can't put unready code in the master.

That is the reason why we use forks. We merge a fork when we have kind of stable code with features that are well documented.

This is not the case at the moment with the splitted VW e-Up code.

/To sum up: Nothing at all changes for the user with me my pull request. Well... besides the name of the VW e-Up vehicle. But is taken care of in the upgrade method./ /I even prepared everything so you have it as easy as possible when this pull request is put into the master: When you pull it your fork you only have to backup your three t26_*.* files from your fork. Then just take 1:1 the openvehicles-master and put your backup back. At least that's how I would do it as I'm not familiar how this is done in git directly ;)/

Regards

Chris

Am Freitag, den 14.08.2020, 07:06 +0200 schrieb Soko:

...

Hey guys,

Just want to let you know on this way as well about the two pull requests I have opened yesterday.

Let me know your thoughts. Would be cool if they will be merged very soon so I can continue my work on the VW e-Up.

regards,

Soko

_______________________________________________ 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

I see the point in not having unfinished code in the master so I removed my OBD implementation from this pull request. Whats left is just the same source as before but with preparation for the OBD part. @others: Please let me know your thoughts On 14.08.2020 10:56, Chris van der Meijden wrote:

I agree on not further discussing this. I made my point.

Chris

Am Freitag, den 14.08.2020, 10:02 +0200 schrieb Soko:

...

I'm not quite sure if we should discuss this here or in the pull request itself. Maybe Mark or Michael should say whats best. Anyhow... Let me put you to ease with my /answers below.../

On 14.08.2020 09:18, Chris van der Meijden wrote:

...

Hey Soko,

sorry I don't agree on this pull request. /Just to make things clear with the other guys: You are talking about one of the pull requests, the one with the source split./

We have already discussed this.

Lets put this straight. My code for the T26A part is not ready yet. Climate control is still very buggy and it would confuse the user to have such a buggy feature within a possible OVMS release. It will take me probably a week or two, maybe longer, to get the climate control fixed. Then we can do a pull request to the master.

/The T26A code in my pull request is not the one from your fork. It's the one that is officially in the master branch of openvehicles. So nothing changes for the user and not one source line is different then before./

...

An other point we also talked about, is that you have not documented your OBD part at all. This is also not acceptable. You can't put features with in the official OVMS repository that are not documented at all. How does the user use your VW e-Up OBD part? What hardware is needed? Where does the user see the results in the webfrontend? Does the app work with your code? ...

/The user is not able to use any of the OBD code as pointed out in the pull request description. This is more an esthetic question as the code is not active. If the others feel the same I can remove my obd_*.* files from the pull request. The outcome is the same... /

...

You can't put unready code in the master.

That is the reason why we use forks. We merge a fork when we have kind of stable code with features that are well documented.

This is not the case at the moment with the splitted VW e-Up code.

/To sum up: Nothing at all changes for the user with me my pull request. Well... besides the name of the VW e-Up vehicle. But is taken care of in the upgrade method./

/I even prepared everything so you have it as easy as possible when this pull request is put into the master: When you pull it your fork you only have to backup your three t26_*.* files from your fork. Then just take 1:1 the openvehicles-master and put your backup back. At least that's how I would do it as I'm not familiar how this is done in git directly ;)/

...

Regards

Chris

Am Freitag, den 14.08.2020, 07:06 +0200 schrieb Soko:

...

Hey guys,

Just want to let you know on this way as well about the two pull requests I have opened yesterday.

Let me know your thoughts. Would be cool if they will be merged very soon so I can continue my work on the VW e-Up.

regards,

Soko

_______________________________________________ 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

Hi Mark, I was trying to do a PR from my master branch as you suggest. My issue was that I've had separate 2 PRs so I had to do 2 branches and 1 PR from each branch. I didn't see any other possibility but I am no git expert and happy to learn. thx Soko On 17 August 2020 05:39:54 CEST, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

I see the discussion on the pull request itself is happening on the pull request and Michael is assisting.

Regarding the process, I think in general we need to keep the core system stable and it is best not to commit partial implementations. I myself sometime violate that rule, but try not to. The better approach is to create a branch and do the work there (committing and sharing to others as you wish). Then, when all is done and ready, you can merge that branch in to master and submit a pull request. These branches can be either local (private) or on your GitHub clone (public). In rare cases, we also publish branches on the main openvehicles GitHub repository (for example, the SPIRAM branch that was there for a year before merging to master, and the upcoming 3.3 branch I am about to create for the changes to move from v3.2 -> v3.3).

Regards, Mark.

...

On 14 Aug 2020, at 5:18 PM, Soko <ovms@soko.cc> wrote:

I see the point in not having unfinished code in the master so I removed my OBD implementation from this pull request. Whats left is just the same source as before but with preparation for the OBD part.

@others: Please let me know your thoughts

On 14.08.2020 10:56, Chris van der Meijden wrote:

...

I agree on not further discussing this. I made my point.

Chris

Am Freitag, den 14.08.2020, 10:02 +0200 schrieb Soko:

...

I'm not quite sure if we should discuss this here or in the pull request itself. Maybe Mark or Michael should say whats best. Anyhow... Let me put you to ease with my answers below...

On 14.08.2020 09:18, Chris van der Meijden wrote:

...

Hey Soko,

sorry I don't agree on this pull request. Just to make things clear with the other guys: You are talking about one of the pull requests, the one with the source split.

We have already discussed this.

Lets put this straight. My code for the T26A part is not ready yet. Climate control is still very buggy and it would confuse the user to have such a buggy feature within a possible OVMS release. It will take me probably a week or two, maybe longer, to get the climate control fixed. Then we can do a pull request to the master. The T26A code in my pull request is not the one from your fork. It's the one that is officially in the master branch of openvehicles. So nothing changes for the user and not one source line is different then before.

...

An other point we also talked about, is that you have not

documented your OBD part at all. This is also not acceptable. You can't put features with in the official OVMS repository that are not documented at all. How does the user use your VW e-Up OBD part? What hardware is needed? Where does the user see the results in the webfrontend? Does the app work with your code? ... The user is not able to use any of the OBD code as pointed out in the pull request description. This is more an esthetic question as the code is not active. If the others feel the same I can remove my obd_*.* files from the pull request. The outcome is the same...

...

You can't put unready code in the master.

That is the reason why we use forks. We merge a fork when we have

kind of stable code with features that are well documented.

...

This is not the case at the moment with the splitted VW e-Up code.

To sum up: Nothing at all changes for the user with me my pull request. Well... besides the name of the VW e-Up vehicle. But is taken care of in the upgrade method.

I even prepared everything so you have it as easy as possible when this pull request is put into the master: When you pull it your fork you only have to backup your three t26_*.* files from your fork. Then just take 1:1 the openvehicles-master and put your backup back. At least that's how I would do it as I'm not familiar how this is done in git directly ;)

...

Regards

Chris

Am Freitag, den 14.08.2020, 07:06 +0200 schrieb Soko:

...

Hey guys,

Just want to let you know on this way as well about the two pull requests I have opened yesterday.

Let me know your thoughts. Would be cool if they will be merged

very

...

...

soon so I can continue my work on the VW e-Up.

regards,

Soko

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

---

OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

Soko, was the charger actually working, i.e. charge in progress? If not, maybe it goes asleep as soon as the 12V aux battery is topped off, and another ignition state change simply reactivates the topping off cycle. Regards, Michael Am 16.08.20 um 16:28 schrieb Soko:

Hi guys,

Question for the CAN and ECU experts:

I am logging into the battery charger ECU on my eUp via the extended diag session code. Otherwise I get 7F as reply.

I am interested in the power efficiency (pe) and power loss (pl) values.

It seems though as they have another timeout than the ext diag session as I am polling it every 5 seconds. So ext diag is "always on".

But after 20 minutes during charging the values change from the realistic ones to pe=100% and pl=0. To get the real values back I have to unlock the car and turn the ignition. Then I can turn off and lock the car again.

Now to the question: Is this behaviour somehow known from other vehicles as well or can it be an error in my code not sending the ext diag msg correctly?

Although when I dont send it at all I dont get even a value for pe and pl, just the 7F error msg.

So do you think it is possible to get those values for longer than 20 mins without having to turn the ignition? Or am I out of luck here as it seems to be some VW specific thing...

thx Soko

_______________________________________________ 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

Hi Michael, Just to make sure: I'm talking about charging the main battery, not the 12V battery. But I didn't check the status of the 12V battery. But it would be weird to happen 2 times during a charging process exactly after 20 mins. What I did is to log a complete main battery charge. Results/Details see here: https://www.goingelectric.de/forum/viewtopic.php?p=1327718#p1327718 To your 2nd email: Yes, the values are for the DC converter of the main battery, not the one for the 12V battery. All values are from this ECU: https://www.goingelectric.de/wiki/VW-e-up-OBD2-SGC6 Soko On 18.08.2020 11:54, Michael Balzer wrote:

Soko,

was the charger actually working, i.e. charge in progress? If not, maybe it goes asleep as soon as the 12V aux battery is topped off, and another ignition state change simply reactivates the topping off cycle.

Regards, Michael

Am 16.08.20 um 16:28 schrieb Soko:

...

Hi guys,

Question for the CAN and ECU experts:

I am logging into the battery charger ECU on my eUp via the extended diag session code. Otherwise I get 7F as reply.

I am interested in the power efficiency (pe) and power loss (pl) values.

It seems though as they have another timeout than the ext diag session as I am polling it every 5 seconds. So ext diag is "always on".

But after 20 minutes during charging the values change from the realistic ones to pe=100% and pl=0. To get the real values back I have to unlock the car and turn the ignition. Then I can turn off and lock the car again.

Now to the question: Is this behaviour somehow known from other vehicles as well or can it be an error in my code not sending the ext diag msg correctly?

Although when I dont send it at all I dont get even a value for pe and pl, just the 7F error msg.

So do you think it is possible to get those values for longer than 20 mins without having to turn the ignition? Or am I out of luck here as it seems to be some VW specific thing...

thx Soko

_______________________________________________ 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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev

Yeah, I've also thought about VCDS but when I used it during charging it was just for a couple of minutes and the ignition was on all the time as I was getting a hole bunch of data and values from it... So another fork of the whole e-Up via OBD project I should investigate. It doesn't get boring for sure :D On 18.08.2020 12:41, Michael Balzer wrote:

Soko,

integrating the 12V DC converter with the main charger can be convenient, as the 12V battery also will need to be charged from the main battery. But it doesn't look like it's done that way on the eUp.

I guess the charger only provides these additional calculations when another unit requested them. As the other unit goes offline, the charger stops providing after some timeout. You'll need to know which unit talks in what way to the charger -- but the gateway won't let you see that. I think you'll need to get access to the unfiltered bus to see what's actually going on.

Or maybe the VCDS continues displaying these values? Then you can log & mimic what that does.

Regards, Michael

Am 18.08.20 um 12:00 schrieb Soko:

...

Hi Michael,

Just to make sure: I'm talking about charging the main battery, not the 12V battery. But I didn't check the status of the 12V battery. But it would be weird to happen 2 times during a charging process exactly after 20 mins. What I did is to log a complete main battery charge. Results/Details see here: https://www.goingelectric.de/forum/viewtopic.php?p=1327718#p1327718

To your 2nd email: Yes, the values are for the DC converter of the main battery, not the one for the 12V battery. All values are from this ECU: https://www.goingelectric.de/wiki/VW-e-up-OBD2-SGC6

Soko

On 18.08.2020 11:54, Michael Balzer wrote:

...

Soko,

was the charger actually working, i.e. charge in progress? If not, maybe it goes asleep as soon as the 12V aux battery is topped off, and another ignition state change simply reactivates the topping off cycle.

Regards, Michael

Am 16.08.20 um 16:28 schrieb Soko:

...

Hi guys,

Question for the CAN and ECU experts:

I am logging into the battery charger ECU on my eUp via the extended diag session code. Otherwise I get 7F as reply.

I am interested in the power efficiency (pe) and power loss (pl) values.

It seems though as they have another timeout than the ext diag session as I am polling it every 5 seconds. So ext diag is "always on".

But after 20 minutes during charging the values change from the realistic ones to pe=100% and pl=0. To get the real values back I have to unlock the car and turn the ignition. Then I can turn off and lock the car again.

Now to the question: Is this behaviour somehow known from other vehicles as well or can it be an error in my code not sending the ext diag msg correctly?

Although when I dont send it at all I dont get even a value for pe and pl, just the 7F error msg.

So do you think it is possible to get those values for longer than 20 mins without having to turn the ignition? Or am I out of luck here as it seems to be some VW specific thing...

thx Soko

_______________________________________________ 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 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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev

Soko, user plugins currently cannot override system pages. That's by design for security and system stability. Compiled modules OTOH can override all system page handlers simply by calling MyWebServer.RegisterPage() on the URI to replace, passing their own handler. The default behaviour of the API call is to replace an existing handler. Before replacing the dashboard completely, consider customizing and/or extending it. The dashboard gauges can be customized by overriding the OvmsVehicle::GetDashboardConfig() method. See OvmsVehicleRenaultTwizy::GetDashboardConfig() for an example. Hook extensions (inline page callbacks) can be installed by users and by compiled modules. See: https://docs.openvehicles.com/en/latest/components/ovms_webserver/docs/hooks... …and the webserver's RegisterCallback() method. The dashboard provides the "body.pre" hook for extensions. See OvmsVehicleRenaultTwizy::WebExtDashboard() for a native code example adding a drive mode profile switcher to the dashboard. This example user plugin adds tuning sliders to the dashboard: https://docs.openvehicles.com/en/latest/components/ovms_webserver/docs/plugi... Regards, Michael Am 21.08.20 um 16:50 schrieb Soko:

Hey guys,

I've found the possibility of creating own pages via Web Plugins which is really great.

https://docs.openvehicles.com/en/latest/components/ovms_webserver/docs/dashb... talks of installing your own dashboard by using exactly this feature.

Is it possible though to replace the default Dashboard link with my own page? So the default dashboard is gone and it uses my own page?

thx

Soko

_______________________________________________ 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

Hey everyone, I'm trying to send a simple tcp msg to a remote tcp-server. I've looked into the FreeRTOS example (esp-idf\examples\protocols\sockets\tcp_client\) which works (kinda) but OVMS behaves weirdly when I do it like that. Thomas pointed me to mongoose... So is this the way to go? I would take canlog_tcpclient.cpp as a model... Ohh... and is it OK if I send my tcp msg in the vehcile task? Mongoose should take care of unforeseen errors so the task shouldn't block, right? thx Soko

Hi Mark, I have my own home automation running at home. I want to push the current values (SoC, odometer, ...) once my car is in the driveway and OVMS is booked into my WiFi. My home automation has a TCP server running were I process the data further. I don't want to the OVMS Server functionality as I'm not a Linux guy, don't want the data in the internet and no SIM use on the OVMS. So does the canlog_tcpclient.cpp take care of the concurrency etc. correctly? I will do the same in my code. Or should I start a separate task from the vehicle task for every push? thx Soko On 23 August 2020 16:37:46 CEST, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

What are you trying to do?

From a design point of view, it seems strange to have an outgoing tcp connection from a vehicle module. Those modules need to be very responsive and realtime.

Mongoose is the correct approach. But take care, because most of the work is done in the network (not vehicle) task, so you need to deal with mutex and other concurrency issues.

Regards, Mark

...

On 23 Aug 2020, at 7:54 PM, Soko <ovms@soko.cc> wrote:

Hey everyone,

I'm trying to send a simple tcp msg to a remote tcp-server. I've looked into the FreeRTOS example (esp-idf\examples\protocols\sockets\tcp_client\) which works (kinda) but OVMS behaves weirdly when I do it like that.

Thomas pointed me to mongoose...

So is this the way to go? I would take canlog_tcpclient.cpp as a model...

Ohh... and is it OK if I send my tcp msg in the vehcile task? Mongoose should take care of unforeseen errors so the task shouldn't block, right?

thx

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

Hi again, Before I decide how to do this I would like to explore the other way: My home automation is polling the data from OVMS. I have had a look to the HTTP API. But it seems this is an API for the server on the internet and not for OVMS itself, correct? Next option: My home automation does a simple HTTP-GET to OVMS and reads data like this. Is there a way to read metrics like this? I have found the config->webserver site. I could point it to an own dir like /store/data. Now I could write/update one file there from my vehicle-module called "current" with all the data I need. Then simply to a http-get to 192.168.4.1/current and I get the data of the file. Is it easy - and most important: allowed - to write/update into a file in OVMS. thanks heaps for the input Soko On 24.08.2020 01:46, Mark Webb-Johnson wrote:

The vehicle module is definitely the wrong place to do this.

If you really want to implement in C++, I suggest you look at the ovms_server_v3 module. You could use that as a template for what you need. It should periodically read from the metrics, and send what you need to your home automation.

You should also consider a javascript plugin to do this. That would probably be simpler and easier to update (without firmware changes). If it is a common home automation system, you could write it as a plugin and share for others with the same system.

Regards, Mark

...

On 24 Aug 2020, at 12:00 AM, Soko <ovms@soko.cc <mailto:ovms@soko.cc>> wrote:

Hi Mark,

I have my own home automation running at home. I want to push the current values (SoC, odometer, ...) once my car is in the driveway and OVMS is booked into my WiFi. My home automation has a TCP server running were I process the data further.

I don't want to the OVMS Server functionality as I'm not a Linux guy, don't want the data in the internet and no SIM use on the OVMS.

So does the canlog_tcpclient.cpp take care of the concurrency etc. correctly? I will do the same in my code. Or should I start a separate task from the vehicle task for every push?

thx Soko

On 23 August 2020 16:37:46 CEST, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:

What are you trying to do?

From a design point of view, it seems strange to have an outgoing tcp connection from a vehicle module. Those modules need to be very responsive and realtime.

Mongoose is the correct approach. But take care, because most of the work is done in the network (not vehicle) task, so you need to deal with mutex and other concurrency issues.

Regards, Mark

On 23 Aug 2020, at 7:54 PM, Soko <ovms@soko.cc <mailto:ovms@soko.cc>> wrote: Hey everyone, I'm trying to send a simple tcp msg to a remote tcp-server. I've looked into the FreeRTOS example (esp-idf\examples\protocols\sockets\tcp_client\) which works (kinda) but OVMS behaves weirdly when I do it like that. Thomas pointed me to mongoose... So is this the way to go? I would take canlog_tcpclient.cpp as a model... Ohh... and is it OK if I send my tcp msg in the vehcile task? Mongoose should take care of unforeseen errors so the task shouldn't block, right? thx Soko ------------------------------------------------------------------------ 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 <mailto: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

Soko, the webserver REST API provides a simple command execution endpoint you can use to execute Javascript code as well. See: - https://docs.openvehicles.com/en/latest/components/ovms_webserver/docs/index... The scripting system has a simple metrics getter and JSON encoder. See: - https://docs.openvehicles.com/en/latest/userguide/scripting.html#ovmsmetrics - https://docs.openvehicles.com/en/latest/userguide/scripting.html#json Example executing a shell command: - http://myovms.local/api/execute?apikey=mypassword&output=text&command=stat Example getting a single metric value: - http://myovms.local/api/execute?apikey=mypassword&type=js&output=text&command=print(OvmsMetrics.Value("v.b.soc")) Examples getting multiple metrics JSON encoded: - http://myovms.local/api/execute?apikey=mypassword&type=js&output=text&command=JSON.print(OvmsMetrics.GetValues("m.net.")) - http://myovms.local/api/execute?apikey=mypassword&type=js&output=text&command=JSON.print(OvmsMetrics.GetValues(["v.c.charging","v.b.soc"])) (URI encode as needed) Also see the scripting documentation and the plugin examples on how to add custom modules providing custom commands. Of course you can also write data to files and poll those via HTTP. That's one of the reasons the webserver provides access to the file system. Write files in C++ as usual, see scripting object VFS for script based file I/O. Regards, Michael Am 24.08.20 um 18:01 schrieb Soko:

Hi again,

Before I decide how to do this I would like to explore the other way: My home automation is polling the data from OVMS.

I have had a look to the HTTP API. But it seems this is an API for the server on the internet and not for OVMS itself, correct?

Next option: My home automation does a simple HTTP-GET to OVMS and reads data like this. Is there a way to read metrics like this? I have found the config->webserver site. I could point it to an own dir like /store/data. Now I could write/update one file there from my vehicle-module called "current" with all the data I need. Then simply to a http-get to 192.168.4.1/current and I get the data of the file. Is it easy - and most important: allowed - to write/update into a file in OVMS.

thanks heaps for the input

Soko

On 24.08.2020 01:46, Mark Webb-Johnson wrote:

...

The vehicle module is definitely the wrong place to do this.

If you really want to implement in C++, I suggest you look at the ovms_server_v3 module. You could use that as a template for what you need. It should periodically read from the metrics, and send what you need to your home automation.

You should also consider a javascript plugin to do this. That would probably be simpler and easier to update (without firmware changes). If it is a common home automation system, you could write it as a plugin and share for others with the same system.

Regards, Mark

...

On 24 Aug 2020, at 12:00 AM, Soko <ovms@soko.cc <mailto:ovms@soko.cc>> wrote:

Hi Mark,

I have my own home automation running at home. I want to push the current values (SoC, odometer, ...) once my car is in the driveway and OVMS is booked into my WiFi. My home automation has a TCP server running were I process the data further.

I don't want to the OVMS Server functionality as I'm not a Linux guy, don't want the data in the internet and no SIM use on the OVMS.

So does the canlog_tcpclient.cpp take care of the concurrency etc. correctly? I will do the same in my code. Or should I start a separate task from the vehicle task for every push?

thx Soko

On 23 August 2020 16:37:46 CEST, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:

What are you trying to do?

From a design point of view, it seems strange to have an outgoing tcp connection from a vehicle module. Those modules need to be very responsive and realtime.

Mongoose is the correct approach. But take care, because most of the work is done in the network (not vehicle) task, so you need to deal with mutex and other concurrency issues.

Regards, Mark

On 23 Aug 2020, at 7:54 PM, Soko <ovms@soko.cc <mailto:ovms@soko.cc>> wrote: Hey everyone, I'm trying to send a simple tcp msg to a remote tcp-server. I've looked into the FreeRTOS example (esp-idf\examples\protocols\sockets\tcp_client\) which works (kinda) but OVMS behaves weirdly when I do it like that. Thomas pointed me to mongoose... So is this the way to go? I would take canlog_tcpclient.cpp as a model... Ohh... and is it OK if I send my tcp msg in the vehcile task? Mongoose should take care of unforeseen errors so the task shouldn't block, right? thx Soko ------------------------------------------------------------------------ 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 <mailto: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

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

I still think MQTT is the best way to handle IoT stuff like this. You will probably want to connect other things to your home automation as well, and MQTT is the standard for that (so you will probably end up with a local MQTT server at some point anyway). Regarding the ovms server v3, you can simply leave it disabled in autostart. Then a one-line script on the wifi connect event to start the ovms server v3, and another on the wifi disconnect event to stop it. Regards, Mark.

On 25 Aug 2020, at 11:06 PM, Soko <ovms@soko.cc> wrote:

Hi guys,

@Craig & Derek: Thanks for your input here! I didn't realize the MQTT server working on a local LAN basis as well. I definitely don't want anything in the internet. Although it means having another service running somewhere as middle man between my HA and OVMS.

Michael's command is what I was looking for. Just tested http://192.168.4.1/api/execute?type=js&output=text&command=JSON.print(OvmsMe... <http://192.168.4.1/api/execute?type=js&output=text&command=JSON.print(OvmsMetrics.GetValues(>"")) successfully. Don't even need the apikey as I don't have a PWD set as OVMS has no AccessPoint started (OVMS is just in my local WiFi with no internet connection).

So if I go down the polling route this is what I'm going to do. Pushing would still be better though as I don't want my HA (Arduino) to freeze for a couple of seconds when polling the car and its not booked into my WiFi. Running a TCP server on my HA and having OVMS push only when its in my WiFi is the more elegant way... but also the more complex.

thanks guys

Soko

On 24.08.2020 22:39, Michael Balzer wrote:

...

Soko,

the webserver REST API provides a simple command execution endpoint you can use to execute Javascript code as well.

See: - https://docs.openvehicles.com/en/latest/components/ovms_webserver/docs/index... <https://docs.openvehicles.com/en/latest/components/ovms_webserver/docs/index.html#authorization>

The scripting system has a simple metrics getter and JSON encoder.

See: - https://docs.openvehicles.com/en/latest/userguide/scripting.html#ovmsmetrics <https://docs.openvehicles.com/en/latest/userguide/scripting.html#ovmsmetrics> - https://docs.openvehicles.com/en/latest/userguide/scripting.html#json <https://docs.openvehicles.com/en/latest/userguide/scripting.html#json>

Example executing a shell command:

- http://myovms.local/api/execute?apikey=mypassword&output=text&command=stat <http://myovms.local/api/execute?apikey=mypassword&output=text&command=stat>

Example getting a single metric value:

- http://myovms.local/api/execute?apikey=mypassword&type=js&output=text&comman... <http://myovms.local/api/execute?apikey=mypassword&type=js&output=text&command=print(OvmsMetrics.Value(>"v.b.soc"))

Examples getting multiple metrics JSON encoded:

- http://myovms.local/api/execute?apikey=mypassword&type=js&output=text&comman... <http://myovms.local/api/execute?apikey=mypassword&type=js&output=text&command=JSON.print(OvmsMetrics.GetValues(>"m.net.")) - http://myovms.local/api/execute?apikey=mypassword&type=js&output=text&comman... <http://myovms.local/api/execute?apikey=mypassword&type=js&output=text&command=JSON.print(OvmsMetrics.GetValues(>["v.c.charging","v.b.soc"]))

(URI encode as needed)

Also see the scripting documentation and the plugin examples on how to add custom modules providing custom commands.

Of course you can also write data to files and poll those via HTTP. That's one of the reasons the webserver provides access to the file system. Write files in C++ as usual, see scripting object VFS for script based file I/O.

Regards, Michael

Am 24.08.20 um 18:01 schrieb Soko:

...

Hi again,

Before I decide how to do this I would like to explore the other way: My home automation is polling the data from OVMS.

I have had a look to the HTTP API. But it seems this is an API for the server on the internet and not for OVMS itself, correct?

Next option: My home automation does a simple HTTP-GET to OVMS and reads data like this. Is there a way to read metrics like this? I have found the config->webserver site. I could point it to an own dir like /store/data. Now I could write/update one file there from my vehicle-module called "current" with all the data I need. Then simply to a http-get to 192.168.4.1/current and I get the data of the file. Is it easy - and most important: allowed - to write/update into a file in OVMS.

thanks heaps for the input

Soko

On 24.08.2020 01:46, Mark Webb-Johnson wrote:

...

The vehicle module is definitely the wrong place to do this.

If you really want to implement in C++, I suggest you look at the ovms_server_v3 module. You could use that as a template for what you need. It should periodically read from the metrics, and send what you need to your home automation.

You should also consider a javascript plugin to do this. That would probably be simpler and easier to update (without firmware changes). If it is a common home automation system, you could write it as a plugin and share for others with the same system.

Regards, Mark

...

On 24 Aug 2020, at 12:00 AM, Soko <ovms@soko.cc <mailto:ovms@soko.cc>> wrote:

Hi Mark,

I have my own home automation running at home. I want to push the current values (SoC, odometer, ...) once my car is in the driveway and OVMS is booked into my WiFi. My home automation has a TCP server running were I process the data further.

I don't want to the OVMS Server functionality as I'm not a Linux guy, don't want the data in the internet and no SIM use on the OVMS.

So does the canlog_tcpclient.cpp take care of the concurrency etc. correctly? I will do the same in my code. Or should I start a separate task from the vehicle task for every push?

thx Soko

On 23 August 2020 16:37:46 CEST, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote: What are you trying to do?

From a design point of view, it seems strange to have an outgoing tcp connection from a vehicle module. Those modules need to be very responsive and realtime.

Mongoose is the correct approach. But take care, because most of the work is done in the network (not vehicle) task, so you need to deal with mutex and other concurrency issues.

Regards, Mark

On 23 Aug 2020, at 7:54 PM, Soko <ovms@soko.cc <mailto:ovms@soko.cc>> wrote:

Hey everyone,

I'm trying to send a simple tcp msg to a remote tcp-server. I've looked into the FreeRTOS example (esp-idf\examples\protocols\sockets\tcp_client\) which works (kinda) but OVMS behaves weirdly when I do it like that.

Thomas pointed me to mongoose...

So is this the way to go? I would take canlog_tcpclient.cpp as a model...

Ohh... and is it OK if I send my tcp msg in the vehcile task? Mongoose should take care of unforeseen errors so the task shouldn't block, right?

thx

Soko OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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 <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 <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 <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 <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 <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>

---

OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

_______________________________________________ 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

-- 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

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@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@lists.openvehicles.com > > > > http://lists.openvehicles.com/mailman/listinfo/ovms > > > > dev > > > > > > > >                              > > > > > >                              > > > > > >                              > > > > > >                              > > >                             _________________________ > > > ______________________ > > > OvmsDev mailing list > > > OvmsDev@lists.openvehicles.com > > > http://lists.openvehicles.com/mailman/listinfo/ovmsde > > > v > > > > > >                            > > > >                            > > > >                            > >                           _____________________________ > > __________________ > > 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/l istinfo/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

        

        

        --  Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

        _______________________________________________ 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

    

    

    --  Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

  

_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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/late > st/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@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::virtua > > > > l 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 http > > > > > > s://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/ov > > > > > msdev > > > > > > > > > >                                > > > > > > > >                                > > > > > > > >                                > > > >                               _____________________ > > > > __________________________ > > > > OvmsDev mailing list > > > > OvmsDev@lists.openvehicles.com > > > > http://lists.openvehicles.com/mailman/listinfo/ovms > > > > dev > > > > > > > >                              > > > > > >                              > > > > > >                              > > > > > >                              > > >                             _________________________ > > > ______________________ > > > OvmsDev mailing list > > > OvmsDev@lists.openvehicles.com > > > http://lists.openvehicles.com/mailman/listinfo/ovmsde > > > v > > > > > >                            > > > >                          > >                         _______________________________ > > ________________ > > > >                         OvmsDev mailing list > > > >                         OvmsDev@lists.openvehicles.com > > > >                         http://lists.openvehicles.com/m > > ailman/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 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 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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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_di > > agnostics#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@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(u > > > > > > int32_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.2 > > > > > > > 0 um 14:43 schrieb Soko: > > > > > > > > > > > > > >                                      > > > > > > >                                      > > > > > > > > Hi guys,  > > > > > > > > > > > > > > > >                                        > > > > > > > > > > > > > > > >                                       Want > > > > > > > > to report success on > > > > > > > >                                       conne > > > > > > > > cting 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 > > > > > > > >                                       Incom > > > > > > > > ingPollReply(..) 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 > > > > > > > >                                       79381 > > > > > > > > 3) and then I get can1 > > > > > > > >                                       error > > > > > > > > s... I'm polling with 10 > > > > > > > >                                       secon > > > > > > > > ds intervall.  > > > > > > > > > > > > > > > >                                        > > > > > > > > > > > > > > > >                                       I > > > > > > > > know that this is as it should > > > > > > > >                                       be... > > > > > > > > but my issue is: I don't > > > > > > > >                                       have > > > > > > > > any way to know if the > > > > > > > >                                       ignit > > > > > > > > ion is on, the key is in, the > > > > > > > >                                       car > > > > > > > > is running, the car is > > > > > > > >                                       charg > > > > > > > > ing as the PIDs are not known > > > > > > > >                                       for > > > > > > > > such values (afaik by the > > > > > > > >                                       lists > > > > > > > > of sharkcow https://www.goingelectric.de/wi > > > > > > > > ki/Liste-der-OBD2-Codes/). > > > > > > > >                                        > > > > > > > > > > > > > > > >                                        > > > > > > > > > > > > > > > >                                       So > > > > > > > > what would be the best approach > > > > > > > >                                       to > > > > > > > > change the different polling > > > > > > > >                                       state > > > > > > > > s? Can I somehow get called > > > > > > > >                                       (in > > > > > > > > my vehicle-class) if an > > > > > > > >                                       can- > > > > > > > > error is thrown? Then I would > > > > > > > >                                       incre > > > > > > > > ase the poll frequency.  > > > > > > > > > > > > > > > >                                        > > > > > > > > > > > > > > > >                                       Any > > > > > > > > suggestions?  > > > > > > > > > > > > > > > >                                        > > > > > > > > > > > > > > > >                                       thank > > > > > > > > s  > > > > > > > > > > > > > > > >                                        > > > > > > > > > > > > > > > >                                       Soko  > > > > > > > > > > > > > > > >                                        > > > > > > > > > > > > > > > >                                        > > > > > > > > > > > > > > > >                                        > > > > > > > >                                       _____ > > > > > > > > __________________________________________ > > > > > > > > OvmsDev mailing list > > > > > > > > OvmsDev@lists.openvehicles.com > > > > > > > > http://lists.openvehicles.com/mailman/listi > > > > > > > > nfo/ovmsdev > > > > > > > > > > > > > > > >                                      > > > > > > > > > > > > > >                                      > > > > > > > > > > > > > >                                      > > > > > > > > > > > > > >                                      > > > > > > >                                     _________ > > > > > > > ______________________________________ > > > > > > > OvmsDev mailing list > > > > > > > OvmsDev@lists.openvehicles.com > > > > > > > http://lists.openvehicles.com/mailman/listinf > > > > > > > o/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/ov > > > > > msdev > > > > > > > > > >                                > > > > > > > >                              > > > > _______________________________________________ > > > > > > > >                             OvmsDev mailing list > > > > > > > >                             OvmsDev@lists.openvehic > > > > les.com > > > > > > > >                             http://lists.openvehicl > > > > es.com/mailman/listinfo/ovmsdev > > > > > > > >                            > > > >                          > > > > > >                        > > >                        > > > > > >                      > > >                      > > > > > >                      > > >                     _________________________________ > > > ______________ > > > OvmsDev mailing list > > > OvmsDev@lists.openvehicles.com > > > http://lists.openvehicles.com/mailman/listinfo/ovmsde > > > v > > > > > >                    > > > >                    > > > >                    > >                   _____________________________________ > > __________ > > 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 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 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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev

Perfekt :-) Then // Migrate vehicle ID VWUP to VWUP.T26 if (GetParamValue("auto", "vehicle.type") == "VWUP")    {   SetParamValue("auto", "vehicle.type", "VWUP.T26");   } should be enough. Am Mittwoch, den 12.08.2020, 20:39 +0200 schrieb 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/O > > > > n-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.openvehi > > > > > cles.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@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.2 > > > > > > > 0 um 16:43 schrieb Soko: > > > > > > > > > > > > > >                                      > > > > > > >                                      > > > > > > > >                                        > > > > > > > >                                       Ahhh > > > > > > > > OK, I've found > > > > > > > >                                         Ovm > > > > > > > > sVehicle::virtual void > > > > > > > >                                         Tic > > > > > > > > kerXXX(uint32_t ticker); > > > > > > > > > > > > > > > >                                         Got > > > > > > > > it! This was exactly my > > > > > > > >                                         iss > > > > > > > > ue as I didn't know about any > > > > > > > >                                         fun > > > > > > > > ction which gets called > > > > > > > >                                         reg > > > > > > > > ularly so I could check > > > > > > > >                                         som > > > > > > > > ething like this... > > > > > > > > > > > > > > > >                                         It' > > > > > > > > s not an ideal situation > > > > > > > >                                         tho > > > > > > > > ugh: I just can slow down the > > > > > > > >                                         pol > > > > > > > > l 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 > > > > > > > >                                         thi > > > > > > > > s 60-sec polling if the only > > > > > > > >                                         thi > > > > > > > > ng I can do is poll :( > > > > > > > > > > > > > > > >                                        > > > > > > > >                                       Afaik > > > > > > > > there is only > > > > > > > >                                         the > > > > > > > > sharkcow's list below, > > > > > > > >                                         rev > > > > > > > > erse engineered by him from > > > > > > > >                                         ODB > > > > > > > > eleven. > > > > > > > >                                       (dev) > > > > > > > > marxx exlpained > > > > > > > >                                         to > > > > > > > > me: There is a gateway > > > > > > > >                                         bet > > > > > > > > ween the CAN-Buses and the > > > > > > > >                                         OBD > > > > > > > > Connector in all VW-AG > > > > > > > >                                         veh > > > > > > > > icles which only replies to > > > > > > > >                                         pol > > > > > > > > ls and also acts as security > > > > > > > >                                         gat > > > > > > > > eway if you want to write to > > > > > > > >                                         the > > > > > > > > buses. > > > > > > > >                                       So I > > > > > > > > think I cannot > > > > > > > >                                         rea > > > > > > > > lly do a can log or use re > > > > > > > >                                         too > > > > > > > > l as the OBD interface stays > > > > > > > >                                         qui > > > > > > > > et if I'm not polling it... > > > > > > > >                                       And > > > > > > > > as there is no > > > > > > > >                                         oth > > > > > > > > er vehicle from > > > > > > > >                                         VW, > > > > > > > > Seat,Skoda,Audi,etc. in OVMS. > > > > > > > >                                         So > > > > > > > > I have no cheat-sheet :( > > > > > > > >                                       Anyho > > > > > > > > w... I would need > > > > > > > >                                         to > > > > > > > > poll one ECU (is this the > > > > > > > >                                         cor > > > > > > > > rect therm?) which doesn't > > > > > > > >                                         shu > > > > > > > > ts down... or maybe the issue > > > > > > > >                                         is > > > > > > > > the OBD-gateway shutting > > > > > > > >                                         dow > > > > > > > > n. > > > > > > > > > > > > > > > >                                        > > > > > > > >                                       What > > > > > > > > do you think? > > > > > > > >                                       Soko > > > > > > > > > > > > > > > >                                        > > > > > > > >                                       On > > > > > > > >                                         30. > > > > > > > > 07.2020 16:17, Michael Balzer > > > > > > > >                                         wro > > > > > > > > te: > > > > > > > > > > > > > > > >                                        > > > > > > > >                                        > > > > > > > > >                                          > > > > > > > > >                                         S > > > > > > > > > oko, > > > > > > > > > > > > > > > > > >                                          > > > > > > > > > > > > > > > > > >                                         n > > > > > > > > > ice progress :-) > > > > > > > > > > > > > > > > > >                                          > > > > > > > > > > > > > > > > > >                                         I > > > > > > > > > f you can't detect vehicle > > > > > > > > >                                         s > > > > > > > > > tate by listening to regular > > > > > > > > >                                         s > > > > > > > > > tatus CAN frames, you can check > > > > > > > > >                                         t > > > > > > > > > he time since the last poll > > > > > > > > >                                         r > > > > > > > > > eply in the per second ticker. > > > > > > > > > > > > > > > > > >                                          > > > > > > > > > > > > > > > > > >                                         A > > > > > > > > > s poll replies normally come in > > > > > > > > >                                         f > > > > > > > > > ast, you should be able to > > > > > > > > >                                         d > > > > > > > > > etect a switch-off by a small > > > > > > > > >                                         t > > > > > > > > > imeout, say 3 seconds… probably > > > > > > > > >                                         n > > > > > > > > > eed to add a counter, as a > > > > > > > > >                                         s > > > > > > > > > ingle poll may get lost / > > > > > > > > >                                         i > > > > > > > > > gnored. > > > > > > > > > > > > > > > > > >                                          > > > > > > > > > > > > > > > > > >                                         C > > > > > > > > > AN tx errors can be caused by > > > > > > > > >                                         o > > > > > > > > > ther issues as well, so should > > > > > > > > >                                         g > > > > > > > > > enerally not be interpreted > > > > > > > > >                                         t > > > > > > > > > hat way. > > > > > > > > > > > > > > > > > >                                          > > > > > > > > > > > > > > > > > >                                         B > > > > > > > > > ut… are you sure there are no > > > > > > > > >                                         s > > > > > > > > > tatus frames on the bus? Have > > > > > > > > >                                         y > > > > > > > > > ou done a can log or tried the > > > > > > > > >                                         r > > > > > > > > > e tool? > > > > > > > > > > > > > > > > > >                                          > > > > > > > > > > > > > > > > > >                                         R > > > > > > > > > egards, > > > > > > > > > > > > > > > > > >                                         M > > > > > > > > > ichael > > > > > > > > > > > > > > > > > >                                          > > > > > > > > > > > > > > > > > >                                          > > > > > > > > > > > > > > > > > >                                         A > > > > > > > > > m > > > > > > > > >                                           > > > > > > > > >  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.d > > > > > > > > > > e/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/l > > > > > > > > > > istinfo/ovmsdev > > > > > > > > > > > > > > > > > > > >                                         > > > > > > > > > >   > > > > > > > > > > > > > > > > > >                                          > > > > > > > > > > > > > > > > > >                                          > > > > > > > > > > > > > > > > > >                                          > > > > > > > > >                                         _ > > > > > > > > > _________________________________________ > > > > > > > > > _____ > > > > > > > > > OvmsDev mailing list > > > > > > > > > OvmsDev@lists.openvehicles.com > > > > > > > > > http://lists.openvehicles.com/mailman/lis > > > > > > > > > tinfo/ovmsdev > > > > > > > > > > > > > > > > > >                                        > > > > > > > > > > > > > > > >                                        > > > > > > > > > > > > > > > >                                        > > > > > > > >                                       _____ > > > > > > > > __________________________________________ > > > > > > > > OvmsDev mailing list > > > > > > > > OvmsDev@lists.openvehicles.com > > > > > > > > http://lists.openvehicles.com/mailman/listi > > > > > > > > nfo/ovmsdev > > > > > > > > > > > > > > > >                                      > > > > > > > > > > > > > >                                      > > > > > > > > > > > > > >                                      > > > > > > > > > > > > > >                                      > > > > > > >                                     _________ > > > > > > > ______________________________________ > > > > > > > OvmsDev mailing list > > > > > > > OvmsDev@lists.openvehicles.com > > > > > > > http://lists.openvehicles.com/mailman/listinf > > > > > > > o/ovmsdev > > > > > > > > > > > > > >                                    > > > > > > > > > > > >                                  > > > > > > _______________________________________________ > > > > > > > > > > > >                                 OvmsDev mailing > > > > > > list > > > > > > > > > > > >                                 OvmsDev@lists.o > > > > > > penvehicles.com > > > > > > > > > > > >                                 http://lists.op > > > > > > envehicles.com/mailman/listinfo/ovmsdev > > > > > > > > > > > >                                > > > > > >                              > > > > > > > > > >                            > > > > >                            > > > > > > > > > >                          > > > > >                          > > > > > > > > > >                          > > > > >                         _________________________ > > > > > ______________________ > > > > > OvmsDev mailing list > > > > > OvmsDev@lists.openvehicles.com > > > > > http://lists.openvehicles.com/mailman/listinfo/ov > > > > > msdev > > > > > > > > > >                        > > > > > > > >                        > > > > > > > >                        > > > >                       _____________________________ > > > > __________________ > > > > OvmsDev mailing list > > > > OvmsDev@lists.openvehicles.com > > > > http://lists.openvehicles.com/mailman/listinfo/ovms > > > > dev > > > > > > > >                      > > > > > >                      > > > > > >                     _________________________________ > > > ______________ > > > OvmsDev mailing list > > > OvmsDev@lists.openvehicles.com > > > http://lists.openvehicles.com/mailman/listinfo/ovmsde > > > v > > > > > >                    > > > >                    > > > >                    > >                   _____________________________________ > > __________ > > 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 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 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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev

Thanks Michael, With my current knowledge of the behavior of  the eUp I don't think this will help. Reason: When the polls are too frequent the car will never shut down. So the only possibility is to use the 12V voltage level to see if the 12V battery is charging or not. I will go forward now and put some usable features into the source. I will go and have a VCDS session tomorrow (hopefully) to see what it is doing and to sniff the ExtendedDiagSession messages which it hopefully uses. Soko On 09.08.2020 13:04, Michael Balzer wrote:

UpMiiGo guys,

Am 30.07.20 um 14:43 schrieb Soko:

...

Can I somehow get called (in my vehicle-class) if an can-error is thrown? Am 30.07.20 um 16:17 schrieb Michael Balzer: CAN tx errors can be caused by other issues as well, so should generally not be interpreted that way.

According to Chris on the GE forum, you're also seeing CAN tx errors on the Komfort CAN bus, so maybe it actually makes sense for you to check for CAN errors.

There are two options:

1. Register a TX callback for a specific TX frame 2. Register a general TX callback

_ Option 1_ is currently not supported by the poller framework (but could be added). For a manual frame transmission, simply set the frame callback pointer to your handler:

static void CAN_tx_callback(const CAN_frame_t* frame, bool success){   if (!success) {     // tx failure   } }

…

  CAN_frame_t txframe;   txframe = {};   txframe.MsgID = 0x705;   txframe.FIR.B.DLC = 8;   txframe.data = { 0x…, 0x…, … };   txfrane.callback = CAN_tx_callback;   txframe.Write(m_can3);

_Option 2_ uses the same handler signature. A handlers is registered as a general callback like this, e.g. on vehicle init:

    MyCAN.RegisterCallback(TAG, CAN_tx_callback, true);

You can also register an RX callback by passing "false" or omitting the third argument. On unloading the vehicle module, simply do:

    MyCAN.DeregisterCallback(TAG);

CAN callbacks are called directly within the CAN driver context prior to all standard queues, so can be used for very fast CAN responses -- and thus need to be very fast too, to not affect CAN driver throughput. Don't do any complex processing in the handler, avoid anything that could block the task.

Regards, Michael

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev