Thanksgiving lighting took a holiday

[mgvra]

Some background
I have two simple rules that will toggle my carport's down lights depending on outdoor brightness when I open the motorized sliding gate. I.e. if the brightness is 1500 lux or less and the gate is opened, the down lights will be switched on, and when the gate is closed, the lights will switch off after 3 minutes. Pretty simple 'coming home' functionality so to speak.

Here's the switch off rule showing the 'hard coded' thresholds

The problem
I would like to parameterize the lux and switch off delay using entities. I bet the lux threshold can be done with local expressions the same way I do my WC background music scheduling:

weekdays_enabled = (time() >= time(getEntity( "mqtt>wc-music-weekdays-enable" ).attributes.string_sensor.value )) && (time() <= time(getEntity( "mqtt>wc-music-weekdays-disable" ).attributes.string_sensor.value ))

But the since I'm using the Condition must be sustained for functionality for the switch off rule, I have no idea how to parameterize that with some entity value.

So my question is that is it even possible to do this using entities or could there some other way to accomplish the same functionality? In this example it's the sustain -value but I might need same kind of parameterization for the delay reset also.

I have to go with entities, since my own HA system will provide the threshold values for the MSR through the MQTTController.

Help would be appreciated @toggledbits
br,
mgvra

MSR latest-23302-b7def56a and MQTTController [0.1.23254]

[toggledbits]

@mgvra said in Rule's sustain / delay reset etc. value parameterization thru entities:

I would like to parameterize the lux and switch off delay using entities. I bet the lux threshold can be done with local expressions the same way I do my WC background music scheduling:

You can use expressions in condition operands by using the substitution syntax: ${{ your-expression }}

But the since I'm using the Condition must be sustained for functionality for the switch off rule, I have no idea how to parameterize that with some entity value.

You cannot use expression substitution in the values of condition options. These are required to be constants (literal values).

The workaround is to group conditions and use additional conditions as gating criteria. For example, if you would change the "sustained for" delay based on time of day, say 120 for day and 600 for night, then you would have conditions structured like this:

Group A - Daytime -- AND group
    Rule Condition: Rule "Is Day" is TRUE
    Entity Condition: some entity test that tests a value
        condition option: Sustained for 120 seconds
Group B - Night -- AND group
    Rule Condition: Rule "Is Day" is FALSE
    Entity Condition: the same test as used in group A
        condition option: Sustained for 600 seconds

[mgvra]

Thanks for your quick reply!

You can use expressions in condition operands by using the substitution syntax: ${{ your-expression }}

I'll use that for the brightness threshold.

The workaround is to group conditions and use additional conditions as gating criteria. For example, if you would change the "sustained for" delay based on time of day, say 120 for day and 600 for night, then you would have conditions structured like this:

Group A - Daytime -- AND group
    Rule Condition: Rule "Is Day" is TRUE
    Entity Condition: some entity test that tests a value
        condition option: Sustained for 120 seconds
Group B - Night -- AND group
    Rule Condition: Rule "Is Day" is FALSE
    Entity Condition: the same test as used in group A
        condition option: Sustained for 600 seconds

Well unfortunately this doesn't help much if I need to set an arbitrary delay value from my custom UI.

You cannot use expression substitution in the values of condition options. These are required to be constants (literal values).

Could this be a new feature request to support expression substitution in timeout values (sustain / delay reset etc) if it's feasible to implement?

br,
mgvra

[therealdb]

I have similar cases and if this is feasible for you, just use delay before/after the actual actions. Delay actions are accepting expressions. I have a couple of them even using random delays.