Is it ok to mix and match security levels or should you aim to keep everything on the same level?
Mix and match is no issue, communication goes on at a different layer, so no issues w/that.
Goal would to be to get your devices off S0 if possible (some don't have an option), and typically I only use S2 on locks and garage doors (barrier devices) nothing else. Everything that is S2 I join w/no security - clear all checkboxes (look up a few posts to the image I posted).
Ok I have converted all zawave devices over to no security, I had to use a secondary controller z stick to include the fibaro dimmers as they would only include S0 on the C7.
The network is a lot quicker now and everything responds within a second to manual operation from GUI, will see how events go over the next few days.
Update, everything working fine now both from manual and event triggers.
Why on earth did they develop S0 as a scheme if its so crappy and screws up the network?
We were playing the long game...waiting for you. [heh, heh, heh]
Got me good........
Edit: Offer rescinded. Wife decided she likes the auto open and auto close too much to give up without another try... I've configured some additional controls for her and we'll see how it goes...
Three iBlinds kits for sale, wife just cannot stand not being able to control them directly using cords. They have been perfect for me, all on 3.03 FW. I have the original boxes and all HW. I'll make a deal if someone takes all three so I can clear them out. PM if interested so we don't clutter up this thread. Thanks.
Just wanted to note that I updated all five of my blinds to FW 3.06 a couple days ago using the HE Device FW Updater app, and all five updated w/out issue. It was not quick - I didn't time it but probably 30m at least per blind. I did wake up each blind before starting by opening and closing them. I did not reboot the hub which might have helped w/the speed, but not sure about that.
In any case, was very happy to see that the built in updater app worked w/out issue to update my blinds.
Sorry to hear that - did you wake the blinds up (open/close, or close/open) before starting the FW update?
On the plus side for your, since updating I've had two mornings recently when one or two blinds in the office didn't open in the AM. They have all closed reliably in the PM.
There are issues w/scenes that HE is aware of/working on, so that may be the source of the issue, but in this case the blinds did receive the open command, it shows up in the blinds events log:
So maybe I'll end up going back to 3.03 if these issues persist...
My blinds are working perfectly now and have been working perfectly for weeks!
But there's a driver update ....
I haven't updated the v3 driver in several months. (If you're using another one, could I convince you to take unrelated discussion about firmware or the devices themselves to a new thread? )
But I actually should update it, I think--the new "remote calibration start" feature sounds nice and could save people a trip to the blinds to initiate. But first I'll have to update my blinds (so I can test this), and they've been working so well lately I'm afraid to touch them...
Exactly!
Has anyone use iBlinds with HomeKit through Homebridge? I have an iBlinds v1 and found that Robert's v2 driver works the best for me because the reverse function works. Robert's v3 and iBlind's official V3.1 drivers do not. Then I added the blinds to my HomeKit through Homebridge, and found that HK sends "value=100" instead of "open" or "on" command when toggling from closed. This causes the blinds to physically rotate to the other closed state instead of my default open value of 60%. I can set the blinds level in HK if I want to. But it defeats the convenience of being able to toggle the state of the blinds in the Favorite screen.
Using Robert's v3 or iBlinds v3.1 would work okay in Hubitat but not when integrated into HomeKit. Without the reverse feature working, I would have to set the default closed/off position to 95 (or 100) instead of 0. When toggled from open to closed in HK, the blinds will go to 95% physically, but HK will show it as open. Only level=0 is recognized as closed in HK, it seems.
This is probably HK's limitation/quirk and probably would benefit from voicing it in that community, but I thought I'd ask here to see if anyone else has similar issues. Currently I use a workaround by modifying Robert's v2 driver to set level = openPosition when value=100 is requested. Attached is a screenshot of Homebridge log. The close command is straightforward. The open command asks for 100% level, and the modified driver sets it to 60%.
Has anyone noticed that these don't send battery reports on their own? I just tested one of mine that last reported 100% in December, did a refresh now, and see it's at 90%. I'm not sure what the threshold is for when it should send one on its own, but I'd expect it to be less than this amount of change. My guess is that they don't, but it's possible it's coming in as a Battery v2 report and I see I didn't specify the version and my driver only looks for v1 (but because it works with refresh()
and I think it's supposed to fall back if possible, I doubt this). You'd see this if debug logging is enabled, but that only stays enabled by default for 30 minutes, so it's unlikely.
I'm modifying the driver to specify v1, but I'm just wondering what anyone else is seeing. I think I'm going to have to add the v2-esque battery polling to this driver unless I've just got a fluke...
My battery level has never reported correctly.
Mine appear to be reporting accurately - refreshing and reloading the page repeatedly does not change the reported level (three at 80, one at 50, one is on USB power). Unless those values are wrong, my blinds appear to be reporting. Using your V3 driver.
Interesting...I wonder why mine doesn't seem to send report on its own. You should see "battery" events on the "Events" tab if it is; any battery report will generate an event, even if the value did not change. A "Refresh" will also request a battery report, so as long as you have reports and haven't been scheduling one or manually refreshing, that's promising. But I'm not sure what's weird with mine then.
Do you mean that you don't belive the percentages it reports are accurate or that it doesn't report on its own? A "Refresh" command will, among other things, request a new battery report. I can modify the driver of the device isn't "spontaneously" reporting (as mine doesn't seem to...a refresh may help you figure that out), but I can't do much if it's another problem.
One blind:
- 90 on 4/19
- 80 on 4/22 (this AM, not when I did the refresh just now)
Another blind:
- 50 on 4/20 (nothing since then except the refreshes I did just now)
So my reports appear to be real...