Jump to content
Jason (ABRP)

[Live Data] AutoPi Car Support

Recommended Posts

At the moment I don't have anything planned, but I plan to do some of my own driving and charging, so if I find any bugs I may update.

Share this post


Link to post
Share on other sites

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.

Share this post


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

Share this post


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!

 

 

Share this post


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.

Share this post


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

Share this post


Link to post
Share on other sites
Posted (edited)

@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

Share this post


Link to post
Share on other sites
Posted (edited)

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

Share this post


Link to post
Share on other sites
Posted (edited)

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

Share this post


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!

Share this post


Link to post
Share on other sites
Posted (edited)
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

Share this post


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.  

Share this post


Link to post
Share on other sites

Thanks Jason, I've updated the script now, tomorrow I'm testing it and let you know if everything is in place. 🙂

Share this post


Link to post
Share on other sites
Posted (edited)

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

Share this post


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.

Share this post


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?

Share this post


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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Well, I ended up removing the is_driving calculation as some testing with @Joaquim Lopes showed it wasn't very reliable.  The current version is reverted back to the previous methodology.  

Share this post


Link to post
Share on other sites

I'm having a lot of troubles after updating to the new release, but it seems like it's not running at all in AutoPi, so there's nothing really wrong with the code itself: I'll try to figure that out and let you know asap...

Share this post


Link to post
Share on other sites

I'm trying to configure the script as a service, to see if it gets unstuck: can you write down all the AutoPi configuration steps you used for your test?

Share this post


Link to post
Share on other sites

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.

Share this post


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?

Share this post


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

Share this post


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.


Contact Us

Bo - Lead Developer and Tesla owner: bo@abetterrouteplanner.com

Jason - New Car Models, Developer and Bolt owner : jason@abetterrouteplanner.com

Idreams - Forums Administrator, Forums Developer and Tesla owner : idreams@abetterrouteplanner.com

×
×
  • Create New...