Wrong real-time consumption

[vag]

Hello everybody,

I was wandering if there is an issue with the real-time consumption on ABRP app version 3.9.9.

I have a Hyundai Kona 64kWh MY2019 and the real-time consumption that I read on ABRP app is: 50Wh/km which is really low in comparison with the reference number of: 176Wh/km for this car.

On the same time, the car instruments display an average consumption of about 185Wh/km which should have been the one to report in ABRP app, instead of 50Wh/km.

As far as I remember, one or two versions back, the real-time consumption was correct in the app, while I realized once that it wasn't correct anymore.

On the side of the car nothing changed and the SOC and all the other real-time data are correct. Only the consumption is wrong the rest is correct (see attached pictures from the app and the web versions).

I hope someone can help me

Thank you

[Jason-ABRP]

Definitely something odd going on which we're investigating.  To help, could you screenshot the PIDs you have selected in Torque? Or are you using EVNotify?

[vag]

Hi Jason,

Thank you for your reply.

I'm am using an AutoPi dongle (info here: https://www.autopi.io/) that sends the data to ABRP through a script, based on the Torque principle.

You can find the script details here: https://community.autopi.io/t/a-better-route-planner/1158

This script works for me since months and the real-time consumption used to work correctly at the begging but not anymore. In the meanwhile there was no change on the car side, nor in the AutoPi.

[Jason-ABRP]

Did the issue start when we released the new app's version of the consumption calibration?  It's a little more advanced now, so it may take some time to learn, and it needs to learn across all speeds, so you may need to take it for a little bit of a drive, maybe set the cruise control at 120km/h for a little bit.  It would also help quite a lot to increase the rate of sending data, once per minute is not nearly often enough to build a good calibration quickly.

If it still doesn't resolve, we'll be bringing a "reset" button to get rid of the calibration and try again.  The final piece we'll be adding sometime soon is a "confidence" display, so you can see where the calibration is lacking and add some data to fill it in better.

On AutoPi, it's an excellent little device I need to spend more time with.  How have the recent updates been as far as wake/sleep management for EVs? That was the main issue I had with it last time I worked on building a more robust AutoPi script for ABRP.

[vag]

It is possible that the issue started with the new version of the consumption calibration, I didn't noticed it immediately

I think increasing the data sending rate is a very good path to follow and I'll give it a try. Initially, it was only sending data every 10 minutes, which is apparently too slow. I now decreased it down to 1 minute and I'll try getting it even faster, if it can work with the AutoPi's cron. Once it is done I'll drive the car at 120km/h for some time to feed the calibration functionality with enough data and I'll let you know after, how and if it worked.

The AutoPi works perfectly. I have it since November 2019 and its current software version is the one provided on: 2019.12.04. I never had any issue with the wake/sleep and the Kona. The only thing that I had to tune was the event of starting/stopping the engine, to generate the trip logs. Not really a big deal

Thank you for your help and for the good job done with ABRP. I'll be right back with my results once I tested the above.

 

[vag]

Hi Jason,

I had the opportunity to drive a small part of highway (something like 8km), not always at 120km/h, because of the traffic...

The real-time calculated consumption is increasing and reached 82Wh/km which is still not good but closer to reality than the 50Wh/km that I had before. I think that after a longer drive it will provide more realistic numbers. Indeed a reset button would be ideal in such cases, in order to recalculate the consumption from scratch.

The cron is actually at 1 minute. Next trial will be to have it every 30 seconds, if it accepts to do. I'll post back my results as soon as I got something new. Thank you.

[Jason-ABRP]

Cron is not able to go less than one minute durations. This weekend I will polish up my updates to PLord's code and post them on Github, which will allow much faster updates (once every 5 seconds or so).  

[vag]

There is a tweak that I'll test by launching the job twice having the second one with a "delay" of 30 seconds. This should give a poll twice a minute (if this works on AutoPi).

I'm impatient to test your new code!

[Jason-ABRP]

Published the code: https://github.com/iternio/autopi-link/blob/master/my_abrp.py

Still needs to be added to the app with setup instructions, but it should work better than the previous version.  Given that you're technical enough to set up the AutoPi, have you toyed with the Kona's PIDs at all? Speed measurement is very critical to the calibration, and I noticed we don't have a working speed PID for the Kona.  We can use the GPS/Glonass data as a backup, but that's relatively unreliable on the AutoPi I've found.

[vag]

Hi Jason,

Thank you for the new code.

I gave it a try today and here are my results:

When I run it from the command line (after having removed the test data and configured the token and the kona as car_model), I have the following:

Running from command line.
('soc', ('220', '105', '(bytes_to_int(message.data[34:35])/2.0)', '7E4'))
('soh', ('220', '105', '(bytes_to_int(message.data[28:29])*256+bytes_to_int(message.data[29:30]))/10.0', '7E4'))
('is_charging', ('220', '101', '((bytes_to_int(message.data[12:13])&1)/1)-((bytes_to_int(message.data[53:54])&4)/4)', '7E4'))
('ext_temp', ('220', '100', '(bytes_to_int(message.data[9:10])/2.0)-40.0', '7B3'))
('current', ('220', '101', '(twos_comp((bytes_to_int(message.data[13:14])*256+bytes_to_int(message.data[14:15])),16))/10.0', '7E4'))
('voltage', ('220', '101', '(bytes_to_int(message.data[15:16])*256+bytes_to_int(message.data[16:17]))/10.0', '7E4'))
('batt_temp', ('220', '101', 'twos_comp((bytes_to_int(message.data[19:20])),8)', '7E4'))

The data uploaded to ABRP is apparently empty or wrong, as on the web interface I have this message: "Missing telemetry: soc, power, speed, lat, lon, is_charging, ..."

 

Regarding the speed calculation, here is the PID and formula used in AutoPi which works for the Kona:

obd.query speed mode=220 pid=100 header=7B3 bytes=63 formula='bytes_to_int(message.data[32:33])' unit=kph baudrate=500000 protocol=6 verify=false force=true

 

If you have some debugging that I could do for the code, don't hesitate.

By the way, in the 3.9.11 version of the APP I found the button/link to reset the consumption calculation of the car, and the new calculation went to 188Wh/km, which reflects the reality.

In one week I'll be driving for approx 2K km, so I'll be able to verify and use the real time data.

[Jason-ABRP]

So, in my nomenclature (trying to approximate the Torque Pro PID lists, since that's where my Bolt PIDs came from):

obd.query speed mode=220 pid=100 header=7B3 bytes=63 formula='bytes_to_int(message.data[32:33])' unit=kph baudrate=500000 protocol=6 verify=false force=true
# Becomes:
'speed':      "220,100,'{30}',7B3",

Assuming I'm doing my early-morning arithmetic correctly and removing the header bytes correctly (0,1,2 are the header in the response)

As far as troubleshooting, it may be that the baudrate and protocol are important. Could you try adding

baudrate=500000,
protocol=6,

To the kwargs dictionary in "get_obd" function at line 134?  See if that helps.  Also, if you're running it as a job from the website, you should be able to pull up the minion log in the command line on the device to see what it's receiving / sending to ABRP.

[vag]

The baudrate and protocol are important in my opinion, as if they are wrong in the AutoPi interface, nothing is read from the OBDII.

I've added them.

I also uncommented the speed at line 247 which is now:

'speed':      "220,100,'{30}',7B3",

Still not working, no transmission to ABRP.

I then replaced (lines from 282 to 288):

 tlm(test=True,testdata={"soc": 88.4, "soh":100, "voltage":388.0, "current": 40,
    "is_charging": 0, "ext_temp":20, "batt_temp": 20, "lat":29.5641, "lon":-95.0255, "speed":113.2
  })
  
 tlm(test=True,testdata={"soc": 88.4, "soh":100, "voltage":388.0, "current": 0,
  })

by:

  tlm(test=False,testdata=None)

and still no results.

Then I replaced in line 32:

get_tlm(test=test,testdata=testdata)

by:

get_tlm(test=False,testdata=None)

without any additional success.

I checked minionutil.last_logs and minionutil.last_errors in the AutoPi's web interface, but they don't return anything.

When I look in file: /var/log/salt/minion, there is n nothing specific nor any error pointing clearly to your script

 

[Jason-ABRP]

Hmm, and you set it up with a job which starts it once a minute, with a "max running" of 1?  This makes it seem like the script isn't running at all.

[Jason-ABRP]

@vag - I spent some time with my AutoPi this morning and got the script working again, I think the problem was the wake/sleep code I was using, which they updated the handling on the device side, so don't need wake-sleep handling anymore.  I'm seeing good data from the device now, but I'm driving a Bolt EV, could you try the updated code now?

Important note: I moved the token and car_model to the kwargs in the job, so it's easier to copy the code to the autopi interface.

Also, if you SSH into the dongle while connected and run

less /var/log/salt/minion

(might have to sudo it) and scroll to the end, you should see an updated call to api.iternio.com with all the car details every 5 seconds or so.

The annoyance is that the AutoPi log doesn't seem to catch compile-time errors, which is why I added the "if __main__" code at the end, but my local execution environment on my desktop doesn't have all the same connections, so lots of the calls fail.

[TheRussian]

@Jason (ABRP) I'm trying out your AutoPi code on a Kona Ev 64kWh: can you tell me exactly how to configure AutoPi cronjob for your code, in every of the following fields?

At the moment I've succesfully configured my own code, but only with a cronjob running every minute, but the estimation results are quite poor when driving in transient conditions (e.g. city/extraurban/mountain), while they are good when driving in steady conditions (e.g. highway), so I would like to test your code.

Have you found a workaround to run faster than once per minute?

[vag]

@Jason (ABRP)

Hi Jason,

I finally found some time to test the last version of the script.

When I run it from command line, it uses the test data and prints out back the following :

------------------------------------

"...

Running from command line.
{'soc': 88.4, 'power': 15.52, 'soh': 100, 'is_charging': 0, 'ext_temp': 20, 'voltage': 388.0, 'lat': 29.5641, 'speed': 113.2, 'batt_temp': 20, 'utc': 1587192573.813606, 'lon': -95.0255, 'current': 40, 'car_model': 'chevy:bolt:17:60:other'}
https://api.iternio.com/1/tlm/send?token=test&api_key=6f6a554f-d8c8-4c72-8914-d5895f58b1eb&tlm={"soc"%3A88.4%2C"power"%3A15.52%2C"soh"%3A100%2C"is_charging"%3A0%2C"ext_temp"%3A20%2C"voltage"%3A388.0%2C"lat"%3A29.5641%2C"speed"%3A113.2%2C"batt_temp"%3A20%2C"utc"%3A1587192573.813606%2C"lon"%3A-95.0255%2C"current"%3A40%2C"car_model"%3A"chevy%3Abolt%3A17%3A60%3Aother"}
None
…"

---------------------------------------

Nevertheless, when i run it from Autopi’s terminal web interface, i find the following in minion logs :

---------------------------------------
" …
2020-04-18 06:51:31,100 [salt.loaded.ext.module.power:189 ][WARNING ][1817] Using deprecated argument 'enable' - use 'add' or 'clear' instead
2020-04-18 06:51:34,495 [salt.utils.schedule:927 ][ERROR   ][1795] Unhandled exception running my_abrp_iternio_v3.telemetry
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/salt/utils/schedule.py", line 842, in handle_func
    message=self.functions.missing_fun_string(func))
  File "/usr/lib/python2.7/dist-packages/salt/utils/error.py", line 36, in raise_error
    raise ex(message)
Exception: 'my_abrp_iternio_v3.telemetry' is not available.
..."

---------------------------------------

I don’t see what could cause the unhandled exception, while it works with the test data in ssh terminal screen.

The token and car_model are well in the kwargs of the job: by the way, this is very convenient

[Jason-ABRP]

Ah, hmm, in the new script I shortened the function to "tlm", perhaps it needs to be my_abrp_iternio_v3.tlm in the job settings?

Also, I made some updates this weekend if you'd like to download again, it should work (have it working pretty well in the car, though appreciate any bug reports).  It should be smarter about not sending data in unless it's useful.  Definitely happy for contributions to make it better.

Finally, I enabled the instructions in the new version of the site / app, if you wouldn't mind giving those a look-through.  I want to document which PID people use to keep their cars awake for easy setup for people new to the AutoPi, here's what I have so far:
https://github.com/iternio/autopi-link/blob/master/autopi_cars.json

Which feeds the setup instructions.  What do you use?

[vag]

@Jason (ABRP)

Hi Jason,

It finally worked!

The problem was only the kwargs setup in the cron job. After a quick check in the code, I noticed that the "abrp_token" was changed to "token" in the last version of the script. Once I did that change in the job, it started working

I'll check the instructions and add/complete information in there. Let me also check about the PID to keep the car awake and I'll get back to you with it.

Thank you again for the good work!

[vag]

@Jason (ABRP)

Here is a link to a draft page with instructions that I created : instructions page

Feel free to modify it and use it of course.

Regarding the PIDs for the Kona 64, these are the ones that are used to keep the AutoPi awake:

Mode: 220
PID: 101
Header: 7E4

They mean that the car is "driving".

I hope this can help you.

Let me know if you need something else.

 

[Jason-ABRP]

Will that PID also keep the Kona awake when charging?

I also need to (at some point) find the time to expand the script support to all the other cars we know the PIDs for:

• Ioniq
• Soul (all versions)
• Spark

Any others you know of?

[vag]

The PIDs that mean that the Kona is charging are the following:

Mode: 21
PID: 01
Header: 7E4

By the way, apparently the script doesn't detects actually when the charging stopped and continues to display the charging sign even when the car has been disconnected from the charger.

You can see in the attached picture here that it still looks like if it was charging, which was not exact when that snapshot was taken. Probably checking the above PID can be used to eliminate this issue.

Regarding the other cars, I don't have any idea, except that I read somewhere that there are similarities between the Ioniq and Kona, so it could probably work without much modifications.

[TomTomZoe]

I never saw the checkmark sign left beneath the battery symbol. What does it mean?

Is this Kona specific or a general new improvement from ABRP in the last version? 

(At the moment live data for Ampera-e is broken (seems to be a Webserver issue) so I don‘t see any live data features at all )

[vag]

When you click on this, it gives you your public charger network preferences (never use this network, prefer that network etc). I don't think it is a Kona specific. But maybe if you don't have setup any network preferences, it doesn't shows up.

[vag]

@Jason (ABRP) I did some additional tests today and I noticed that the script seems not to run continuously. When I launch the it in the AutoPi's web console followed by my data:

token=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx
car_model=hyundai:kona:19:64:other

It works until the next reboot of the AutoPi.

When it is configured as a job, it apparently doesn't works.

I tried the token & car_model in the Kwargs (and also in the Args), without success.

[Jason-ABRP]

On 4/27/2020 at 2:27 PM, vag said:

@Jason (ABRP) I did some additional tests today and I noticed that the script seems not to run continuously. When I launch the it in the AutoPi's web console followed by my data:

token=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx
car_model=hyundai:kona:19:64:other

It works until the next reboot of the AutoPi.

When it is configured as a job, it apparently doesn't works.

I tried the token & car_model in the Kwargs (and also in the Args), without success.

Hmm, it should run continuously, and the job should try to restart it every minute if it fails.  Unfortunately I don't have a whole lot of time to troubleshoot the script right now, so if you'd like to tinker with it I'd welcome the help, especially as I don't have a Kona to try the charging PID you suggested.

Do you have the job configured to run once a minute, and to only allow one to be running at a time?