List of unavailable entities (other fields found) for Cupra Leon VZ 2025

[socram70]

I have 32 other fields found with no entities. I don't have any entity of my car in HA.

state:
translated: "32"
raw: "32"
last_changed: "2026-06-18T19:15:05.562Z"
last_updated: "2026-06-18T19:15:05.562Z"
attributes:
bem_level: "0"
locked_state__rear_left_door: "3"
locked_state_front_engine_bonnet: "3"
locked_state_front_left_door: "3"
locked_state_front_right_door: "3"
locked_state_rear_right_door: "3"
locked_state_tailgate: "3"
oil_level_dipstick_indicator_function: "1"
oil_level_total_max: "1.0"
position_front_left_door_window_lifter: "0"
position_front_right_door_window_lifter: "0"
position_rear_left_door_window_lifter: "0"
position_rear_right_door_window_lifter: "0"
safe_state_front_engine_bonnet: "3"
safe_state_front_right_door: "3"
safe_state_rear_left_door: "3"
safe_state_rear_right_door: "3"
safe_state_tailgate: "3"
state_of_hood: "0"
state_service_hatch: "0"
state_spoiler: "1"
state_sunroof_motor_hood_3: "0"
tyre_pressure_actual_front_left: "1"
tyre_pressure_actual_front_right: "1"
tyre_pressure_actual_rear_left: "1"
tyre_pressure_actual_rear_right: "1"
tyre_pressure_actual_spare_tyre: "1"
tyre_pressure_required_front_left: "1"
tyre_pressure_required_front_right: "1"
tyre_pressure_required_rear_left: "1"
tyre_pressure_required_rear_right: "1"
tyre_pressure_required_spare_tyre: "1"
model: ""
assumed_state: true
icon: mdi:help-circle-outline
friendly_name: Cupra Leon [redacted] Other fields found

[socram70]

In the meantime, some entities showed up and disappeared again. Also, the vehicle ID is in front of every entity. Maybe the screenshots help troubleshooting:

[socram70]

I fixed this here.

[WulfgarW]

1. Which of the 32 fields that you stated above, seem necessary in HA? Less is more.
2. Unfortunately, some fields are sometimes missing in the EUDA files and then they appear again. And it's very often not just the 'value' line, that is missing then, but the total field.

[socram70]

1. I think all of the fields are relevant (except for the sun roof, as I don't have one - but that's of course just my personal requirement). I think I would include everything and let the users decide what they want. I think it's also possible to deactivate less common entities by default?
2. I would use the last known value and field name in this case and it might make sense to mark this as outdated?

[WulfgarW]

1. I think all of the fields are relevant (except for the sun roof, as I don't have one - but that's of course just my personal requirement). I think I would include everything and let the users decide what they want. I think it's also possible to deactivate less common entities by default?

a) I will implement sensor entities for the window lifter position fields. (Although I think, that the binary sensors 'Window closed xxx', that are already present, carry the important fact in a simple two state information.)

b) Do you really think, that you need entities for the 'individual' locked state of 4 doors, the bonnet and the tailgate, when you already have an entity 'Doors locked'? If you see in HA, that 'Doors locked' is open or you have built an alarm for that, you still have the MyCupra app to look into the details and even to lock your car.

c) What insights do you gain from the fields (1) oil_level_dipstick_indicator_function: "1" and (2) oil_level_total_max: "1.0"? Do you expect, that the values of these fields will change sometime?

d) And what about the fields, that you think, that they are relevant, although your vehicle does not support them(e.g. bem_level: "0", state_of_hood: "0", state_service_hatch: "0" and state_spoiler: "1")? What information do the safe_state_xxx fields provide for your vehicle?

e) Regarding the tyre pressure fields: Your vehicle does not have tyre pressure sensors. So the fields don't provide useful information for you.

f) And what kind of implementation would you expect? Should I build sensor entities for fields like the tyre_pressure_xxx or safe_state_xxx to support, that they can have more then two different values? But for vehicles, that support the respective feature, I think, that a binary sensor makes much more sense. (But what should Get_EUDA_Data show for vehicles not supporting the respective feature?)

I think, I will wait until a user, who has those features (see d) and e)) on his vehicle, asks for the entities to be available in HA.

2. I would use the last known value and field name in this case and it might make sense to mark this as outdated?

What do you mean with 'mark this as outdated' technically?
With the current implementation, the user can easily see, that no value was provided with the last EUDA file, and if the user wants to know the last known value, he opens the entity details.

[socram70]

a) I agree, I didn't mean that you need to take over every sensor 1:1, but using the relevant information might make sense (as far as it's useful). To stay with your example, I think a binary sensor for the window makes most sense since I think the information is provided as binary value anyway.

b) Most likely not, what I meant is that the user might want to decide which sensors they would like to use. My experience with building HA extensions is very limited, so please excuse my ignorance, but I know from other integrations (e.g., Shelly) that some of the entities are deactivated by default and can be enabled manually (e.g., frequency of a shelly 2pm). Wouldn't it make sense to use one window sensor and four optional sensors in case some users want to use this information? I opened a window to see if it shows a percentage of the amount it's opened, but unfortunately nothing happened for a while here - I'll update this post as soon as something changes.

c) I understood (1) as indicator of the functioning of the sensor. I checked the Data Dictionary, but this is also not really helpful, because the description is limited to "Indicates if off (0) or active (1)". oil_level_total_max is described as follows "Amount of motoroil level in liter".

d) BEM (Battery Energy Management) Level for auxiliary battery is supposed to show the "BEM (Battery Energy Management) Level for auxiliary battery" in percent, state_of_hood and state_service_hatch is "Indicates the state of the car hood (service hatch) unsupported (0) or invalid(1) or open (2) or closed (3)", while state_spoiler works similar "Indicates the state of the spoiler unsupported (0) or invalid(1) or open (2) or closed (3)".

e) Yes, I'm aware of this. Even though it's not useful for me, it might be useful for people who have these sensors? Unfortunately, even though I have the "indirect sensor" in my car which alerts me if the tire circumference changes, this doesn't seem to change this value as it's described with "Indicates if the actual front left tyre pressure is unsupported (0) or invalid (1) or valid (int)". Therefore, this might only be useful where this value is not 0 or 1.

f) Yes, where there's no int value, I think a binary sensor makes most sense. For all sensors which are either "unsupported" or "invalid", I think they should be disabled or not shown at all.

Regarding the last point: I think currently it was (is?) implemented in a way which shows "unavailable" where there hasn't been a value in the last data set. Could it be that the value is not delivered when there's no update? In this case, it might make sense to use the last value which has been available here and update the entity's friendly name with something like "outdated" or mark the icon as grey?

[WulfgarW]

... I opened a window to see if it shows a percentage of the amount it's opened, but unfortunately nothing happened for a while here - I'll update this post as soon as something changes.

The window lifter position fields are really an integer that tells, how wide oen the window is (in percent).
As I already wrote: I will implement it. But the added value is rather small.

Regarding the last point: I think currently it was (is?) implemented in a way which shows "unavailable" where there hasn't been a value in the last data set. Could it be that the value is not delivered when there's no update? In this case, it might make sense to use the last value which has been available here and update the entity's friendly name with something like "outdated" or mark the icon as grey?

No, fields should not be missing in an EUDA file, just because their value did not change.

[socram70]

1. For me, the entities (e.g., ...window_closed_left_back) aren't integer, but binary sensors. I don't have integer values related to the window opening state.

[WulfgarW]

Yes, the windows closed entities are binary sensors.
But the new 'Windows lifter position xxx' entities, coming with the next release, will be sensors with value in %.

[WulfgarW]

The entities 'Window lifter position xxx' are now available with version 0.0.15.

[socram70]

I can confirm that this works for my Cupra Leon 2025. However, I think the window lifter position should be inverted. My windows are nearly closed and show between 14 and 21 percent. At least I would expect that the lower the percentage is, the wider the window is open?

I also noticed that even though I don't have a sunroof, it shows "Sunroof closed" as open. "Parking brake" shows closed. But that's probably because it's a "door" entity. Maybe a lock or a safety entity type might fit better?

[WulfgarW]

I can confirm that this works for my Cupra Leon 2025. However, I think the window lifter position should be inverted. My windows are nearly closed and show between 14 and 21 percent. At least I would expect that the lower the percentage is, the wider the window is open?

The data dictionary says: Indicates if the position of the front right door window lifter is open in percentage or closed (0)
So 100% means open and not closed.

I also noticed that even though I don't have a sunroof, it shows "Sunroof closed" as open. "Parking brake" shows closed. But that's probably because it's a "door" entity. Maybe a lock or a safety entity type might fit better?

The entity "Sunroof closed" should become unavailable, if your vehicle does not support it. For new users, it works, but for old users not. I have to check it.
It will set up the 'Parking brake' without a device class. Then HA shows it as 'On' or 'Off'.

[socram70]

The data dictionary says: Indicates if the position of the front right door window lifter is open in percentage or closed (0) So 100% means open and not closed.

I didn't mean that you implemented anything incorrectly. What I meant was that I think that VW's approach is rather unconventional here. I (and I guess most likely also other users) would probably expect that it shows 100% if the windows are closed and not the other way around. But maybe that's just my first impression.

The entity "Sunroof closed" should become unavailable, if your vehicle does not support it. For new users, it works, but for old users not. I have to check it. It will set up the 'Parking brake' without a device class. Then HA shows it as 'On' or 'Off'.

Understood, thank you.

[WulfgarW]

I didn't mean that you implemented anything incorrectly. What I meant was that I think that VW's approach is rather unconventional here. I (and I guess most likely also other users) would probably expect that it shows 100% if the windows are closed and not the other way around. But maybe that's just my first impression.

If it helps, I could change the unit from '%' to '% open'.

[WulfgarW]

Upgrade to version 0.0.16 and then overwrite const.py in custom_components/get_euda_data/get_euda_data with the attached one.
(Github doesn't send a notification, if someone just adds a reaction. So I saw your reaction, after I released 0.0.16.)

const.py