Has anyone explored reporting and controlling the motion sensitivity setting on the motion sensors? I have some sensors where I’d like to vary the level of sensitivity depending on various events (time of day, whose home, etc) and am wondering if there’s a recommended approach for this.
that could indeed be useful, but I am sorry to say I fear the same issue as with my quest for the schedule settings: whenever I enable that in the form of a command_line sensor, the sensor itself isnt working any longer as expected, needs to be switched on (while in the current setting using only the Hue CC, sensors reports their attributes, even when the motion sensor is switched Off)
see: Hue motion sensors + remotes: custom component - #691 by Mariusthvdb
but you could check the api, see what values are there for sensitivity, and probably set it with a Put command.
Thanks Marius for the reference. In my curl tests it seems like GET’ing and PUT’ing the sensitivity value works fine, without any issues gathering other attributes on the main sensor that you seem to have encountered with the schedules (but maybe they’ll pop up later?)
I thought about creating an input_select for each motion sensor, a sensor to GET each value, a shell_command to update the value (and map the input_select friendly name to the API value), automations to call the shell_command when the input_select changed, and automations to update the input_select when the sensor updated.
For one motion sensor this wouldn’t be too bad, but for multiple motion sensors it seems pretty hairy, especially since I’d need to hardcode the sensor ID# for each sensor, on top of managing the bridge IP and API key in a second place. It’d probably also cause a once-loop when the input_select change causes the sensor to update, which would cause the input_select automation to fire again.
In the end I don’t actually have much need for a selector UI to show/control the status, I just want to be able to know the status and change it with automation.
So for now I went with the below. Not super pretty but at least it’s brief.
rest_command:
hue_command:
url: 'http://HUE_BRIDGE_IP/api/APIKEY/{{ type }}/{{ id }}/{{ command }}'
method: put
payload: '{{ data }}'
- id: set_motion_sensitivity_to_medium
trigger:
...
action:
- service: rest_command.hue_command
data:
command: config
data: '{ "sensitivity":1 }'
id: 7
type: sensors
- id: set_motion_sensitivity_to_high
trigger:
...
action:
- service: rest_command.hue_command
data:
command: config
data: '{ "sensitivity":2 }'
id: 7
type: sensors
Left the rest_command.hue_command fairly generic in case I have other uses later. Also updated the hue CC binary_sensor to collect and display the ‘sensitivity’ attribute so I can view the current value on the existing binary_sensor badge.
For a manual update, I can do a service call to rest_command.hue_command from dev-service. The main thing is having to remember the right sensor id numbers.
np, and cool thinking!
I have several sensor testing the reachable of a few lights, and that works just fine without causing any issues.
Maybe its just the way I post the query to the sensors, that have them act up. Don’t know yet, and I have disabled it for now.
will be following you here though, cause I like the way we can play with the HUE api from within HA.
I think the thresholds could be added to the CC sensors, and it would probably be not very much extra effort to add that to it, and be very convenient to not have to do all the manual labor. adding to the CC might even be less tressful to the Hue system interaction. Maybe @robmarkcole and @yottatsa could read along with you?
Getting the current values would be a bi step forward, and leave you only to sort out changing that 
btw, I always put all urls or resources in the secrets file, which is very nice and easy to copy then, only have to sort things out once, and no risk of sharing your config over the community …
Getting the current sensitivity value on the existing CC binary_sensor is of course trivial, just a quick 2-line change to enable it.
What would the thresholds do?
Thought about putting the URL in the secrets file (which I do for normal credentials fields) but wasn’t sure whether the template values would still be parsed, plus it would make the listed rest_command somewhat unhelpful. 
But yeah, that’s a good suggestion. Ideal would be if I could use !secrets BLAH in the middle of a value, but haven’t seen any indications that that’s possible.
No it isn’t… Have stopped trying that, and added many full lines to the secrets file. It has the nice effect of compact configuration files, and easy to copy secrets.
I have 11 sensors…
please create a PR for this! if it is that simple, no reason not too? Maybe you’d be willing to see if the day and night times of the sensors would be just as easy? I’d really need those…
about the commands: couldn’t you use a variable for id too? that why you could
1- set sensitivity,
2- set id, and
3- hit execute.
somewhat like my set hue scene setup:
hue_light_control:
name: Hue Light Control
icon: mdi:spotlight
control: hidden
entities:
- input_select.hue_scenes
- input_select.hue_groups
- script.set_hue_scene
and script ( in your case rest command)
script:
set_hue_scene:
alias: Set Hue scene
sequence:
service: hue.hue_activate_scene
data_template:
group_name: >
{{ states('input_select.hue_groups')}}
scene_name: >
{{ states('input_select.hue_scenes')}}
no need for automation and time to reconsider if you change your mind before executing
I do use a variable for the id, though as you point out using some input_select’s as an input field to a script would be easier than dropping the json into dev-service if one needed to do manual changes regularly. For me it’ll be 99% automations, but I might borrow your scene select for actually selecting hue scenes. 
Thanks for the example!
I was hoping input_select’s had “friendly names” for the values, so I could pick map friendly names (“Hall”, “Garage”, “Living Room”, etc.) to the id numbers, which would populate the actual input_select state. That’d make it more worthwhile.
please create a PR for this! if it is that simple, no reason not too? Maybe you’d be willing to see if the day and night times of the sensors would be just as easy? I’d really need those…
Almost more of a configuration choice, but since you asked, I created a PR. It can count as my request to have it added.
Re: the day and night times, I don’t think it’s as simple as those seem to be setup as rules, whereas sensitivity is just another config attribute like “battery” or “reachable”, which is already read but instead currently discarded.
you’d be most welcome. have a look here how Ive done it, added scene Off and use it in a tiles setup both in regular ha and Lovelace:
1 Like
they’re not discarded are they, and fully templatable?:
would you be able to add the ‘tholddark’ of the ZLLLightLevel sensor too?
I have several scenarios I could use that for:
night scenes vs day scenes and automatically adjust lightlevel sensitivity
home/away modes are obvious: motion detection has to be more sensitive when out of the house
sleep/awake: dont want to have the lights go on when I turn around in bed.
btw, that what my quest for the day-night schedules is for, being able to automatically read and disable at those set times, or maybe even change them in the weekend to sleep out.
but, for now, please add the tholddark to the PR?
I use the Philips Hue API to change the rules that configure the motion sensors depending on the day/night state.
A RESTful command with some templating in the payload is necessary for that.
sure. I am aware we can do that, and use the api on more than 1 place.
please help us with your code to do so? Id be keen to see what and how you do it.
as it stands, we’re trying to have several attributes show in HA for now, so we can use that in automation or commands to change them /trigger on them, or use in conditions.
cheers
Coming very soon, Hue motion sensor for outdoors 
1 Like
I have an input_boolean for my “nightmode”. As soon as it is switched on, I modify the motion sensor rules using an automation. This is an example:
- service: rest_command.set_hue_rule
data_template:
id: 3
payload: '{"conditions":[{"address":"/sensors/8/state/status","operator":"lt","value":"1"},{"address":"/config/localtime","operator":"in","value":"T07:30:00/T{{now().strftime("%H")}}:00:00"},{"address":"/sensors/7/state/dark","operator":"eq","value":"true"},{"address":"/sensors/6/state/presence","operator":"eq","value":"true"},{"address":"/sensors/6/state/presence","operator":"dx"}]}'
The rest_command that is used just encapsulates some functionality to avoid the code to become too redundant…
rest_command:
set_hue_rule:
url: "http://192.168.1.33/api/<API Key>/rules/{{id}}"
method: "put"
content_type: "application/json"
payload: '{{payload}}'
So I just modify the existing rule(s) to have my night scenes (that I defined in the Hue app) active whenever my input_boolean in HA is switched off. I think you want to follow another approach, i. e. to have all the logic in HA and use the Hue motion sensor data for it. I do it another way by keeping the basic logic in Hue. I just change the time when day/night scenes shall be used, but of course one could also change the lightlevel sensitivity etc. It’s all in the rules…
1 Like
nice! thanks you for sharing this, Ill add that immediately!
please help me out, I’d like to add some extra flexibility, by using an input_select for the id, (i have 11 sensors)… and have the service use a variable for id, that can either be taken from that input_select, or maybe an automation sending a few motion sensor id’s to that script
would something like this work:
in secrets file:
hue_command: http://HUE_BRIDGE_IP/api/APIKEY/{{ type }}/{{ id }}/{{ command }}
in a package:
rest_command:
hue_command:
url: !secret hue_command
method: put
payload: '{{ data }}'
automation:
- id: set_motion_sensitivity
trigger:
[some_trigger]
action:
service: rest_command.hue_command
data:
command: config
data: >
{ "sensitivity": "{{states('input_select.set_hue_sensitity')}}" }
id: >
{{states('input_select.select_hue_motion_sensor')}}
type: sensors
input_select:
set_hue_sensitivity:
name: set Hue sentitiviy
options:
- 0 #low
- 1 #medium
- 2 #high
input_select:
select_hue_motion_sensor:
name: Select motion sensor
options:
- 5
- 7
- 12
- 22
- 28
- 33
- 44
- 48
- 52
- 56
- 60
another question:
Im trying to read the times for the day and night, as you might have seen. Now you are using a put command, and since my curl command_line sensor doesn’t work without implicating the sensors behavior, i was thinking maybe using a get command could get those schedule times too?
needing to extract value in {“address”:“/config/localtime”,“operator”:“in”,“value”:“T07:30:00/T{{now().strftime(”%H")}}:00:00"}
see: Hue motion sensors + remotes: custom component - #687 by Mariusthvdb
for a (each) motion sensor?
is that what you do in HA:
if so, that is exactly what I am trying to accomplish, next to be able to read it and display it in HA…!
buried in the rules I can find this for all motion sensors:
MotionSensor 5.day-on is {“address”:“/config/localtime”,“operator”:“in”,“value”:“T06:45:00/T22:45:00”}
MotionSensor 5.day-dark-on is {“address”:“/config/localtime”,“operator”:“in”,“value”:“T06:45:00/T22:45:00”}
MotionSensor 5.night-on is {“address”:“/config/localtime”,“operator”:“in”,“value”:“T22:45:00/T06:45:00”}
MotionSensor 5.night-dark-on is {“address”:“/config/localtime”,“operator”:“in”,“value”:“T22:45:00/T06:45:00”},
… so. a lot of the same info… what would be wise to select in order to be able to set the schedule from HA
Kind of… The Hue API does not allow dedicated commands, it’s just GET (=read), PUT (=modify), POST (=create new) or DELETE (=remove). You would also need to read/modify the rules, not the sensors. Each motion sensor has (at least) 4 rules you need to modify if you want to change the times. I can strongly recommend the All4Hue Android app which is a big help for identifying rule IDs etc.
To extract the configured times into a template sensor in HA, I would pick one of those 4 rules of the sensor, use a rest sensor on /api/>API Key>/rules/<ruleID> with something like value_template: "{{ value_json.conditions[1].value }}" and go from there. The template sensor(s) probably need(s) some fancy Jinja logic to extract the exact hours/minutes…
EDIT: I see you already found the 4 rules I mentioned… It was actually a real PITA to write all that code, especially since the API does not allow to change single values, you always have to PUT the entire {conditions} element…
If I relied 100% on HA (which I don’t), I would probably model the entire logic in HA without messing with the Hue rules, but I want my lights to be fully functional even when HA is offline, that’s why I chose this way.
suppose one would be enough indeed , since they all contain the same info… Im good when using jinja, but first make the sensor up to
http://192.168.1.212/api/api/rules/20 and extracting the value out of {“address”:“/config/localtime”,“operator”:“in”,“value”:“T22:00:00/T07:00:00”} ?
full set for rule 20 is:
{"name":"MotionSensor 48.night-dark-on","owner":"redacted owner","created":"2019-01-20T12:58:29","lasttriggered":"none","timestriggered":0,"status":"enabled","recycle":true,"conditions":[{"address":"/config/localtime","operator":"in","value":"T22:00:00/T07:00:00"},{"address":"/sensors/48/state/presence","operator":"eq","value":"true"},{"address":"/sensors/49/state/dark","operator":"eq","value":"true"},{"address":"/sensors/49/state/dark","operator":"dx"},{"address":"/sensors/50/state/status","operator":"lt","value":"1"}],"actions":[{"address":"/groups/2/action","method":"PUT","body":{"scene":"fHEB6SwiIIlSXMt"}},{"address":"/sensors/50/state","method":"PUT","body":{"status":1}}]}
would this be it:
sensor:
- platform: rest
resource: http://192.168.1.212/api/API/rules/20
method: GET
value_template: >
{{ value_json.conditions[1].value }}
not sure bout the [1]
btw this command_line works also:
curl -X GET http://192.168.1.212/api/API/rules/20
any preference between the command_line and rest sensors?
testing these now:
- platform: rest
name: Schedule Hue sensor rest
resource: http://192.168.1.212/api/API/rules/14
method: GET
value_template: >
{{ value_json.conditions[1].value }}
- platform: command_line
name: Schedule Hue sensor cmd
command: curl -X GET http://192.168.1.212/api/API/rules/25
value_template: >
{{ value_json.conditions[1].value }}
UPDATE
should have been {{ value_json.conditions[0].value }} (duh, first item in the list is 0… ;-0
And please, since you do set these times in HA, give me that code too…?
as an update to the previous post, and to keep things tidy, I can report success:
command_line and rest sensors both work. Command line seems to react somewhat slower though.
- platform: command_line
name: Laundry schedule
command: curl -X GET http://192.168.1.212/api/API/rules/93
value_template: >
{{ value_json.conditions[0].value }}
or:
- platform: rest
name: Corridor schedule rst
resource: http://192.168.1.212/api/API/rules/74
method: GET
value_template: >
{{ value_json.conditions[0].value }}
template sensor based on the above:
laundry_schedule_night:
friendly_name: Laundry schedule night
value_template: >
{{states('sensor.laundry_schedule')[1:-13]}}
laundry_schedule_day:
friendly_name: Laundry schedule day
value_template: >
{{states('sensor.laundry_schedule')[11:-3]}}
creating the option for an automation like this:
- alias: 'Weekend Switch Off Masterbedroom motion sensor'
id: 'Weekend Switch Off Masterbedroom motion sensor'
initial_state: 'on'
trigger:
#platform: time
#at: '07:00:00' # the time set in the Hue app, which has only day setting, and doesn't recognize weekend
platform: template
value_template: >
{{now().time().strftime(%H:%M) == states('sensor.master_bedroom_schedule_day')}}
condition:
- condition: template
value_template: >
{{ is_state ('sensor.activity_selection', 'Slapen')}}
- condition: template
value_template: >
{{is_state('binary_sensor.workday_sensor','off') or
is_states('input_boolean.home_mode_vacation','on')}}
action:
- service: switch.turn_off
entity_id: switch.master_bedroom_motion_sensor_switchSure. Switching nightmode on:
- alias: "Nachtmodus wurde aktiviert"
trigger:
- platform: state
entity_id: input_boolean.b_nightmode
to: "on"
action:
# Bewegungsmelder Toilette
- service: rest_command.set_hue_rule
data_template:
id: 3
payload: '{"conditions":[{"address":"/sensors/8/state/status","operator":"lt","value":"1"},{"address":"/config/localtime","operator":"in","value":"T07:30:00/T{{now().strftime("%H")}}:00:00"},{"address":"/sensors/7/state/dark","operator":"eq","value":"true"},{"address":"/sensors/6/state/presence","operator":"eq","value":"true"},{"address":"/sensors/6/state/presence","operator":"dx"}]}'
- service: rest_command.set_hue_rule
data_template:
id: 5
payload: '{"conditions":[{"address":"/sensors/8/state/status","operator":"lt","value":"1"},{"address":"/config/localtime","operator":"in","value":"T07:30:00/T{{now().strftime("%H")}}:00:00"},{"address":"/sensors/7/state/dark","operator":"eq","value":"true"},{"address":"/sensors/6/state/presence","operator":"eq","value":"true"},{"address":"/sensors/7/state/dark","operator":"dx"}]}'
- service: rest_command.set_hue_rule
data_template:
id: 14
payload: '{"conditions":[{"address":"/sensors/8/state/status","operator":"lt","value":"1"},{"address":"/config/localtime","operator":"in","value":"T{{now().strftime("%H")}}:00:00/T07:30:00"},{"address":"/sensors/7/state/dark","operator":"eq","value":"true"},{"address":"/sensors/6/state/presence","operator":"eq","value":"true"},{"address":"/sensors/6/state/presence","operator":"dx"}]}'
- service: rest_command.set_hue_rule
data_template:
id: 15
payload: '{"conditions":[{"address":"/sensors/8/state/status","operator":"lt","value":"1"},{"address":"/config/localtime","operator":"in","value":"T{{now().strftime("%H")}}:00:00/T07:30:00"},{"address":"/sensors/7/state/dark","operator":"eq","value":"true"},{"address":"/sensors/6/state/presence","operator":"eq","value":"true"},{"address":"/sensors/7/state/dark","operator":"dx"}]}'
- delay: "00:00:01"
And for switching it off:
- alias: "Nachtmodus wurde deaktiviert"
trigger:
- platform: state
entity_id: input_boolean.b_nightmode
to: "off"
action:
# Bewegungsmelder Toilette (MotionSensor 6)
- service: rest_command.set_hue_rule
data_template:
id: 3
payload: '{"conditions":[{"address":"/sensors/8/state/status","operator":"lt","value":"1"},{"address":"/config/localtime","operator":"in","value":"T{{now().strftime("%H")}}:00:00/T23:00:00"},{"address":"/sensors/7/state/dark","operator":"eq","value":"true"},{"address":"/sensors/6/state/presence","operator":"eq","value":"true"},{"address":"/sensors/6/state/presence","operator":"dx"}]}'
- service: rest_command.set_hue_rule
data_template:
id: 5
payload: '{"conditions":[{"address":"/sensors/8/state/status","operator":"lt","value":"1"},{"address":"/config/localtime","operator":"in","value":"T{{now().strftime("%H")}}:00:00/T23:00:00"},{"address":"/sensors/7/state/dark","operator":"eq","value":"true"},{"address":"/sensors/6/state/presence","operator":"eq","value":"true"},{"address":"/sensors/7/state/dark","operator":"dx"}]}'
- service: rest_command.set_hue_rule
data_template:
id: 14
payload: '{"conditions":[{"address":"/sensors/8/state/status","operator":"lt","value":"1"},{"address":"/config/localtime","operator":"in","value":"T23:00:00/T{{now().strftime("%H")}}:00:00"},{"address":"/sensors/7/state/dark","operator":"eq","value":"true"},{"address":"/sensors/6/state/presence","operator":"eq","value":"true"},{"address":"/sensors/6/state/presence","operator":"dx"}]}'
- service: rest_command.set_hue_rule
data_template:
id: 15
payload: '{"conditions":[{"address":"/sensors/8/state/status","operator":"lt","value":"1"},{"address":"/config/localtime","operator":"in","value":"T23:00:00/T{{now().strftime("%H")}}:00:00"},{"address":"/sensors/7/state/dark","operator":"eq","value":"true"},{"address":"/sensors/6/state/presence","operator":"eq","value":"true"},{"address":"/sensors/7/state/dark","operator":"dx"}]}'
- delay: "00:00:01"
I had to copy the conditions rule by rule from the API (just call it in a browser window with /sensors/{ruleID}) and paste them into my code 
It seems that my conditions are in a different order than yours, hence the difference between conditions[0] and conditions[1]…
That’s the code for one single motion sensor. Added a short delay after each sensor to prevent the Hue bridge from overload.
1 Like
o dear… thanks…
may I ask why you don’t only use the changing part in the payload? As far as I can understand this now (need some more studying… you change the time in the schedule to now().strftime(“%H”) but that’s the only thing changing in all sensors?
couldn’t you just ‘put’ that condition then, and not all the others per sensor? Or would that delete everything else?
like this:
- alias: "Nachtmodus wurde aktiviert"
trigger:
- platform: state
entity_id: input_boolean.b_nightmode
to: "on"
action:
# Bewegungsmelder Toilette
- service: rest_command.set_hue_rule
data_template:
id: 3
payload: '{"conditions": {"address":"/config/localtime","operator":"in","value":"T07:30:00/T{{now().strftime("%H")}}:00:00"}
- service: rest_command.set_hue_rule
data_template:
id: 5
payload: {"address":"/config/localtime","operator":"in","value":"T07:30:00/T{{now().strftime("%H")}}:00:00"}
- service: rest_command.set_hue_rule
data_template:
id: 14
payload: '{"conditions":{"address":"/config/localtime","operator":"in","value":"T{{now().strftime("%H")}}:00:00/T07:30:00"}
- service: rest_command.set_hue_rule
data_template:
id: 15
payload: '{"conditions": {"address":"/config/localtime","operator":"in","value":"T{{now().strftime("%H")}}:00:00/T07:30:00"}
- delay: "00:00:01"
Forget about the above_
I see I missed what you said here:
could you please tell me in words what you achieve by setting Nachtmodus aktiviert und deaktiviert. What actually changes in the Hue setup other than the actual time you do it.
(I am correct you dont actually switch on/off anything ?) Like we can set to ‘do nothing’ in the app, or set a scene, but I dont’ see you do that? Those would be my main reasons to try and do this all,
- set day/night to do nothing , or set a scene
- set sensitivity
btw @Martso have constructed this mapper, I think you wanted something like the too for the friendly_names? hop over to Map values for an input_select? and we can work this dedicated issue out without further disruption of this thread…