Jump to content

[Live Data] AutoPi Car Support


Recommended Posts

  • Replies 85
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

The AutoPi ABRP script is to a point where I'm much happier with its behavior.  If there's interest, I'd be happy to add car support for the cars we know PIDs for (mainly Ioniq and Soul), but I need p

I've done another test this morning, I can confirm that during this test the charging power and SOC are updated correctly, so it must have been something else than your script (maybe carrier coverage

Great to hear! Feel free to PM me or email me if you've got questions on how to make it work. Awesome! Glad to hear it.

Posted Images

Turns out that was a lie, rewrote my_abrp quite substantially to make it easier to handle per-car differences like shifter position or methods to determine if a car is on or not.  On which note, is there any PID for the Kona / Niro which gives shifter position? Looking for something I can use to reliably determine if you're driving the car.

Link to post
Share on other sites

I made some more tests and it seems everything works fine now (3x charging sessions, icons went ON and OFF correctly, on a regular basis).

On 5/30/2020 at 6:59 PM, Jason (ABRP) said:

Turns out that was a lie, rewrote my_abrp quite substantially to make it easier to handle per-car differences like shifter position or methods to determine if a car is on or not.  On which note, is there any PID for the Kona / Niro which gives shifter position? Looking for something I can use to reliably determine if you're driving the car.

I actually use those two PIDs to determine whether the driving mode is on or not: BMS relay = 1 means the car is on (either charging or driving, you cannot tell from this), while Ignition relay = 1 means that your vehicle key is turned to start (I have never checked what happens in case you're charging and you also start the Ignition key though).

Following code for PIDs in AutoPi:

def get_bms():
# bms relay 1=on means "charging or driving"
# obd.query Relay_Ignit mode=220 pid=101 header=7E4 bytes=64 formula='((bytes_to_int(message.data[12:13]))&1)/1'
# unit=OnOff baudrate=500000 protocol=6 verify=false force=true
try:
args = ['Relay_BMS']
kwargs = {
'mode': '220',
'pid': '101',
'header': '7E4',
'bytes': 64,
'baudrate': 500000,
'formula': 'bytes_to_int(message.data[12:13])',
'protocol': '6',
'verify': False,
'force': True,
}
return (int(__salt__['obd.query'](*args, **kwargs)['value']) & 1) / 1
except:
return -1
 
def get_ignit():
# ignition relay 1=on means "driving"
# obd.query Relay_Ignit mode=220 pid=101 header=7E4 bytes=64 formula='((bytes_to_int(message.data[53:54]))&4)/4'
# unit=OnOff baudrate=500000 protocol=6 verify=false force=true
try:
args = ['Relay_Ignit']
kwargs = {
'mode': '220',
'pid': '101',
'header': '7E4',
'baudrate': 500000,
'bytes': 64,
'formula': 'bytes_to_int(message.data[53:54])',
'protocol': '6',
'verify': False,
'force': True,
}
return (int(__salt__['obd.query'](*args, **kwargs)['value']) & 4) / 4
except:
return -1
Link to post
Share on other sites

I implemented the ignition PID, but I think I've realized a hole in the logic for the Hyundai/Kia PIDs.  If BMS is active, and ignition is not, then you're definitely charging.  If BMS is active and ignition is active, then you could be charging or driving (could be sitting in the car during a charge).

If we can count on power being negative during a charge, perhaps we can check that to see if charging or driving?

Alternately, what about using these PIDs:

000_Normal Charge Port    0x220101    {j:5}    0    1        7E4
000_Rapid Charge Port    0x220101    {j:6}    0    1        7E4

obd.query is_charging mode=220 pid=101 formula=(((bytes_to_int(message.data[12:13])&32)/32) or ((bytes_to_int(message.data[12:13])&64)/64)) header=7E4 force=True

Can someone with a Kona/Niro/New Ioniq run that obd.query and see if it gives reasonable results (1 while charging, 0 while not charging)?

Finally, I created Add-On support for the script, since OBD calls take so long I figured it might be helpful for people to use that for their own scripts using EV data I'm already pulling (to avoid redundant calls).  Pretty easy to work with, setup instructions are in the Readme, and there's an example/template script in the repository:

https://github.com/iternio/autopi-link/blob/master/my_script.py

Let me know how it works for you!

 

 

Link to post
Share on other sites
9 hours ago, Jason (ABRP) said:

I implemented the ignition PID, but I think I've realized a hole in the logic for the Hyundai/Kia PIDs.  If BMS is active, and ignition is not, then you're definitely charging.  If BMS is active and ignition is active, then you could be charging or driving (could be sitting in the car during a charge).

If we can count on power being negative during a charge, perhaps we can check that to see if charging or driving?

Alternately, what about using these PIDs:


000_Normal Charge Port    0x220101    {j:5}    0    1        7E4
000_Rapid Charge Port    0x220101    {j:6}    0    1        7E4

obd.query is_charging mode=220 pid=101 formula=(((bytes_to_int(message.data[12:13])&32)/32) or ((bytes_to_int(message.data[12:13])&64)/64)) header=7E4 force=True

Can someone with a Kona/Niro/New Ioniq run that obd.query and see if it gives reasonable results (1 while charging, 0 while not charging)?

I can definitely do some tests on those PIDs and give you the result. Give me a couple of days to test. 😉

On the Add-On side, I haven't got exactly how to use them (the Readme is not really a step by step description 😛), so if you could give me some more hints about implementation  I can try and test it for you.

Link to post
Share on other sites
6 hours ago, TheRussian said:

I can definitely do some tests on those PIDs and give you the result. Give me a couple of days to test. 😉

On the Add-On side, I haven't got exactly how to use them (the Readme is not really a step by step description 😛), so if you could give me some more hints about implementation  I can try and test it for you.

Great! Let me know if it works reliably.

For the add-ons, I updated the instructions so they're more detailed, feel free to ask me questions where it's not clear.  It's mainly for those who are code-inclined to write their own scripts that use the same data I'm already retrieving:

https://github.com/iternio/autopi-link/blob/master/README.md

Link to post
Share on other sites

@vag or @TheRussian - One more PID to check if you wouldn't mind:

obd.query motor mode=220 pid=101 formula=twos_comp((bytes_to_int(message.data[56:57])*256+bytes_to_int(message.data[57:58])),16) header=7E4

This should retrieve the motor RPM, which would help in distinguishing charging vs driving.  Can you check if it returns a non-zero value when moving, but zero when parked?

Edit: For anyone interested, I tried out the new "Services" feature in the most recent update, and it doesn't seem to start any faster than the previous Jobs function.  I will probably spend a little time seeing if I can optimize it somewhat, but we may be out of luck on getting faster booting.  I'm pretty consistently seeing 2-3 minute start times.

Edited by Jason (ABRP)
Added note about services
Link to post
Share on other sites

Hi Jason, I tested your obd.query scripts, here's the result (you have to force=True both of them, otherwise AutoPi replies that are not supported:

IS_CHARGING (formula is not supported in the way you wrote it, so I launched other queries as separate tests, without success):

obd.query is_charging mode=220 pid=101 formula=
(((bytes_to_int(message.data[12:13])&32)/32) or ((bytes_to_int(mess
age.data[12:13])&64)/64)) header=7E4 force=True
 
>-
  Passed invalid arguments to obd.query: query() got multiple value
s for keyword argument 'pid'
 
 obd.query is_charging mode=220 pid=101 formula=
(((bytes_to_int(message.data[12:13])&32)/32)) header=7E4 force=True
 
'Failed to calculate formula: unexpected EOF while parsing (<string>, line 1)'

MOTOR:

obd.query motor mode=220 pid=101 formula=twos_c
omp((bytes_to_int(message.data[56:57])*256+bytes_to_int(message.dat
a[57:58])),16) header=7E4 force=True
 
_type: motor
_stamp: '2020-06-13T07:33:39.436058'
value: 0
Edited by TheRussian
Link to post
Share on other sites

Moreover, I subscribed in order to do some more testing and found out that if I export a typical day of usage to Excel, ABRP doesn't show the following (I blackened locations and vehicle name for privacy, but they're accurate):

- Energy Added

- Start Odometer

- End Odometer

Is this due to missing KonaEv PIDs or it's something else on ABRP side?

image.thumb.png.f14d66bdbac892812543831929136c3b.png

 

Apart from that, I'm still running one of your older release and Drive/Charge are detected flawlessly, so I wouldn't add anything else honestly on KonaEv side.

Edited by TheRussian
Link to post
Share on other sites
On 6/13/2020 at 3:19 AM, TheRussian said:

Moreover, I subscribed in order to do some more testing and found out that if I export a typical day of usage to Excel, ABRP doesn't show the following (I blackened locations and vehicle name for privacy, but they're accurate):

- Energy Added

- Start Odometer

- End Odometer

Is this due to missing KonaEv PIDs or it's something else on ABRP side?

image.thumb.png.f14d66bdbac892812543831929136c3b.png

 

Apart from that, I'm still running one of your older release and Drive/Charge are detected flawlessly, so I wouldn't add anything else honestly on KonaEv side.

We don't have PIDs in the AutoPi for either of those for the Kona yet.  If you have something which reliably reports either of those, I'm happy to add them!

Link to post
Share on other sites
On 6/18/2020 at 2:28 PM, Jason (ABRP) said:

We don't have PIDs in the AutoPi for either of those for the Kona yet.  If you have something which reliably reports either of those, I'm happy to add them!

No problem, here they are! 😉 I already know they work correctly, as I use them constantly in my AutoPi scripts.

ODOMETER:

$ obd.query Veh_Odometer mode=22 pid=B002 header=7C6 bytes=64 formula='bytes_to_int(message.data[10:12])' unit=km baudrate=500000 protocol=6 verify=false force=true

VEHICLE SPEED:

$ obd.query Veh_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

CUMULATIVE ENERGY CHARGED (this is a cumulative absolute value, in order to get the energy charged during a session, you need to do the difference between: value@chargeEND - value@chargeSTART):

$ obd.query CEC mode=220 pid=101 header=7E4 bytes=64 formula='(bytes_to_int(message.data[41:45]))/10.0' unit=kWh baudrate=500000 protocol=6 verify=false force=true

Let me know when you update the code, I'm ready to test it. 😉

Edited by TheRussian
Link to post
Share on other sites

I've implemented these (and haven't tested to make sure they work, as I don't have a Hyundai/Kia to test on).  It at least doesn't have any syntax errors, so that's a start.

For anyone interested, I also toyed with turning the ABRP script into a service, which should start immediately on boot according to the AutoPi team, however in my testing it doesn't start significantly faster than the standard scripts, so I'm not sure it's worth the extra hassle running as a service comes with.  

Link to post
Share on other sites

First testing today shows all the additional information correctly on the Hyundai Kona, BUT the data were not polled every 5 seconds as usually. I’m doing more testing later and let you know how it goes (maybe it’s an AutoPi issue, not related to your script at all.

 

EDIT: yes, I think the problem was AutoPi dongle temperature that went up to 60 deg and the system shut down... 😅 No worries apparently on your script side.

Edited by TheRussian
Link to post
Share on other sites

Well, one thing that might help, if you have a lot of scripts, would be to tie them into the ABRP script with the add-on feature.  This will prevent some overload, as each __salt__ call seems to take a lot of processing, so doing a lot of redundant OBD pulls costs a lot of processing power.  Should be easy enough to adapt your existing scripts, assuming that's the issue.

Link to post
Share on other sites

Actually I have a pretty low number of loggers and just 5 scripts, all very slowly triggered, so I don’t think this is the issue.

 I don’t know if it is due to the addition of the speed obd query, but now ABRP script runs only once every couple of minutes when driving, while everything is normal during charging. I did a 32 km trip and only got 8 data points in ABRP, while all the data are recorded correctly in AutoPi...

Do you have any idea how this is possible and what could cause this issue in your latest script?

Link to post
Share on other sites
On 6/25/2020 at 3:10 PM, TheRussian said:

Actually I have a pretty low number of loggers and just 5 scripts, all very slowly triggered, so I don’t think this is the issue.

 I don’t know if it is due to the addition of the speed obd query, but now ABRP script runs only once every couple of minutes when driving, while everything is normal during charging. I did a 32 km trip and only got 8 data points in ABRP, while all the data are recorded correctly in AutoPi...

Do you have any idea how this is possible and what could cause this issue in your latest script?

That's very strange, I'm running the same code in my Bolt EV and I'm getting quite a decent data rate (one every 5s).  Are you set up to easily SSH into the dongle and read the logs while it's running to see if we can determine what's going wrong?  Shoot me an email if so and we can do some debugging.

Link to post
Share on other sites
  • 2 weeks later...

I think it has something to do with the is_driving calculation you did for the Kona: if you give me the specific command line to test, I can run it from the web interface while driving and let you know (unluckily I don't have a SSH connection setup while driving, but I can run the commands from the web terminal, no problem).

My feeling is that is_driving is not working correctly, so the script runs on the cronjob basis instead, skipping some values when Mobile Data connection is not strong enough.

Link to post
Share on other sites
  • 2 weeks later...

I added install instructions to the "service" branch, let me know if I missed anything:

https://github.com/iternio/autopi-link/tree/service

It does start up ~10 seconds faster.  If it doesn't work right, try setting debug to true and that'll give you some extra logs when it starts up.  You'll probably also have to power cycle the AutoPi once it's sync'd to get the script to start.

Edit: For what it's worth, the most recent version of the script starts up just fine on my AutoPi.

Link to post
Share on other sites

Thanks for the guide, I may try this out later in the week.

As of now, the current "Excecution script" has for sure some troubles (at least for me) as it doesn't update on 5 seconds basis during running (but it is basically run by the cronjob every minute), but it actually works fine when charging...

I don't have a direct SSH access while running, do you have some other hints to debug or get extra debug data from the web interface?

Link to post
Share on other sites

That's may be by design, actually. To avoid using more data then we need, I have it only send data in when it's different from the last measurement, or if enough time has elapsed to keep the data marked 'fresh' in the app.  That's minimum every 30 seconds while driving, or every 60 seconds while charging.

Of course, it should send much more frequently when the data is actually changing (IE while on the road).  If you want to get rid of this in your copy of the script to see if that resolves your issue just change these lines to a much smaller timeout value (or 0):
https://github.com/iternio/autopi-link/blob/master/my_abrp.py#L102-L106

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...