So it looks like by changing scenes from a switch to a button that they are no longer available as tiles in ActionTiles. Also can't activate scenes anymore using Alexa or Google Home. Other than creating virtual switches in Hubitat that then push the button activating a scene, is there another way to bring that functionality back that I'm missing?
If you can use the native Alexa or Google Home integrations, I'd recommend those. That being said, I suppose one workaround would be to bring back "Switch" as a sort of momentary switch that just turns off automatically after being turned on. This would increase compatibility with apps like this -- perhaps at the cost of confusion (e.g., why "off" doesn't do anything). Using version 4.2 is certainly another opton.
Does AT not have a way to use button devices directly? If not, the same might help.
It looks like I’m late to the recent update game and didn’t fully read the release notes.
Unfortunately, all of my automations and button controller settings are broken as a result of the recent update.
I can go through and reprogram everything to push buttons instead of switches as I had them configured, but my issue is cycling through scenes. I used to do this by comparing which scene switch was on, and then turning on the next scene switch in my desired order.
I moved from Wink and feel like I’m just barely scratching the surface of HE and still consider myself an absolute newb. Previously, I tried to record local Hubitat scenes, but they never lined up exactly as I have multiple bulbs at varying levels and colors and the scenes never showed active because of something like one bulb being off one color temperature degree. Apart from a more complicated and duplicitous status update like that, can anyone possibly point me in a direction of how to do this quickly and efficiently?
Thanks for your help in advance!
P.S. Despite this minor setback, I still absolutely love CoCoHue and the majority of the functionality. I know I’ll get it dialed back in, just need a little guidance.
If you add the capability "Momentary" to the driver code for the CoCoHue scene then yes, ActionTiles recognizes that as a momentary button and you can activate scenes with a tile.
Unfortunately this does not restore functionality on Alexa or Google Home so creating a virtual switch in Hubitat that activates the CoCoHue scene when turned on seems to be the easiest option.
Here's an easy way to restore that kind of "scene cycle" functionality. Create a virtual dimmer switch in Hubitat and then use Rule Machine to do different things as you change the dimmer level. I use this to automate panels in the entryways of Airbnb units that I manage. Each unit has its own virtual dimmer switch that I call the guest module. For example, one of my units is located in the Towers building in my town. The unit number is 310. The dimmer switch is called T310GuestModule. Then I have a Rule in Rule Machine called T310GuestMachine.
If I set T310GuestModule to a dimmer level of 25, this activates a welcome screen in the entryway of the unit, sets the lighting in the unit to a preset level, turns on appliances like mini fridges, and does a bunch of other automation. Then when the guest first enters the unit, triggering of the motion sensor sets the T310GuestModule dimmer to a level of 26. When that happens, it triggers other automations such as alerting me that my guest has arrived, sending a text message to the guest with welcome information, changing the display panel in the entryway to say "Welcome Guest Name", and other automations. So basically I can automate 100 different things using a single dimmer switch, just by changing the level and triggering an automation.
So you could create a single virtual dimmer switch and then each time the level is increased, it would activate a different scene.
Here's a snapshot of how one of the basic virtual dimmers operates in Hubitat. In this example, Doug's S23 is my personal cell phone that has all sorts of Tasker automations and Doug's S10 is actually an old cell phone that I've mounted up in a wall frame in the entryway of this particular unit. It basically functions as an interactive message center for the guests in that unit.
Depending on how you want to cycle through "scenes" (or really CoCoHue scenes, Hubitat scenes, or preconfigured settings of your own choosing), don't forget about my other app:
This works really well if you're trying to get Hue Dimmer-type functionality (press the On button on the first gen model or the weird Hue button on the new one to cycle through scenes) out of another device like a Pico remote, as I was when I wrote the app -- but it is flexible enough that it can work for some other use cases, too.
I probably won't change that message since this issue is specific to early 5.0 beta users (I wish there were better rewards for testing...thanks!), so it's unlikely to come up for future upgrades. But FWIW if it does, the hidden migration retry or actually receiving eventstream data from the device -- which I suppose can't happen if it's totally unreachable by the Hue system -- should have worked on their own (without a "Done," though that can't hurt either).
Sorry @bertabcd1234 , but I've only partially been following this recent conversation, but almost all my motion lighting in RL is using the scenes as switches and stopped working with the latest update. Was rolling back to v4 a manual step or something relatively quick to do? Otherwise I will go through and find all my uses of the scene devices and update them. Thanks.
@sburke781, you'll need to use a Hub back-up to go back to v4.2 (or even 5.0.x). CoCoHue 5.1 removed the switch functionality for all scenes and it's now buttons only. Some tweaks to RL should allow you to stay on 5.1 as activation will just be via button press instead of turning on a switch.
Thanks. Just starting to look at that, but I can't seem to find how to change the Type for the scene to a button.... I'm pretty sure you can....
Ah, looks like you can only change it for devices where the current Type is a capability it supports...? Maybe? This could be a little more effort than I thought... I might just have to turn them on manually for a few days and sort it out at the weekend.
If you have already updated to 5.1, I think there are only two options:
1.) Roll back to 4.2 using a hub back-up. Doing this should fix the "type" issue as the scenes would have both switch and button functionalities. Before upgrading back to 5.1, make sure to move all of them to button.
2.) Remove the scene from RL, click "update", and then add the scene back into the instance. It should come in as a button this time.
Yeah, I might go down the option 1 route, and perhaps even disable updates for a while until I finish the re-config. Thanks for the reply @JB10
BTW.... That did the trick.
EDIT - Also see @halfrican.ak 's suggestion in a later comment about re-capturing the scene states.
Any chance you could gove a steer on how to do this? I am switching on the scenes using room lighting, and my good lady updated CoCohue whilst k was out and is now complaining none of the lights are coming on in the house!
Edit: just seen the later posts. I sincerely hope the Mrs did a hub backup before mindlessly updating
Yep, was about to say....
See my recent conversation with @JB10 and some of my screenshots. It will likely be easier for you to roll back to an earlier hub backup, disable updates temporarily and adjust everything before moving onto v5. The UI does not appear to allow you to move off Switch Type in RL if the device does no support the Type.
I had previously setup my daily backup to happen just before HPM did it's automatic updates of any custom code.
I found that room lighting requires that you go back into the rules and re-capture the scene states to get it working after the update. I'm assuming it has to do with the state changes introduced by the "breaking" code change.
Looks like (almost?) everyone has found workarounds. If anyone needs it, would not be impossible to add switch back to the real driver or a temporary driver--the issue is how to actually implement the commands, particularly "off," and how to deal with the current "switch" attribute state. If anyone has strong feelings, let me know.
Though FWIW this is the way I wish I would have always done it.
If anyone wants to downgrade, going back to 4.2 would require a hub backup. However, going back to 5.0.x should work (just harder to get to--could make that more accessible though probably not something I'd recommend long-term), whether from code or also from a hub backup.
Without knowing the complexities of keeping / re-introducing the switch capability, I at least prefer the way it reads in automations to use the on command, rather that button 1, even though I know it's not really a switch in the true sense. I'd be happy for it to revert to off shortly after being turned on and for people to understand they can't use the state for anything.
I did notice the switch attribute still appeared after pressing button 1, not sure if that was intentional? No real issue, just thought I'd mention it.
No problem changing my rules to use buttons instead of switches. That all appears to be working fine.
I had some scene switches on dashboards. They no longer work as switches, of course, so I changed the tiles to buttons. Now I get this error but the buttons do appear to work.
Not sure if there was something else I needed to do?
Looks like you didn't specify a button number? Try 1 (for now, any number works, but other numbers might mean something else in the future...).