check here Binary sensor - Home Assistant motion is a valid device_class for a motion sensor.
If you check the device in states does it show a device_class of motion for that sensor?
eg
good so we’re in agreement that the GUI editor creates the correct code as per my last post above.
good so we’re in agreement that the GUI editor creates the correct code as per my last post above.
No we are not. Maybe you misunderstood what I said. If I enter the correct code in the yaml file the GUI shows the same as yours. When I use the GUI to create the code it again looks the same, but it creates incorrect code on my setup. There are other threads with other users experiencing the same issue as me. They can create the automation in yaml that runs correctly, but they can not create it in the GUI.
I don’t have an issue anymore for my automation, but if you are interested to help the developers we can explore the differences further in this thread, another thread or maybe PMs to see why you have zero issues and I and others have many?
Maybe… I do notice that I only see things configure via an integration in the list of devices I can select.
So the actual code I created was created by the GUI editor - I did not manually enter it - it was what the editor put in the yaml file that I then pasted here. In your initial screenshot you were trying to add the before and after sunrise/sunset in the same condition which wouldn’t work and would produce faulty code but in mine I added seperate conditions and it does produce the correct code. I can’t comment on other threads/users but I would suspect on examination they are also making an error in how they are creating the automation in the GUI. It’s not impossible there is some kind of bug but you have not demonstrated that yet with this automation. (The wizard with devices/integrations may be a bug but I think it just doesn’t support all devices yet)
I finally understand what you are saying. My confusion is that an " or "always requires two conditions. I thought when the editor opened and showed the two conditions that is what it wants you to do. Why would a user think otherwise?
I tried it again with the second condition and it works as you showed.
@bschatzow It’s far more elegant to use the sun elevation, like I posted in the other thread you are commenting about the same automation. You don’t need to worry about “or” conditions, use a template that looks at the suns elevation, if below the horizon, it triggers, if above, it will not. Very simple.
trigger:
platform: state
entity_id: binary_sensor.pir_back_garden
to: 'on'
condition:
condition: template
value_template: "{{ states.sun.sun.attributes.elevation | int > 1 }}"
action:
service: switch.turn_on
entity_id: switch.back_garden_security_light
I personally use an elevation of 8° in my sun based automations for outdoor lights, and 12° for indoors. I live in Brisbane, Australia, so find these 2 numbers work well for dusk/dawn based automations.
Yeah I thought we were at crossed purposes. Actually I think this is at the very least unexpected behaviour (if not a bug). You shouldn’t be able to bundle before and after sun condition together in the one condition - they would always be seperate conditions I think Maybe there is a use case I can’t think of for doing them together.
I saw your post and tried to find more information on elevation. I saw had it was use (similar template), but did not find a good definition.
How do you use hours before or after.
It doesn’t use before/after, it always looks at the current elevation, so while the sun is down, the elevation will show -x°.
Yes “or” is the case. You want this or that sunset or sunrise. This sets your boundaries.
I have started using Phil Bruckners sun2 binary sensor as it’s not looking at a -0.833° (or whatever it is) to say it’s above/below horizon. My automation uses 25° above the horizon
binary_sensor:
- platform: sun2
monitored_conditions:
- elevation
- elevation:
above: 25
name: Sun Above 25
So that sensor is on if above 25 and off below and then the automation just looks like this:
- id: '1505977024304'
alias: Turn Lounge Light On Elevation < 25° & after 4PM
trigger:
- platform: state
from: 'on'
entity_id: 'binary_sensor.sun_above_25'
to: 'off'
- platform: time
at: '16:00:00'
condition:
- condition: time
after: '16:00:00'
- condition: state
entity_id: 'input_boolean.homeandawayauto'
state: 'on'
- condition: state
entity_id: 'binary_sensor.sun_above_25'
state: 'off'
action:
- service: script.turn_on
data:
entity_id: script.loungenormal
(I don’t want it on before 4)
Note I get 2 binary sensors:
Any reason you have to use another sensor? Couldn’t you just use the existing sun.sun sensor and add an and condition for below X° AND after 4pm?
I don’t understand what you mean. I have the exact and condition you mention. I have 2 triggers. I prefer Phils sun2 to sun due to how sun now updates. Phils one knows when the sun will be at a certain elevation rather than polling at an interval…
I get you, I just didn’t understand the need for using another sun sensor.
I can see input booleans and extra sensor use, I don’t understand the need for, but, I don’t know your config, so whatever works for you is good. I try to avoid using extra booleans and things unless absolutely necessary.
I use other features of that sun sensor as well…
Not having a go at you 
Well I have a home and away input boolean so if we are away, I can tap a button for away mode and it then doesn’t run a bunch of automations (like turning the light on and turning my coffee maker on) when we are not home. I used to manually turn automation on/off and then I had an automation to turn them on/off but in the end using an input_boolean just works better and I have a button that shows if I’m home or away etc. I have a similar one for if my wife is working overtime or if it’s a holiday and my automations check those input booleans and will then trigger at different times under those conditions.
You can also see from my screenshot above that the binary_sensor KNOWS when it’s going to change state - it has a next_change attribute so whereas the inbuilt sun sensor polls if above or below, sun2 doesn’t. You can actually disable sun if you use sun2 (although default_config uses sun anyway)
