Fibaro Door Sensor V2

Configuration
63

it maintains the previous state. If the previous state was closed, it will stay closed.

64

In my case though, the door was open, when all of a sudden it changed to Closed when it went to 254


Edit:

I think I found my issue :confounded: , I was setting it to:

else states('sensor.frontdoor')

When actually, they are binary_sensor’s, so it should be:

else states('binary_sensor.frontdoor')

Edit again:
Nope, that didn’t fix my issue either. As soon as it goes 254, it changes to closed. I suppose because the binary sensor returns a on/off, while the test is looking for a true/false.

This is what works for me:

- platform: template
  sensors: 
    frontdoor:
      sensor_class: door
      friendly_name: Front Door
      value_template: " {{ is_state('sensor.fibaro_system_fgdw002_door_opening_sensor_2_access_control', '22') if states('sensor.fibaro_system_fgdw002_door_opening_sensor_2_access_control') in ['22','23'] else states('binary_sensor.frontdoor') == 'on' }} "
1 Like
65

Hello,

I have just recently moved from Jeedom to Home Assistant. I greatly appreciate this change, but like you, I have concerns/questions about this sensor.

I use Home Assistant 0.99.3 on HassOS 2.12. Normally I am up to date =]

I just added five FGDW002 sensors to Home Assistant and don’t understand many things.

2019-10-02%2014_46_06-Home%20Assistant
2019-10-02%2014_46_06-Home%20Assistant487×569 30.8 KB

Why are so many elements added to the home page (default_view)? The opening state and temperature are the only usable elements.

I understand that it was necessary to create a binary sensor for the opening state. Why is this sensor not integrated directly by Home Assistant?

Can we contribute to the integration of devices? If so, how?

66

Because that’s what happens for every entity if you’re using the auto-generated UI

It’s not necessary it’s simply convenient. Home Assistant doesn’t do that because nobody has stepped up and developed a function that does that.

See the developer docs.

67

Thank you for your answer!
It’s very clear and so I started to create my own custom dashboard.

68

Just moved over to HASSIO and lost this device again, editing in zwave_xxxx.xml does not do the trick since the file is overwritten/goes back to default.

How can I get this device to work in HASS.IO?

69

Hi,

Digging up that subject since I moved from Jeedom to HA but i have problems with that sensor.

I only have a number and an eye in my lovelace card which is not waf. I tried to use the code from this topic but it doesn’t work.

I’d like to have an icon with a door or a window (i succeeded with custom icon) but is it possible to change the icon from close to open depending on the value (22/23) and write the status (open/close) to be clearer.

I’m new in HA and i’m improving but still have troubles to understand how it works.

Thanks

Tricky

70

Create a binary sensor with a device_class of Door

binary_sensor:
  - platform: template
    sensors:
      storage_door_fix:
        device_class: door
        value_template: >-
          {% if is_state('sensor.storage_door_access_control', "23") -%} 
            false
          {% else -%}
            true
          {% endif %}

Although I have the v1 sensor and not the v2, I have to use this because the binary sensor created with the v1 has a bug that doesn’t report the first open/closed change after about 15 minutes.

71

FYI, you can significantly simplify that template since templates return true and false

        value_template: >-
          {{ not is_state('sensor.storage_door_access_control', "23") }}
2 Likes
72

I tend to write mine a little more verbose when I can, just habit, so it’s clearer to anyone who picks up the code what it does.

73

That’s killing me :exploding_head:

I tried with that code in my configuration.yaml in the binary_sensor section

      porte_fenetre:
        device_class: door
        value_template: >-
          {% if is_state('sensor.capteur_salon_access_control', "23") -%} 
            Closed
          {% else %}
            Open
          {% endif %}}   
        icon_template: >- 
          {% if is_state('sensor.capteur_salon_access_control', "23") -%} 
            mdi:window-closed-variant
          {% else -%}
            mdi:window-open-variant
          {% endif -%}

Porte fenĂȘtre

Porte fenĂȘtre settings

Nothing happens in the lovelace. Do I miss something or is there something wrong in the code ? I know that it’s a long code but for now, it’s easier for me to understand.

Thanks a lot

74

Hello,

I succeded with the icon which is open/closed depending on the state (I hade to use a new entity). But, it’s always written Closed near the icon. The code is the same as above. Any ideas ?

75

Binary sensors are on/off, not Open/Closed

Just use the example in the documentation. If it’s a window, change door to window for the class:

binary_sensor:
  - platform: template
    sensors:
      YOUR_SENSOR:
        friendly_name: "Friendly name here"
        device_class: door
        value_template: "{{ is_state('sensor.YOUR_ORIGINAL_SENSOR_access_control', '22') }}"
2 Likes
76

That’s working with your code. So thank you so much.

Do you think that I can improve the code for the icons ?

77

Icons are handled automatically if you set the device class - there’s nothing to do if you want the stock icons.

78

Thank you for your answer. I kept my icons and the code i used.

Now, everything works perfectly.

79

This is actually what seems to work, to keep the status as is, until a new status appears.
Thanks a lot.

80

Please check the addition that Veldkornet made (see my mail of today.
The standard code doesn’t work, as the access_control sensor doesn’t keep it’s status to 22 when it goes to sleep.

1 Like
81

This really helped me solving my issues with the sensor.
It is now showing very reliable the state and only changes when the window opens or closes. Nothing when it goes to “deep sleep”.
Thanks to all of you!

82

Petros’ idea up there to return the sensors own state if the zwave device is in the 254 state really saved my day. Thanks for that.

There’s one problem left. The value of the template sensor is not kept between HA restarts. So if a device is in deep sleep while HA restarts, the template can’t render and ends up in a degraded ‘Unavailable’ state until the device state changes (and there’s an error in the HA logs).

I can’t believe that this situation isn’t being taken care of in the HA zwave integration itself. The (in)famous deep sleep 254 state is standard behavior for pretty much every modern battery powered zwave sensor device. And many newer devices cannot be switched to binary reporting mode anymore. So handling the 254 case is super important if you want to get reliable states. Nothing is worse than using a template sensor with incorrect deep sleep state handling and then getting reports that a door is closed when in reality it’s actually open.

1 Like