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
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:
Patch OZW to support the Barrier Operator command class
Create an automation that I use exclusively for external triggering which checks the current state report before determining what to do.
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.
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.)
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:
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 think I’ve worked it out @mrgrumpy83! 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!
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:
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
I’m resetting both Input Booleans each time to ensure they’re both ready after an automation has run.
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.
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! WiFi/Bluetooth/OwnTracks/GPS tracker/tasker… so much reading to do!
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.
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?!
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
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)
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.
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.
WiFi/Bluetooth/OwnTracks/GPS tracker/tasker… so much reading to do!