Can I get help with new button controller?

📐 Rule Machine® All things Rule Machine
1

A little background. I still have all my routines on the legacy rule manager and thought I might as well remake some so I started with button controller. I disabled the old button controller rule for this specific room's switch, then recreated it in Button Controller 5.1.

I thought I would use the bulb groups this time instead of each individual bulb. It seemed to work at first except the button 4 press/hold actions made the lights go on full 100% when used. I removed the level set from the actions and now when I use the button 4 actions, it just turns off my bulbs. That is nowhere in the action as far as I can tell so anyone have any idea why this is happening?

image
image1104×880 95.1 KB

2

Seems odd. If your device driver can log what commands are actually sent to the device, that may help shed some light on this. (With Inovelli's drivers, turning on debug logging normally does this. If you're using the built-in Hubitat driver, sometimes this does--particularly with newer drivers--but sometimes not.) Enabling logging for the Button Rule may also help.

My guess: sending "Set Color Temperature" with just a CT and not a level to this device makes it turn off under some odd specific circumstance (the latter was recently added as a new/optional parameter; formerly just CT was available and required). You can play around with the command on the device page manually to see if that does anything odd for you, too. But logs will likely be more help here--especially if you can see what commands are actually being sent (with debug logging on the device, hopefully!).

3

Here are some logs. First was turning the light on, second was button 4 pushed.

dev:14732022-06-01 15:28:00.368 info[Bulb Kasa - Guest Bedroom 1: 6.5.4]: setSysinfo: [status: [on_off:0, dft_on_state:[hue:0, saturation:0, color_temp:6500, brightness:10, mode:normal], err_code:0]]

dev:14732022-06-01 15:28:00.366 debug[Bulb Kasa - Guest Bedroom 1: 6.5.4]: parseUdp: [smartlife.iot.smartbulb.lightingservice:[transition_light_state:[on_off:0, dft_on_state:[hue:0, saturation:0, color_temp:6500, brightness:10, mode:normal], err_code:0]]]

dev:15112022-06-01 15:28:00.347 info[Bulb Kasa - Guest Bedroom 4: 6.5.4]: setSysinfo: [status: [on_off:0, dft_on_state:[hue:0, saturation:0, color_temp:6500, brightness:10, mode:normal], err_code:0]]

dev:15112022-06-01 15:28:00.338 debug[Bulb Kasa - Guest Bedroom 4: 6.5.4]: parseUdp: [smartlife.iot.smartbulb.lightingservice:[transition_light_state:[on_off:0, dft_on_state:[hue:0, saturation:0, color_temp:6500, brightness:10, mode:normal], err_code:0]]]

dev:14752022-06-01 15:28:00.313 info[Bulb Kasa - Guest Bedroom 3: 6.5.4]: setSysinfo: [status: [on_off:0, dft_on_state:[hue:0, saturation:0, color_temp:6500, brightness:10, mode:normal], err_code:0]]

dev:14752022-06-01 15:28:00.309 debug[Bulb Kasa - Guest Bedroom 3: 6.5.4]: parseUdp: [smartlife.iot.smartbulb.lightingservice:[transition_light_state:[on_off:0, dft_on_state:[hue:0, saturation:0, color_temp:6500, brightness:10, mode:normal], err_code:0]]]

dev:14742022-06-01 15:28:00.293 info[Bulb Kasa - Guest Bedroom 2: 6.5.4]: setSysinfo: [status: [on_off:0, dft_on_state:[hue:0, saturation:0, color_temp:6500, brightness:10, mode:normal], err_code:0]]

dev:14742022-06-01 15:28:00.291 debug[Bulb Kasa - Guest Bedroom 2: 6.5.4]: parseUdp: [smartlife.iot.smartbulb.lightingservice:[transition_light_state:[on_off:0, dft_on_state:[hue:0, saturation:0, color_temp:6500, brightness:10, mode:normal], err_code:0]]]

dev:15162022-06-01 15:28:00.243 infoGuest Bedroom Light colorName is Skylight

dev:15162022-06-01 15:28:00.239 infoGuest Bedroom Light colorTemperature was set to 6500

dev:15112022-06-01 15:28:00.212 debug[Bulb Kasa - Guest Bedroom 4: 6.5.4]: sendLanCmd: [ip: 172.16.8.68, commsTo: 3, cmd: {"smartlife.iot.smartbulb.lightingservice":{"transition_light_state":{"on_off":0,"transition_period":0}}}]

dev:15112022-06-01 15:28:00.209 warn[Bulb Kasa - Guest Bedroom 4: 6.5.4]: checkLevel: level entry error. Level set to 0

dev:14752022-06-01 15:28:00.191 debug[Bulb Kasa - Guest Bedroom 3: 6.5.4]: sendLanCmd: [ip: 172.16.8.67, commsTo: 3, cmd: {"smartlife.iot.smartbulb.lightingservice":{"transition_light_state":{"on_off":0,"transition_period":0}}}]

dev:14752022-06-01 15:28:00.187 warn[Bulb Kasa - Guest Bedroom 3: 6.5.4]: checkLevel: level entry error. Level set to 0

dev:14742022-06-01 15:28:00.170 debug[Bulb Kasa - Guest Bedroom 2: 6.5.4]: sendLanCmd: [ip: 172.16.8.66, commsTo: 3, cmd: {"smartlife.iot.smartbulb.lightingservice":{"transition_light_state":{"on_off":0,"transition_period":0}}}]

dev:14742022-06-01 15:28:00.163 warn[Bulb Kasa - Guest Bedroom 2: 6.5.4]: checkLevel: level entry error. Level set to 0

dev:14732022-06-01 15:28:00.144 debug[Bulb Kasa - Guest Bedroom 1: 6.5.4]: sendLanCmd: [ip: 172.16.8.65, commsTo: 3, cmd: {"smartlife.iot.smartbulb.lightingservice":{"transition_light_state":{"on_off":0,"transition_period":0}}}]

dev:14732022-06-01 15:28:00.138 warn[Bulb Kasa - Guest Bedroom 1: 6.5.4]: checkLevel: level entry error. Level set to 0

dev:15112022-06-01 15:27:57.793 info[Bulb Kasa - Guest Bedroom 4: 6.5.4]: setSysinfo: [status: [on_off:1, mode:normal, brightness:10, hue:0, saturation:0, color_temp:6500, err_code:0]]

dev:15112022-06-01 15:27:57.790 debug[Bulb Kasa - Guest Bedroom 4: 6.5.4]: parseUdp: [smartlife.iot.smartbulb.lightingservice:[transition_light_state:[on_off:1, mode:normal, brightness:10, hue:0, saturation:0, color_temp:6500, err_code:0]]]

dev:14752022-06-01 15:27:57.763 info[Bulb Kasa - Guest Bedroom 3: 6.5.4]: setSysinfo: [status: [on_off:1, mode:normal, brightness:10, hue:0, saturation:0, color_temp:6500, err_code:0]]

dev:14752022-06-01 15:27:57.760 debug[Bulb Kasa - Guest Bedroom 3: 6.5.4]: parseUdp: [smartlife.iot.smartbulb.lightingservice:[transition_light_state:[on_off:1, mode:normal, brightness:10, hue:0, saturation:0, color_temp:6500, err_code:0]]]

dev:14742022-06-01 15:27:57.748 info[Bulb Kasa - Guest Bedroom 2: 6.5.4]: setSysinfo: [status: [on_off:1, mode:normal, brightness:10, hue:0, saturation:0, color_temp:6500, err_code:0]]

dev:14742022-06-01 15:27:57.742 debug[Bulb Kasa - Guest Bedroom 2: 6.5.4]: parseUdp: [smartlife.iot.smartbulb.lightingservice:[transition_light_state:[on_off:1, mode:normal, brightness:10, hue:0, saturation:0, color_temp:6500, err_code:0]]]

dev:14732022-06-01 15:27:57.722 info[Bulb Kasa - Guest Bedroom 1: 6.5.4]: setSysinfo: [status: [on_off:1, mode:normal, brightness:10, hue:0, saturation:0, color_temp:6500, err_code:0]]

dev:14732022-06-01 15:27:57.720 debug[Bulb Kasa - Guest Bedroom 1: 6.5.4]: parseUdp: [smartlife.iot.smartbulb.lightingservice:[transition_light_state:[on_off:1, mode:normal, brightness:10, hue:0, saturation:0, color_temp:6500, err_code:0]]]

dev:15162022-06-01 15:27:57.597 infoGuest Bedroom Light switch is on

dev:15112022-06-01 15:27:57.556 debug[Bulb Kasa - Guest Bedroom 4: 6.5.4]: sendLanCmd: [ip: 172.16.8.68, commsTo: 3, cmd: {"smartlife.iot.smartbulb.lightingservice":{"transition_light_state":{"on_off":1,"transition_period":1000}}}]

dev:14752022-06-01 15:27:57.537 debug[Bulb Kasa - Guest Bedroom 3: 6.5.4]: sendLanCmd: [ip: 172.16.8.67, commsTo: 3, cmd: {"smartlife.iot.smartbulb.lightingservice":{"transition_light_state":{"on_off":1,"transition_period":1000}}}]

dev:14742022-06-01 15:27:57.518 debug[Bulb Kasa - Guest Bedroom 2: 6.5.4]: sendLanCmd: [ip: 172.16.8.66, commsTo: 3, cmd: {"smartlife.iot.smartbulb.lightingservice":{"transition_light_state":{"on_off":1,"transition_period":1000}}}]

dev:14732022-06-01 15:27:57.502 debug[Bulb Kasa - Guest Bedroom 1: 6.5.4]: sendLanCmd: [ip: 172.16.8.65, commsTo: 3, cmd: {"smartlife.iot.smartbulb.lightingservice":{"transition_light_state":{"on_off":1,"transition_period":1000}}}]

--- Live Log Started, waiting for events ---

I'll mess around with it some more, but it was working earlier so I'm not sure what I messed up. I did recreate the light groups because they were Group 2.0 and now they are group 2.1, but I can't see why that would cause this drastic change in functionality.

4

I'm not familiar with the Kasa products or integration, so I'm not sure what to make of those logs. Perhaps someone who is can see if it seems like BC is sending unexpected commands. App logs (from the Button Rule) may also be helpful so you can see what it thinks it is doing when.

5

It's not just the kasa bulbs. I just tried targeting it to some other zigbee bulbs and they don't respond at all.

Here's the log when targeting a zigbee lamp:
dev:15132022-06-01 16:18:59.235 infoGuest Bedroom Lamp colorName is Sunrise

dev:15132022-06-01 16:18:59.224 infoGuest Bedroom Lamp colorTemperature was set to 2200

Seems normal enough to me but nothing actually happens anymore. I can still change these lights directly from the device page and through alexa (which is changing through hubitat).

Something is really strange here. I wish I had not have deleted the old legacy rule that was working.

6

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.)

7

You can restore from backup

8

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.

9

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.

10

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
11

@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.

12

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.

13

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...

14

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.

15

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. :slight_smile:

16

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.

17

At this point you should post in this thread. The author is very responsive

18

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.

19

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. :slight_smile:

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
20

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"