How did testing go? Just found out about these and am interested.
Trying to minimize open/close delay of the iBlinds …
I thought I would share the following…(a bit long perhaps). There is also a 2023 update here as well
I wanted to control my iBlinds using some sort of button/switch that was located in the same room as the iBlinds. You can use just about any button/switch that can talk to Home Assistant, and have Home Assistant control the iBlinds using an HA Automation. I had used an Aeotec Wallmote Quad as such a button and the setup works, but found that there could be anywhere from a couple of seconds to several seconds of delay, and if there are multiple blinds in the room, they would open/close in a serial fashion, and so the overall delay was multiplied. I wanted to see if there was a better option. The write-up below is a solution I came across that, well, performs a little better.
The solution uses an Aeotec Ltd. illumino Wall Switch ZWA038 (Mains powered)
to control my iBlinds directly instead of an HA automation. The result is that the delay is fairly consistent at 1 to 2 seconds, but there is an occasional 6 (or so) second delay. The iBlinds still open sequentially, but the next one starts opening/closing shortly (less than a second) after the previous one starts opening/closing. So all-in-all I’m pleased, but it is somewhat an expensive option.
Here are some of my notes:
-
Beaming Support
The iBlinds is a FLiRs (Frequently Listening Routing Slave), aka “Listening Sleeping Slave” (LSS). In order to save battery, it wakes up once a second listening for a wake up “Beam” and if it sees a Beam it will wake up completely so that it can perform its main operations. So it must be hit with a “Beam” either by the remote controller if the remote controller supports Beaming, or the remote controller must use a repeater that supports beaming (in order to hit the iBlinds with a Beam and wake it completely up). The Illumino Wall Switch supports beaming so a repeater is not needed. -
Group Association and Return Route
The Illumino Wall Switch was configured with a group association with the iBlinds that are in the same room. However, it has been reported (See here) that this is insufficient, and that a “Return Route” needs to be sent from the ZWave Controller to the device sending the Beam (in this case the Illumino Wall Switch). After setting up the association, one can use ZWaveJS-UI, to assign a “Return Route”. This is done using the ZWaveJS-UI GUI and going to the specific node/device (Illumino Wall Switch) and performing a “Heal Network”. -
Illumino Wall Switch
Although the Wall Switch is used to control a Load (such as a light), I could not find a way to control a Load independent of controlling the iBlinds, so as such it is only used to control the iBlinds. I ended up using Association Group 5: which controls associated devices using the top button to only send ON commands, and the bottom button to send only OFF commands.
By default, the Wall Switch uses “Basic SET” to control the iBlinds, but what I found was that iBlinds by default maps the Basic Set as Switch Multilevel with On/Off set to either 0% or 100%, so this didn’t work for me because the iBlinds were positioned at either 0% or 100% and I needed 0% or 50%. However the Wall Switch can be configured (via parameter 82) to instead send Binary Switch ON/OFF, and by using the iBlinds configuration parameter 4 it will treat a Binary Switch ON as 50%. This I found to be the solution.
As to why I didn’t use groups 2 through 4 is that they use “toggle” and the “toggle” relies on getting state update from the iBlinds. I still use HA Automations to control the blinds, and when HA controls the blinds, the iBlinds do not send state updates to the Wall Switch, so the toggle function didn’t really work. -
Updating state to HA.
In my HA setup, I use ZWaveJS-UI and use the dedicated socket connecting it directly to HA’s ZWaveJS integration. In HA the iBlind looks like acover.XXXwith a “position” for the slats and this corresponds to ZWave’s MultiLevel CC. In HA, the iBlind also has aswitch.XXXwhich corresponds to ZWave’s BinarySwitch CC. For the iBlinds, I use the cover.xxx/Multilevel to control and track the open/closed state of the iBlinds. What I discovered, was that when the Wall Switch sends a BinarySwitch ON/OFF to the iBlinds, the iBlinds in turn sends switch.XXX/BinarySwitch state update to Home Assistant, but it does not send Multilevel state update to HA even though the levels have changed, so HA’s open/close state got out of sync.To solve this, I have HA Automations that once they receive a switch.XXX/BinarySwitch state update from an iBlind, the automation will call a service which sets the cover.XXX position and this synchronizes the open/close state of the blinds.
[UPDATE] In the mid/later part of 2023, ZWaveJS added support for Window Covers and dropped support of BinarySwitch and Multilevel CCs for iBlinds. In HA, Window Cover appears as
cover.XXX_horizontal_slats_angleand uses “tilt_position”. Because BinarySwitch CC is no longer supported, this results in the inability to receive “switch.XXX” updates from iBlinds when the Wall Switch sends a Binary Switch ON/OFF to the iBlinds.
To fix this, the Wall Switch has been configured to send a ZWave Central Scene notification to ZWaveJS. When ZWaveJS receives this, it in turn sends to HA appearing on its event bus and this in turn can be used to trigger the same kind of automation which now updates the Window Cover tilt position.
3 Likes
This sounds pretty miserable. I guess its a pass on these, as this was looking to be the simplest thing to do to revamp exiting blinds. I believe all my light switches have beaming technology so can always send an automation that way, but this seams like too much effort and inconsistent states which is not what I want.
Are you using the latest 3.1 version?
They are v3 something, but I think they are 3.0.
I will add that I still use the Wallmote Quad in one of my rooms with 3 blinds, let HA Automation control the iBlinds and that the long delays are not all that often, and as such the user experience is not all that bad.
I am not an expert at mqtt or route tracing or coding. I can say, however, that iBlinds (www.myiblinds.com) window blind motors are working great so far. There is a slight delay of a second or two, but they do work. I plan to add more.
1 Like
I’m not getting battery level with iBlinds through Zwave JS. Anyone else have this issue? I have the iBlinds 2.0 version. I moved the blinds from Homeseer, where I did get battery updated.
OK so I have to ask everybody is talking about the Zwave js integration however does this not work with a direct integration with Z wave and the Z wave dongle?
I am looking at replacing some homemade 8266 devices that are starting to show signs of wear from early 3d printer builds.
It is often confusing to people, but HA’s ZWave integration is needed by HA to talk to ZwaveJS/ZwaveJS-UI which runs standalone. ZwaveJS/ZwaveJS-UI is the also in control of the Dongle.
HA+Zwave_Integration<----->ZwaveJS/ZwaveJS-UI<-->ZwaveDongle
Perfect ty. There have been many updates since .33 when I installed my devices and have not had all the time to keep up.
Appreciate the feedback.
I have the same issue. I’ve been going back and forth with iBlinds support, and they claim it’s an issue with Home Assistant driver for the blinds, and they’re “actively working” the issue. I have a bridge to sell you if you believe that.
1 Like
I had the same issue with a few v3.0 but it resolved after pushing newest firmware via HA to the blinds. It took a few mins after update for battery stats to come in.
I used SmartThings prior to HA and thinking back about it, battery stats also didn’t report back correctly for the same blinds.
What firmware version are you on?
I thought I would share a 2023.6 breaking change that I only recently came across…
The 2023.6 release of HA along with ZWaveJS added support for “Window Covering” CC which iBlinds v3 actually supports already. The iBlinds continues to support Binary Switch CC and Multilevel CC. Along the way, ZWaveJS dropped support of iBlind’s “Binary Switch” and “Multilevel” CC, and as I understand it, the reason for this was in order to meet ZWave standards compliance. However, unless an existing iBlind is re-interviewed, this change is not actually performed, in which case, ZWaveJS and HA will continue to operate as it had originally. It was only recently that I re-interviewed one of my iBlinds that I stumbled into this change (and again it was only for the one iBlind that I re-interviewed).
Regarding HA, the breaking change is that originally, an iBlind had a cover.NAME and switch.NAME entities, which represented the Multilevel CC and Binary Switch CC respectively, as the ways of controlling the blinds. However with the new change, cover.NAME and switch.NAME are gone and cover.NAME_horizontal_slats_angle entity is now used to control the iBlinds as it represents the new Window Covering CC.
As it stands now, cover.NAME_horizontal_slats_angle always has a state of unknown but does have an attribute of current_tilt_position and this position can be controlled using the service cover.set_cover_tilt_position. I’ve tested service cover.stop_cover_tilt and it works but I believe there is a bug in that the current tilt position isn’t updated properly.
cover.open_cover_tilt (opens to 50%) and cover.close_cover_tilt also work.
So for now, I’m trying to figure out how to work with the new cover.NAME_horizontal_slats_angle entity especially given the fact that the state is always unknown.
1 Like
Has anyone found a solution to this ZWaveJS “Upgrade”?
This a a serious problem for iBlinds users. I can’t reliably control or automate my newest iBlinds.
My four existing iBlinds 3.1’s are working fine with the legacy integration.
Where can we report this breaking change?
Its already been reported as an issue on HA GitHub. Long story short, is it is currently in limbo as an HA Architecture question that has not been answered (yet).
Here is a hack that is about the only solution I came across, and is the approach I took (although my automation is somewhat different).
1 Like
Let me start by saying I am VERY new to Home Assistant. I am quite technical and I been doing Home Automation (on HomeSeer) for many many years.
I have 4 iBlinds (ver 3.1) motors. They are some of the very few Z-Wave devices I have on Home Assistant.
I originally set them up back in November 2022 and everything worked prefectly. I could control and get feedback from them using:
- A Switch - Entity: switch.blind_controller
- A Slider - Entity: cover.blind_controller
Both would also report status.
Recently I updated all of my Home Assistant to the latest version of the OS and Z-Wave JS. I also had to replace one of my iBlinds that would not charge.
When I added the new iBlinds motor, I now only get:
- A Slider - Entity: cover.window_blind_controller_horizontal_slats_angle
I lost the switch and the slider only reports “Unknown”
My other 3 previous iBlinds keep working just fine and have the original functionality.
I have read the thread but I do not understand what has happened.
I can control my blind by using the “cover.window_blind_controller_horizontal_slats_angle” but I have no way of seeing the value of what position the blind is set to or if it is opened or closed.
Can someone please help me understand what I can do to regain the previous functionality? Is there any way I can tell the status of the blinds on the newly enrolled iBlinds motor?
How can I help fix this?
Again, apologies for my newnewss to the platform and not understanding the previous posts.
Zwave had an update that removed switches for entities like these blinds controllers. I never used it so I’m not sure the effect on any capabilities.
In terms of the cover.window_blind_controller_horizontal_slats_angle, you can use that for your controls. It has an attribute called current_tilt_position. That will show you the position between 0-100. I also use that in my automations to set the angle to 50 for open or 5 for closed. I have a weird issue where on some blinds it won’t close if I set it to 0, but will for 5 which is pratically the same visually. I think its a calibration issue or might get around it in the device configuration. I’m still experimenting.
So in summary I use the service cover.set_tilt_position to set the states in automations and use the attribute current_tilt_position in my dashboards to know what state it is in.
Let me know if there is other functionality you are missing.
Re-read my Jan 1 post and my Mar 26 post, and then ask questions that you are still struggling with.
In a nutshell, the iBlinds that show up as cover.NAME-horizontal_slats_angle (btw any other controls you had previously are replaced by this) are considered by HA to not have state (open/close) and thus are always in the “unknown” state. You can still control the tilt position. Not having state is a bad outcome IMHO, but there is a hack you can use with an automation to force the state (open/close) if you need it.
