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.
I was hopeful last October. As with most Open Source projects, there is no real timetable. Around the October timeframe, Sigma, the Zwave owner, released a lot of the zwave protocol to open source. That may have triggered a lot of rewriting, but I really have no idea.
I have recently got my AEOTEC Garage Door Controller installed and working - although it works, I was wondering what entity’s other members have?
Mine is set to hail mode else I was unable to get it opening and closing correctly, however there seems to only be a few entities such as the “cover”, “switch” and a couple of sensors which appears to not do much.
Does anyone know if this is because of the lack or barrier support currently? Or is there no other entity’s anyways?
In any case, the automations work and I can control the door to go up and down (although there is not “stop” feature?? Does anyones have a stop button along with the up and down arrow?) and notifications via PushBullet etc work fine…
Has anyone had any luck with displaying the state of the Garage as “closed” or “open” rather than just an up and down arrow???
If you look at the history it does say open or closed however I can’t seem to find any entities with these values where I could display it intuitively on the front end as open or closed rather then up and down arrows
You see the state of the Garage either from the icon of the up/down arrow of the cover
or you read the state of the switch (tilt sensor). The switch is off if the door is closed an on if it is open.