Floorplan does not detect changes in cover.* entities to "set class"?

[Aephir]

I have been trying to set the css class based on the state of a cover. I can see that the cover is associated with the element (hovering over the element shows info, and clicking it brings up the control).

But it doesn’t set the class of the linked element based on the state of the cover.

This:

    - name: Trunk
      entities:
        - entity: cover.model_y_trunk
          element: trunk_open
      state_action:
        service: floorplan.class_set
        service_data: '${(entity.state === "open") ? "visibility-on" : "visibility-off"}'

perpetually shows this (you can see the “hover info”):

Even when the state is not open:

However, this (simply using another entity type, and input_boolean):

    - name: Trunk
      entities:
        - entity: input_boolean.guest_mode
          element: trunk_open
      state_action:
        service: floorplan.class_set
        service_data: '${(entity.state === "on") ? "visibility-on" : "visibility-off"}'

toggles the trunk_open element just fine; this is how it looks while input_boolean.guest_mode is not on:

I have tested the covers in multiple floorplans and with multiple different settings, but nothing seems to work.

Is this something about covers in general, or something specific to the entities provided by the tesla custom integration? Unfortunately, I don’t have any cover entities that are not related to the car, so I can’t test whether this is a cover problem or a tesla custom integration problem.

EDIT: The (in progress) svg file, css, and yaml can be found here: https://github.com/Aephir/ha-tesla-lovelace-floorplan/tree/main/troubleshooting . Updated files are in the top level of the same repo (for when I start too fix things)

EDIT: I am using other entities from the tesla integration in another floorplan (both the device_tracker and the sensor.model_y_battery), which seem to work fine (also to “set class”; this is the colored battery circle), leading me to suspect cover.* in general more than the integration:

[OzGav]

So just to confirm when the trunk is actually open and you hover over it can you see the state as open?

[Aephir]

In the hover text, yes:

That works fine for both cover.* and input_boolean.*. It’s just that the css class is not set when using the cover.* (so the image of the trunk is not hidden).

EDIT: I added a link to the github repo with all files and some additional info in the first post.

[OzGav]

It indeed could be a bug in the code. Let me check with the devs.

Edit: Just an FYI to simplify your code. If you name the SVG element the same as the entity_id you don’t need the element key.

[Aephir]

@OzGav

Let me check with the devs

Great, thanks!

@OzGav

If you name the SVG element the same as the entity_id you don’t need the element key.

Good to know, but in most cases I use the same entity_id to “control” multiple different elements with different “rules”.

[OzGav]

@Aephir

I use the same entity_id to “control” multiple different elements with different “rules”.

Sounds good.

[Aephir]

Actually, I think I found at least part of the problem (on my side).

I have two rules that relate to the same element (well, multiple pairs). Removing the “duplicates” fixed the behavior.

So follow up question, if I may:

How do I have an element react (listen) to changes in two different entity_ids?

For instance, I have these two rule:

    - name: Frunk Open (Passenger Front Closed) - Doors
      entities:
        - entity: binary_sensor.model_y_doors
          element: frunk_open
      tap_action: disable
      hover_action: disable
      state_action:
        service: floorplan.class_set
        service_data: |-
          {
            const passenger_front = hass.states["binary_sensor.model_y_doors"].attributes.passenger_front;
            const frunk = hass.states["cover.model_y_frunk"].state;
            
            if (passenger_front === "closed" && frunk === "open") {
              return "visibility-on";
            } else {
              return "visibility-off";
            }
          }
    - name: Frunk Open (Passenger Front Closed) - Frunk
      entities:
        - entity: cover.model_y_charger_door
          element: frunk_open
      tap_action: disable
      hover_action: disable
      state_action:
        service: floorplan.class_set
        service_data: |-
          {
            const passenger_front = hass.states["binary_sensor.model_y_doors"].attributes.passenger_front;
            const frunk = hass.states["cover.model_y_frunk"].state;
            
            if (passenger_front === "closed" && frunk === "open") {
              return "visibility-on";
            } else {
              return "visibility-off";
            }
          }

Since the logic relates to both the passenger_front attribute of binary_sensor.model_y_doors and the state of cover.model_y_charger_door.

I want the class_set to happen regardless of which one of them changes. It doesn’t seem to work to just add them both in the same rule under entities.

        - entity: binary_sensor.model_y_doors
          element: frunk_open
        - entity: cover.model_y_charger_door
          element: frunk_open

[OzGav]

You could create a group with the two sensors or make a binary sensor and use a template

[Aephir]

I was hoping to avoid creating a lot of additional sensors, but maybe that’s the best approach. Thanks!

[OzGav]

I use a package for floorplan so everything is in the one spot. I find that makes it more manageable.

[Aephir]

Sounds reasonable.

Can you actually keep the card yaml config in the “package” as well, and refer to it/load in from there? The UI card editor is most definitely not suited for the quite large flooplan yaml files you can get; I currently edit all in a different file, then copy into the UI editor.

[OzGav]

Not in the package but you can have an include in your dashboard YAML. I ccreated a dashboard folder and put them all in there. (I generally don’t use the UI for my dashboards but that’s just me)

  - !include dashboard/lights.yaml
  - !include dashboard/bedrooms.yaml
  - !include dashboard/house.yaml
  - !include dashboard/mgzsev.yaml

[HaoleBoy (Jay)]

trying to use the !include for my different floorplans

i’m not understanding where it goes. if I edit the dashboard like this. it returns an “unknown tag” error

views:
  - !include weather-card.yaml

[OzGav]

You can only use it if you are in YAML mode for your dashboard.

Also I have not had any luck using include for part of a view only a whole view. So I have my first two views in my ui-lovelace.yaml and then all my other views are just included as a file per view.

Using !include in lovelace dashboard storage mode?

Is there a way to use !includes in UI configurable dashboards?

Lovelace - !include files

finally: got it working: #ui-lovelace.yaml title: Main Lovelace views: - !include /config/lovelace/view_Home.yaml - !include /config/lovelace/view_Lights.yaml cool, and so much easier to edit the files… thanks. about the resource template: cant we also use set path = ‘/config/lovelace/’ and use that in the template creating the resource url’s? I was wondering how this would work, and, secondly, if the version control could be added? like: {% set resources = [ '/column-card.js', 'lovela…