So, where are we?

Back in september 2018 I posted some initial thoughts on what I would like to see to support my electric car ( Electric car features ). I thought it would be useful see we are are against those ideas - partly to see how far we’ve come, but also to put some perspective on what is still pending.

General

Hey its working ! I have data coming from the car and displaying in the cloud console ! So great progress. But …

  1. Trips are not working ( I know thats pending of course )
  2. Its early days for the dash board widgets ( just look to see what you can do on torque pro and others )
  3. Data is somewhat distorted by averaging ( eg integers become floats ! )
  4. Can bus recording doesn’t work with my car ( and many others I believe )
  5. OBD requests seem to be slow ( about 2 a second ) - maybe we can expose logger data to custom scripts ( to avoid re-requesting ) or, perhaps, move to an async model like OVMS. Scrips are limited to once a minute.
  6. It can be painful to work with autopi due to its in the car and power quickly runs out. Text console is very slow ( responses in minutes ), issues when functions return 0, not quite the same behaviour between console and scheduled job

Responses to early wish list

Looking back at the earlier post, this is where I am :

  • Support a selection of electric car’s ( of course ! )

This is probably the main issue with autopi and similar devices - it depends on manufacturer specific OBD information which they don’t release ( and, yes, I’ve asked ), so we’ll always be trying to reverse engineer the car.

I’ve been wondering if autopi can open up relationships with the manufacturers to see if more information can be found ( after all, info is shared to diagnostic devices ).

Or, failing that, maybe, we need a fast scanning tool with autopi, with associated tools so that data can be gradually understood.

  • Support displaying State of Charge (SOC) - battery percentage full

Yep, done ( thanks to the early explorers ar https://github.com/JejuSoul/OBD-PIDs-for-HKMC-EVs )

  • Support displaying State of Health (SOH) - percentage of the original battery max capacity
    • Especially over time (years) as the car ages

Yep, done. Although we’ve not had the autopi for years yet !

  • Detect charging
    • Include on map
    • Keep track of failed charges
    • Alert when charging is finished

Partially done. I don’t believe there is a way to draw chargers on the map. However I did coble together some python code ( Receive charging alerts on your phone ( and smart watch ) ) … but its a shame it can only poll once a minute and not use data already gather by autopi ( so data is always going to be old ).

  • Calculate cost of charging
    • Based on KW’s charged
    • Find cost per KW from location, maybe query on-line database for costs ( eg https://openchargemap.org/site/poi/details/106888 )
    • If at home location, take into account home electricity costs, economy 7 etc
    • Compare with petrol prices ( for gloat value in the pub :wink: )

Not done.

  • Calculate CO2 saved

I am tinkering with this as part of the charging alerts. Not sure yet if the sums are right though !

I don’t see a way to even start on this.

One idea is to submit data to a better router planner, ie ABRT ( https://abetterrouteplanner.com/ ), since they seem to be able to do the sums ( eg for teslas see https://forum.abetterrouteplanner.com/blogs/entry/11-range-vs-speed-vs-temperature-from-805-teslas/ ).

With that in mind, I have opened a discussion with the ABRT folks.

  • Turn on pre-heating (on cold days)

As far as I know, no-one has discovered how to do this. In any case, we don’t have a graphical way to send commands yet.

  • WiFi hotspot support for Hyundai Kona ( to support Tom Tom )

Worked out of the box !

Priorities

So, from my point of view, these are the next steps in priority order -

  1. Trips for EV
  2. Improve dashboard
  3. Add some tools to scan OBD and process the results ( or, get more info from the manufacturers ! )
  4. Consider ways to speed up requests ( especially from custom code ), look at async calls and integration of the logger with custom scripts
  5. See if there is a better way to test scripts

Summary

I suppose a post like this was always going to feel a bit negative, but thats not my intent. A lot is working and autopi is now fully installed in my car. So many thanks to the autopi folks for the progress so far … pretty awesome :slight_smile: Many thanks for the product and the support offered here. Much appreciated.

8 Likes

Unless i’m missing something… there’s still no way to replace car on/off state detection via RPM PID with something that makes sense in the context of EVs.

I’d think that one would be absolute priority for EVs?

1 Like

Yep - thats required for “Trips”. Also my number 1.

2 Likes

Hi @plord,

As always thank you for the good feedback from you and the rest of the community. We really value and read every single comment you make.

I want to address the point you’ve highlighted.

  1. Trips: As you say we are working on this actively. Next week we will make an update which contains the next part of the trips for EV. It’s not the complete part but will contain the first steps.
  2. Dashboard: Indeed, you are right. We have made some improvements on this in the next release. Some of it will be ability to autorefresh and other visualization updates.
  3. Averaging: It’s on the todo, I’m not sure if we will have it done by the next release, buts its something we are working on.
  4. CAN bus recording: Hmmm, it should. Have you tried the obd.monitor function? If it keeps bugging you, then please reach out to support@autopi.io, they can assist you with this.
  5. Slow requests: You need to use the obd.send function instead. It’s much lower level and will improve speed. See docs.autopi.io
  6. Power on: You can change the power settings to allow the device to remain online. If you have it connected to the Charger, the you can simply disable the sleeptimers. If you want to work directly with the AutoPi commands, you can always SSH into the device and run the commands directly. Simply postfix every command with AutoPi, like autopi power.status.

I do have one comment on the Trips. As of now I believe you should be able to get it working on the Kona. All you need to do is add a logger for RPM. You can use 000_Drive Motor Speed 1 found in:

The only thing important is that the name of the logger (in the library) is RPM. The system will then automatically use the RPM value for that logger. You could use any value, as long as the name of the logger is RPM.

As to your other comments, nice work. We appreciate the effort you’ve put in to customizing your device, I’m sure all fellow EV’s does the same.

best
Peter

I couldn’t get it to work in custom code - see Best way to do scans ,,,

Maybe share an example custom code running obd.send and parsing the results ?

I also understand that its common to do asynchronous calls - ie send several requests at once and processes the responses as they come back in a separate thread. Presumably the logger already does this, but I don’t see a way in custom code.

But also, any reason why a script can’t access the latest logger results ? Presumably the logger is nice and efficient already. We would need to get both the last result and the latest successful result.

Many thanks,

Pete

On my car there is nothing to capture … the OBD port seems to be deliberately firewalled off.

I did notice in https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master/vehicle/OVMS.V3/components/vehicle_kianiroev/src/kn_can_send.cpp that it seems to be possible to put the car into “tester” mode … maybe that unlocks the firewall.

I just don’t know enough about OBD or my car to know.

Yes, I know. But autopi shuts down pretty quickly ( I think there is a small battery between the main 12v battery and the OBD port ) and the dev cycle to run custom code is long. Typically the car powers off before I get much done.

Yes, I’m using ssh as much as I can, but it doesn’t stop the car from powering down when at critical level.

Also, when I have to connect to the autopi locally, it usually means sitting in the car with a laptop rather than on my desk which isn’t great.

I suspect what we need is a way to run custom code in a simulator outside of the car, with much a quicker dev cycle.

Oh, wow, I didn’t know that. I’ll try a little later :slight_smile:

How about something like this -

  • Add a “OBD scan” tool on the cloud
    • Option for a fast scan to run through a set of commonly used PIDs and records the results
    • Option for a full scan to run through all PIDs and record the results
    • Option for multiple recordings ( eg parked, driving etc )
  • Add a “OBD results editor” tool on the cloud
    • Allows annotating of captures ( eg bytes 3,4 is mapped to “speed” ), ECU 7EA is “BMS” etc
    • Future captures have old annotations applied automatically
    • Annotations can be shared and discussed
    • Over time, more and more of the responses are discovered
    • Create library from this discovery
  • Some easier language to extract data from responses ( eg in Torque Pro format )
  • Add a “Car simulator” tool to the cloud
    • Previous scans used to test library, logger and widgets
    • Previous scans used to test custom code
  • Add a diff tool
    • Run scan 1
    • Do an action - eg open door
    • Run scan 2
    • Compare the two scans to isolate what PID is probably the door

BTW, I’m sort of doing some of this now. I have a custom code that performs a number of OBD scans and write the hex dumps to the logger. I then scp the logs to my desktop and run a perl script to try and decode them … for example -

./analyse.pl minion.log
pid 22c00b @ 2019-05-02T19:20:17.252460
7A8 10 17 62 C0 0B FF FF 00
7A8 21 00 AF 44 01 00 B1 46 [?=0] [Tire Pre_FL=35] [Tire Temp_FL=18] [?=1] [?=0] [Tire Pre_FR==35.4] [Tire Temp_FR=20]
7A8 22 01 00 B4 43 01 00 AF [?=1] [?=0] [Tire Pre_RR=36] [Tire Temp_RR=17] [?=1] [?=0] [Tire Pre_RL=35]
7A8 23 42 01 00 AA AA AA AA [Tire Temp_RL=16] [?=1] [?=0] [?=170] [?=170] [?=170] [?=170]

pid 220101 @ 2019-05-02T19:20:18.816943
7EC 10 3E 62 01 01 FF F7 E7
7EC 21 FF B8 23 3F 46 50 03 [?] [SOCBMS=92] [MAXREGEN=90.23] [MAXPOWER=180] [BMS?=3]
7EC 22 FF E5 0F B5 10 0F 0F [BATTCURR=-2.7] [BATTVOLTS=402.1] [BATTPOWER=-1.08567] [BATTMAXT=16] [BATTMINT=15] [BATTTEMP1=15]
7EC 23 0E 0F 10 00 00 0F CD [BATTTEMP2=14] [BATTTEMP3=15] [BATTTEMP4=16] [BATTTEMP5=0] [?] [BATTINLETT=15] [MAXCELLV=4.1]
7EC 24 4B CC 46 00 00 93 00 [MAXCELVNO=75] [MINCELLV=4.08] [MINCELLNO=70] [BATTFANSPD=0] [BATTFANMOD=0] [AUXBATTV=14.7]
7EC 25 00 98 8A 00 00 95 C1 [CCC=3905] [CDC=3833.7]
7EC 26 00 00 39 DF 00 00 36 [CEC=1481.5]
7EC 27 B5 00 1A D8 F3 09 01 [CED=1400.5] [OPTIME=488.743055555556] [?BMSIGN=9]
7EC 28 91 00 00 00 00 03 E8 [BMSCAP=401] [RPM1=0] [RPM2=0] [SURGER=1000]

Nice idea … but didn’t seem to work. I still get no trips -

06

Can you send me a screenshot of the following:

  1. how you setup your rpm in the library
  2. how you configured your logger to use the rpm
  3. confirmation that you have a field type in the widget configuration called “obd.rpm”

To my understanding it should work.

Best
Peter

02

55

05

No - I only get “obd.rpm.value” not “obd.rpm”

So the docs contain -

  • header (str): Identifer of message to send. If none is specifed the default OBD header will be used.
  • auto_format (bool): Apply automatic formatting of messages? Default value is False .
  • expect_response (bool): Wait for response after sending? Avoid waiting for timeout by specifying the exact the number of frames expected. Default value is False .
  • raw_response (bool): Get raw response without any validation nor parsing? Default value is False .
  • echo (bool): Include the request message in the response? Default value is False .
  • protocol (str): ID of specific protocol to be used to receive the data. If none is specifed the current protocol will be used.
  • baudrate (int): Specific protocol baudrate to be used. If none is specifed the current baudrate will be used.
  • verify (bool): Verify that OBD-II communication is possible with the desired protocol? Default value is False .
  • output (str): What data type should the output be returned in? Default is a list .
  • type (str): Specify a name of the type of the result. Default is raw .

I noticed -

  1. No description of the return type when auto_format = True
  2. No description of the return type when raw_response = True
  3. No alternatives for output option - just default of list
  4. No alternatives for type option - just default of raw

As far as I can see, this returns a list of strings - I don’t see a way to get at the data object for example.

Thanks.

1 Like

First priority for me is RPM mandatory for wake up on going and charge status daemon for ev cars wake up . ( your telegram bot is beautiful @plord :slight_smile: )

I like to add it DASHBOARD display first settings to show all loggers and not trip that is not useful to see at first … it’s fast to implement

1 Like

Hi @plord,

The obd.rpm.value should be correct. But do you actually get some data back from this? Can you try to run it manually with the engine on? If the function doesn’t return data, then it wont work.

When it works, you should also be able to see a number of different events, under the “Events” page. Do you see any?

best
Peter

So I have two loggers configured the same - ‘MOTOR RPM 1’ which is reporting data and its appearing in the widgets and ‘RPM’ which isn’t reporting data.

In the logs I see -

2019-05-06 10:08:52,343 [messaging        :232 ][ERROR   ][749] Recurring exception (30 times) in worker thread 'readout_10sec' while running workflow for message: {'filter': 'alternating_readout', 'handler': 'query', 'returner': 'cloud', 'args': ['RPM'], 'kwargs': {'force': True, 'pid': 101, 'header': '7E4', 'mode': 220, 'formula': 'twos_comp(bytes_to_int(message.data[56:57])*256+bytes_to_int(message.data[57:58]),16)', 'protocol': 'auto'}}
Traceback (most recent call last):
  File "/var/cache/salt/minion/extmods/utils/messaging.py", line 188, in do_work
    self._call_hook_for(message, "workflow", message)
  File "/var/cache/salt/minion/extmods/utils/messaging.py", line 410, in _call_hook_for
    return True, func(*args, **kwargs)
  File "/var/cache/salt/minion/extmods/utils/messaging.py", line 325, in extended_workflow
    found, result = self._call_hook_for(message, "handler", *args, **kwargs)
  File "/var/cache/salt/minion/extmods/utils/messaging.py", line 410, in _call_hook_for
    return True, func(*args, **kwargs)
  File "/var/cache/salt/minion/extmods/utils/messaging.py", line 515, in synchronizer
    return func(*args, **kwargs)
  File "/var/cache/salt/minion/extmods/engines/obd_manager.py", line 131, in query_handler
    res = conn.query(cmd, header=header, formula=formula, force=force)
  File "/var/cache/salt/minion/extmods/utils/obd_conn.py", line 28, in decorator
    return func(self, *args, **kwargs)
  File "/var/cache/salt/minion/extmods/utils/obd_conn.py", line 239, in query
    res = self._obd.query(cmd, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/obd/obd.py", line 276, in query
    messages = self.interface.query(cmd_string, header=header)
  File "/usr/local/lib/python2.7/dist-packages/obd/interfaces/elm327.py", line 563, in query
    lines = self.send(cmd, read_timeout=read_timeout, raw_response=not parse)
  File "/usr/local/lib/python2.7/dist-packages/obd/interfaces/elm327.py", line 610, in send
    raise ELM327Error(self.ERRORS[line], code=line)

Anyways, maybe I just need to wait for the next release :slight_smile:

1 Like

We wait next release also to do a simple guide to use and install … in Italy 10+ people take autopilot on their Kona Evs … you ve a big potential market on Kona EV … go go :smiley:

2 Likes

Sure !!! In France too !! EV car is the futur, and futur is now ! :robot:

1 Like

I noticed that if I rename it to ‘RPMx’ instead of ‘RPM’ then it does record data. So it doesn’t look like we have have a replacement ‘RPM’.

1 Like

This ?
58
I not see option mandatory or similar , therefore how can use to control autopilot cycles ?