How to use the "Car Explorer" feature

Car Explorer

community-library-overview-crop

This guide will give an overview of the new car explorer feature, which is a way to discover the available PID’s in your car, both hidden and public/default OBD-II and sharing them with the community.
(In turn it will also include various raw CAN messages)

We will go over the following topics in this guide.

  • How and when the car reports the supported PIDS.
  • How to find PID’s in the Community Library.
  • How to add a PID to your library.
  • How to create (and share) proprietary PID’s
  • Troubleshooting if no PID’s are reported from the device.

How and when the device reports the supported PID’s

When the device connects to the server, it will check the following

  • Updated to the most recent version
  • The active vehicle has no autodetected busses associated
    • OR if the autodetected bus has no PID’s associated.
  • That the engine has been started since the update. It will only be able to detect the supported commands when it is connected to the bus and the engine is running.
    (You can see what busses are registered in settings > device)

Then the device will know to report the supported PID’s.
After the device has reported to the cloud with the supported PID’s, they will show up in the “My Library” tab in the “Car Explorer”-section.

23

How to find (and use) the PID’s

You can also browse the community library, where all PID’s are available and searchable.
The filters will default to the model, make and year of the vehicle configured on your active device.
The PID’s that are shown here are all the PID’s that are reported as supported by the makes and models of the AutoPi users.
Please note that the number of PID’s visible here will go up once devices are updated and reports the supported PID’s or if people create and share proprietary PID’s.

If you change the filter to only include the type “Proprietary”, it will only show the PID’s that are created by other AutoPi users, and who has chosen to share it with the community.
In time these proprietary PID’s are very likely where you will find the most interesting PID’s for your vehicle.

How to add a PID to your library

When you find a PID you’d like to try, you can view it, and in the right side, there is a preview of the command needed to execute the PID on your car. But the PID may be associated to a specific bus that your car does not have, so unless you are filtering on your specific car make and model, it will most likely not work, at least not without some fiddling.

Clicking the Add to library button, the PID will be associated to the bus on your active vehicle. If no bus exists that matches the bus info in the selected PID, it will be created.
As mentioned above, unless you filter on your specific make and model, even if the PID is actually supported by your vehicle, you may need to do some fiddling before it will work, which can be done by running the PID directly in the terminal (Keep in mind that the engine may need to be running for it to respond to PID’s).

Now the PID should be available in My Library.

After adding the PID, it is available in the Logging section, so you can now set up a logger that runs every N interval, and logs data by executing a specific PID.

15

How to create (and share) proprietary PID’s

To create a new PID, click the “Create” button in “My Library”.
37

You will now need to fill out the following fields.

Name
A slug with the name of your PID - it must be unique as it is used by the device when sending the logged value to the cloud (if used in a logger).

Description
If you want to share the PID, a proper description is really nice, and if not, it’s still very useful to describe or maybe add a link to where the PID originates from.

Mode and Code
These two values together is a PID.

Header
The default 7DF value means a Request message. The default should be used unless you need another for some proprietary magic :slight_smile:

Bytes
This is the expected length of the response.

Formula
The formula is executed on the device, and takes a byte array from one or more response messages, and translates it to the actual value, like temperature, speed etc.

You may notice that none of the standard PID’s has a formula specified. This is because all the default PID’s are identified by their name, and the code that translates the byte response to a value, is already embedded in the library (py-obd) we use for communicating with the car.
This is only the case for the standard PIDS.

The formula is plain python with some added helper functions:

  • bytes_to_int
  • bytes_to_hex
  • twos_comp

More info here
So to convert a temperature response one would write the following formula

bytes_to_int(message.data[2:])-40

NOTE: Remember to use the data attribute on the message object
The above example is the short “formula” way to write the following decoder function
You can also find more examples in the above link.

Hint
For prototyping, you can execute the PID on your device by using the terminal, then copy the byte response into a python terminal, insert the above helper functions, to be able to test the parsing directly in the terminal.

Unit, Min and Max
Select a unit that matches your data, or write your own.
Like the name, this unit is used when the device stores the response value of the PID, for easier parsing and displaying of the value in the dashboard widgets.
Min and max are also used when storing and displaying the data.

Bus
To use a PID, you need to associate it to one of the busses on your vehicle, it may be as simple as associating it to the auto detected one, but you may also want to create a custom one. This can be done in the settings > Garage - You don’t have to associate the PID with a bus straight away.

Now click save, and you new PID is created, and can be found in My Library.
If you want to share the PID, it needs to be associated to at least one bus, when you have done that, and saved the PID, you can now click the Share with community, after which the PID will be discoverable in the Community Library, and other users can find it. You can also verify that it looks correct, and has the right make and model by searching for the PID.

Troubleshooting if no PID’s are visible

If you PID’s are listed in my library, check the following things.

  • That you device is updated to the most recent version.
  • That the device has been online since the update.
  • That the engine has been running for a little while since the update.
  • That the vehicle associated to your device, has the correct make and model specified.
  • That you have no errors in the log on the device.
    See this guide if you are unsure how to get the logs from the device.

Issues?

Let us know if you experience any issues, or if you have suggestions.
We heavily rely on the feedback from you guys!

1 Like

Many thanks for the update :slight_smile: I’ve tried using this to get my Kona state of charge.

Firstly I can use the following to get the the data that I need -

$  obd.query SOC_Display mode=220 pid=105 verify=false force=true 
_type: soc_display
_stamp: '2019-03-02T08:52:16.375263'
value: |-
  7EA037F2212
  7EB037F2212
  7EC102E620105003FFF
  7EC2190000000000000
  7EC220000000000001B
  7EC23A446500001500A
  7EC240003E80403E835
  7EC25C60000CECE0000
  7EC260D00000000AAAA
  7ED037F2212

The data I need is in row 7EC25 - I need to convert C6 to a percentage ( to int then / 2 to get 99% ).

I figured the request header in this case is 7E4 (response is 7EC) and I think the offset is 26 bytes ( in torque pro counting, or perhaps its 32 ), so the GUI gives me a command of -

$ obd.query SOC_Display mode=220 pid=105 header=7E4 bytes=45 formula='bytes_to_int(message[26:])/2' unit=%
 baudrate=500000 protocol=6 verify=false force=true
'ERROR: ''int'' object has no attribute ''encode'''

Indeed, I found I got the same error without the foruma -

$  obd.query SOC_Display mode=220 pid=105 header=7E4 force=true
'ERROR: ''int'' object has no attribute ''encode'''

Have I misunderstood something ? What does this error message mean ?

Apparently I have version 2019.03.01 on my device.

Thanks.

2 Likes

Hi @plord,

As a temporary workaround can you try to quote the header value like so:

obd.query SOC_Display mode=220 pid=105 header=‘7E4’ bytes=45 formula=‘bytes_to_int(message[26:])/2’ unit=%
baudrate=500000 protocol=6 verify=false force=true

There sometimes seem to be a bug when parsing this value unquoted. This will be fixed in the next release.

1 Like

Thanks that helped. I now see -

$ obd.query SOC_Display mode=220 pid=105 header='7E4' force=true
_type: soc_display
_stamp: '2019-03-04T17:24:39.250087'
value: |-
  7EC102E620105003FFF
  7EC2190000000000000
  7EC2200000000000025
  7EC234A430800015008
  7EC240003E80403E835
  7EC25B10000C7C70000
  7EC260A00000000AAAA 

but when I apply a formula I get -

$ obd.query SOC_Display mode=220 pid=105 header='7E4' bytes=45 formula='bytes_to_int(message[26:])/2' unit=% baudrate=500000 protocol=6 verify=false force=true
>-
ERROR: Failed to calculate formula: 'Message' object has no attribute
'__getitem__'

Given that the colon is a python slice operator I also tried a range -

$ obd.query SOC_Display mode=220 pid=105 header='7E4' force=true formula='bytes_to_int(message[2:3])'
>-
  ERROR: Failed to calculate formula: 'Message' object has no attribute
  '__getitem__'

Now I did try ignore the example above and use something like -

 $ obd.query SOC_Display mode=220 pid=105 header='7E4' force=true formula='bytes_to_int(messages[0].data[6:7])'
_type: soc_display
_stamp: '2019-03-04T17:54:48.845947'
value: 144

But the ranges seem to fail when I try to move further into the response -

  $ obd.query SOC_Display mode=220 pid=105 header='7E4' force=true formula='bytes_to_int(messages[0].data[14:15])'
  _type: soc_display
_stamp: '2019-03-04T17:55:21.268868'
  value: |-
    7EC102E620105003FFF
    7EC2190000000000000
    7EC2200000000000025
    7EC239A430800015007
    7EC240003E80403E835
    7EC25B00000C7C70000
    7EC260A00000000AAAA

Any ideas what I can use to extract a single int ?

1 Like

Ah. I tried adding the byes ( presumably there is a default for bytes ) -

$ obd.query SOC_Display mode=220 pid=105 header='7E4' bytes=54 formula='bytes_to_int(messages[0].data[38:39])/2' unit=% baudrate=5000
00 protocol=6 verify=false force=true
value: 99
_stamp: '2019-03-04T18:21:05.640377'
_type: soc_display
unit: '%'

So I have the data !

It would be good to confirm that we need to use messages[0].data[38:39] instead of message[38:39]

2 Likes

Next question, how do I see this on the dashboard ? I was expecting to see SOC_Display on the list of fields but I don’t see it.

2 Likes

Hi Peter

You are absolutely correct, the code i posted is missing the .data attribute - it has been fixed in the guide now.

Regarding the missing fields in the widgets, I have not looked into the data yet, but at the moment, you are unable to do all this in “one sitting”, this is because to create the widget, it needs to have the data in our storage system, so you’d have to configure the logger, and then wait the data to be logged, and then create the widget.

I expect that it just hadn’t gotten any data yet, but if you are still unable to see the fields, please let me know, and I will look into it asap.

Best regards
/Malte

1 Like

Ok. But do we need converter or logger don’t need it ?
It is for SoC
Thanks image image

19

I can’t save mod on formula ‘7E4’ but also I cannot found data , any workaround about it ? also missing attribute can not permit to use widgets … please resolve in few time not month !

Many thanks :slightly_smiling_face:

Well, I’ve added some custom PID’s ( which seem to work when testing ), added a logger and did some test drives. New PID didn’t show up on the dashboard :frowning:

52

I found the car needs to be on to display SOH and SOC … maybe thats it.

I use wake up method every 3 min , therefore data can be done only when is active, I think , when is offline … reply timeout …

In the Kona, I’m seeing that the battery info from OBD port is only available when the car is either ready to drive or plugged in and charging. So unless one of these is true, autopi can’t return any battery data.

1 Like

Ook now this clear my mind , today i test it, therefore is useful if we can aoutonomus or with aoutopi dev a specific widget or logger.

When is active or recharge update
When is inactive last status loaded correct

Is a solution ?
I think as if ll come ! “no value data” change else last

1 Like

Hi, thanks for the update.

It looks like you support only PID which are manually requested. However, on my Renault Zoe, the PID I need is broadcasted regularly by the car. The obd.dump shows some lines with PID 42e which contains the SOC of the car.

In this case, could you clarify how to fill your new “Create new PID” UI?
Best

Still no fields for the dashboard :frowning:

I have several PID’s now, for example -

59

an associated logger -

24

I’ve done a few test trips in the car, and data is getting back to the cloud -

03

But nothing in the list of fields :frowning:

41

Anything I can check locally ?

4 Likes

I think with no brackets log not work , not work no data , no data not showed , I understand this from @Malte previous reply