Jump to content

Jason (ABRP)

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jason (ABRP)

  1. 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.
  2. 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.
  3. I'll let you know when it's just about ready to test!
  4. I just got that version yesterday evening, haven't driven my car in a while so had to actually turn it on for a bit to get the AutoPi to take the update. Annoying that jobs seem to be prevented from running while it's staging the update. I'll be taking it for a drive today, have to get groceries, so will see how everything performs now on the new update.
  5. I have an idea on this, when I thought it was possibly a "zombie" copy of the script running I introduced an auto-quit call in the manage_sleep function. This would cause the ABRP script to potentially miss a lot of data in the period where the charge is ending, as it's dying and restarting multiple times (intentionally). I've since reverted that change since it didn't do anything useful. Does your current version of the script have: else: # Kill script, gives us 60 seconds to wait and check again. safelog("Car not active, retrying in 60 seconds", always=True) os._exit(1) At line 206-209? If so, update to the most recent version from the GitHub. I really need AutoPi to come up with a better way to share user scripts so you get notified when I update. If we have to we'll build something into the ABRP app. If not I'll need to think on it more.
  6. You read our minds! This is coming soon.
  7. We really like this idea too, it's on our to-do list! Really helpful for caravanning road trips with friends.
  8. When you say you saw the power go from 2.2kW to 0kW, where did you see that? In ABRP or in AutoPi's interface, or somewhere else?
  9. Huh, interesting, if the last charge rate was 2.2kW, it should have stayed awake. What did the log on the AutoPi say about why it went to sleep? Perhaps a critical power event, 12V battery voltage got too low? My Autopi > Advanced > Events
  10. Ah, is this with the most recent version of the script where I cut off the is_charging marker at 0.5kW to avoid phantom charge events? Bet there's some very low power battery conditioning still going on, so it should probably stay awake for a little longer to catch the tail end of that. I've pushed a new version of the script which lowers the sleep tolerance to 0.01kW, or you can just change line 202 from: if 'power' in data and round(data['power']) != 0: To: if 'power' in data and abs(data['power']) > 0.01: Which will have the same effect.
  11. Sounds great! I think the first order of business is for us to expand our poller so we can easily incorporate additional manufacturer methods like BlueLinky. As far as parameters which can be retrieved - if we have SoC only that's workable. It'll take a long time to calibrate correctly though. Calibration is much faster if we can get Power data from the battery pack (input/output) and much more accurate we've found. Of course, if it's not possible, that's a limitation we'll have to deal with.
  12. Yes, we've been talking about how to best link, once we get through that I'll post an update.
  13. We don't have an easy way to delete them outright, but if you're concerned about having them stored you could set them to an arbitrary other location.
  14. Interesting that it offers that as an option. As far as we know, the Tesla app can't open ABRP links. To forward a destination to your Tesla you'll need to connect MyTesla and then use the "Send to MyTesla" button in Driving Mode (so we can figure out what the next destination is).
  15. That'd be great! We actually have a system set up to poll APIs, as you mentioned for the Tesla logins. It was designed to be easily expandable once we gain enough knowledge about another API. The main things we'd need from the API to make it useful to you (in order of importance): SoC Speed Lat/Lon Power Any other data about the car's status (health, temperature, voltage, current, etc) If we can get those things relatively frequently, we can make a really good tool! Of course, once we find enough about the API to start building, we'd need someone with an actual Hyundai to help us out so we can test the telemetry calls out.
  16. Thanks, all! It really helps to raise awareness that it's not just me and Bo who want the data if the community lets them know they'd like the live data too.
  17. Great! Although nothing I changed should really change that... I checked with the AutoPi devs and I think it just takes a while to start Cron Jobs sometimes. I'm working with them to find a way to ensure we get started faster most of the time, and then eventually I want to add the capability to support Plugins, since each __salt__ call seems to take quite a while, and having lots of scripts running simultaneously really bogs you down. Yes, this is intended, it should go once every 100 seconds (give or take, due to the length of the __salt__ calls) while charging unless the data is meaningfully different (IE, if soc/power/is_charging have changed): min_changed = ["soc","power","is_charging"] should_send = False for param in min_changed: if param in data and param in last_data and data[param] != last_data[param]: should_send = True break if "is_charging" in data and data["is_charging"] and time.time() - last_data_time > 100: should_send = True elif "is_charging" in data and not data["is_charging"] and time.time() - last_data_time > 30: should_send = True elif last_data == {}: should_send = True Every minute it re-checks status, and if it thinks it should be awake it resets a 10 minute sleep timer. So from the last time you have a non-zero power, speed, or is_charging reading, it should stay awake for 10 minutes. If you'd like to investigate more, and see exactly why you could set debug=True on the kwargs, and tail the minion log while SSH'd into the AutoPi: sudo tail -f /var/log/salt/minion | grep ABRP You might have to reboot the Pi or touch the ABRP script to force it to reload: touch /opt/autopi/salt/modules/my_abrp.py
  18. One option would be for me to set a certain power threshold for "is_charging" to take effect. Would <1kW be sufficient to discard false charges? Also, I did some experimenting with my AutoPi in my car, timing boot-ups, and I don't think there's really anything I can do. The first time the Cron Job is called is about 2:30 after I saw the hotspot appear. I guess I never really noticed because I always get my AC on remotely before I load up my family into the car and drive, so the AutoPi always seems to be booted up by the time I start actually driving.
  19. You can thank @Bo (ABRP) for fixing it! On the new bug, I'm not sure I understand. The avoid settings can be a little confusing since you can store them per-plan, so if you make a plan with an "avoid this charger", then enable it for a new plan, then reload an old saved plan it'll re-apply the "avoid this charger" setting.
  20. The fact that it only did the weird routing when it was from one charger to another clued us in, and found a fix! It should be a lot better now, give it a try.
  21. That is extremely weird, can't say I've seen the planner do something like that. The weird part is that selecting waypoints right on the superchargers doesn't exhibit the same behavior. Will definitely spend some time on this little bug.
  22. Meaning you see a charging status in the ABRP app when you plug the car in and it shows charging? Are there any other scenarios where the app shows a charge session active, but your car is not actually charging? @Joaquim Lopes was noting that PID went active when it would turn the car on to charge the 12V battery.
  23. It's not that surprising, actually, I don't have the ABRP script report in unless it has a minimum amount of data (Need SoC and Power, if memory serves) So if the car is off it won't receive that data, and it won't report in. I checked with AutoPi, and when they say "sleep" they actually turn the Pi all the way off. So my zombie process hypothesis doesn't really hold water.
  24. I've updated the script in a way which should help startup times (assuming it's a still-running, sleeping, copy of the script from the last wake/sleep cycle). Assuming the ABRP script is the one which put the device to sleep due to inactivity from the car, it will self-quit in the 10 minute go-to-sleep window. Would appreciate if someone who was experiencing slow wakeups could check the behavior and see if it's still happening with this version: https://github.com/iternio/autopi-link/blob/master/my_abrp.py
  25. Jason (ABRP)

    $50 Wasted

    Thanks for reporting the error, that'll help us find and fix the bug. Loading up your plan this is what I see: Which makes sense to me, the proposed alternate route goes through Joshua Tree, but since park speed limits are lower it'll take a lot longer to drive that route. A Better Routeplanner is time-optimized, so we always try to return the fastest plan with a few alternatives. If you'd like to drive through Joshua tree, I recommend adding a waypoint somewhere in Joshua tree directly, either by searching for something like a Visitor center, or right clicking on the map and selecting "Add Waypoint" where you'd like to go. Let me know if I misunderstood the issue and I'll definitely take another look!

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...