Automation using Sunset and weather conditions won’t start

Configuration
, ,
1

Hi there!

I am new to Home Assistant but had wide expirerende with PiMatic in the past. As I am going, imam trying to copy the automations from PiMatic over to HASS.

All going pretty well - but - 2 of my automations won’t start for some - to me - unclear reason.

I have a (old) sunscreen which I automated using Tasmota. The automations include weather responses as well as going up during sunset.

But, whilst other automations work, the weather automation and sunset do not. I feel there is something wrong with the condition I use, but reading the HASS documentation I couldn’t pinpoint the issue - also I am not 100% sure the condition is the issue.

This is what I’m using right now:

Trigger weather:


platform: State
entity_id: sensor.openweathermap_condition
from: Rainy

Trigger Sunset:

platform: sun 
event: sunset

Conditions and action is the same for both:

Condition:

condition: state
entity_id: input_boolean.zonnescherm_helper
state: 'On'

Action:


service: script.zonnescherm_omhoog
data: {}
2

For the weather triggering, try to change it to something like this --> from: cloudy to rainy. What you shown here doesn’t seem right as it’s just showing from: rainy.

For the sunset triggering, you can try to use the entity state instead. For example, entity_id: sun.sun and from above_horizon to below_horizon.

3

Thanks for the quick response - I have just updated it. And will test during the day.

My ultimate goal would be to have the sunscreen go up when it’s raining, but it seems quite difficult to get that from OWM what I remember from earlier attempts in PiMatic.

Is there a way in HASS to specify the amount of rain (in mm) instead of using cloudy/rainy? Or would cloudy/rainy work still best?

4

You can actually test the automation right a way by setting the states in the developer tools>states page. Just set the state of the weather/sun sensor and don’t worry about messing up the actual sensor state. It will eventually get overwritten when the sensor has an update/refresh.

You can use numeric state as triggering if you want to use amount of rain. But provided you have a sensor/attribute that’s reporting this.

5

I tested both the rain and sun, and changed the state in developer. For sunset i even created a automation to go down on sunrise, but still these are not working.

Edit:
Ok - I removed the condition of the helper state to be on, now when I change the rain setting it Is working, so I could confirm the error is here.

The helper is an “switch” type which in the script (sunscreen down) is triggered to move to “on” whilst the other script (sunscreen up) triggers this off.

It seems I am currently using the wrong method of using this in an automation - anyone could help?

6

I’ve tried different scenarios, but as soon i add the condition the automations stop working.
I would need this condition to prevent my relays to turn on while the screen is up already.

So far, no clue left… anyone has an idea whats going on?

condition: state
entity_id: input_boolean.zonnescherm_helper
state: 'On'

Edit:

After spending quite some hours, i finally found a method which seems to work.
Instead of having the " State " attribute check the status of the switch i now use a Template:

condition: template
value_template: '{{ is_state(''input_boolean.zonnescherm_helper'', ''on'') }}'

I have just tested this and it seems to work properly. Unless someone would tell me different, i will convert my automations to this format.

7

state: 'on'

An input_boolean’s states are 'on' and 'off' not 'On' and 'Off'.

Had you used 'On' in the template, it would have also failed to work correctly.

8

I just tested this and the only thing i think right now is… omg…

I created these automations using the iOS app, and it seems to have added an auto capital letter…

9

Look at an entity’s state in Developer Tools > States. That’s the correct spelling you must use in trigger, condition, etc.

10

Thanks - didnt know - yet - HASS is case sensitive…

11

It’s a common misconception.

In addition, don’t make the mistake of believing what is displayed in the UI, for example Open and Closed, to represent the spelling of the entity’s actual state.

For example, if you set the device_class of a binary_sensor to door, the binary_sensor’s actual states remain on and off but they are displayed in the UI as Open and Closed. Trigger and condition must use the binary_sensor’s actual state names, on and off, never their “display” names.

1 Like
12

Thanks - very helpfull indeed. I came from another home automation platform that wasnt picky on the - this is a good lesson for me tho!

13

Another tip: an entity’s state is always a string value and it cannot exceed 255 characters in length.

For example, assume you have a temperature sensor and its state is 21. That’s a string value. If you want to do some arithmetic with it, you must convert it from string to integer or float using the int or float filters.

This won’t work:

{{ states('sensor.exterior_temperature') > 10 }}

but this will:

{{ states('sensor.exterior_temperature') | int > 10 }}

In contrast, an entity’s attributes can have other types besides string such as integer, float, list, etc. In addition, they are not limited to 255 characters in length.

Assuming an entity has an attribute called humidity and it’s an integer or float, then this will work:

{{ state_attr('sensor.exterior_temperature', 'humidity')  > 34.5 }}
1 Like