25 posts / 0 new
Last post
fritsr
Better rules for motion sensor

When you connect a motion sensor to the bridge, the Philips Hue app creates 8 rules in your bridge. I have changed these rules to make them easier to maintain.
 
settings
Let's say you want the lights of group 1 to react to the motion sensor. After 5 minutes of no motion, you want the lights to switch off.
Scene PfbYVhfM7kd2OUV is used during daytime (8:00 am to 23:00 pm).
Scene yRutnfA2zXgF7cx is used during nighttime (23:00 pm to 8:00 am).
Sensor 19 is my motion sensor (presence sensor)
Sensor 20 is my motion sensor (light sensor)
Sensor 21 is an extra CLIP sensor for status

Rules 1 and 2: what
The first rule detects motion when it is already dark.

{
 "name": "MotionSensor.Motion-on",
 "conditions": [
  {
   "address": "/sensors/19/state/presence",
   "operator": "eq",
   "value": "true"
  },
  {
   "address": "/sensors/19/state/presence",
   "operator": "dx"
  },
  {
   "address": "/sensors/21/state/status",
   "operator": "eq",
   "value": "0"
  },
  {
   "address": "/sensors/20/state/dark",
   "operator": "eq",
   "value": "true"
  }
  ],
 "actions": [
  {
   "address": "/sensors/21/state",
   "method": "PUT",
   "body": {
    "status": 1
   }
  }
 ]
}

The second rule detects when it gets dark when there is already motion detected.

{
 "name": "MotionSensor.Dark-on",
 "conditions": [
  {
   "address": "/sensors/19/state/presence",
   "operator": "eq",
   "value": "true"
  },
  {
   "address": "/sensors/20/state/dark",
   "operator": "eq",
   "value": "true"
  },
  {
   "address": "/sensors/20/state/dark",
   "operator": "dx"
  },
  {
   "address": "/sensors/21/state/status",
   "operator": "eq",
   "value": "0"
  }
 ],
 "actions": [
  {
   "address": "/sensors/21/state",
   "method": "PUT",
   "body": {
    "status": 1
   }
  }
 ]
}

These rules just set the status to 1.

 

Tip 1
When you don't want the motion sensor to take control over the lights when you already manually had switched one or more lights on, you can easily add the following condition to both of these rules. This prevents the rules from switching off the lights after 5 minutes (and having a shower in the dark…).

{
 "address": "/groups/1/state/any_on",
 "operator": "eq",
 "value": "false"
}

Tip 2
You could use a dimmer switch to have the same effect as when motion is detected. Just let a key press change the status to 1.

Rules 3 and 4: when
The next two rules specify what has to happen when the status changes to 1, depending on the time of day.
{

{
 "name": "MotionSensor.Day",
 "conditions": [
  {
   "address": "/sensors/21/state/status",
   "operator": "eq",
   "value": "1"
  },
  {
   "address": "/sensors/21/state/status",
   "operator": "dx"
  },
  {
   "address": "/config/localtime",
   "operator": "in",
   "value": "T08:00:00/T23:00:00"
  }
 ],
 "actions": [
  {
              "address":"/groups/1/action",
              "method":"PUT",
              "body":{
                 "scene":"PfbYVhfM7kd2OUV"
              }
  },
  {
   "address": "/sensors/21/state",
   "method": "PUT",
   "body": {
    "status": 2
   }
  }
 ]
}

 

{
 "name": "MotionSensor.Night",
 "conditions": [
  {
   "address": "/sensors/21/state/status",
   "operator": "eq",
   "value": "1"
  },
  {
   "address": "/sensors/21/state/status",
   "operator": "dx"
  },
  {
   "address": "/config/localtime",
   "operator": "in",
   "value": "T23:00:00/T08:00:00"
  }
 ],
 "actions": [
  {
              "address":"/groups/1/action",
              "method":"PUT",
              "body":{
                 "scene":"yRutnfA2zXgF7cx"
              }
  },
  {
   "address": "/sensors/21/state",
   "method": "PUT",
   "body": {
    "status": 2
   }
  }
 ]
}

The default rules had a combination of these first four rules. In the default rules the conditions and scenes are specified twice. This change makes these rules easier to maintain.

 

Tip 3
It is easy to add more timeframes like morning, dusk, evening, night, and late. Just copy one of the "Night" or "Day" rules and adjust the times and action.

 

Rule 5: dim
Before switching off the lights will dim with this rule.

{
 "name": "MotionSensor.Dim",
 "conditions": [
  {
   "address": "/sensors/21/state/status",
   "operator": "ddx",
   "value": "PT00:04:00"
  },
  {
   "address": "/sensors/21/state/status",
   "operator": "eq",
   "value": "2"
  },
  {
   "address": "/sensors/19/state/presence",
   "operator": "eq",
   "value": "false"
  }
 ],
 "actions": [
  {
   "address": "/groups/1/action",
   "method": "PUT",
   "body": {
    "bri_inc": -128
   }
  },
  {
   "address": "/sensors/21/state",
   "method": "PUT",
   "body": {
    "status": 3
   }
  }
 ]
}

Tip 4
You can also use a slow off rule to let the lights gradually dim. Check https://developers.meethue.com/content/lights-autooff

 

Rule 6: recover
When there is motion detected while the light is already dimmed, the following rule sets the status back to 1, causing the lights to brighten again. The default rules use an extra scene to store the light state. We don't need that.

{
 "name": "MotionSensor.Recover",
 "conditions": [
  {
   "address": "/sensors/19/state/presence",
   "operator": "eq",
   "value": "true"
  },
  {
   "address": "/sensors/19/state/presence",
   "operator": "dx"
  },
  {
   "address": "/sensors/21/state/status",
   "operator": "gt",
   "value": "1"
  }
 ],
 "actions": [
  {
   "address": "/sensors/21/state",
   "method": "PUT",
   "body": {
    "status": 1
   }
  }
 ]
}

 

rule 7: off
This rule switches the lights off when they are 30 seconds dimmed.

{
 "name": "MotionSensor.Off",
 "conditions": [
  {
   "address": "/sensors/19/state/presence",
   "operator": "eq",
   "value": "false"
  },
  {
   "address": "/sensors/21/state/status",
   "operator": "ddx",
   "value": "PT00:00:30"
  },
  {
   "address": "/sensors/21/state/status",
   "operator": "eq",
   "value": "3"
  }
 ],
 "actions": [
  {
   "address": "/groups/1/action",
   "method": "PUT",
   "body": {
    "on": false
   }
  },
  {
   "address": "/sensors/21/state",
   "method": "PUT",
   "body": {
    "status": 0
   }
  }
 ]
}

 

rule 8: Arm
In case something goes wrong with the status, this rule resets the status to 0, when all lights are off.

 {
 "name": "MotionSensor arm",
 "conditions": [
  {
   "address": "/groups/1/state/any_on",
   "operator": "eq",
   "value": "false"
  },
  {
   "address": "/sensors/19/state/presence",
   "operator": "eq",
   "value": "false"
  }
 ],
 "actions": [
  {
   "address": "/sensors/21/state",
   "method": "PUT",
   "body": {
    "status": 0
   }
  }
 ]
}

Tip 5
If you want to add a second motion sensor to guard the same room or group, you can copy these rules for the second motion sensor. Just use the same status sensor (in this case number 21). You don't have to copy rules 3 and 4. They don't check the for motion changes.

Conclusions
 • The rules are simpler, so easier maintenance (both manually as by an app)
 • You can easier expand the possibility's using the tips.
 • Maybe Philips should implement these rules in their app…

 

If you see any problems, please let me know.

 

Happy coding,
Frits.

icepick
Thanks for sharing that with

Thanks for sharing that with us! Especially tip 1 is very handy for me!

lph
Hi

Hi

Thank you for these rules.  I've been looking into the rules for the motion senser as I've discovered a problem.  We have found that sometimes the motion sensor fails to turn on the light, which seems like a random event, then 5 minutes later it will start working.  On investigating it seems our trigger threshold is quite dark to serve our circumstances, and it seems the light sensor updates every 5 minutes.  If that 5 minute update occurs when the light is already triggered on, the light from the turned on light is bright enough for the sensor to record high enough values that it sets the dark state to false.  The light will no longer turn on for motion until another 5 minutes have lapsed and it's seen the dark room again.

Ideally the light sensor shouldn't record a value whilst the light is triggered on (as it's a false reading), or should record another value immediately the light turns off, but I've not found a way to control the light sensor updates.  

Any ideas?

Edit: I've added a new action to the rules, so on turning on for motion, I set the light sensor config "on" : false, then on MotionSensor 9.off rule I'm setting the light sensor back on, so it can not sense during the duration the light is trigger on where it gets a false brightness reading, I will udpate here if this fixes it.

Regards 

Phil

fritsr
testing

You could do some more testing to see if this is really the cause of the problem. Test in the dark, adjust the used scene with less brightness, place the sensor in another spot (not looking to the light).
​Check the number of times the rules are triggered, check the value of the status CLIP sensor when the motion sensor does not seem to respond.

When you disable the motion sensor the 'recover' rule will not fire, and the lights will switch off, even if there is motion...

 

 

lph
Hi

Hi

I've been doing a lot of testing and can't really make any sense of the results.

When motion triggers the sensor and I immediately check the light sensor status I see something like this, where it has updated at the moment movement is detected, note that the status shows dark as false as the light level reading shows 13887 which is a reading with the light activated and is above my threshold.  If I wait for the light to go back out, the status will still show the same values for around 5 minutes until it updates again (at the moment there is no light at all when the light goes out and it will read 0 and dark=true after it updates again around 5 minutes later), but even though for 5 minutes it continues to show dark=false and the high light level because it has yet to update, I can trigger the light again with movement even though the rule shouldn't be true to fire the action as the dark=false.

Maybe when movement is detected it first updates the light reading which would be less than the threshold, the rule fires, the action turns on the light, and it then immediately takes a second reading which captures the light level with the light on.  However that doesn't explain how the rules are still true to keep the light on continuously whilst motion is still detected, as all the rules have dark=true condition.

"16": {
		"state": {
			"lightlevel": 13887,
			"dark": false,
			"daylight": false,
			"lastupdated": "2017-01-04T22:07:04"
		},
		"config": {
			"on": true,
			"battery": 100,
			"reachable": true,
			"alert": "none",
			"tholddark": 6000,
			"tholdoffset": 11000,
			"ledindication": false,
			"usertest": false,
			"pending": []
		},
		"name": "Hue ambient light sensor 1",
		"type": "ZLLLightLevel",
		"modelid": "SML001",
		"manufacturername": "Philips",
		"swversion": "6.1.0.18912",
		"uniqueid": "<removed>:29-02-0400"
	}

The rules don't seem to use the daylight value, however I've upped the tholdoffset much higher as I noticed previously on occasion there was enough light to flip daylight=true, which might have been causing some logic change.

It seems though the light level sensor values shown with a get in the API are somehow different to values the rules get when they run.

Regards

Phil

fritsr
The values for the sensors

The values for the sensors you see in the bridge are indeed updated only once every 5 minutes. The 'dx'- rules however are triggered immediately when a value changes. So you better check when rules are triggered.

lph
Hi

Hi

Just an update, since I increased the tholdoffset it has been okay.  I think because I set the light threshold to a low value and the sensor is positioned in a way it gets lit up quite a bit by the activated light that sometimes it was tripping the daylight flag to true.  Whilst the conditions do not check the daylight flag, I suspect, (need to test some more) that when the sensor see's daylight (light level greater than tholdoffset + tholddark) the sensor goes into a lower power state mode and the values stick and are not updated as often.  This makes sense from a battery saving point of view as daylight is so much greater than the dark threshold it isn't going be dark in the next 5 minutes.  The problem arises when you have a low light threshold trigger and the light coming on can then be enough to trip the sensor into thinking it is daylight.  

Regards

Phil

 

ebaauw
Hue Motion Sensor behaviour

From observing how my motion sensors work, I've come to the following conclusions:

  • The Hue bridge independently polls each ZLLPresence, ZLLLightLevel, and ZLLTemperature sensor about once every 5 minutes and updates the corresponding state attributes (`presence`; `lightlevel`, `dark`, and `daylight`; or `temperature`) incuding `lastupdated` on the bridge.  Proof: You see different values for `lastupdated` for each bridge sensor, even though they belong to the same physical Hue Motion sensor.
  • The Hue Motion sensor "continuously" checks for motion (or at least as freqeuntly as once every second or so).  Internally, it keeps a presence state.  When it detects motion, it sets its internal presence state; when it no longer detects motions for like 15 seconds, it clears its internal presence state.  When this internal presence state changes the Hue Motion sends a push notification to the Hue bridge.  Upon receving this notification, the Hue bridge updates the ZLLPresence sensor state `presence` and `lastupdated`.  Proof: When you move continuously, `lastupdated` doesn't change.  When you stand still for 15 seconds, it does; when you move again afterwards it does again.  Also note that the sensor's LED blinks red when the Hue Motion sensor cannot reach the bridge - it does so only when the sensor's presence status changes, so it is pushing a notification to the Hue bridge.
  • The Hue Motion sensors "continuously" monitors the lightlevel (at least while its internal presence state is set).  Internally, it keeps a lightlevel state, so it can detect changes in lightlevel.  When the lightlevel crosses a threshold (i.e. when `dark` or `daylight` changes) while its internal presence state is set, it sends a push notification to the Hue bridge.  It also sends this notification when the internal presence state becomes set after the internal lightlevel has crossed a threshold.  Upon receiving this notification, the Hue bridge updates the ZLLLightLevel sensor state `lightlevel`, `dark`, `daylight` and `lastupdated`.  This actually makes sense: only monitor the lightlevel closely while someone is in the room.  Proof: When I close or open my curtains `lastupdated` changes immediately.  When I stand very still and close the curtains without the motion senser detecting me, nothing happens, but as I move, `lastupdated` changes.

I've configured my Hue Motions sensors, or rather the ZLLLightLevel sensor config `tholdoffset`, to make sure that `daylight` remains `false` when all lights are on (and there's no natural light).  Also I've changed the rules on the Hue bridge, to turn lights on when `dark` becomes `true` and to turn them off when `daylight` becomes `true`.

rufusdriessen
Motion Sensor is turning light on again after being switched off

 

 

Would appreciate to have your suggestions to solve following issue with the Hue motion sensor.

In the kitchen, my ceiling lights are operated by a Dimmer Switch and a Motion Sensor.

When I am off to bed, I turn my lights off using the dimmer switch. Unfortunately, the motion sensors turns them on again after about 1 second!!!  I need to turn the lights off one more time using the dimmer switch for all lights to remain off. 

 

Is there a way I could make the rules such that the motion sensor does not activate the lights immediately after I have turned them off with the dimmer switch ?

 

> Current settings of Motion Sensor

Light sensitivity is all the way down: I would like the sensor only to activate when I come home and it is dark in the kitchen

After 1 minute without motion: do nothing - I would like the light to stay on forever or until I manually turn them off

Standard Rules set - happy to change the rules if that could solve my problem

And yes, the dimmer switch is in the line of sight of the motion sensor

 

> Hypothesis why this undesired behavior may happen

Once the light is on, motion detection does not trigger anything to happen

The moment the lights are turned off and it has become dark, the motion sensor jumps into action

 

> Potential solution ?

I assume that if the light sensor would have a small delay, long enough for me to move out of the kitchen (10 seconds?), it could work properly. But I have not found out how to implement this in the default rules.

fritsr
Motion Sensor is turning light on again after being switched off

Maybe you could try it the other way around. When you turn off the lights using the dimmer switch, let the lights go off after a minute or so.

HemiBob
Why not add the "Daylight" sensor?

On my hub there is a sensor of type “Daylight” which has a state called “daylight” which actually means between sunrise and sunset at your location.

For it to work it must be configured with your latitude and longitude (there are two offset values for you to fine tune these to your taste).

There is a flag to tell you it is configured but as far as I can tell you can't read back the lat/long values to check you have set them correctly (security, to prevent you being burgled?)

I have mine configured and have tested it with a light it turns on at dusk and off at dawn, so it works well.

So I intend to make use of this sensor to disable the various motion detecting rules during the day, maybe even disable the presence and ambient light sensors if it saves battery life. I intend to make use of the temperature sensor for something else.

Has anyone done this so far?

HemiBob
Checking dx and value of a status

My present software will not allow me to have a condition in a rule that checks the same thing twice for different things (the author is looking into it).
So I can't, for instance, check for "status eq 2" AND "status dx" - so I am getting around this for now by checking the dx of the lastupdated field instead.
It's not quite working as it should so I'm interested in knowing what you guys use to program your hub, I'm on WinHue3 beta 2.6 but it would be great to have another option.
I only have a Windows machine.

 

 

Butz
Trigger Event

I want to code an app that create an event (e.g. email) when there is a move on the motion sensor.

Can the motion sensor push an event or does I allways have to pull?  

infobits
How to add these rule?

hi, I just got into the Philips Hue ecosystem and wanted to change or modify the motion sensor rules to what was posted in this thread. My questions are: 

Do I delete all the default rules first and then use POST to add all the new rules? Or do you add these rules over the default rule or in addition to the default rules?

My last question is, I am using the windows web browser to login to my Hue Hub using the http://<ipaddresss>/chip.html debug interface.  But I cannot add any new rules or settings using POST method.  It always errors out and says that POST is not available for given resource. I’ve read over the developers api starters pages and followed the examples but the interface fails to POST anything.  Can someone experienced with doing this please explain what to do to successfully mod the default behaviors? My main goal is to implement the mentioned Tip 1 so that the motion sensor does not turn off the lights after time out period when the lights were already turned on manually.

My hue hub is on "apiversion": "1.23.0"

infobits
Why no answers om these

Why no answers om these forums from Philips or any knowlegable developers of Hue?

fritsr
You have to delete (or

You have to delete (or disable) the standard rules for this to work.

Can you turn a light on using the examples on the Getting started page?
 

 

 

 

Eggu
In "rule 8: arm" a trigger

In "rule 8: arm" a trigger-condition is missing, so I think this rule will never fire  (also wrong in the original philips configuration).

Do you agree ? 

fritsr
No, the rule gets triggered

No, the rule gets triggered if one of the conditions becomes true while the other is true. You only need something like dx when you want the rule to be executed every time one of the conditions is updated (while the conditions were already true).

gvz@garnix.de
The "long floor" problem

Hi, I just want to describe the "long floor" problem, on that I finally give up now.

Let's take the fictious person "Ed", an IT nerd, who convinced his employer, the hotel X, to buy Hue, and lost his job now. What he promised the manager: "We will place a motion sensor (MS1) right behind the elevator, and it will trigger light 1. Then, pretty soon as the guest moves forward, the next motion sensors MS2, located between light 1 and 2, will trigger both lights (1&2). MS3 will trigger light 2 & 3, and so one." 

Now, let's see how Ed failed to keep the 3 promises:

a) the light will be turned off automatically

b) everybody will have light for time X.

c) Yes, it works with Alexa, dimming switches, you name it.

Obviously, the default behaviour will make MS1 to turn off light 1 "preterm". If the guest is still active below MS2, light 1 will go off by the "turn off" rules of MS1.

There are the iConnect-Hue approaches, but they also don't work for overlapping segments of controlled light groups. Neither "do nothing, MS2, if a light is already on" will help (as light 1 is already on), nor saving scenes will help.

Now, as "Ed" is a good programmer, he tried to explore the possibliities of programming himself the Hue bridge.

His first idea:

1) Each MS does not set the light to a 100% settting, but to its specific setting of 100%, 99%, 98%, 99%, 100%. When deciding if to turn off the light after presence is false and time X has expired, the light setting shall be checked, and only if the light is at the motion sensors specific value, the lights shall be turned of. However, Ed soon understands, that the conditions only understand "lights on/off", and cannot check the brightness of a light. No chance, strategy fails.

2) Ed tries to introduce a CLIPGenericStatus sensor (let's call it variable, to name it, what it is). That variable shall be set to the number of the triggering rule that fired the "light on" event, and on dimming / turn off, it shall be checked by the timed "ddx" event, if this MS was the one that triggered "light on", or anybody else (Alexa, the dimming switch, another motion sensors) has meanwhile taken last control. As not every change of a lights state is triggered by rules (Alexa, Hue app, you name it), he introduces a general rule ("On light state change, set the value of the variable to 999" (for Alexa etc)). Also, he introduces a rule behind the change of the light state for the motion sensors, to set this variable to the number of the rule. However, Ed has to learn: Also this fails. The variable is perfectly changed to "999" on a light change, but the later actions of the triggering rule, to set the variable to the rules number, are failing. No chance to save his a. by this!

How can we save Eds job? Well, #1 is certainly: The Hue bridge should propagate events. To IFITT, to given HTTP URLs, to a simple syslog of the bridge. But AFAIK this demand has neither been declined nor fulfilled since 2016... Bad thing, as a lot of discussions would be gone than, and Philips would sell a lot more of motion sensors and dimming switches. However, they also gave up production of the great device Living Whites Smartlink Adapter 69165, and I don't know of any devices that 100% (including dimming) have replaced this product, so they are not really driven by money...

Option 2: Make the lights brightness readable by conditions! It's a hack, but it could work

Option 3: Understand the problem, that you introduced, when you decided to place the product "Motion sensor":

a) There is a queueing and priority problem. A "manual" command should always take precedence over an automatic command as given by the motion switch 

b) When we talk of brightness, among all automatic rules (night light e.g. 8pm to 11pm, motion trigggered light) should set the "minimum brightness", not the absolute brightness.

c) "Turning off" the light by motion sensors should be organized in single entry queues, and once another motion sensors wants to turn off the light at a later time, that "job" should overwrite the existing queue.

Anything I got wrong?

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 17.0px Monaco; color: #000000; background-color: #ffffff} span.s1 {font-variant-ligatures: no-common-ligatures}

fritsr
Ed's lucky day

It must be Ed's lucky day. Last week I changed the rules in my bridge. I solved the problem I had, that I wanted a manual command to override the motion sensors. I used a CLIPGenericStatus sensor to note the status. See my post on https://developers.meethue.com/content/2-motion-sensors-and-2-dimmer-switches-one-group.

Probably he needs more than one CLIPGenericStatus sensor. Maybe for every motion sensor one CLIPGenericStatus sensor.
I think Ed will find my post inspiring.

 

fritsr
waiting for admin

I'm waiting for the admin of this forum to approve my post... Sorry Ed.

gvz@garnix.de
Saving Ed

Hi Fritsr, just to point out: Ed is fictious. In fact, it is the boring staircase of my home, and not Ed job, but my marriage to get safed, because my wife gets upset over me spending so much money for things that don't work perfectly :-)

Yes, it is still not possible to see your link. 

However, Eds problems are two:

- The "third party" (non dimmer switch) commands coming from Alexa, App etc., where I am curious for your solution

- The "overlapping segments of controlled lights". I guess this could be solved by having a state variable for each light, being set to the number of the rule which activated that light on "lights on", and having the ddx-Rule for "lights off after presence" checking for a match that still the correct rule number is in this variable. However, this doubles the number of rules for light deactivation in Eds long hotel floor.

 

As we are waiting for the admin:

To understand, what happens in the rule engine, I have written a small nodejs program that dumps the rules in a more readable format. It translates the conditions to a more readable pseudo-javascript notation, and sorts all terms of the conditions by the number of their occurence to build IMHO more userfriendly nested IFs. Does anybody think it makes sense to upload it to github etc? Currently, it is "read only", so you cannot edit the rules and upload them again. Attached are some initial lines of my configuration... 

if ( sensors['Schalter Wohnzimmertür'].state/lastupdated.dx ) {
  // Rule 30 Dimmer Switch 11 reset timer, lastTriggered=2018-11-04T16:02:47
  /schedules/2 = {"localtime":"PT00:00:10","status":"enabled"};
  if ( sensors['Schalter Wohnzimmertür'].state/buttonevent eq "ON_INITIAL_PRESSED" ) {
    if ( sensors['Dimmer Switch 11 SceneCycle'].state/status eq "1" ) {
      // Rule 19 Dimmer Switch 11 on1, lastTriggered=2018-11-04T16:02:47
      groups['Flur Erdgeschoss'].action = {"on":true};
      sensors['Dimmer Switch 11 SceneCycle'].state = {"status":2};
    }
    if ( sensors['Dimmer Switch 11 SceneCycle'].state/status eq "2" ) {
      // Rule 20 Dimmer Switch 11 on2, lastTriggered=2018-11-02T17:42:51
      groups['Flur Erdgeschoss'].action = {"on":true};
      groups['Flur Keller'].action = {"on":true};
      groups['Flur oben'].action = {"transitiontime":4,"bri":220,"on":true};
      sensors['Dimmer Switch 11 SceneCycle'].state = {"status":3};
    }
    if ( sensors['Dimmer Switch 11 SceneCycle'].state/status eq "3" ) {
      // Rule 21 Dimmer Switch 11 on3, lastTriggered=2018-10-29T18:51:52
      groups['Flur Erdgeschoss'].action = {"on":true};
      sensors['Dimmer Switch 11 SceneCycle'].state = {"status":4};
    }
    if ( sensors['Dimmer Switch 11 SceneCycle'].state/status gt "3" ) {
      // Rule 22 Dimmer Switch 11 on4, lastTriggered=2018-10-28T08:43:30
      groups['Flur Erdgeschoss'].action = {"on":true};
      sensors['Dimmer Switch 11 SceneCycle'].state = {"status":0};
    }
    if ( sensors['Dimmer Switch 11 SceneCycle'].state/status lt "1" ) {
      // Rule 18 Dimmer Switch 11 on0, lastTriggered=2018-11-04T16:02:47
      groups['Wohnzimmer'].action = {"on":true};
      sensors['Dimmer Switch 11 SceneCycle'].state = {"status":1};
    }
  }

 

fritsr
There is still no reaction

There is still no reaction from the administrators of this forum. So I'm trying to use an link to a shared OneNote notition.

https://1drv.ms/u/s!AqT0YA2gEj6Kz_c15UAeYJQZm9jH0A 

 

 

 

gvz@garnix.de
Thank you - interesting

Not yet tried out, but it looks really interesting and like "the better solution". Thank you, Georg

jhonnow
new user question

Hi 

I am new at the api use and just starting and have a question about Tip 1
When you don't want the motion sensor to take control over the lights when you already manually had switched one or more lights on, you can easily add the following condition to both of these rules. This prevents the rules from switching off the lights after 5 minutes (and having a shower in the dark…).

I have been able to download the sensor api from my bridge but have no idea how i can enter the code for tip 1 in that api .

Is there a way that i put the downloaded code here and you put the code for tip 1 in my api so i can see and learn how to use and rework an api ?

Log in or register to post comments