16 posts / 0 new
Last post
Jason_ABRP
Jason_ABRP's picture
ABRP Script Updates

I've been working on some small updates to the ABRP / OVMS Script, and I think it's more or less ready for some general testing.  Some new features:

  • Variable send rates
    • Instead of sending only once per minute no matter what, the script now chooses an appropriate interval:
    • Every 25 minutes if the car is inactive (maintains 'connected' indicator on ABRP app)
    • At least every 30 seconds while driving or charging
    • At most every 10 seconds if relevant telemetry has changed.
  • Less setup required
    • Car Model is determined by the ABRP server based on your token
    • URL is now generic
    • Script can be auto-started by ovmsmain.js

I've been running it for a day or so on my Leaf, and it works quite well.

You can try out the new script from here:
https://github.com/iternio/ovms-link

And feel free to suggest improvements!

If it works well for others too, I'll submit it as a pull request to the main repository and update the docs.

I do have one technical question I didn't find an answer for in the docs (or perhaps I was looking in the wrong places). Are there signals I could connect to for when the OVMS sleeps the modem so I can avoid trying to send data in when the OVMS is trying to sleep?  This would help further improve the 12V battery impact of the script.

dexter
dexter's picture
ABRP Script Updates

Jason,

thanks for your support!

The OVMS power management sends signals "power.<device>.<mode>" on state changes. Be aware modem sleep modes haven't yet been implemented, and the modem device will also get a more generic device name in the near future (with the 5G modem), so you might consider delaying the implementation until then.

You will later (firmware 3.3) see a signal "power.cellular.sleep" or "power.cellular.deepsleep" when the modem is sent to sleep / deep sleep, and "power.cellular.on" for a wakeup. Modes "off" and "devel" may also be used, simply use any mode except "on" for pausing the ABPR transmission.

You can also get the current power mode (for script init) by the command "power <device> status". This would currently be "power simcom status", and "power cellular status" in the future (firmware 3.3). The command result is a string "Power for <device> is <mode>\n".

Regards,
Michael

bofi
Hello,

Hello,

i just installed the new script on my kia soul ev.

 I had to change the ovmsmain.js to:

abrp = require("sendlivedata2abrp");

abrp.send(1)

to make the script work properly.

I also deletet all "SOH" parts  in sendlivedata2abrp.js because the kia soul ev 30kWh always returns 60% witch was set by abrp even i disabled the automatic data for soh in abrp app and web.

As long the SOH frpm Kia Soul EV 30kWh is not reportet correct by ovms i will set it manually.

 

Regards,

Daniel

Jason_ABRP
Jason_ABRP's picture
Thanks for the info, @dexter,

Thanks for the info, @dexter, I'll see if I can figure out a good way to use those.  As a point of curiosity, would `power.cellular.on` be set even when on WiFi? Wouldn't want to pause sending data while on the home wifi network and charging on the home EVSE.

I've made some more updates to the script, found some annoyances with my Leaf that I've sorted out, and it's much more stable.  I did have one place where it lost my user token (which is set using the `config set usr....` command).  I thought those were stored to non-volatile storage, is it expected that might happen occasionally?  Or maybe some kind of bug somewhere perhaps?  Restarting the script, and rebooting the OVMS module itself didn't restore the config, so I had to log in and set the token manually.

dexter
dexter's picture
ABRP Script Updates

Currently, the modem is kept powered with Wifi active, but that may change or become configurable. If an available network option is the key, consider tracking the "network.up" & ".down" events.

The whole config storage is supposed to be persistent, that includes any "usr" space configs. We've seen issues with the "/store" partition getting corrupted in such a way, that it no longer was able to keep any new data changes, but still delivered the previously stored elements. In all these cases, the only option is a factory reset (formatting the /store partition) and doing a config restore from a backup.

That's an unsolved issue with the underlying FAT filesystem implementation. You can test that condition by trying to write to a file on "/store" and see if that succeeds and the file actually has your content afterwards.

 

jamesc83
Hi,

Hi,

I am trying this new script out on my MG ZS EV so will let you know if I have any issues.

 

bofi
Hi,

Hi,

i installed the new script (without removing soh for Kia Soul) and i get multiple error messages in shell:

E (11001204) script: [sendlivedata2abrp.js:276] TypeError: cannot read property 'is_charging' of null ……: at [anon] (duk_hobject_props.c:2549) internal ……: at SendLiveData (sendlivedata2abrp.js:276) ……: at callSubscriberWithImmediateExceptions (int/PubSub.js:1) strict ……: at deliverMessage (int/PubSub.js:1) strict ……: at [anon] (int/PubSub.js:1) strict ……: at publish (int/PubSub.js:1) strict ……: at [anon] (int/PubSub.js:1) strict preventsyield

 

But it is sending data.

The next problem i found:

The data even the car parks and is switcht off is:

{"car_model":"kia:soul:18:30:other","url":"http://api.iternio.com/1/tlm/send","user_token":"d50585c7-36b8-402d-b0cd-8e51bcb227c7"}
Start sending data...
 soh: 60,  soc: 76,  lat: 47.++++,  lon: 12.++++,  elevation: 494.7,  power: 8.891,  batt_temp: 22,  ext_temp: 23.5,  voltage: 381.6,  current: 23.3, 
altitude = 494.7m
latitude = 47.8880°
longitude= 12.1518°
ext temp = 23.5°C
charge   = 76%
health   = 60%
bat temp = 22°C
voltage  = 381.6V
current  = 23.3A
power    = 8.891kW
charging = 0
Sending: Telemetry changed.

this makes ABRP do not detect different drives.

 

 

Jason_ABRP
Jason_ABRP's picture
For the errors you're seeing,

For the errors you're seeing, I think I fixed that one in a recent update, an annoying bug where on occasion the data object would get nulled, and thus inaccessible as the error suggests.  Let me know if you're still seeing it on the most recent versions.

On the 'stale' drives in history I noticed the same thing on my Leaf, and I think it has to do with OVMS not receiving a non-zero value for some of the readings.  I've added a staleness check which zeroes out the offending values, so hopefully that helps.

For the odd 'SoH' value you see, how would it be easiest to account for those variations? Ideally you could fix OVMS' reading of the SoH for your car model (Have you tried the 'deterioration' values from this PID list?).  But barring that, I could add a 'whitelist' of allowed values at the top, and you could just edit that list to remove SOH from the log.

arkranium
arkranium's picture
Nice work. I started fiddling

Nice work. I started fiddling with the script a while ago and tidied it up a bit. Completely forgot to submit a PR. 

FWIW it's here https://github.com/biddster/Open-Vehicle-Monitoring-System-3/blob/master/plugin/abrp/sendlivedata2abrp.js

I was looking at building an autoSend so if the car was powered it would send and stop when you turned the car off.

 

bofi
I will try the new script.

I will try the new script.

Fixing the SOH reading for the 30kWh Modell is not easy. I tried jejusouls PID in Torque already and the reading is 110 initially and then drops to 60/ like ovms. The ony app that reads constant 100% is SoulSpy but i don´t know the real SOH of my car.

See: https://www.mykiasoulev.com/forum/viewtopic.php?f=6&t=471&p=8116&hilit=30kWh+max+det#p8116

and

https://github.com/JejuSoul/OBD-PIDs-for-HKMC-EVs/issues/43

Perhaps the best solution is to don´t read SOH  if "car_model":"kia:soul:18:30:other"  ?

Whithelist will do the job too.

jamesc83
I am have been having an

I am have been having an issue where my unit reset to setup mode if I unplug it for a few hours.

Would abrp cause this? Or is it more like an issue with my unit?

jamesc83
I am have been having an

I am have been having an issue where my unit reset to setup mode if I unplug it for a few hours.

Would abrp cause this? Or is it more like an issue with my unit?

dexter
dexter's picture
unit reset to setup mode if I unplug it

That's most likely an issue with your store partition. Try a factory reset.

jamesc83
Thanks I have tried that

Thanks I have tried that having seen some other posts. Working ok so far, will see how it goes. Haven't reinstalled abrp at the moment but I agree it's unlikely to be the cause.

Jason_ABRP
Jason_ABRP's picture
I don't think I'm doing

I don't think I'm doing anything in the script which would cause that behavior.  The ABRP script should be completely benign.

On a different note, I'd like to be able to add a 'try/catch' type statement to catch any remaining uncommon nagging errors in the script, but the standard Javascript version didn't seem to work when I tried it.  I couldn't find much online about it either, has anyone managed to implement this kind of thing using the OVMS scripting engine?

dexter
dexter's picture
try/catch

try/catch should work, example:

(function(){
 try {
  a.b = 1;
 }
 catch (e) {
  print ("catched: " + e + "\n");
 }
})()

→ Output:

catched: ReferenceError: identifier 'a' undefined

Can you supply the code you tried?

Log in or register to post comments
randomness