I extracted the images and plan to add them to VisibleTesla. Can you tell us what the API is returning as a wheel type for Aero? Thanks.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Model S REST API
- Thread starter timdorr
- Start date
-
- Tags
- Model S User Interface
I extracted the images and plan to add them to VisibleTesla. Can you tell us what the API is returning as a wheel type for Aero? Thanks.
araxara
X-LR M3AWD, MYLR
Sorry but my wheels were "upgraded" from 21" Silver Turbines to Aero at the service center and they didn't update the setting in the car. The API still returns the silver wheels (at least that's what VisibleTesla says and what is displayed in the car).
negative elevations ??
I noticed yesterday that the streaming API returns negative elevation values ?
I'm quite sure the car is at 85m ABOVE sea level, so did anybody also observed this ?
To be complete: I'm monitoring 2 cars and only have this curious behaviour with 1 car.
I noticed yesterday that the streaming API returns negative elevation values ?
I'm quite sure the car is at 85m ABOVE sea level, so did anybody also observed this ?
To be complete: I'm monitoring 2 cars and only have this curious behaviour with 1 car.
hans
P631
Car thinks it's in the Netherlands ;-)
GPS elevation is the altitude above the WGS84 reference ellipsoid. It is not the altitude above ground level or sea level. See for more details http://www.unavco.org/edu_outreach/tutorial/geoidcorr.html
What I have noticed is that elevation changes while the car is parked. The streaming API often sends updates because the only field that has changed is elevation. I think this is because the GPS elevation inaccuracy is more than it's lat/long inaccuracy.
yes, I mailed the owner to check his car was not sinking into the ground :biggrin:
Notice the car is parked and this happens within the same minute.
If elevation measurement is based on air pressure measurement, this pressure was/is dropping 'fast' for some reason.
well, his car was still above ground level, so must be GPS inaccuracy.
The owner told me navigation was off by 100m when starting car (even after firmware update), but after a 'while' it regained 'correct' coordinates.
I know this has been covered, but I can't seem to find the answer searching the forum. I want to monitor my range loss on 5.8, but I don't want to interrupt sleep mode.
I know that simply calling /vehicles will tell me whether it's asleep or awake and will not interfere with sleep mode. What I want to know is if I call /vehicles while the car is awake, will this prevent it from entering sleep mode? In other words, is there any harm in polling /vehicles, say every 5 minutes or will the car reset its "sleep timer"? If so, how am I supposed to navigate around that?
To further clarify, my concern stems from this statement from the VisibleTesla docs:
So how do you guys record any data without giving the car insomnia?
I know that simply calling /vehicles will tell me whether it's asleep or awake and will not interfere with sleep mode. What I want to know is if I call /vehicles while the car is awake, will this prevent it from entering sleep mode? In other words, is there any harm in polling /vehicles, say every 5 minutes or will the car reset its "sleep timer"? If so, how am I supposed to navigate around that?
To further clarify, my concern stems from this statement from the VisibleTesla docs:
So how do you guys record any data without giving the car insomnia?
Last edited:
dirkhh
Middle-aged Member
Just calling /vehicles won't keep the car awake. Apparently any other api call does.
hans
P631
The reason this makes sense is that /vehicles lists ALL your cars. I know most people only have one but if you did have two or more, it would make no sense to wake them all up. Every other REST call is specific to a particular car so the car must be woken up so the request can get data directly from the car.
So how do we collect data without keeping the car awake?
The trick is to detect when the car is parked and to stop collecting data for a long enough "nap" period that allows it to fall asleep naturally. Once asleep the program can monitor /vehicles until it sees the car wake up, and then it starts collecting data again (until the next time the car is parked).
Last edited:
Eggplant
Member
I hoping someone can clear up my confusion over charger_actual_current vs battery_current.
It appears that the app and car report kW = charger_actual_current * charger_voltage when charging AC, and kW = battery_current * charger_voltage when charging DC (Supercharger).
Thing is, when charging AC I see that battery_current is about 60% charger_actual_current.
Does charger_actual_current measure current at the outside of the AC charger? (seems to) I assume battery_current is measured current entering/leaving the battery.
What accounts for this difference? Just loss in the AC/DC conversion in the charger?
Does this mean that comparing kW charging AC vs DC is skewed? Would it be more accurate to always use kW = battery_current * charger_voltage? If so, it means I'm getting about 5.8 kW charging @ 240/40A and not 10 kW reported by the car/app, correct?
It appears that the app and car report kW = charger_actual_current * charger_voltage when charging AC, and kW = battery_current * charger_voltage when charging DC (Supercharger).
Thing is, when charging AC I see that battery_current is about 60% charger_actual_current.
Does charger_actual_current measure current at the outside of the AC charger? (seems to) I assume battery_current is measured current entering/leaving the battery.
What accounts for this difference? Just loss in the AC/DC conversion in the charger?
Does this mean that comparing kW charging AC vs DC is skewed? Would it be more accurate to always use kW = battery_current * charger_voltage? If so, it means I'm getting about 5.8 kW charging @ 240/40A and not 10 kW reported by the car/app, correct?
Eggplant
Member
Also-- (sorry if this was covered before)
charger_power seems to return the kW number for both AC and DC charging, but it's negative when DC charging. Perhaps I should stop worrying and learn to trust that number?
charger_power seems to return the kW number for both AC and DC charging, but it's negative when DC charging. Perhaps I should stop worrying and learn to trust that number?
LJordan
Member
Assuming the car is "off", how long do you have to block API calls (other than vehicles) for the car to go enter "sleep" mode?
Eggplant
Member
hans
P631
Thats what I use. Experimented with 20 minute naps but it didn't work often enough to be my default time.
I have seen the car fall asleep in 8-10 minutes on occasion but I could not determine why it was so fast to sleep versus all the other times.
Somewhere along the line I got confused about the whole sleep/awake thing. I'm running 5.8. If I use the -z flag with streaming.js will it wake a sleeping car or prevent it from sleeping? I have streaming running all the time.
hans
P631
Yes, run it with "-z" (or "--zzz") and it will not wake a sleeping car, as well as it will allow a parked (non-charging) car to fall asleep. Make sure to get the latest release too because there were a few nasty bugs in some past versions that got my IP blocked.
Last edited:
jackie
Member
Just wanted to update status on defrosters - they came on automatically when I started the airconditioning and it was -1C outside. The car decided to turn on the front defroster and warm everything up for me. Ooh I love this car :love:
Eggplant
Member
So, I've been playing around with scheduled charging by issuing set_charge_limit and charge_start commands.
One thing I've seen is that if a charge completes, the car shows charging_state = "Complete" and if I then try to change the charge_limit and issue a charge_start it will return an error with the message "complete." But charging will start anyway. However, if I don't change the limit and try issuing a start it will return that error and not start, even if the SOC is lower than the limit.
Anyone else seen this?
I guess I'll try changing the limit, even if I end up changing it back, and waiting a second or two before issuing the charge_start to see if I can work around the error.
One thing I've seen is that if a charge completes, the car shows charging_state = "Complete" and if I then try to change the charge_limit and issue a charge_start it will return an error with the message "complete." But charging will start anyway. However, if I don't change the limit and try issuing a start it will return that error and not start, even if the SOC is lower than the limit.
Anyone else seen this?
I guess I'll try changing the limit, even if I end up changing it back, and waiting a second or two before issuing the charge_start to see if I can work around the error.
Hi Eggplant,
I think if you replace your Supercharger with kW= battery_current * pack_voltage (because this is direct pack charging), then know that you don't exactly know the pack voltage during normal charging, it will make a bit more sense. Then when normally charging, your kW = charger_actual_current * charger_voltage should ~= battery_current * pack_voltage. Note there is some error there due to charger conversion efficiencies.
Since the pack voltage runs ~320-398V empty to full, and your home charger will be about 240V, you would see the current drop by about 25-40% plus some loss due to inefficiencies.
Peter
I think if you replace your Supercharger with kW= battery_current * pack_voltage (because this is direct pack charging), then know that you don't exactly know the pack voltage during normal charging, it will make a bit more sense. Then when normally charging, your kW = charger_actual_current * charger_voltage should ~= battery_current * pack_voltage. Note there is some error there due to charger conversion efficiencies.
Since the pack voltage runs ~320-398V empty to full, and your home charger will be about 240V, you would see the current drop by about 25-40% plus some loss due to inefficiencies.
Peter
Eggplant
Member
Similar threads
