It should be possible to choose between Wh/km (mainly Teslas) and kWh/100km (other EVs).
Great, thanks @mutmut, I hadnāt noticed on the APIs that it was in kWh/100km. Iāll add the unit.
Personally I often use km/kWh
For the record, Renault/Dacia API https://airtable.com/appnqv8fdlWYRB0D4/shrvRjmlxxXZwVizK/tblCBBV23F1zBOnhI
@guim31 thatās custom, isnāt it? Are there APIs that use this unit?
so I do that in my head to get an idea but Iād never seen that unit in real life ⦠except on a petrol C4 I had 10 years ago where you could choose km/l for the display, but well it was CitroĆ«n so I figured that was normal (but not for me
).
So if Iām not mistaken, itās the unit often used by the US. I see it very often on Reddit, by the way.
I therefore set that unit in my car, which offers that setting.
Iāve gotten into the habit of using it as a reference because it helps me better picture my home charging: since I use the surplus from my solar panels, it charges slowly, and I appreciate being able to measure that Iāve added, for example: 1kWh to the battery, so I can go 6km further.
Itās not something Iāve seen in APIs because Iāve never dug into those APIs ![]()
Ok @guim31, Iām adding the unit; it will in any case be available on MQTT for connections with Node-RED and weāll see if the APIs expose this value. Otherwise we can propose an automated calculation later!!
Here you go @guim31 :
For anything related to the last charge, couldnāt the attribute be more explicit?
charge-energy-added ā last-charge-energy-added
charge-energy-consumption ā last-charge-energy-consumption
In general we rarely put metadata in the features; why isnāt the vehicle name simply the device name?
We rarely use abbreviations in the features; Iād be in favor of battery-temperature
Same for indoor-temp ā indoor-temperature
@T
Looks great ![]()
I do notice, however, that the vehicleās connection indicator is Open/Closed.
Wouldnāt it be more sensible/visually clear to have Yes/No (possibly with green/red highlighting)?
And for what itās worth, on my vehicle you can also see whether the charging port cover is open or closed.
And I donāt know if this is of any use for this development but hereās something I found regarding Hyundai / Kia: GitHub - Hyundai-Kia-Connect/kia_uvo: A Home Assistant HACS integration that supports Kia Connect(Uvo) and Hyundai Bluelink. The integration supports the EU, Canada and the USA.
[quote="guim31, post
Not easy starting from 0 and Iām short on time at the moment, sorry.
I see 2 important items: information retrieval and action initiation.
I havenāt seen the tires, even if the calculation is done while driving. Sometimes it loses a bit and we could add a Gladys alert. Retrieving the location seems complex on a dashboard. Maybe integrate a check that the front trunk (frunk) is closed (Tesla). Proper connection to the WiāFi network ?
For actions, I like my commands to request a full charge or auto charge depending on available power (solar panels) .. constant charging or not. Maybe a button to force data retrieval. Preconditioning could be interesting when coupled with the calendar.
That could be interesting yes but maybe already tied to the connected charging port?
Iām up for that.
Pr info les commandes possibles sur TeslaFi :
Resume polling
Wake vehicle
Put to sleep
Enable logging
Disable logging
Honk
Flash lights
Start the HVAC
Stop the HVAC
Set HVAC system temperature
Heated seats
Heated steering wheel
Preconditioning presets
Start charging
Stop charging
Set charge limit
Set charge amps
Unlock doors
Lock doors
Sentry Mode
Max defrost (when itās off, the A/C remains on)
Open charge port
Close charge port
-\u003e Thanks for all your work
![]()
Thanks everyone for your feedback, Iām trying some things.
@pierre-gilles quick question, because the category is becoming ⦠unreadable ā¦
Would it be wise to have several categories:
ELECTRICAL_VEHICLE_SOC
ELECTRICAL_VEHICLE_BATTERY
ELECTRICAL_VEHICLE_DRIVE
ELECTRICAL_VEHICLE_CONSUMPTION
ELECTRICAL_VEHICLE_STATE
ELECTRICAL_VEHICLE_CLIMATE
Itās actually separated into several objects/routes in the APIs.
It would look something like this (thanks Cursor for this kind of thing, it takes 15s for the examples ^^):
ELECTRICAL_VEHICLE_BATTERY: {
BATTERY_HEALTH: 'battery-health', // integer - sensor
BATTERY_LEVEL: 'battery-level', // integer - sensor
BATTERY_POWER: 'battery-power', // integer - sensor
BATTERY_RANGE_EST: 'battery-range-est', // integer - sensor
BATTERY_TEMPERATURE: 'battery-temperature', // integer - sensor
BATTERY_VOLTAGE: 'battery-voltage', // integer - sensor
BATTERY_CURRENT: 'battery-current', // integer - sensor
},
ELECTRICAL_VEHICLE_CHARGE: {
CHARGE_CURRENT: 'charge-current', // integer - sensor
CHARGE_ENERGY_ADDED_TOTAL: 'charge-energy-added-total', // integer - sensor
CHARGE_ENERGY_CONSUMPTION_TOTAL: 'charge-energy-consumption-total', // integer - sensor
CHARGE_ON: 'charge-on', // binary - command
CHARGE_PORT_DOOR_OPEN: 'charge-port-door-open', // binary - command
CHARGE_PORT_LOCKED: 'charge-port-locked', // binary - sensor
CHARGE_POWER: 'charge-power', // integer - sensor
CHARGE_SCHEDULE: 'charge-schedule', // binary - sensor
CHARGE_VOLTAGE: 'charge-voltage', // integer - sensor
CHARGING_TIME_REMAINING: 'charging-time-remaining', // integer - sensor
LAST_CHARGE_ENERGY_ADDED: 'last-charge-energy-added', // integer - sensor
LAST_CHARGE_ENERGY_CONSUMPTION: 'last-charge-energy-consumption', // integer - sensor
PLUGGED: 'plugged', // binary - sensor
TARGET_CHARGE_LIMIT_SOC: 'target-charge-limit-soc', // integer - command (SOC charge limit)
},
ELECTRICAL_VEHICLE_DRIVE: {
DRIVING: 'driving', // binary - sensor
LOCATION: 'location', // text - sensor (optional/sensitive)
ODOMETER: 'odometer', // integer - sensor
},
ELECTRICAL_VEHICLE_CONSUMPTION: {
ENERGY_CONSUMPTION: 'energy-consumption', // integer - sensor
ENERGY_CONSUMPTION_TOTAL: 'energy-consumption-total', // integer - sensor
ENERGY_EFFICIENCY: 'energy-efficiency', // integer - sensor
ENERGY_REMAINING: 'energy-remaining', // integer - sensor
},
ELECTRICAL_VEHICLE_STATE: {
CELLULAR_CONNECTED: 'cellular-connected', // binary - sensor
DOOR_OPEN: 'door-open', // binary - sensor
FIRMWARE_VERSION: 'firmware-version', // text - sensor
MAINTENANCE_ALERT: 'maintenance-alert', // binary - sensor
TIRE_PRESSURE: 'tire-pressure', // integer - sensor
VIN: 'vin', // text - fixed
WIFI_CONNECTED: 'wifi-connected', // binary - sensor
WINDOW_OPEN: 'window-open', // binary - sensor
},
ELECTRICAL_VEHICLE_CLIMATE: {
CLIMATE_ON: 'climate-on', // binary - command
INDOOR_TEMPERATURE: 'indoor-temperature', // integer - sensor
OUTSIDE_TEMPERATURE: 'outside-temperature', // integer - sensor
PRECONDITIONING_ON: 'preconditioning-on', // binary - sensor
SEAT_COOLING: 'seat-cooling', // binary - command
SEAT_HEATING: 'seat-heating', // binary - command
STEERING_WHEEL_HEATING: 'steering-wheel-heating', // binary - command
TARGET_TEMPERATURE: 'target-temperature', // integer - command
},
ELECTRICAL_VEHICLE_COMMANDS: {
ALARM: 'alarm', // binary - command
FLASH_LIGHTS: 'flash-lights', // binary - command
FRUNK_OPEN_CLOSE: 'frunk-open-close', // binary - command
HONK: 'honk', // binary - command
LOCK: 'lock', // binary - command
TRUNK_OPEN_CLOSE: 'trunk-open-close', // binary - command
VALET_MODE: 'valet-mode', // binary - command
WINDOW_VENT: 'window-vent', // binary - command
},
Well, aside from it adding French comments to itself ^^
Looks better, doesnāt it?
Yes, I donāt mind having several categories, I was actually going to suggest that to you ![]()
By the way ELECTRICAL_VEHICLE_SOC I donāt understand what that is, thereās no abbreviation in Gladys ![]()
Wait, but youāve added a thousand things there ![]()
We said weād start small!
Great
I modified it afterwards ![]()
But regarding the type Ā« TARGET_CHARGE_LIMIT_SOC Ā», do you want me to remove it then? Letās say itās used by all the APIs (StateOfCharge), thatās why I kept it ^^ But itās fine with me
I think I misunderstood you ^^ itās following the posts below, I did agree that there were more useful basic things since according to other manufacturersā APIs, they pretty much offer all these elements.
But I can
I just wanted to get the list you proposed validated, to make sure we donāt lock ourselves into Tesla-only behaviors.
Iām still in favor of sticking to the base list if itās validated by everyone
(List that you published here: https://community.g
Phew! Thanks ^^ Iām just adding the speed I had omitted
On the other hand, the idea of separate categories is good, so Iām totally in favor of separating them right now (it wonāt be possible later)











