I’ve got a ZW062 which is working fine however I’ve noticed something a bit odd.
This controller is meant to be stateful in that it has a sensor which shows if the door is open or closed. However, if the door is open (and the state is ‘open’) and you again tell it to open (by way of an API call to change the state of the cover to open, for example), it will still trigger the relay even though the value of the cover hasn’t actually changed. The knock-on effect of this is that the garage motor sees this as a button press and it will then close the door.
I would have expected that being stateful, the controller would set the door to the correct state. In essence a second open command would do nothing at all if the door is already in open state.
Has anyone else experienced this? Is this a behaviour of the controller? I believe that HA is just reading and sending the commands to the controller so I’m assuming that this is in fact a quirk with the controller but would love to hear any ideas about how to prevent this from happening.
Another question: will it change state if you open or closes the garage door manually (or with the old opener)? I don’t think my tilt sensor works. Seems like it only changes state if I open or close with the Z wave controller.
The state changes fine for mine if I open/close with a regular controller however this wasn’t the case by default. I had to change config parameter 80 (“Report type when the state of garage door is changed”) to “Hail” to get it to work.
I don’t have a delay at all, it triggers instantly.
I also disabled the alarms using ZWave parameters rather than the rather brute force method of deleting the files. I wonder if this has had an impact on that operation?
Changed parameters -
32 (Startup ringtone) = 0
37 (Configure alarm mode for when the door is opening) = 167837952
38 (Configure the alarm mode when the garage door is closing) = 83951872
39 (Configure alarm mode when the garage door is in unknown state) = 117506304
40 (Configure the alarm mode when the garage door is in closed position) = 16843008
You can actually do this from within HASS. Z-Wave on the left, select the node and then choose the parameter under node config options. Details will be provided for how to calculate the values that you want.
I just got everything working! I have just been googling the delay before and come up with nothing, you got me on the right track. Much better solution to edit the z wave parameteres! I had to do it via OZWCP because the values just changes back inside HASS. I’ve not read all the documentation, but it might to do with me not having copied the options.xml, and it’s added as a secure device(?).
Thank you very much! It was kind of useless without the Hail value
Yeah I guess - except I’ve made an assumption that the device itself is stateful. Ie. my assumption is that telling it to change state to ‘open’ when it is already in that state should do nothing.
I’m sure I can intercept the calls and check them in HASS but I believe that the device should actually handle that logic itself. Not sure why, but I guess without it it’s just a big switch and the ‘state’ function of it is somewhat useless.
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.
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.