New categories / new types dedicated to EVs

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.

1 Like

Current result:

Associated units:

Dashboard:

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 :wink: ).

1 Like

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 :wink:

1 Like

The PR : PR2 - Add Categorie VE - Electrical Vehicle by Terdious Ā· Pull Request #2318 Ā· GladysAssistant/Gladys Ā· GitHub

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

1 Like

Here you go @guim31 :

1 Like

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

1 Like

Looks great :wink:

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.

1 Like

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

2 Likes

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 :+1: :clap:

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?

1 Like

Yes, I don’t mind having several categories, I was actually going to suggest that to you :slight_smile:

By the way ELECTRICAL_VEHICLE_SOC I don’t understand what that is, there’s no abbreviation in Gladys :slight_smile:

Wait, but you’ve added a thousand things there :sweat_smile:

We said we’d start small!

1 Like

Great

I modified it afterwards :sweat_smile:
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 :slight_smile: (List that you published here: https://community.g

2 Likes

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)

1 Like