Description
The goal is to create a new dashboard dedicated to Electric Vehicles and the associated features.
We want to add a ‹ type › field when creating the dashboard:
This field allows you to create a dashboard specific to electric vehicles:
You can see a repetition of the new type field allowing modification of the current dashboard, followed by a list of new fields specific to EVs.
Depending on the data entered here, widgets
Here is an example of a dashboard :
Whimsical link : Gladys VE
List of features :
| Name | New Category | New Type | Type | New unit | Unit | Sensor | Comment |
|---|---|---|---|---|---|---|---|
| Alarm activation | Electric vehicle (ELECTRICAL_VEHICLE) | alarm | binary - command (Modification Terdious) | ||||
| Battery instantaneous power | Electric vehicle (ELECTRICAL_VEHICLE) | battery-power | kW | Yes | integer - sensor (Modification Terdious) | ||
| Estimated range in km | Electric vehicle (ELECTRICAL_VEHICLE) | battery-range-est | km | Yes | integer - sensor (Modification Terdious) | ||
| Battery temperature | Electric vehicle (ELECTRICAL_VEHICLE) | battery-temp | °C | Yes | integer - sensor (Modification Terdious) | ||
| Battery voltage | Electric vehicle (ELECTRICAL_VEHICLE) | battery-voltage | V | Yes | integer - sensor (Modification Terdious) | ||
| Charge current | Electric vehicle (ELECTRICAL_VEHICLE) | charge-current | A | Yes | integer - sensor (Modification Terdious) | ||
| Energy added last charge | Electric vehicle (ELECTRICAL_VEHICLE) | charge-energy-added | kWh | Yes | integer - sensor (Modification Terdious) | ||
| Energy consumed last charge | Electric vehicle (ELECTRICAL_VEHICLE) | charge-energy-consumption | kWh | Yes | integer - sensor (Modification Terdious) | ||
| Charge power | Electric vehicle (ELECTRICAL_VEHICLE) | charge-power | kW | Yes | integer - sensor (Modification Terdious) | ||
| Charge voltage | Electric vehicle (ELECTRICAL_VEHICLE) | charge-voltage | V | Yes | integer - sensor (Modification Terdious) | ||
| Charging activation | Electric vehicle (ELECTRICAL_VEHICLE) | charging-on | binary - command (Modification Terdious) | ||||
| Preconditioning activation | Electric vehicle (ELECTRICAL_VEHICLE) | climate-on | binary - command (Modification Terdious) | ||||
| Doors open | Electric vehicle (ELECTRICAL_VEHICLE) | door-open | Yes | binary - sensor (Modification Terdious) | |||
| Instantaneous consumption | Electric vehicle (ELECTRICAL_VEHICLE) | energy-consumption | Yes | Wh / km | Yes | integer - sensor (Modification Terdious) | |
| Total energy charged | Electric vehicle (ELECTRICAL_VEHICLE) | energy-consumption-total | kWh | Yes | integer - sensor (Modification Terdious) | ||
| Range in kwh | Electric vehicle (ELECTRICAL_VEHICLE) | energy-remaining | kWh | Yes | integer - sensor (Modification Terdious) | ||
| Interior temperature | Electric vehicle (ELECTRICAL_VEHICLE) | indoor-temp | °C | Yes | integer - sensor (Modification Terdious) | ||
| Lock / Unlock | Electric vehicle (ELECTRICAL_VEHICLE) | lock | binary - command (Modification Terdious) | ||||
| Vehicle name | Electric vehicle (ELECTRICAL_VEHICLE) | name | Yes | text - fixed (Modification Terdious) | |||
| Odometer | Electric vehicle (ELECTRICAL_VEHICLE) | odometer | km | Yes | integer - sensor (Modification Terdious) | ||
| Plugged in | Electric vehicle (ELECTRICAL_VEHICLE) | plugged | Yes | binary - sensor (Modification Terdious) | |||
| Charge current setpoint | Electric vehicle (ELECTRICAL_VEHICLE) | target-current | A | integer - command (Modification Terdious) | |||
| Windows open | Electric vehicle (ELECTRICAL_VEHICLE) | window-open | Yes | binary - sensor (Modification Terdious) | |||
| Range | Electric vehicle (ELECTRICAL_VEHICLE) | battery | % | Yes | integer - sensor (Modification Terdious) | ||
| Climate temperature setpoint | Electric vehicle (ELECTRICAL_VEHICLE) | target-temperature | °C | integer - command (Modification Terdious) | |||
Google Sheets link : Specs VE - Google Sheets
That could be interesting yes !! 
1 Like
Welcome to this community, @S-Axel.
I read your feature request, and I’m wondering if your need concerns :
- the dashboard layout in two parts, one above the other, the first being in 4 columns ?
- having a preconfigured dashboard ?
- creating
Hi @StephaneB,
The purpose of this request is to have a Dashboard dedicated to EVs (véhicules électriques) fully managed by Gladys, somewhat in the vein of the Home Assistant (HA) Energy Dashboard.
This therefore requires adding/modifying categories and maybe one widget (not mandatory).
So this is indeed a request.
We want here to have a working base that won’t go too far so that later:
- Add manufacturer APIs or manufacturer « bridges » (like Tessie, Tesla Fleet, Renault, Dacia, others…)
- Enhance this type of « Electric vehicle » Dashboard with automations or calculations.
Hi @tiboys,
Feel free to tell us more precisely what you think and what your current basic visual need/desire would be (for the moment we are focusing on the base.
Indeed we also own 2 Teslas (Model 3 for @S-Axel and Model Y @Terdious) as well as a Dacia Spring (@Zeldious) and Tesla offers a wide range, but the goal here is already to offer something useful to all manufacturers.
I saw that you posted on Gérer les véhicules électriques Renault et Dacia via l'API - #10 par tiboys in reply to @gaetanb76 with his Zoé. That’s great. Feel free to give us a sample visual you would consider that isn’t limited to 3 columns.
The goal of this dashboard is to provide a basic end-to-end visual that can then be augmented below (or optionally above if needed) by the usual three columns.
So far we have implemented:
-
Modification of the type « Temperature » (which was actually a setpoint) in the « Air conditioning » category to « Temperature setpoint » as for the thermostat + addition of the type « Temperature » as a sensor:
-
Modification of the type « Battery » in the « Battery » category to « Range ». We therefore added the dedicated units « km » and « kWh » to this category
-
Addition of the « Charging » category with dedicated types and notably the « Current setpoint » type identical to the « Temperature setpoint » type.
-
Dashboard type when creating:
-
Dashboard type when editing as well as the titles that separate the section dedicated to the standard configuration. By changing the type to standard here, we return to the usual view.
The Widget part remains to be implemented.
Hi @S-Axel, @Terdious and @Zeldious 
Thanks to you for looking into this topic, that’s really great! I’m convinced there will be demand for integrating electric vehicles into Gladys.
As always, I encourage you to proceed gradually, because this project touches many parts of Gladys.
-
I think the first step is defining the data model of an electric vehicle, meaning defining all the necessary features. That’s already quite an undertaking in itself and, for me, the necessary first step before even talking about other things
-
Regarding the dashboard, I’m not sure it’s necessary to create a specific type. We can perfectly design widgets dedicated to electric vehicles that could be used in any dashboard. Why did you consider a dedicated type?
@Terdious, I feel like you’re falling back into your old habits a bit too quickly 
I think there’s still real upfront design work to do, even before writing a line of code.
Would you like to set up a call to discuss it?
I’ll be working on Gladys today and Friday this week 
Hi @pierre-gilles,
As for me, I’m available whenever you want!
No, one doesn’t prevent the other; as always there’s nothing stopping us from starting to code while waiting for feedback (which this post kicks off). The code I’m writing here is a draft made from the basic specs we put together by combing through the various APIs of all the manufacturers. So that work has already been done for us.
As you pointed out, the first dev should be simple; maybe the direction isn’t right, but precisely that’s why we’re starting the debate. As users of VE, we roughly know our needs.
Don’t hesitate to tell us if you have something in mind.
The dedicated dashboard part would be (as mentioned above) something defined and embraced on the dev side (depending on user feedback of course) but allowing us not to be limited to columns/rows. I don’t know in this case whether you’ve actually read the whole spec.
2 PM this afternoon, would that work for you?
1 Like
Hello EV
2 Likes
Hey!
Since we’re on the subject here, I have a Ford plug-in hybrid. I intended to manage that via Node-RED but never got around to it…
Maybe all this could motivate me 
3 Likes
Hello !
Following our call with Pierre-Gilles, we determined that for the 1st PR we will limit ourselves to integrating categories / types; this is already significant and will then allow us to look directly at the APIs and/or some widgets.
The notion of a dedicated dashboard is, at least for now, set aside (I’m renaming the request).
The goal is therefore to create a global dedicated category « Electric vehicle » containing the types listed in the table at the top of the request (which I updated):
The question to ask (@pierre-gilles) is whether some of the already-existing types should be specifically typed in order to later enable dedicated automations in Gladys’s core or via scenes.
I am thinking for example of energy values (power, current, energy, etc.) since there can be multiple of them, for example:
- Charging power
- Instantaneous battery pack power while driving
or: - Charging current
- Instantaneous battery pack current
or: - Interior temperature
- Exterior temperature
- Minimum battery temperature
- Maximum battery temperature
=> The types defined here cannot be modified.
@Terdious for autonomy did you set everything to type « battery » ?
Gladys must be able to distinguish each feature by the category + type pair, if they’re all the same it won’t work, shouldn’t we make it even more specific?
Thanks for your answer @pierre-gilles, that was the whole point of my question. I didn’t want to go in that strongly right away, but I agree.
For range, for example, I was thinking we could distinguish it using the trio category + type + unit. But that’s fine with me ^^
So we agree then that, for example, for charging current and charging power, we would rather use a spec « charge_current » and « charge_power »
They are also generally named like that in the APIs — see even more specific naming at least for Tesla:
Yes, I think so
1 Like
I support the initiative given that I’ve just switched to electric!
2 Likes
Ok, table updated!
All that’s left to do ^^