Jump to content

Jason (ABRP)

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jason (ABRP)

  1. Thanks for being so willing to help out @Radek Wroński! We'd love to connect directly with Greenway, if you'd like to send them our contact info (bo@abetterrouteplanner.com, jason@abetterrouteplanner.com). Like you say, we're getting the charger data from Plugsurfing, who it seems have generally good live station status, but poor power data for each stall. We've submitted quite a few issues with their data to them, but it wouldn't hurt to hear it from extra mouths. If you submitted it to OpenChargeMap, it'd be the same as GoingElectric, our priority when trying to determine what the mos
  2. @vag - huh, do you have the ability to SSH into the AutoPi and check the logs? https://community.autopi.io/t/guide-how-to-ssh-to-your-dongle/386 If so, try adding: debug=True To the Job's Kwargs, then restart the AutoPi (to restart the job), SSH in, and run: sudo tail -f /var/log/salt/minion | grep ABRP Which will isolate just the logs associated with the ABRP script. See if there's anything useful that would tell us what's going on causing the issue?
  3. @muhmann I bet the Ioniq 38 uses the same PIDs as the Kona/Niro since it's on their newer battery platform, so we added that to the support list, can you try it out and report back?
  4. That's very strange, and you're certain you have the most recent version of the script? I haven't changed it in the last month or so, and it's been working pretty much constantly for me.
  5. Was that on a route with very little elevation change? We've found that weight has very little effect on range when on flat ground, and so we neglect its effect there to improve the computation speed. We may add it back in later. If you're using a live data source which provides all the data needed to calibrate we'll calibrate your consumption curve to include this effect, though, so it'll be very accurate.
  6. For Tesla we don't have a way to directly retrieve the degradation or capacity so we calibrate while charging. The Tesla API reports how much energy is fed to you by the charger, so we track that against your battery percentage to determine the degradation. That said, the process could probably do with some refinement, as with only a few measurements it's prone to the behavior you describe.
  7. @conny - this is already done on the web version of the app. Our intention is that if you're in the car following a plan on your phone, it's really only useful to navigate to the next waypoint on the list, as the waypoint following that might change depending on how much you charge, or how the weather or traffic changes in the interim.
  8. @Phil Hays - It actually does do this right now, but it looks like we've got a little display bug. If you load up your configuration and exit and re-enter the settings it'll update the displayed value. We'll get that fixed so it updates the displayed value immediately on switching configurations. But it does seem to be working as expected otherwise.
  9. As I suspect @lfornaciari has done, the best thing here is to send an email to our support address and we'll take a look at the account. Easy way to do this is just press the "Tell us what you think" button in the app, or email directly at premium@iternio.com (for questions specifically about premium subscriptions) or support@iternio.com for general support stuff.
  10. @moritzoes Ah, yeah, we have a known issue with Plugsurfing, a lot of their EMSP data from many providers is incorrect, and we're pressing on them to fix it. If they don't fix it, we'll look into corrections we can apply on our side, but we'd rather correct the source information. While we work on it, you can submit issues to Plugsurfing for ENBW to point them to the problem areas, perhaps that would help?
  11. Great to hear! Feel free to PM me or email me if you've got questions on how to make it work. Awesome! Glad to hear it.
  12. Hmm, strange, we rely on power data from LeafSpy for the calibration, but I thought that was added quite a few versions ago. Did LeafSpy have an update recently?
  13. Glad to hear it's working as intended now! And to avoid sleep management, don't even need to remove the manage_sleep function itself, just where it's called on the second line you quoted. I also just pushed a version that adds a 0.1kW power tolerance on the sleep function, only keeps you awake if you have >= 0.1kW power.
  14. Jason (ABRP)

    Trip chart

    This is a little complicated to do, but we're working on it!
  15. Nice! Saw this and got all ready to fix the LeafSpy API, glad it was an easy fix on his side. We used to return status:0, not sure when we changed that.
  16. This bug is now on our priority backlog, so expect it fixed soon!
  17. This is probably a problem with the Open Street Map there, if you click on the route you should see an "edit in Open Street Map" button: Where you can make sure it's showing it properly as a split-lane highway, and submit edits to have it done properly.
  18. Wellp, I made a dumb error. Generic is_driving() always returned false for you, so yeah, it'd basically go to sleep and never report in. I upgraded the generic 'is_driving' function so it's a little smarter than that, so hopefully it works as expected now. I also merged it into the service branch, so feel free to grab either version and give it a try.
  19. I'll take it! Or if easier, just pick out the commit on Github with the most recent working version: https://github.com/iternio/autopi-link/commits/master And I'll work it out from there.
  20. The Bolt's MyChevy App can display all the kinds of information we want to for ABRP, so it's not impossible. They do have some more leverage, as they're also the ones installing AA in their cars.
  21. I think we also need to have that toggle on the map like in other mapping applications, instead of hidden on a difficult-to-parse 'Modes' button. I've added both to our to-do list.
  22. That's really weird, I just took my Bolt for a camping trip with the AutoPi and it worked really well. That would imply that the problem is somewhere in the HKMC-specific code. Wish I had one on-hand to test with. Don't suppose anyone is in Houston with one so I can test directly? Either way I'll take some time and see if I can figure out what's going on. Great! Will probably need to tinker with the CAN recording mode to figure out the PIDs. I've also heard that the E-Tron has a system which sets the alarm something tries to access the OBD while it's locked and off, might have
  23. 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/ite
  24. 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.
  • Create New...