Like a similar post here, I too am experiencing issues specifically with the Bond integration controlling my window shades that were not present prior to this upgrade. I have RM rules that open and close shades and sometimes they open, sometimes not and affect different shades randomly. Logging on the rule will show the open/close or on/off command is sent, and if you look at the Events tab on the shade itself, you see the command, but its state doesn't change. If you then open or close the shades using the controls on the device page itself, it always works, so it seems this issue is related to triggered rules only.
I tried an updated app and driver from another fork of the Bond Integration and got the same results.
Something in 2.4.1.157 has changed that is impacting my rules and their expected outcome (randomly) related to the Window Shades. Other rules controlling lights, switches, custom integration for Google Nest etc.. have been working as expected.
There's nothing new in the Bond integration in 2.4.1.157.
Since the Bond integration is RF dependent, my suspicion is that there is something new in your RF environment that is interfering with the Bond bridge controlling your shades. Can you control your shades with no issues directly from the Bond app?
However, you can roll your platform back to the previous version you had, and update this post with the outcome.
Thanks but it's not RF related. Commands are not getting to the Bond device in some scenarios. Both the Bond App and controlling the shades from the Device page controls manually in Hubitat work as expected. This is only an issue with rules that trigger shades.
Here is a scenario from tonight. The All Upstairs Bond shade is a single channel that closes all the upstairs shades. The command to close was issued by the RM action and a single event generated on the Events tab of the "All Upstairs Bond" device. There should be 3 events always, with the critical event being the "Bond Home Integration" event proving the command was sent to the Bond Hub. The end result was the All Upstairs group status changed to "closed" on my Sharptools dashboard but shades didn't close.
Included in that channel group is a shade called Theater. It went down and was closed.
I have another rule that closes each individual shade (after a delay) once the "All downstairs" group closes, to ensure the open/close status is kept in sync. That RM rule ran, but again it only generated the 1 event for the Theater Shade:
The end result was a shade that was closed by the ALL Downstairs Bond group device, but the actual device page for the individual Theater shade showed otherwise:
I don't use the Bond integration but I've also had failures with blinds since upgrading to the latest version. Maybe it's just coincidence, but I have two IKEA Zigbee blinds that are controlled by a room lighting app. Twice in the last week, one of them had closed but the other has not when the RL app tried to close both of them at sunset. The logs show a command sent to each blind.
In both cases, running the action again worked on the first try. I can't remember the last time one of these blinds failed to respond to a command before this. They're in the same room as the hub and I have a reliable Zigbee mesh.
I turned on the command retry logic on both blinds and am waiting to see if it happens again.
Yes, same thing here with 2 internal blinds in another room, still on Bond but I'm positive thats not where the issue is. One blind goes down, the other not (not always, but most times). There is another post of issues with the latest update as well, very similar behaviors:
I've now rolled back to 155 and will observe tomorrow's rules and behaviors.
[Update] I rolled back first to 2.4.1.155 and got similar issues. I then remembered I had actually jumped from the 2.4.0.151 to the 2.4.1.157 release. So rolled back to 2.4.0.151 now 24 hours ago.
So far, all triggered rules have worked with the shades all operating and their devices updating the open/close status. I therefore believe the issue has presented itself in the major upgrade from 2.4.0.x to 2.4.1.x, which has a lengthy list of improvements, bug fixes, etc...
I will give it a couple more days of observation before seeking input from Hubitat support themselves. I'm staying on 2.4.0.151.
The "all group" device status changes to "closed" as expected, but you are left with the individual shutters in Hubitat as devices which are now out of sync on their open/close status (due to the fact that RF shutters do not provide 2-way feedback to advise of their status). So this 2nd rule is then triggered which effectively sends a second "open/close" command to each shutter and therefore changes its status to "closed":
Its always been the user Bond app from 2020 (Dominick Meglio) for the last 3-5 years for the Somfy RTS roller shutters and 2 RF fans. I may have started with it if it existed before any built in app and just stuck with it. I'm also using the original Bond Hub v2.56.1 (the one without the ability to do schedules) and when testing to try add it using the built-in app, it can't find it:
Let me break down the 3 events you normally see. the command-close is due to the rule calling the Close command on the device. This is where the rules interaction ends, after this it is up to the device driver code. The second event "windowShade closed" says it is produced by the rule but it is changed by the driver during the close command being run. So the rule caused it to change but the device driver code is what actually pushes the event. The final event switch off I suspect is when the child device calls the function on the parent hub to send the command to the device, the hub then sends the switch off event back to the child device, effectively saying it got and sent the command out.
If your issue is consistent, you should see similar results by clicking the close command directly on the device page. If you turn on debug logging for the device (and maybe the parent hub also) it might reveal more details.
Have you check the log for errors also? Seems like maybe the child or parent would be tossing errors where it is failing.
It could be a petty easy patch in that community integration if you want to stick with it.
sorry I edited my previous post just as you posted. Please see edits.
Currently I can't reproduce the issue as I'm on 2.4.0.x but all the rules in questions have logging on for Triggers, events, actions...
It was never consistently an issue, random. It might be fine in the mornings opening shades, but then evenings it would affect one or 2 shades... and it was never the same shades affected.
It always worked as expected if you manually clicked open/close on the device page.
The community app from 2020 I don't believe is developed anymore. There was a fork made last year which I tried but that also experienced the same issues.
The built in integration uses a newer API for the bond hub which eliminate the polling. You can have both integrations running at the same time, so you could test switching one rule over to the new devices to see how it works.
Not sure why it wont find it. Is there no way you can update the firmware on your bond hub? The system integration might also rely on mDNS or some other discovery method to find it, may be getting blocked in your LAN or something.
If you need to stick with the user integration and want it to work you are going to have to do some debugging for it yourself.
I thought it couldn't list it because it was already part of the user integration...
The firmware on my Bond is 2.17.4.3 and it says it's the latest for years now I think.
No, you can have both. I was testing both at one time and had them both installed and working at the same time. It is possible your old Bond hub does not support the V2 API though.
Yeah, I'm wondering if that OG bridge version is the underlying issue here. Bond hasn't meaningfully been supporting that one for years now - the current firmware for its (non-Pro) replacement is 4.14.2
I had one of those when Bond first started, but I replaced it when the newer hardware released - it was pretty clear even back then that they were going to sunset the OG model quickly.
Yeah that my suspicion as well.. the v2 API mentioned likely won't recognise and find the older Hub. I never replaced it as it just worked and by itself through their App, still does. I never had the need for their scheduling feature as Hubitat did all that so left running.
If I do upgrade the Hub to be able to use the built-in integration, does it work with the Pro version? or stick to the non-Pro?
