Aeon Labs ZW062 Garage Door controller - stateful commands

I’m looking more at this - perhaps it’s actually a bug in the code driving all this.

The state is reflected properly in HASS front-end always, and won’t allow it to be changed to the existing state (ie. if the door is closed then the close control is inactive). However, when changing the state via API (even from closed to closed) it will always trigger the relay in the controller, causing the door to move. Ie if the door is closed and you POST the below, the door will open. The state will then change to open once the door is open.

I’m making an API call to /api/services/cover/close_cover and sending the following JSON:
{ “entity_id”:“cover.aeotec_zw062_garage_door_controller_switch_4_0” }

Any thoughts? I guess what I’m expecting is to set a desired state - if the door is closed and you tell it to close via API then it shouldn’t change.

Same behaviour when attempting this with the switch. The switch state is ‘off’ when the door is down/closed and ‘on’ when it’s up/open.

If the switch state is already off and I then call the turn off API, it will actually turn the switch ON and open up the door. Again, I don’t know if this is something HASS, OZW or the controller itself is doing.

I have a wemo switch and issuing the ‘turn off’ call via API is ignored if the switch is already off, as expected.
I also have other ZWave switches and turning these off via API when they’re already off is also ignored - it’s ONLY the garage door controller that exhibits this behaviour.

I have no knowledge of this. What I hear from what you are saying it seems the garage door only has a toggle switch and doesn’t care about state…? If you can intercept the call… Can’t you just intercept the call and double check it before you stop or execute it?

Appreciate it if you post it here if you create a solution. And anything else for that matter :blush:

Actually, it does show the state some HASS knows about it. It’s just the current state seems to be ignored when requesting a state change to the same value. It’s weird, hard to explain.

I tried to intercept the call briefly, but on the automation I used it actually intercepted it after the state changed so the end result was still the same - door opened or closed when it shouldn’t have. I need to investigate other way to handle that automation.

The root issue I believe is that the ZWave implementation HAS uses doesn’t support the Barrier Operator command class.

As I see it, my options are:

  1. Patch OZW to support the Barrier Operator command class
  2. Create an automation that I use exclusively for external triggering which checks the current state report before determining what to do.

I’ll definitely post the outcome I come up with!

This thread:

will help with option #1 in case you’re bored :stuck_out_tongue:

Hi guys,
Here’s a conditional action working for my Aeotec Garage door controller, so I hope it helps with what you’re trying to do. :slight_smile:

I’ve added an action to the HTML5 notification I receive when the garage door is left open, that allows me to easily close the door. This action only triggers if the garage door is still open though, in case the door has been closed in between the notification firing and me seeing it and tapping the action:

[automations.yaml]
- alias: Garage door open notification
  trigger:
    - platform: state
      entity_id: cover.aeotec_garage_door_switch
      to: open
      for:
        minutes: 30  
  action:
    - service: notify.html5
      data:
        message: "Garage door has been left open"
        data:
          data:
          tag: garage_door_open
          actions:
          - action: close_door
            title: "Close door"

- alias: Garage door close
  trigger:
    - platform: event
      event_type: html5_notification.clicked
      event_data:
        action: close_door
  condition:
    - condition: state
      entity_id: cover.aeotec_garage_door_switch
      state: open
  action:
    - service: cover.close_cover
      data:
        entity_id:
          - cover.aeotec_garage_door_switch

(First post so let me know if I haven’t pasted this right.)

What I’m trying to do now is call the ‘garage door close’ automation (or a similar one with the same condition) from IFTTT / Google Assistant. I’m currently using the voice commands that Rishidawar shared here which is cool, but because the Aeotec cover responds to the change state even when it’s already in that state (ie “opening” the door when it’s already open…which closes it) it’s a bit hit and miss. Can anyone point me in the right direction please!?

PS thanks @mrgrumpy83 for listing the parameters and values above to change, although all but 8 and 32 keep reverting back to the original numbers which is strange. (Even in OZWCP.)

Hey @stokesy thanks for your post.

Sounds like you’re attempting to do exactly the same thing as me. I’m already using IFTTT and Google Assistant and it works perfectly except that the existing state of the door is ignored - the controller responds to the state change regardless. I think I’ll grab your snippit for your notification and put that in place.

I actually contacted Aeonlabs regarding this ignoring the state and triggering anyway behaviour and their response was basically that this occurs because the z-wave software in use doesn’t support the secure barrier class - which is correct, OZW does not. The OZW barrier class definition dictates that controllers should NOT send the ‘open’ state unless the door is ‘closed’.

I have hesitated to attempt to compile in the barrier support because I prefer to actually have the standard running environment so have been thinking of other ways to do it.

Using an automation is the obvious choice, however using the ‘open_cover’ or ‘close_cover’ trigger to start an automation conditional on the pre-existing state of the cover element doesn’t work - it only fires when the cover state changes, which is too late as it has already caused the door to move so the actions etc following are useless.

My next thought is to actually call an automation using IFTTT with an API call. You can do this as follows:

URL: https://IP:8123/api/services/automation/trigger?api_password=MY_PASSWORD
Method: POST
Type: Json
Body: {“entity_id”:“automation.yourautomationname”}

This would seem like a fairly easy task - certainly the conditions and actions are (action of open_cover, condition of cover state = closed) however I couldn’t work out how to define an automation which was essentially only triggered manually. The only time I would want it to run is if it’s called by the API. I spent about 15mins on it and gave up in frustration.

Any ideas on how to create an automation that is only triggered manually by calling it?

I see this too but the behaviour suggests that the numbers have actually held as the tones don’t actually play…

I think I’ve worked it out @mrgrumpy83! :joy: Or at least it appears to be working for me, however I’ve been trawling through these forums and this code for…way too long - so keen to get you to confirm.

I also gave up trying to get IFTTT to trigger the automation directly, so instead it’s toggling a switch (input_boolean) in HA, which then triggers the automation. There’s got to be an easier way, but this is working for now!

configuration.yaml

automation: !include automations.yaml
input_boolean: !include input_boolean.yaml

input_boolean.yaml

garage_door_open_trigger:
  name: Garage door open trigger
  initial: off
  icon: mdi:garage-open
garage_door_close_trigger:
  name: Garage door close trigger
  initial: off
  icon: mdi:garage

automations.yaml:

- id: a_garage_door_open_notification
  alias: Garage door open notification
  initial_state: True
  hide_entity: False
  trigger:
  - platform: state
    entity_id: cover.aeotec_garage_door_switch
    to: open
    for:
      minutes: 15
  action:
  - service: notify.html5
    data:
      message: "Garage door has been left open"
      data:
        data:
        tag: garage_door_open
        actions:
        - action: close_door
          title: "Close door"
- id: a_garage_door_close
  alias: Garage door close
  initial_state: True
  hide_entity: False
  trigger:
  - platform: state
    entity_id: input_boolean.garage_door_close_trigger
    from: 'off'
    to: 'on'
  - platform: state
    entity_id: sun.sun
    to: below_horizon
  - platform: event
    event_type: html5_notification.clicked
    event_data:
      action: close_door
  condition:
  - condition: state
    entity_id: cover.aeotec_garage_door_switch
    state: open
  action:
  - service: cover.close_cover
    data:
      entity_id:
        - cover.aeotec_garage_door_switch
  - service: input_boolean.turn_off
    data:
      entity_id: 
      - input_boolean.garage_door_close_trigger
      - input_boolean.garage_door_open_trigger
- id: a_garage_door_open
  alias: Garage door open
  initial_state: True
  hide_entity: False
  trigger:
  - platform: state
    entity_id: input_boolean.garage_door_open_trigger
    from: 'off'
    to: 'on'
  condition:
  - condition: state
    entity_id: cover.aeotec_garage_door_switch
    state: closed
  action:
  - service: cover.open_cover
    data:
      entity_id:
        - cover.aeotec_garage_door_switch
  - service: input_boolean.turn_off
    data:
      entity_id:
      - input_boolean.garage_door_close_trigger
      - input_boolean.garage_door_open_trigger

Notes:

  1. If you add the two Input Booleans to a group you can test them from the UI, plus watch them fire when the IFTT request works for extra satisfaction
  2. I’m resetting both Input Booleans each time to ensure they’re both ready after an automation has run.
  3. Because I’ve added IDs to my automations (so I can view them in the UI) the line indents have changed from my previous post, so be careful if you cherry pick!

My IFTTT recipies for Google Assistant are:

If You say “Open garage door”, then make a web request
URL: https://URL/api/services/input_boolean/toggle?api_password=
Method: POST
Body: {"entity_id":"input_boolean.garage_door_open_trigger"}

If You say “Close garage door”, then make a web request
URL: https://URL/api/services/input_boolean/toggle?api_password=
Method: POST
Body: {"entity_id":"input_boolean.garage_door_close_trigger"}

I think that’s all…please let me know if I’ve missed something and how you go.

It appears to work fine for the most part - great work.

The one thing that I found is that the boolean switch will not reset for a same state condition. Ie. if the door is closed, and you issue the close command, the boolean will stay ‘on’ because the action to reset it only runs if the conditions are met (ie. the cover is in open state). A subsequent ‘close’ run will then toggle the switch back but of course not have any impact. So in the event where things aren’t ‘in sync’ properly, it could take 3 runs to get the door to do what you want.

You can fix it by moving the conditions into the action block and resetting the toggle first. It runs from top down and stops if the condition is false, so ordering is critical.

action:
  - service: input_boolean.turn_off
    data:
      entity_id:
      - input_boolean.garage_door_close_trigger
      - input_boolean.garage_door_open_trigger
  - condition: state
    entity_id: cover.aeotec_zw062_garage_door_controller_switch_5_0
    state: open
  - service: cover.close_cover
    data:
      entity_id:
        - cover.aeotec_zw062_garage_door_controller_switch_5_0

Tested this and it all works properly - finally!

Now I need to get my notifications working properly so I can know about it if I’ve left the area and forgotten about the door!

Thanks so much for your help! If you do ever figure out how to call an automation on demand feel free to post it here!

Glad to hear!

I didn’t know you could have a condition within the action - so much to learn! And handy for this because I wasn’t sure how else to reset the switch (boolean). Although I also hadn’t thought it would matter much, for example, what position the close switch (boolean) was in when the door was closed; when the open automation ran it would “reset” the close switch ready. I realise now though that if the garage door is opened by the remote… so thanks for improving it.

If only the Barrier Operator command class was available!

Can I ask what you use for location tracking? That’s my next challenge: when I approach the house in my car or bike I want the garage door to open automatically! :grin: WiFi/Bluetooth/OwnTracks/GPS tracker/tasker… so much reading to do!

PS Looking at your garage entity ID above, have you seen that the Z-Wave IDs will be changing in 0.48? https://home-assistant.io/blog/2017/06/15/zwave-entity-ids/

Nothing at this stage. I looked at using OwnTracks but only got part way through setting it up. It’s pretty involved to set up properly and seemingly not that accurate at times anyway.

However - having an automatic open when in the car (assuming it has bluetooth) should be achievable with tasker (or macrodroid) without necessarily configuring location tracking in HASS. Set up a geofence, condition it on your cars bluetooth and have that trigger off the door automation via the REST call above. IMHO this is a far simpler way to set it up if that’s the end result. Of course if you want HASS to do other location aware stuff then you’re better off with location tracking. For me though, I’d prefer to manually instruct the door to open.

Yes, I’m aware that the Z-Wave IDs will be changing. I’ve got updating HASS and the Z-Wave IDs on my list to do this week.

Time to revive this thread with support added for barrier commands - anyone else given it a go?

The good news is that the cover commands work correctly now! eg calling close.cover when the garage door is closed doesn’t do anything.
However the bad news is that, for me at least, HA and/or OZW no longer seems to know if the door is open or closed. The state updates if you use the cover commands - but if you use the remote it has no idea the garage door has changed and so gets out of sync. :confused:

I’ve tried re-connecting the door tilt sensor, removed and re-added the GDC from the Z-wave network and then factory reset the GDC… and even “started again” when I moved from the AIO on Raspbian to hass.io. So I don’t know what else I can try?!

Anyone else have any experience?

1 Like

What is the first line in your OZW_Log.txt file?

I’m also having the exact same issue mentioned above. For me the first line says
2017-08-13 09:26:48.710 Always, OpenZwave Version 1.4.2508 Starting Up

Same version for me:
2017-08-13 23:37:23.077 Always, OpenZwave Version 1.4.2508 Starting Up

Running Hass.io 1.0 and Home Assistant 0.51

You need OpenZwave version 1.5.xxxx for it to work properly.

See this thread here

Didn’t HA 0.50 support Barrier_operator, as per the change notes:

The Home Assistant Z-Wave Cover implementation has been updated to support the latest development version of OpenZWave. If you are currently applying a workaround to your OpenZWave installation to support the barrier command class, you’ll need to make sure you update your workaround to the latest development version of OpenZWave. (@firstof9 - #8574) (cover docs) (cover.zwave docs) (breaking change)

Plus the cover state is working!?

The Barrier support comes from OpenZwave and it is only in the development version of OpenZwave. The changes to HA were to “not break” peoples work around’s.

Oh OK. That was not clear in the release notes, but thanks for clarifying it now.

Any idea how long until OZW might be updated in HA with this support? (ie days, weeks or months?)