That is a great set of pictures, thanks for posting that.
I use blue painter's tape to hold my battery in place, and secure any of the wires that are flopping around. Love it because it holds well enough, but releases when I want it to. My blinds aren't going to be moving around so not worried too much about that stuff.
I had the same issue w/the existing tilt adjustment hole being too large and also used the double-sided tape to secure the charge adapter assembly. Works great.
Just an FYI on open/close reliability - I now have five blinds automated, and I was getting one or another not opening from the automation in the morning.
I created scenes for open/close w/the five blinds in the scenes, and last night and this AM all five blinds closed and opened. So not a very long trial, but so far, so good.
I have noticed some reporting issues - this AM three of my blinds that were open were reporting closed. They are the three in the office, closest to the hub by far (the hub is in the office). They are reporting correctly now but I had rebooted the hub for another reason so not sure if they finally woke up and reported, or if the reboot is what updated them.
Same here, the blinds were all closed when I got home but one of them showed a position of 40 (my open position). Unfortunately I missed the closed routine by literally seconds so I don't know if they were all opened or not. I'll have to check tomorrow. Hitting refresh did update it properly so if at least the blinds all move properly then I'll just add in a delayed refresh command. Time will tell...
Yes, I use RM for everything. If I get home tomorrow and less than 3 blinds are opened then I'll have to play with RM. Maybe a short delay between position changes to see if that makes a difference.
What's weird is that 'run action' seems to work each time.
I can add in retries, too if I have to just to make sure they move. I don't really care if it takes a few seconds as long as I can make sure they physically open or close.
Latest update, good and bad.
All 3 blinds opened this morning to the correct position (good news), although 1 blind did not update the position (or anything else for that matter) and there were no events reported (bummer ). A refresh updated the position and put an entry into the events log.
My close blind routine ran and physically closed all the blinds (good news), this time a different blind did not update the position (bummer). A refresh correctly updated the position.
Unless @bertabcd1234 had an epiphany as to how this can happen I'm going to put in some delays and retries into my RM rule. I'm making an (un)educated guess that it's a timing thing between RM, HE, and the blinds in that once in a while a blind's message get's lost or tossed. What I've noticed during the last few rule action runs is that the last blind has reported each time. Very small sample size but it's worth noting and leads me in the direction of a timing issue.
Assuming you have all v3 units, I'd use the Basic Z-Wave Tool to check that parameter 3 is set to 1, since that's what the driver relies on to get the status back from either digital or physical changes automatically. The driver should set this on its own upon installation and via "Configure," but maybe something went wrong. Using the Tool would at least let you see (or set if needed) without the driver. Rebooting the blinds also can't hurt, because...who doesn't have to reboot their blinds?
But assuming that's not the problem, I'd also lean towards a "too much happening on the Z-Wave network at the same time" issue. My C-7 seems to be better about this than my C-3 (yeah, I've been here a while...ha), but I still don't open or close more than one or two blinds at a time via a rule without putting at least a few seconds, preferably more, between each. They seem to work better that way. Whether it's the blinds or the hub, I don't know, but since it's happened with both hubs, I'm leaning toward the blinds. It could also be a signal streth issue (or a combination of these two things), so maybe the update mentioned above will help with that if/when iBlinds releases it publicly.
I've not had any blinds fail to open or close since I changed over to using scenes to manage that. Can't tell if it's just a coincidence of course, but things have been good using scenes.
I'll give that a look see, thanks. All my blinds are in the same room and maybe max 15ft away with line of sight to the hub. So while signal shouldn't be a problem, I do have to say that the blinds have done a lot of ZW re-routes even though every time I check them they're routed direct. So until the FW comes out as long as they physically move I can code around intermittent reporting. Thanks
I've successfully updated three blinds today using the 2.2.4 Device Firmware Updater app.
Two didn't cooperate as well:
One (connected S2 Auth) was so slow uploading the FW that it got stuck (or seemed it had) so I aborted that, excluded it from HE and used a UZB stick and PC Controller to update the FW, then added it back to HE w/out any security (my desired configuration).
The last one got stuck at 66%, waited and waited and didn't move, so aborted again. Rebooted my hub to see if that would help w/the FW updater. The hub took a long while to reboot and when it finished the blinds came up sad face (below), and Z-wave network was struggling. Refresh/Repair didn't help, used Remove to remove it. It then refused to connect to any hub or stick, so I did a Z-Wave clear (CLBR button 10s) and Z-Wave reset (IN/EX button five times) and then it joined to UZB stick and I updated it and then rejoined it to the hub (again, w/no security).
I just wrote some code with a few delays and a refresh position and retry. Let me know how they all behave with scenes (with proper position reporting) and I'll have give it a try if it's stable.
Thanks
Not to hijack this thread (despite my prior attempt ) but I asked about the API and the owner of the company responded and said he would let me know when its posted, and sure enough he did. It's a brain dead simple API using HTTP get and put calls to retrieve state and send commands.
It's cloud based, but not a deal breaker for me as I could just get off my butt and operate the blinds with the wand as God intended them to be operated. But local control would be nice and I asked if that was a possibility. Going to order one now.
Silly question, if you pair the UZB stick to HE as a secondary controller can that and PC controller be used to update the firmware directly without having to go through the in/ex of the blinds? If so then that might be an easier, more robust way to upgrade.
Theoretically you can update your FW via UZB as secondary controller. However, I've never gotten it to work. After adding the UZB as a secondary controller to HE, I select the blinds and tap the FW update icon to go to screen the FW update page:
You have to use the "Get" option to retrieve the current firmware info:
It should then fill in like this:
That never works for me when the UZB is connected as a secondary controller - the fields don't fill in so I can't do the FW update. It should fill in like above, but never does. I've only been successful w/FW updates when the blinds are paired directly w/the UZB stick, which of course requires that they are excluded from HE. However, FW updates via UZB stick seem to be much more reliable than via HE FW updater, at least for iBlinds (my only experience w/udpating FW on HE).
YMMV of course - iBlinds does say on their support pages that FW update may work via secondary controller.
Blinds all opened again this AM w/out issue, and all reported properly. Using Scenes for opening does really seem to have solved my issues w/them opening and closing reliably.
Got it, thanks. Let's hope I don't have to. So far so good all 3 opened and reported correctly with my refresh/retry logic so if that stays stable (and I know I have a working solution) I'll give the scenes a shot as that is a more elegant solution.