GPIO Button rule

So on my rpi3 I have several buttons connected to the GPIO:

	Contact Contact_LivingRoomL (Group_LightSwitches,Group_History) {gpio="pin:23 debounce:0 activelow:yes"}  //SW1
	Contact Contact_LivingRoomR (Group_LightSwitches,Group_History) {gpio="pin:18 debounce:0 activelow:yes"} //SW2

So these buttons are like :

So untill now I have only been using them as on/off, however I have seen phillips hue and xiamio switches use a lot of logic to their switches.

So my idea is to :

  1. use single tap left as on/off(toggle) white color
  2. press left hold in to dim up
  3. press right hold in to dim down
  4. single tap right as on/off(toggle) warm white color
  5. double tap to select scenes(groups of lights to be on)
  6. double press hold to change color

So have anyone done something like this? How can I achieve this in rules?

I recommend against trying to do this in Rules if you can. This is going to be far easier to implement through a Python script (for example) than it will be through Rules. It probably can be done in Jython Rules but I’m not positive about that.

The problem comes from the fact that OH Rules are event driven and not state based. What event represents “I’m holding the button down, continue to dim the light”? There isn’t one, that’s a state (button is being pressed) . So one has to go to great lengths in Rules to rapidly poll the switch (100 msecs or less to get good human factors reaction times) and generate events out of the that rapid polling as necessary.

This sort of thing Rules are really poor at.

So I recommend moving that rapid polling to something outside of OH like a Python script. Then implement logic inside the script to detect each of these six states in the buttons and publish the proper events to OH accordingly (REST API or MQTT). For something like a long press, you will probably want to either use something like Rollershutter commands (UP, DOWN, STOP when button is released) or send periodic events while the button is being pressed. has some code that interacts with GPIO pins and communicates with OH. You can use it as an example to get you started.

Point taken,

so what you recommend is to create an Number Item: Livingroom_switch

which then receive commands 1 to 6 depending on what happens on the GPIO, the logic on what happens on GPIO either through python or inbuilt Jython…

for long press it could update the state of the Livingroom_switch every 200ms and the the rule will increas/decrese dimmer value with 5% everytime that happen:

so the rule will look like sth like this:

rule "LivingRoom switch"
    Item LivingRoom_switch received command
    switch(receivedCommand.toString ) {
      case "1": {
               loop through all members of livingroom lights and set to ON or color white if state is on otherwise OFF
      case "2": {
               loop through all members of livingroom lights and set to ON or warm white  if state is on otherwise OFF
      case "3": {
               livingroom_scene.sendCommand(livingroom_scene.state+1) ' how to check if we reached max number of szenes and the loop back to 0?
	  case "4": {
               livingroom_scene.sendCommand(livingroom_scene.state-1) ' how to check if we reached max number of szenes and the loop back to 0?
	 case "5": {
               livingroom_dimmer.sendCommand(livingroom_dimmer.state+5) ' 
	  case "6": {
               livingroom_dimmer.sendCommand(livingroom_dimmer.state-5) ' 

but has noone done anything similiar to this, this is a standard feature in many hardwired switches or phillips hue remote?

Essentially, though I would probably use a String Item and use human readable names for the events instead of numbers. Why add an additional mental translation step between numbers and what they mean when you can use a String whose meaning is self evident? And loss in performance or increase in resources will be unmeasurable in a home automation context.

I’d actually probably use a Rollershutter Item and let it implement the tight loop based on an UP/DOWN command.

OH really isn’t built well to handle processing Rules at 200ms increments. I worry about how evenly it can process the events coming in that fast. And the slightest problem will cause your Rules to grind to a halt for a time as you consume all your threads and Rules waiting to execute start to pile up.

This sort of thing is implemented all the time, but it’s not usually implemented in OH Rules. OH Rules are not well suited to implementing this sort of thing.

Can Node red be used for this?

Is there no examples out there of similar cases?

I wouldn’t expect NodeRed to be any better at this than OH is in terms of timeliness.