Fixed an issue in the BOND Home Integration app code that was not properly updating a fan's light device's status in Hubitat when the device was operated using the Bond native (local) control.
Because the bug was in the core app code, this requires updating your installed instance of app code instead of creating a new file and switching to it like as with drivers.
Open up BOND Home Integration under Apps code and replace the entire code base with the code from my file linked above. Once you have save the update, go to each instance of BOND Home Integration under Apps and click Next, Next, Done to reload the code base.
You may or may not see [error] getDeviceById: 404 - null in the logs. If only seen when you perform the app reload, it can safely be ignored.
The app, by default, pulls the latest Bond device state every thirty seconds (you can change the interval in the app configuration). So changes to the device using the native/local Bond interface will be reflected in the light driver state within 30 seconds of any change. This will keep the Hubitat driver in sync with the light and also facilitate proper behavior with other apps that monitor and react to device driver state such as Rule Machine and Switch Bindings 2.0.
Edit - Footnote: my Bond fans only have one light. if you have a Bond fan with a top and bottom light, I'd appreciate feedback if this code change works with both light devices in Hubitat. The code as DMan had it is slightly different from a single light so my fix for the dual light is a blind edit.
I'm guessing at this point those of us using HPM should probably unmatch the package since the main code will no longer match the code listed in the manifest
Detected state changes on the Bond controller to power/switch now report as type "physical" which may or may not be useful to you for apps such as Rule Machine where you may want to act differently on physical vs digital events.
Events triggered by human interaction with the Bond drivers (device interface in Hubitat), for now, should show up as type empty ("") or null. They may still distinguished from non-human events such as those triggered by Rules and and other Hubitat apps which may report as type "command".
Probably for now until I have time to rebuild the entire system (app and drivers) and issue a separate "Bond v2" package. Although unless you do some kind of force repair, it shouldn't matter? I don't expect that the original Bond Home Integration HPM package will ever again be updated.
I was thinking the same thing but didn't want to accidentally hit repair on the package. I just used the URL to import the code so if you make another change I just have to hit import and it will pull it from GitHub.
If you switch any or all the files to my forked repo, the internal importUrl has been updated in all files, even ones I have not otherwise modified or updated.
I am hesitant to create a new HPM package just yet as I intend to completely restructure (*) the app for full Bond controller feature support and easier (for me) maintenance. I think I'll create a v2, or more likely "v3" (**), named package when I complete the restructure and am ready for initial testing. I fear creating a v2 package now then releasing a v3 "not too long from now" will create unnecessary confusion and increase any support headache.
(*) Rearchitect the internal app code base and how the app works in terms of handling multiple controllers. Reachitecture of the code structure is to make the Hubitat app's internal Bond interface exactly wrap and emulate the Bond system API. If you read the Bond API docs, my new code should be easy to follow, and to modify following any future Bond API changes.
(**) I say "v3" for a new restructured package since I have referred to these recent patch updates as "v2", and Bond system firmware is now at version 3.5. The current Bond API is versioned as "3.0.0".
If you don’t mind being a guinea pig, I’ll blind update the direction driver. I just don’t have that hardware to test code on. Mine are all physical direction switched. I live in Arizona, we don’t have a winter we are aware of.
Obvious deep-fake. Or caused by an explosion at the local salt mines.
Crazy weather! Remember one time years ago that we had hail in SoCal and a neighbor of ours who had grown up here rushed out to try to make a snowman for his kids. Pretty funny...
Not sure if you are interested, but if you are going to do a new version I made an update to the Shade driver. I have Leviosa shades which do not have a percentage setting, but setpoints. You can create multiple set points. The current driver would only allow me to open and close the shade, which is fully open or fully closed. I added a OpenNext and Closenext to the driver. With this driver I can tell Alexa to raise or lower my shade and it goes to next setpoint, if I say open or close then it's set to fully open or close.
I brought it up with the original developer back in 2021, but I think he stopped supporting right around that time. [edit] From looking back I think he just didn't want to do it as he never asked me anything else after the initial post.
I have a github account but I don't really know how to do pull request or anything else like that. Never had a need. If you are interested I can send you the code. The code is probably not completely correct but works great for my application.
Fix immediate issues in the existing application and drivers and provide user manually applied code updates (I'm calling this "v2")
Rearchitect app and drivers for a new HPM hosted Bond Integration package. (Calling this "v3")
I'm happy to take in any fixes you've worked out, even happier if you want to test future updates since you have hardware I do not. I'd really like it if I could get you to run some interrogation code against your Bond controller so I can see how your hardware (devices) expresses itself in the Bond API.
With the fans what I have done so far is implement missing Hubitat required features for capability "FanControl". With lights I fixed an issue where local changes on the hardware were not being reflected in Hubitat driver Current States which was both annoying for monitoring, and had resulted in failed automation.
I can accept either the raw (full) code or a diff against Dman's original driver, whatever is easiest for you.
I made an incorrect assumption about Bond fans having Breeze support, yours does not. Although I do see an "OEMRandom" in the bondDevice that might be a Breeze like feature. I'll poke at that later if you are so inclined.
Please update code and in your device:
Click Save Device
Click Wipe State Data
Refresh the page
Click Configure
Click Query Device
Refresh the page when told
Send me screenshots of both the Data section under Device Details and the Current States section in the upper right.
In the interest in trying to be helpful, I'm running the same BOND Fan With Direction, so I followed your instructions with your BOND Fan With Direction v2 and this is what I see with the original App code (without your modifications):
With your App code modifications, I get the following when following your instructions above, however I did append a "2" on the name of the modified app.
The Failed to get Bond commands data warning is expected, I'll update the message to indicate that. Apparently that API endpoint is specific to certain types of Bond controllers.
Can you look at the v2 driver code you have and confirm for me that line 284 is:
If so can you screen shot for me your BOND Home Integration Application State? In Apps, click the gear icon left of the app, or go into the app and click the gear icon in the upper right. Then scroll down.
