How to use the "Car Explorer" feature

plord · March 7, 2019, 10:08am

Did you mean quoting the header when running test commands in the console window ? I had assumed that was only an issue when testing, not when running normally.

Malte · March 7, 2019, 10:55am

Hi Peter

That is correct, the issue with the quotes is a bug in the terminal on my.autopi.io - where it interprets the string 7e4 as scientific notation and converts it to 70000. It has been fixed, and we will release it within the next few hours.

Regarding the missing fields in the cloud, I am looking into the issue now.
Do you see any issues in the logs on the device?

Best regards
/Malte

Malte · March 7, 2019, 11:12am

Hi Peter & Co

I have found an issue with the loggers that are executed on the device, I expect to have a fix ready later today.
I will let you know when It has been resolved.

Best regards
/Malte

asetyde · March 7, 2019, 11:43am

Thanks Malte ! Remember about “NOT VALUE” is present when Kona is not cabled or active, therefore is last value used or can create issue on log/widget ?

exec1216 · March 7, 2019, 1:07pm

Hi Malte,

Any answer about my question above? This would help.

Best,

Malte · March 7, 2019, 1:26pm

Hi

I had replied to you, but apparently only in my head

Yes, the current implementation unfortunately only works for request-response PID’s.
The next step is for us to also support the raw data that is broadcasted on the bus.

So while we don’t support it yet, we have already begun mocking up how it should work, and behind the scenes, we have been aligning things for a while to make this possible.

Best regards
/Malte

plord · March 7, 2019, 1:38pm

Brilliant ! Many thanks

Malte · March 7, 2019, 2:24pm

Hi Peter

I have updated our backend, and removed the invalid data from our storage system.

The issue was that the formula was not applied correctly on the device, and thus it would upload the response directly, without parsing it. The fields dropdown will by default only include fields with a numeric type, so that’s the reason the field was not visible in the dropdown.

But this also means you’d have to do another test trip for it to upload the data…

But before you do, we need to make sure that the device get the updated logger.
To do so, you can go mark the PID as modified, this is done by clicking the PID in My Library and clicking save. That should mark at as modified, and then the device should update by itself.

I may have more cleaning up to do, but we will see once data starts to arrive in our storage system.

Best regards
/Malte

Malte · March 7, 2019, 3:16pm

Hi

Just a short notice that i can see some errors in our system, so it may not have been as easy as i expected.
I’m looking into it now.

/Malte

Remy_Tsuihiji · March 7, 2019, 4:24pm

I try but still not succeed…
anyone have suggest ?

asetyde · March 7, 2019, 5:05pm

Now it’s working !

@Malte
I try to use as autopilot activation flag, if : is charging or active = data , if not = not data , is perfect ! as rpm for ICE cars

Can I use as mandatory logger ? data as 0-100 or not data

Remy_Tsuihiji · March 7, 2019, 5:10pm

good !! but I am only the one who is not working… I need help to send the right SOC command , also to put the good value to the power management…

asetyde · March 7, 2019, 5:11pm

i remove and reput on my library , try to do

Remy_Tsuihiji · March 7, 2019, 5:14pm

I can’t delete it, I have http error
only I can modify!
What is wrong ?

plord · March 7, 2019, 7:43pm

Okay, some more info :

I re-enabled ssh access from wlan to more easily get at the logs. I noticed -

An error returned from another PID, a bit of an odd one so I’ll push to a seperate thread. I disabled this one and went for a further test drive.

Having said that, I don’t think all PID’s should fail if one fails.

Many many of these -

2019-03-07 18:45:01,389 [obd.OBDCommand :101 ][WARNING ][2055] 010C: Engine RPM did not receive any acceptable messages

The electric car doesn’t support RPM so not surprising - presumably on the to-do list already

A couple of these -

2019-03-07 18:45:05,078 [obd.interfaces.elm327:387 ][WARNING ][2055] No data received when trying to verify connectivity of protocol '6'

I presume this is transient.

After the test drive one of these -

2019-03-07 18:54:16,812 [cloud_cache :165 ][WARNING ][2057] Temporarily unable to upload batch with 38 entries from queue 'pend': ('Connection aborted.', error("(104, 'ECONNRESET')",))

After parked and switched off a series of -

2019-03-07 19:00:12,534 [salt.loaded.ext.engines.api_service:28 ][ERROR ][2065] exception occurred: Unable to verify connectivity of protocol 'auto': Unable to connect because no supported protocol found

After that, the dashboard shows map updates for this test drive, also RPi temp and battery voltage. Still not able to see new PID’s in add widget.

Hope this helps.

plord · March 8, 2019, 10:35am

I will be out and about today in the car - however I’ve changed the minion log level to debug in the hope that there is some more info in the logs to crawl through this evening.

Malte · March 8, 2019, 12:10pm

Hi Remy

You probably have a logger configured, that uses the PID you are trying to delete.
I have just added a notification so that you will see an error the explains this to you if you try to delete a PID that is used in a logger.

Can you verify that this is the cause?
To solve it, just go delete the logger that used the PID, then you should be able to delete the PID.

I expect it to be released later today.

Best regards
/Malte

Malte · March 8, 2019, 12:46pm

Hi Peter

Yes, the RPM warning will be solved once we change the setup of loggers to be configurable.
I think the rest of the errors you see are all transient,
The verify the protocol error, if by design and is done for all standard PID’s.
The ECONNRESET error is most likely a hickup in the network connection, it should just try again shortly afterwards.
The last one about no supported protocol, is just the device wanting to talk to the car, but when turned off some or all of the busses are unavailable.

We have a few issues to resolve i our storage system, I will let you know once it’s done.
I can however tell you that your device has inserted some obd.soc_display values that are formatted correctly. So we do have data in the system!

Best regards
/Malte

Malte · March 8, 2019, 4:57pm

Hi Guys

I have not been able to solve the issues today. After a bit more digging, I discovered that we need a better way to solve these field type issues, where the issue is that a PID can send data to our system, but if the parsing is done incorrectly, or in this case, another issue prevented a Logger from doing the parsing at all, the data is a string, but should be a numeric value. Which causes some issues in our storage system.
When the field type is a string, we don’t show it in the dropdown when configuring widgets, it only shows the fields with numeric values, as it’s hard to aggregate on strings

So I expect us to have a solution ready sometime next week.

Have a great weekend.
/Malte

exec1216 · March 8, 2019, 5:01pm

I’m struggling to understand the meaning of mode, code and header in the previous posts.

On your github project, in obd_manager.py, function query_handler, I can read:

mode = "{:02X}".format(int(str(mode), 16)) if mode != None else "01"
pid = "{:02X}".format(int(str(pid), 16))

I understand that mode and pid arguments are 2 hexadecimal digits. But in the posts above there are 3 hexadecimal digits: obd.query SOC_Display mode=220 pid=105
How is it possible?

I am working on Renault Zoe, and inspired by CanZE app ( https://github.com/fesch/CanZE ). From there, I know that if I send [0x03,0x22,0x32,0x06,0,0,0,0] on PID 7E4, I will get an answer from PID 7EC.
In this example, could you clarify which values I should set for mode, code and header?

Best,