Best way to convert or format Zwave responses?

Configuration
1

I’ve got a Zwave door sensor that rather oddly doesn’t return “open” and “closed”. From watching the values, it returns 22 when the door is closed and other values when open (almost always 23, but definitely 22 when closed).

So far I’ve worked around this by creating a template sensor that refers to the Zwave entity as follows:

  - platform: template
    sensors:
      door_access:
        value_template: '{% if is_state("sensor.door_access_control", "22") %}closed{% else %}open{%endif %}'
        friendly_name: "Door"

Where sensor.door_access_control is the ZWave sensor. I then hide that sensor so that I only see the template version.

Is this the only way or is it possible to directly apply the template by defining a sensor with platform of zwave and defining the translation template there? Just want to check I’m not creating unnecessary extra entities if it can be done in one step.

2

A lot of Zwave sensors don’t output a ‘normal’ response; Fibaro motion sensors come to mind.

I use the same method as you and it doesn’t seem to add any appreciable over head.

3

Cheers, thanks for the quick response.

4

No problem. At one time I was using an original version of the Weather Underground component that required template sensors to pull out each of the observed conditions. I must have had over 25 of them running just for that, and while it did make restarts a little slower, it didn’t have a affect on performance. And that was pre async I/O days. LOL

5

Im guessing you have the GE door sensor that I have. This is what I made:

  - platform: template
    sensors:
      main_door_hindge:
        value_template: >
          {% if is_state('sensor.main_door_t_access_control_9_9', '23') %}
            closed
          {% elif is_state('sensor.main_door_t_access_control_9_9', '22') %}
            open
          {% else %}
            closed
          {% endif %}
        friendly_name: Main Door Status
      entry_door_hindge:
        value_template: >
          {% if is_state('sensor.entry_door_t_access_control_18_9', '23') %}
            closed
          {% elif is_state('sensor.entry_door_t_access_control_18_9', '22') %}
            open
          {% else %}
            closed
          {% endif %}
        friendly_name: Garage Entry Door Status

Using the code like this will set the state to closed during start up so you don’t get that annoying ‘None’ is not a valid attribute error on start up.

6

Sounds like you have one of the GE Hinge sensors too. Someone out here did a review on them and was able to get a satisfactory response out of them after a while. I’ll see if I can find that link.

7

Yeah, I made some comments on that thread when i stumbled upon it: Here is the link

1 Like
8

I’ve got one too. I was trying to get ozwcp to work so I could try and get it to synch right and respond or do something, and ended up trashing my install and starting over. Two days later I think I have just about everything put back together so I can get back to the door tonight or over the weekend.

9

Mine’s actually a Hauppauge 4 in 1 sensor, but from what I gather elsewhere that’s just a rebranding of a generic sensor type. The naming conventions certainly look similar - I omitted it for brevity in the example above but my door sensor is actually door_access_control_2_9

Mine seems to be the opposite to your examples though - 22 is closed, 23 is open for me.

It also has luminance level, temperature - which both work as expected - and “burglar” which activates when the sensor is moving.

10

Interesting… I wonder if GE and Hauppauge use the same interal chip/device. Odd coincidence that the door sensor has the same values just reversed.

11

Possibly. All of the entities from mine report battery level and a node_id, which seems to match the first number in the entity name - so I assume door_access_control_2_9 is sensor 9 on device 2 in their terms.

Still, OpenZWave is doing better than my SmartThings hub did with them - that could only pick up the door contact sensor and not the others (I started with ST just over a year ago and will keep it for my Zigbee stuff while I transition to ZWave and HA over time)

12

Ah, further research. Got it wrong, 23 is definitely closed. My sensor was playing up - it’s only reliable with the magnet on one side of unit and it’s very sensitive so I was getting some odd results where it was reporting open when it looked closed.

And I’ve tracked those magic numbers down on page 73 of the ZWave Command Class spec - 0x16 (decimal 22) is “Window/Door is open” and 0x17 (23) is “Window/Door is closed”.

Some useful info in there and I’m hoping I can use it to decode the other values I’m getting from the sensors.