Open beaune33 opened 8 months ago
Hey @beaune33
Are you able to read the SoC using car scanner app?
Is the return value shown above something defined my anybody?
Probably by the car manufacturer
Is this a special meatpi behavior?
The adapter will forward whatever it receive on CAN bus
Thank for this hint, indeed this behavior always may be watched, when car snanner app also does not manage to connect ECU. So, it is more a topic of the car, which seems to be sleeping somehow, but not totally, as there is a reaction to my mqtt request on can. Do you think there is a "wake-up"possibility? I know, the complete functionality of car scanner app does require the car ignition to be on; thats of course not possible to swirch on remotely. But reading some parameters does not require ignition beein switched on. There seems to be a state in between. Any idea what a wake-up call could be?
@beaune33 Have a look at this issue : https://github.com/meatpiHQ/wican-fw/issues/17#issuecomment-1456925171
I think they were successful waking up the ECU if the car is unlocked.
@beaune33 did you had any success so far? I'm struggling to get any data from my kangoo https://github.com/meatpiHQ/wican-fw/discussions/112#discussioncomment-9063407
Zoe PH1 and Kangoo are quite similar on OBDII, so far I'm struggling to get any response. how do you request SOC by SID 0x22 / DEC 34 ?
My request so far: {"bus":"0","type":"tx","ts":21767,"frame":[{"id":2020,"dlc":8,"rtr":false,"extd":false,"data":[3,34,32,2,170,170,170,170]}]}
THX
The communication itself works pretty fine. I am not sure how similar these cars are really are. The Zoe uses 29-Bit identifiers for CAN, not 11-Bit, so it must be completely different from your telegram, e.g. for asking SoC:
{"bus":"0","type":"tx",frame":[{"id":416996337,"dlc":8,"rtr":false,"extd":true,"data":[3,34,146,193,170,170,170,170]}]}
For defining the telegram you need to know,
· which ECU does support your parameter (eg. for SoC it is 0xDB)
· what is the resulting CAN identifier, e.g. 0x18DADBF1
· the coding of the read request (SID: 0x22 for Zoe, Read Data by Identifier, defined by Unified Diagnostic Service UDS)
· the DID for the requested parameter (SoC: 0x92C1)
· the length of this telegram without length byte (3)
The other question is, when does the car feel fine to communicate with you. Easisest this works while charging, as then the car is fully awake. It may also work directly after opening doors, or going to drive. In soe situations, e.g. when connected to wallbox, but not charging, you may also succeed by some special wake-up-commands, but this seems to be very individual, and it is also good not to do too often, as this could discharge the 12V battery.
I hope this gives some new ideas to you, but indeed it will be necessary to step into deeper to clarify basic information.
Ok, by the CanZE Source the 29Bit identifier is for "new" Zoe, only the old (PH1) are similar to the Kangoo...
While charging or ignition on and a old elm327 I can get data with CanZE or other apps... but not with WiCAN. So still try to find the reason...
You could connect two adapters, one for CanZE and the WiCan for listening… I did so. This could help you to find out Can identifiers and parameter ids.
Ok, I do have a CAN-USB adapter, with Linux I can also da a CAN-Dump too.
Hello,
I am trying to request some parameters from an Renault ZOE and encountered some strange behavior:
When I request for a data, lets say SoC by using SiD 0x22, then the first request will return this mqtt string:
{"bus":"0","type":"rx","ts":17021,"frame":[{"id":1785,"dlc":2,"rtr":false,"extd":false,"data":[131,192,0,0,0,0,0,0]}]}
This is funny, as the car always uses 29 bit identifiers, never 11-bit. But: If I just send the same request a second time, it is fulfilled correctly.
Same behavior if I start a new diagnostic session by SID 0x10.
My question: Is the return value shown above something defined my anybody? Is this a special meatpi behavior? Whats the exact meaning and how to avoid this (negative?) response?