@DeLorean , Are you saying you have the developer access and the integration is now working?
Sorry, I meant that I’ve got the evlinkha.se setup going. I was replying from my phone so didn’t clearly see that you had already gotten this going as well.
Altho, I’m guessing there’s performance issues as I’m having challenges just logging in to set up the HA integration itself.
I did send an enquiry to enode.io but haven’t heard back yet. I’m guessing they must support AU given that evlinkha.se is using that service.
Yeah I have, I’ve also reminded them a couple of times.
I hooked evlinkha to my BYD, it works - but best to use a different account for the link to the BYD account otherwise it will log you out of the BYD app. You can use the authorisation function in the app to add a different email address.
Not sure I’ll continue using it after the paid period though. The pricing when you look to upgrade doesn’t match the advertised price
Advertised
Reality - the $1.99 plan is limited to 10 api calls a day and requires you also purchase token packs
You will find that overall only one account can be logged in at once, even if it’s a separate authorized account. Quite annoying when you have multiple drivers.
Thanks
I have already implemented logic in HA to estimate current SOC based on the last known SOC and the KWh fed from the EVSE, so sticking to the free plan 2 API callls per day is probably adequate for me at least until I get a bi-directional charger (that may actually publish car SOC) where finer control may be required.
Does your code also work with other ODB2 dongles? If so, how would they need to be adapted? I have an iCar Pro 2S.
I suspect not as that device looks to be standard Bluetooth and not BLE. You would need to adapt the code to use the standard elm327 library.
But if it is BLE, you can change the variable DEVICE_NAME name in config.h to match the name of your device.
It must be BLE because I can connect it to A Better Route Planner. The Bluetooth name is “IOS-Vlink” for BLE and the pairing code is “1234”. Is the Bluetooth name the same as DEVICE_NAME? And do I also have to enter the pairing code?
I also have an iCar Pro BLE4.0 DUAL at hand.
Yes use the Bluetooth name, you shouldn’t need to add the pairing code, but make sure the dongle is ready to accept a new device.
For the OBDLink CX, it’s only able to pair with new devices in a 10 minute window after being plugged in. Not sure the security on your device though.
You can only try, see if it works. The current version is explicitly designed to run on an M5stack AtomS3 Lite though since I added functionality for RGB status lighting. I still need to pare it back so there’s a generic ESP32 option.
Unfortunately, I haven’t had any success so far. Compiling and uploading works, but the AtomS3 doesn’t respond. Not even the LEDs light up. However, it’s not because of your code, but because of my inexperience with Arduino. Is there a beginner’s guide you can recommend? I just want to get your project up and running. I don’t want to do anything else with it.
Now it works. How can I change the Time zone from AEST to CEST?
I did it. Now it works with my BYD Atto 3 and iCar Pro 2S. And that’s with the CEST time zone.
Thanks for your work and effort!
Regarding the API, unfortunately, I haven’t found a solution, but there is a workaround.
For this, you need a Raspberry Pi with PiOS and an old smartphone running the BYD app.
On the Raspberry Pi, install the following:
sudo apt install adb tesseract-ocr imagemagick
Then connect the smartphone via USB and enable ADB in the developer options (confirm the connection permanently the first time).
Run the following commands in a script (the coordinates in input tap and crop need to be measured from a screenshot and adjusted depending on the device used):
adb shell input keyevent KEYCODE_HOME # Show home screen
sleep 5
adb shell input tap 540 1700 # Reopen the app (if BYD app link is at these coordinates)
sleep 5
adb shell input tap 500 330 # Refresh data
sleep 1
adb shell input tap 500 270 # Refresh data (if SOC is not displayed)
sleep 30
adb exec-out screencap -p > screenshot.png # Take a screenshot
convert screenshot.png -crop 200x100+220+200 cropped.png # Crop the screenshot
tesseract cropped.png stdout -c tessedit_char_whitelist=0123456789 --psm 6
This should output the SOC value. You can then process this value in various ways—for example, I send it to my Loxone Miniserver for intelligent charging control.
I set the screen timeout to 30 minutes, brightness to minimum, and query every minute to keep the ADB connection alive. It has been running stably for a few days.
This is a very interesting workaround. I will test ist.
Found a little more stable version:
adb shell am force-stop com.byd.bydautolink
adb shell monkey -p com.byd.bydautolink -c android.intent.category.LAUNCHER 1
and then screenshot etc…
and sometimes it reads the Flash-Sign as 400, so you should check if the Value is >400 and then subtract 400 from the value.
This method only reads the SoC, correct? Can it also be extended to range, remaining charging time and charging power?
you can read everything that’s displayed in the App, even on other pages, but navigating to them with adb taps is tricky and maybe unreliable and has do be adapted on App redesigns.
you just need to crop the region of interest in other files and ocr them to values