How do I trigger an event on transistion of numerical value?

Configuration
1

I would like to create an automation of this pseudo code

if sensor.tas_beamer_energy_power[current] > 50 and sensor.tas_beamer_energy_power[current-1] <= 50
{
  set light.uk_hall_deco brightness to 1
}

Where sensor.tas_beamer_energy_power[current] is the current value and sensor.tas_beamer_energy_power[current-1] the previous one in the history.

This is to dim some decorative lights when the power meter on the projector plug reports a transition from power consumption below 50W to above. After this transition has happened, I don’t want this triggered again, until the plug has reported a value below 50 again in the meantime.

2 
trigger:
  platform: numeric_state
  entity_id: sensor.tas_beamer_energy_power
  above: 50
1 Like
3

You don’t need the “and previous value <= 50”, the numeric state trigger takes care of this already.

Edit: Too slow xD

1 Like
4

Great, thanks!

5

Is there any sort of automatic inverse action / reset?

I have these two automations now:

alias: Dim down deco light when beamer turns on
description: ''
trigger:
  - platform: numeric_state
    entity_id: sensor.tas_beamer_energy_power
    above: '50'
condition: []
action:
  - service: light.turn_on
    data:
      brightness: 1
    entity_id: light.uk_hall_deco
mode: single

alias: Dim up deco light when beamer turns off
description: ''
trigger:
  - platform: numeric_state
    entity_id: sensor.tas_beamer_energy_power
    below: '50'
condition: []
action:
  - service: light.turn_on
    data:
      brightness: 100
    entity_id: light.uk_hall_deco
  - delay: '300'
  - service: light.turn_on
    data:
      brightness: 1
    entity_id: light.uk_hall_deco
mode: single

Dimming the light when the projector switched on worked. Then, when I switch it off, it was supposed to go to brightness 100 for 5 min, then switch back to 1.

What actually happened was that it went to 35 on switch off, then to 1 after 5min. 35 might have been the original state before switch on, I am not sure. No other idea where that would have come from.

6

What you have will do that.

Are you perhaps forgetting that the maximum brightness is 255?

100/255 = about 39% brightness.

1 Like
7

Ok, that makes sense. I don’t quite understand why brightness there would be interpreted as a relative value to 255, instead of as an absolute value, but it would be an explanation.

Does that mean that I can in general not use a higher resolution than 8bit? Because that could be an issue in some situations. Gladly in my case, the device maps 1-100 to 12bit resolution. 1/255 is not dim enough in many setups.

8

Nvm, found brightness_pct. Still, a possibility for directly accessing higher resolutions would have been nice.

9

1/255 is a smaller step than 1%.

10

Yes, but AFAIU, brightness_pct: 1 for a brightness_scale: 4095 entity would send 1, which would be 1/4095, while brightness_pct: 100 would send 4095 .
At east this is what I get from “1 is the minimum brightness”. Might be wrong, though.
In my experience, accessing very low brightness is more important aspect of high resolutions than accessing every step.
But as I said, a method for the latter would be nice. I think there should be either brightness_raw, or float support for brightness_pct.

As I said, in my case, I am fine, because the device takes care of a nonlinear mapping from 1-100 to 1-4095. So for me, brightness_pct works.

11

No, it would send 1% of 4095 which is 41.

1/255th of 4095 is 16.

12

Then the doc is wrong. It states “0 means the light is off, 1 is the minimum brightness and 100 is the maximum brightness supported by the light”.
I don’t see any reason to claim that 0.01* brightness_scale is the “minimum brightness supported by the light”. It wouldn’t even be true for a brightness_scale: 255 entity, that could be fully accessed in the current state of homeassistant.

13

It could be the case. That would mean the step from 0 to 1% would be different from every other pct_brightness unit step though.

I’ll look at the source latter if I get time and see if I can confirm either way.

14

It looks like you are right. I grep’ed for brightness_pct and ATTR_BRIGHTNESS_PCT, and neither gives any indication that it is anything but int(round((brightness_pct * 255) / float(100))). Didn’t see any special cases for brightness_pct==1.

1 Like