Do the Zigbee bulbs have any pre-staging options enabled, if the driver offers one? (They shouldn't, or you'll need an explicit "On" to go along with this if you do have it turned on.)
You can restore from backup
Good idea. I actually ended up cloning one of my other switch rules in legacy rule machine and modified it for the guest room switch again to get it back.
Tested a few things and here is what I found.
Legacy button rules still work as they did before, everything works correctly when using the bulb devices. Certain things, such as setting the color temp do not work when using the bulb group. So I just have to list every bulb I want to control (4 in this case), which is fine and the way I did it before.
I tried setting up the new button controller 5.1 again for this room, using the individual bulbs just like in the legacy rule. The Legacy rules nicely let you stop or pause the whole rule which is very useful for this. The new rules do not work correctly no matter what I tried.
Sadly the new rule machine (button controller) is broken and I have two major issues.
--It doesn't set bulb temperature at all, instead it just turns off the bulbs.
--There is no way to pause/stop the rule for testing or other reasons. Best I can do is export it to a file and delete it, then restore later.
Seeing that they disabled adding new rules to the legacy rule machine, forcing me to switch to the "new" rule machine which clearly has less features and broken features is really discouraging. One of the reasons I left smartthings was because they kept breaking things.
Now my only option is to downgrade to a version that lets you create "legacy" rules if I want to continue to have working rules, something I never thought they would do to us.
Ugh, I tested importing the exported rule and it just created additional devices (non-working of course) for all the bulbs it had in its rules. Man there are so many problems with the new rule machine stuff.
Alright, you have to set a brightness level for the "set color temperature" function to work. If you don't, it just turns off the bulbs instead of changing color temperature. This seems like a regression from how it works in the legacy rule manager. I remember them having this problem before and fixing it. Now it's returned in the new rule manager which is a shame.
Unless things have changed and I'm doing it wrong, how do you change colors without changing the current bulb brightness setting? I can't be the only person needing this functionality.
That's not correct, each rule can be disabled or stopped in a number of ways. You can expose the disable options with the greyed out X on the top right of the page.
@bravenel could you look at the Kelvin settings when no level is used please.
1 Like
@xamindar I tested this am I'm not seeing any issue. what devices are you using? mine is working as expected, I am on the beta though.
It doesn't work with the following: kasa wifi bulbs, tradfri zigbee bulbs. These are used in the two bedrooms I have been testing.
As you are unable to reproduce, I went ahead and set up the Master bedroom switch the same, which has Sengled Element Plus bulbs and that actually seems to be working properly. So maybe it is certain types of bulbs that do not work in the new rule system.
I'm not sure I follow you here. I do not see any greyed out X in the new button controller rules.
Are you using custom drivers for these? (I suppose you have to be for at least the former, but probably both if the Ikea ones are still odd.) You might be dealing with a driver problem.
Specifically, I'm wondering how they handle null for optional parameters instead of no value at all. This isn't easily tested from the device detail page in most cases, though for Set Color Temperature, you could try leaving the level blank and supplying a transition time (and color temperature) to see if that does anything odd. Then you'd get a bull value for that middle parameter, level, rather than nothing at all (like you'd get if you left both of the last two blank). This may be helpful for the developer if this demonstrates the problem for you. Just a guess as to what may be different...
The answer is yes, custom drivers. The Kasa are using the Kasa integration by davegut and the tradfri are all through hubconnect to my old smartthings hub. This may be a contributing factor, but it should not be the cause. Remember, these all work perfectly fine in legacy rules.
Also, setting color temp without changing level all work perfectly from the various buttons on the device page so there should be no reason a rule can not produce the same result.
There actually could be a reason for the change. I alluded to this above, but the crux of the issue is that the "Set Color Temperature" command added two optional parameters in platform version 2.2.6, and perhaps the custom drivers do not properly handle the new ones or at least a specific combination (including partial absence) thereof. Newer apps, including Button Controller 5 and Rule 5.x, may use the newer specification of these commands. Button Controller 3 and older versions of RM will not. That's one possible difference. If this is it, that's a driver problem rather than an app problem.
Again, it's normally not possible to test all possible combinations of these from the device page, specifically passing null instead of nothing at all for optional paramers that aren't between other optional-but-specified parameters, though it could be done easily from Groovy if you're able.
If you have any bulbs that are "officially" compatible with native drivers, I would try those and see if you can replicate the problem. If my above guess is correct, then you likely won't be able to, and this would be the reason. This is something the driver would be able to fix.
Again, all just a guess without knowing more about these drivers, but the pieces all fit together so far. 
Gave that a try. The only difference is the bulbs are delayed from turning off (or doing nothing in the tradfri case) by the amount of delay I put in. Otherwise, same result.
At this point you should post in this thread. The author is very responsive
That would make sense. In this case though, they should not have disabled the ability to create new legacy rules because forcing everyone to the new rule machine will force all these custom devices out of the platform. It would be better to still allow us to use the old one for the devices we have that need it. I hate the idea of having to buy new devices because the platform decided to deprecate them. And yes, I understand the drivers are community created and I could dive in blah blah blah. But that's not the point.
The platform did not deprecate any devices. The capability specification was changed, and eventually, new apps (like Button Controller 5) began taking advantage of the new specifications. IIRC, there was a major release or two for things to catch up in before any built-in apps started doing this. All that needs to happen is for the community drivers to be updated. If they aren't flat-out erroring out, they likely have been updated by now--just perhaps not fully tested if you get unexpected results like this.
You can always clone an existing rule/app and then modify it as needed to create a new one. (This is a bit easier if you have a "blank" or nearly-so rule you can use to start the clone out with, but really anything would work.) This can be done on the App Status page.
EDIT: For disabling an app, also see: https://docs.hubitat.com/index.php?title=Apps#Disable_Apps
1 Like
Not in the rule, in each rule there is a pause and a stop. This is per event rather than the whole button controller. So go onto each press event for example and your see.
The hidden X is on the driver and app main page. This then enables you to fully disable a "anything"
They cannot be responsible for other people's drivers, only their own. Dev's have the updated specs and are responsible for updating their stuff. Nor can or should have to maintain legacy software.
OMG I totally kept glossing over that little gray X. Thanks haha. That is pretty neat!
Yes because that was the issue with legacy button controller, the fact that it was done in a way that it was "one app/ rule" but with individual triggers / conditions like individual rules caused inconsistent issues.
It also ment there were two code bases between rule machine and button controller so some features/ fixes kept getting missed.
My understanding now though is they are almost identical (at least the important stuff) it's just button controller has a UI layer essentially that keeps button devices together to make it easier to see/ understand. The cux of it though is that now each button "event" is its own rule machine rule.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
