iBlinds v2 Tips and Troubleshooting

Valuable Information about the iBlinds v2 Horizontal Blind Controller

As always, it’s best to check with the manufacturer for support. This information may not be up to date.

iblinds Community and Support Site  

Best Practices for Blinds and Locks

It’s always a good idea to make sure you have a good Z-Wave repeater/range extender for any battery operated device. While many wall switches and plug in modules have this capability, they don’t always play well with locks and certain blind controllers.

Charge Adapter Button:

The charge adapter push button can also be used as the include / exclude button when the device is installed.    This button also if held for about 7-10 seconds will reset the device and initiate the auto calibration process.

Battery:

Due to shipping regulations, batteries can’t shipped the battery fully charged so users will need to charge the battery. The new (v2) case is transparent so now users can see when the battery is charged (this is of course before the unit is installed).

Charging LEDs:

  • RED – USB Charger is connected
  • Amber – Battery is Charging
  • Green – Battery is charged

 Battery Switch:

  • “I” is on and “0” is off   (Some users think “0” is for one)

Calibration:

Multi Blinds sometimes one does not respond to commands.

 Users have several blinds (usually 8 or more) that are command at the same time.  Ex: at sunrise open ALL the blinds.

  • iBlinds KB article https://support.myiblinds.com/intermittent-connectivity/
  • Seems the fix is to add an offset for the problem blind (open 10-15 seconds after sunrise or open 1 minute after sunrise)
  • Optional fix is to add a new “beaming capable” repeater.  Place it in the room with the problem blind and run Z-Wave Repair to rebuild the mesh network.   Then this new repeater can help handle the processing load.

Problems Pairing the unit with the Hub

This is not a common occurrence but iBlinds think there is something happening at the Z-Wave protocol layer that is causing the problem. There seems to be an overlap in the asynchronous command processing when trying to control several FLiRS (Frequently Listening Routing Slave) devices at or near the same time.

Most smart devices in our homes are not FliRS devices they are probably AOS (Always On Slave devices) or RSS (Reporting Sleeping Slave) so they don’t sleep and wake up frequently to check in for new commands from the controller, their communication with the controller is near-instantaneous. This would explain why we wouldn’t see this phenomenon before now.

JD Roberts from the ST forum shares some great insight about door locks and repeaters on the SmartThings forum.  When reading the post you can replace “Door Lock” with “iblinds” because they follow the same FLiRS principals. Z-Wave FLiRS devices sleep to save battery life and wake up every second (or so) to check with the hub or nearby repeater to see if they have any messages (Z-Wave Beaming).

If you are curious and have some time here are the links to the forum post, check them out when you have a few minutes.

https://community.smartthings.com/t/faq-why-would-i-need-another-beaming-repeater-if-my-zwave-lock-is-already-close-to-my-hub/137629?u=eric1500

https://community.smartthings.com/t/full-air-bnb-shclage-connect-integration-for-multiple-property-listings/128994/17?u=eric1500

The guys in the forum post suggest adding a beaming capable repeater to solve the problem which seems to have helped a few of our users who have reported this problem and we’ve also had a couple of users who were able to stagger their commands to solve the problem.

is Automating Z-wave & Zigbee, the Smart Home Basics