Programming to simulate a 3 way bulb - where to begin?

I'm having a real learning curve with everything, so please be patient.

But my wife wants this as easy to use as she was used to. We've found these Samsung "buttons" which we like, but they don't dim, making you carry around your phone to turn the light down or slightly brighter. (we don't carry our phones around all the time)

So I was thinking how easy it should be to write a program that would take a button click but then cycle through if off->then on 100%, if on 100%, then 50%, if on 50% then on 10%, if on 10%, then off.

But I couldn't figure out how to do that in "rules" and while I know 5 programming languages (including Python and Java), I really don't want to learn all the ins and outs of Groovy for this one application.

I'd really like some EXAMPLES of such applications, but can't find any. I mean like, any.

You just wrote it

1 Like

I'd recommend using Rule Machine with a "Button Device" trigger (I'd recommend "Button Device" over "Button," though if you're really only using one action on the button, I guess it dosn't matter...but it also supports double tap and hold, so maybe you'll change your mind?). Then, for "Actions for button 1 pushed," you could do something like:

IF (Light is On) THEN
  IF (Light level > 75%) THEN
    On: Light to 75%
  ELSE-IF (Light level > 50%) THEN
    On: Light to 50%
  ELSE-IF (Light level > 25%) THEN
    On: Light to 25%
  ELSE
    Off: Light
ELSE
  On: Light to 100%
END-IF

I just made this up quick and didn't think through all the logic, so if I'm missing something or have something backwards, feel free to correct it. :slight_smile: Otherwise, this is at least the general structre you'd want for a rule. (To be more specific: The IF (Light is On) THEN should be a conditional that tests the switch state; the inner IFs are conditionals that test the switch/dimmer level. The "On" actions should be the "Set Dimmer Level" option, as I think it's called, that let you turn a light on to a specific level.)

3 Likes

I came up with this, Its untested and but I think It might work.

I forgot to add the Off state, but you can get the jist.

Yes. I'm familiar with pseudo code, but the question is, how to get the state of the light (off, on, level, etc) Is there some kind of function? var_light_level = state.lights.device(004); (or what?)

How do you reference the light (var?) in the program?

How does any of this get into or out of the rules interface?

Do you make global or local variables? How do you query the lights and get "light level"?

You just wrote it

Where do I paste the code that I just wrote?

Rule Machine isn't code (though it's often written out as something that resembles it on the forums because it's easier than making rules and copying and pasting a screenshot). You can't copy and paste. All rules are built using the drown-down menus in the Rule Machine UI.

1 Like

Thanks

The point of all of this is that I can't figure out how to I get this into the rule machine.

I can't figure it out to do anything along the lines of which I've laid out here.

As I wrote in my first message:

But I couldn't figure out how to do that in "rules" and while I know 5 programming languages (including Python and Java), I really don't want to learn all the ins and outs of Groovy for this one application.

I'd really like some EXAMPLES of such applications, but can't find any. I mean like, any.

Is there a tutorial where I can see something like this (anything like this?) being done?

This is in the rule I suggested. With a conditional in the actions, you can test for the current state--whether the switch (on/off) or level attribute, or something else entirely--of the light. (You could get the level and assign it to a variable, but I think that's over-complicating things here.) I might give one of those (e.g., this one) a look before diving into RM for the first time with something else. The docs are also good reading.

There are some videos on Hubitat's YouTube channel on creating basic and slightly complex rules. There's no denying that UI is clunky (it is subject to constraints that more or less originated due to decisions SmartThings made when creating their mobile app interface and the SmartApp framework).

FOLLOW UP! I GOT IT TO WORK!

May I THANK everyone here for pushing me to figure this out.

I HAVE to say that the rules machine is AWKWARD and the learning curve is higher than, well, it could be but if you put the time into it (90 minutes?) and wrap your head around how IT thinks, then I could see doing many things.

Coming into this, I just wanted to solve "this one" problem, however, getting an idea of how the rules machine works, I can see doing many things I hadn't considered.

Thanks again to everyone here for helping me get through this!

1 Like

Thanks for your encouragement. Without the people here I couldn't have have the patience of getting through my first "app".

I have to say that 90% of my difficulty is learning how the rules machine "thinks".

Once I tinkered with it's "behaviors" (such as its "helpful" reporting the current state of a variable to look like it's part of the code) then I started to get the hang of it.

I should add many of the tutorials for the rules machine seem to be oriented around making the transition from 3.0, but I never used that so all that was just an added layer of confusion.

Playing with it for long enough did the trick. Thanks for the help.

Glad to see that!

One note: I think you might want to re-work your rule in light of this fact: a switch state of off is not the same as a level value of 0 (though a setLevel(0) will normally turn off the device; the point is that this changes switch to off while leaving level at whatever it was before and what it would turn back on to if just issued an on() instead of a setLevel(), which by the way will also turn a device on unless your device supports prestaging and you have that enabled).

The above is why I used the logic I did in my example, where I tested for switch state and level separately. Some devices have weird quirks here one way or the other, but this is pretty standard behavior. Just something that might help if you notice odd behavior in your rule!