FWIW, Button Controller seems to have solved this problem by just...picking one device, maybe the "first"? Iterating over all and find the max number of buttons (and maximum set of capabilities)? I don't know. But I do know it's not perfect. I did something similar in a custom app per a user request, and there's definitely some sort of awkwardness either way, especially if someone chooses multiple devices with different capabilities or numbers of buttons and thinks everything should work the same on all of them.
One thing a user could do if they don't want to set up a separate ABC instance: does the driver for the device you're using with ABC support the pushed() (or held(), released(), etc.) commands? Most (all?) stock Hubitat drivers do--there was some debate in the early days about whether these should be a required part of the capability, but they are officially not--and many community drivers do, too. This would allow you to simulate a "digital" button press, triggering whatever apps are subscribed to that event. You'd still need a rule or something to do this based on the "other" device, but you'd only need one ABC instance (and yes, it might add milliseconds of delay since it's putting one more event/subscription in between everything, but probably not consequential).
The stocks apps that do this use what appears to be some sort of app-settings-serialization for this that I know isn't available to us with user apps. I suppose it would be possible for a user app to have some sort of import/export for settings, but since Hubitat's security model requires users to select devices within a particuar app, "true" cloning (like system apps can do) will never be possible as-is without some sort of user intervention to restore those. Still considering experimenting with something like this in a couple of my apps, but it sounds messy and won't be quite the same (though not necessarily worse from a user-experience perspective...).
Thanks for your work on this project - I'm new to HE and this looks like it's going to solve a bunch of things I am trying to do with RM (and trying to find better ways).
However, when I go to the Apps Code section, and click on the "import" button, it asks me if I want to override the (empty) code box and then ... nothing happens.
It looks like the links at the top of the thread point to the github page directly rather than the raw code link, which imported successfully.
I did the same thing with the child app.
However, once I tried to add the ABC app using the Add User App button, I was presented with a screen that said "there was an issue, check the log" - but the log didn't have anything related in it. And now it's not even in the list of User Apps anymore.
Ah! Brilliant. I didn't think to look there... adding that to my debug repertoire!
Looking there, I saw that one of the scripts had vanished (I think due to user error) and I added them both back and that seems to have fixed it, thanks!
EDIT: Regarding below: I deleted and then re-created the scene, and now it shows up in the right place. Odd, but it's showing/cycling in the correct order now.
=====================
Having an issue w/using the Scene cycle option in Other. No matter what I name the scenes, they persistently end up being out of order in the cycle.
They appear in the expected oder in the device selection drop-down in ABC, but always show up in the summary button screen (second image below) out of order, and are cycled through in that order when I press the Pico button, i.e., 4-3-1-2, rather than 4-3-2-1.
Has anyone seen this and have any suggestions? These are % close settings scenes, so they need to be executed in the expected order. I know I can change the scenes' settings to make it work out of order w/the naming, but that makes it confusing for managing other scene cycling mappings I'm going to create in ABC. Thanks!
Shoot...happened again. Finally realized the app appears to remember the last scene you used, even if the blinds have been fully opened or closed after going through one or two scenes, it will continues on to the next scene the next time I use the scene cycle button.
E.g., if I cycle through two scenes (30-20 % open) and then open the blinds fully via device page or open/close using another button/ABC automation on the pico, the next time I use the cycle scene option it appears to start up at the next scene (15) and go from there. Have I got that right?
It is designed to cycle through each scene in the list you create. The app has no insight into the state of devices or whether another scene is activated. It simply moves to the next in the list. Unfortunately if you are using other methods to change scenes, then the ABC app may not be your solution.
Thanks for confirming. The ABC app is still my weapon of choice, though, as I'm using the Dimmer Increase Level and Dimmer Decrease Level options rather than the scenes. I think it will actually work better for my wife's use-case, so ABC win again.
I've got kind of an odd issue. I just bought some Hue Dimmer Switches, and they pair reporting a state of "numberOfButtons : 1". I presume ABC takes this state to determine how many buttons to show, but the device has 4 buttons accessible through the current built-in Philips Dimmer Button Controller driver. These are registered totally normally in Rule Machine, but seem to be completely inaccessible in ABC. Am I missing something? Is there a way to force ABC to show more buttons than it thinks a device has to map?
You're my hero! I'm not sure if that was there in the old app version I was running until about 2 minutes ago, but it's there after the update. Thank you!
stop() appears to be a custom command on the Springs Windows driver you are using. It isn't listed as part of the windowShade capability. I'm willing to update the shade section of the app but only to be compliant with the capability. As you can see below, there are startPositionChange() and stopPositionChange() commands available. I can add these but it won't do anything for you if it's not implemented in the driver. Let me know if the author of the driver is willing to add this to the driver and PM with a link to the driver after it has been updated. I will then update the ABC app to support it but I'll need you to test it out for me before I post it officially. I don't have any shades to test myself.
**Update 06/17/21 ** ABC Child App updated to v0.2.210617
added support for stopPositionChange() and startPositionChange(direction) to comply with windowShade capability
As of v0.2.201002 - If you have previously configured any locks, you will need to edit that button and chose the action you would like performed (lock or unlock).
PLEASE NOTE: (IF UPDATING FROM v0.2.190210 OR EARLIER) THIS UPDATE CHANGES A SIGNIFICANT SECTION OF THE CODE. YOU WILL NEED TO OPEN EACH CHILD APP AND CLICK DONE.
I quickly skimmed the post about the RM 5.0 but saw nothing regarding API changes. Can you be more specific as to what your issue is or what errors you are seeing in the logs if any?
I did something similar in a custom app per a user request, and there's definitely some sort of awkwardness either way, especially if someone chooses multiple devices with different capabilities or numbers of buttons and thinks everything should work the same on all of them.
