Saw a few references to iBlinds on the forum but nothing solid/recent. How easy is the Z-Wave integration with iBlinds if anyone knows? Was thinking of buying some but hear it’s more seamless with some systems other than HA. Myself I have the Z-Wave JS to MQTT and Z-Wave JS integration.
The iBlinds I purchased earlier this summer works fine with ZWaveJS2MQTT for me. I don’t use MQTT discovery with my ZwaveJS2MQTT so can’t speak to that part. The only think I can think of to be aware of is that the iBlinds are sleeping devices that wake up every few seconds to save energy, so when you go to open/close an iBlind with an automation, it can take a few seconds for them to actually open/close.
Thanks Tommy. I don’t use the MQTT piece either. Are you using battery power on these? Wonder if they stay online if you plug them in physically or buy the solar charging adapter.
I use the Solar Panel. To my knowledge, the USB power is only to charge the battery, so I believe even if connected via USB the iBlinds will still sleep. There may be ways to wake up the blind and avoid the delay, but I haven’t played/investigated with it enough to say for sure.
This is good to know as I just bought a pair of these for testing in my master bedroom. If the testing is all I hoped I’ll expand out to the four remaining first floor windows.
TBH, I don’t mind if blinds aren’t instant response. A light, yeah, that’s more critical that it go on/off near-instantly… but blinds, meh.
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.
2 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?