I'm not sure if the HE team got to allowing access to the new RM rules yet.
@bravenel did this get added already and would I need to change anything in my app to support the new rules?
Unfortunately I don't know what type of devices your Ecobee exposes for control...but it's unlikely it would have anything that would let you get to a preset temp (possible but unlikely). What you are doing via the switch and the rule is probably going to be your best bet. If/when the new RM rules allows 3rd party app access...then at least you will have one less step in the chain (the virtual switch won't be needed).
Ah, ok I see how things kind of work now.. your app uses the built in abilities of Hubitat and because ecobee has it's own app ABC would have to somehow pull in the ecobee app( or any other smart thermostat app) and communicate through it.. I think.. cool cool, I was just thinking that because ABC can communicate with the MyQ app to control my garage doors that it would be similar with the ecobee set up.. I do plan to learn Al lot more of the coding side of Hubitat if I ever get to retire.. lol.. thanks again for your time and help..
Not quite.
Like most things smarthome related there are many ways to skin a cat. I chose to write ABC to be as device agnostic as possible (except in rare cases that benefitted me personally). There are standard drivers/device types that HE supports natively that also expose capabilities and commands that apps use to interact with them. Custom drivers can expose custom commands that can make them more powerful. I wanted the ABC app to cover as many devices as possible in the simplest way possible..so it could be my goto for all button related interactions. The only way I could do this and maintain my sanity was to only allow for devices that conformed to Hubitat's documented capabilities and commands. Custom devices also have a way of being changed frequently, which would make my life hell trying to account for these updates and also support older versions of a custom driver/app.
TLDR - kept it as simple as possible by staying within the HE driver framework. As long as custom drivers and apps use the documented standards created by HE, they should work fine with ABC.
Hi @stephack , it seems that with the release of the new Rule Machine, I can only pick legacy Rule Machine rules to run in your app. Any new rules I've created aren't shown as an option in the drop down of rules that can be run by a button push unless I'm missing something?
EDIT: Nevermind, just saw a few posts up that someone else made this comment already! Hoping you're able to add the new Rule Machine as I love your app!
Yes, the first time I asked, Bruce advised that RmUtils (essentially the RM api that let's external apps access rules) was not updated to work with the new rule machine. I reached out again when I was asked again the last time but unfortunately I still haven't received a response. I glanced through the docs and didn't see anything obvious. So either the new RM is still not compatible with RMUtils or I'm too much of a simpleton to find it.
Tldr...Without an api to tie into my app, there is no way for me to add that functionality. Sorry
It's available now, although the docs (still...) apparently haven't been updated:
In my own apps, I concatenate a list from both versions into one list, then present them to the user as one (while still needing to keep track of the version, since you apparently have to send it when running the API method or it will default to 4.x). Not sure if there's a more elegant way, though I suppose you could just present them as two separate lists in the first place.
Thanks for the update Robert. I'll probably just create a separate section for RM5 rules. I can't easily test everything so I'll probably make it as simple for myself as possible. Not as good for the user, I realize, but better than nothing I guess.
Hi.
I' done some searching, but not found anything relevant, so hoping a question here will be OK.
I use ABC to cycle through scenes - this works really well, but it seems that each button mapping has a private view of what the scene is currently - so for example, if I use one mapping to cycle through states 1-2-3-4 and leave it in scene 2 say, then when I use a different button that previously left things in scene 4, the next scene in line will be scene 1 rather than 3.
The hub knows what the current scene is ("Scene 2" shows up as on in "Groups and Scenes").
Is using the 'global' rather than 'private' scene state possible?
Unfortunately there is no generic way to programmatically track what scenes was run last. Everyone can create a scene with infinite naming conventions. What you need would require a custom app dedicated for that purpose. This is way outside of the scope of what ABC is designed to do.
Oh - that's a shame - not even within ABC itself? I could see that getting states set elsewhere would likely be a pain.
Why do the namings matter? Scenes I'd have thought are referred to be the same names wherever..
The names are needed to check their states. Essentially every scene you are cycling through would have to be checked everytime to confirm which one is activated before then activating the next one in the sequence. Since anyone can name their scenes to literally anything, ot would require code outside the scope of what ABC was design to do. In fact, I was hesitant to add the scene cycle functionality at all because of this. I decided to add the requested feature only because I could do it by simply sorting the list.
It not an issue with if it can be added but more of a question of if it should be added. This would be considered bloat to an already large app. The scene coordination would be better served by being done in a smaller separate app. That app could then expose a simple button that ABC could use to push and then trigger the scene sequence logic outside.
Hopefully the above explains why I won't be adding this to ABC. Maybe someone in the community can whip up a "Scene Coordinator" app for you.
Maybe this is the poke I need to get back into writing some code myself - although if anyone else beats me to it, that won't be a bad thing, it's been a while....
Everything I shared was from forum posts staff had made after release of the features; the "documentation" issue is that it never made it to the formal, central docs for easy access to those who weren't following things like that.
A lot of us got started using the old Smartthings documentation (HE is built on an almost identical backbone). I originally built ABC for ST and ported it over to HE once I migrated my system here. Everything HE specific was taken from their formal docs and/or via forum posts by their staff.
Any chance you're interested in adding a function similar to this in the Set Temperature section?
I have a bulb that I change color on in some automations, but when I use a button on my Pico to toggle the bulb on/off, I want it always to come on at CT 2750. That doable?
I guess you're asking for a Toggle OnToTemp/Off feature....correct? I haven't really thought it through but this sounds like it would be better served being done via Scenes or a separate automation that sets temp when the light turns on. Mapping colors/temps/levels together can get tricky since they are all using different capabilities (that would need to be verified) and multiple commands.
I apologize as this may not be the right forum for this question but I am trying to get the Advanced Button Controller setup in Hubitat. I have a Lutron Smart Bridge Pro 2 and I have paired it with a 5 button Pico remote in the Lutron app. Furthermore, I disabled the Pico from controlling any of the physical switches I have in my Lutron ecosystem. When I configure the Pico remote in the Advanced Button Controller application, if I digitally press the buttons using the Hubitat button interface, everything works as expected. When I press the physical Pico remote buttons or Pico remote button through the Lutron application, nothing happens. I am kinda stuck on the troubleshooting for this. Thank you in advance.
