Thanks. I had I marked as private, it’s fixed now.
OK, got the script illuminance.py working and have successfully upgraded HA to 0.115.2
I’ve used the weather_data custom component as a replacement for the yr component.
I got an error when installing weather_data custom component. I removed PERCENTAGE from the imports in weather_data’s sensor.py file and just added the line
PERCENTAGE = '%'
on its own line.
in my sensor.yaml file I added
- platform: weather_data
- platform: illuminance
name: YRS Illuminance
entity_id: sensor.yr_symbol
and finally in the custom component illuminance sensor.py file I had to remove the yr import line and add an import from custom_component weather_data
# line below added to use custom component weather_data for yr sensor data
from custom_components.weather_data.sensor import ATTRIBUTION as YRS_ATTRIBUTION
# i removed the line below because yr platform has been removed
# from homeassistant.components.yr.sensor import ATTRIBUTION as YRS_ATTRIBUTION
I think it’s working, I have no errors in the log. It’s dark now so I’ll find out in the morning. One thing I’ve noticed is the sensor.yrs_illuminance is reading 10lx even though it’s pitch black outside. Not sure but I thought it used to read zero at night.
nice coding
how do you automate this? what the automation triggering both sensors into a service? If you’d share that would be appreciated
thanks!
Some of you might be interested in a template sensor version of this code I worked on today. I don’t know that it works 100% yet, but I think it is working pretty well so far!
I could talk about my light switch free smart home all day, happy to share.
I have installed AM312 mini pirs throughout my apartment. I have loft access which has been a God send. The AM312s are connected to my HA Pi via GPIO. Each door in my home has a pair of PIRs, one either side of the door. I have removed the lens from the PIRs and they peer through a 4mm hole in the ceiling, creating a 99 pence ‘laser’ tripwire. As you walk through a door you trip one sensor then the other. Direction of travel can be determined by the order that the PIR pair trigger. An input number is incremented for the room you entered, an input_number is decremented for the room you left. Everyone is well aware how the system works, so no messing about in doorways. If you change your mind about walking into a room you must continue through the door and wait one second before turning around! A small price to pay.
This system means you can be motionless in a room reading a book and the weather suddenly gets gloomy or the sun begins to set and the system will know to light the room just enough for you. You can set a night time dimming level so after a user defined time an artificial sunset will gradually dim down the now full power lights (because the real sun set hours ago) to a comfortable value before bedtime.
The automations which turn on the lights are fairly straightforward. Three state triggers, room occupancy above zero, a change of dynamic brightness sensor, a change of dynamic color temp sensor. Conditions are applied to check the room is occupied and that it is dark enough outside to need lighting.
Every room’s automations are the same, count people in and out, turn on/adjust the lights, turn lights off. Here’s the autoamtions for my study which has MiLight RGB+CCT down lighters:
### STUDY ###
- id: turn on study lights
alias: turn on study lights
trigger:
- platform: numeric_state
entity_id: input_number.study_occupancy
above: 0
- platform: state
entity_id: sensor.dynamic_brightness
- platform: state
entity_id: sensor.dynamic_color_temp
condition:
- condition: numeric_state
entity_id: input_number.study_occupancy
above: 0
- condition: numeric_state
entity_id: sensor.dynamic_brightness
above: 0
action:
- service: light.turn_on
data_template:
entity_id: light.study_lights
brightness: "{{ states('sensor.dynamic_brightness') | int }}"
color_temp: "{{ states('senosr.dynamic_color_temp') | int }}"
transition: 1
- id: turn off study lights
alias: turn off study lights
trigger:
- entity_id: input_number.study_occupancy
platform: numeric_state
below: 1
action:
- service: light.turn_off
entity_id: light.study_lights
transition: 1
- id: someone entered the study
alias: someone entered the study
trigger:
- platform: state
entity_id: binary_sensor.pir_study
from: 'off'
to: 'on'
condition:
- condition: state
entity_id: binary_sensor.pir_hall_study
state: 'on'
action:
- service: input_number.increment
entity_id: input_number.study_occupancy
- service: input_number.decrement
entity_id: input_number.hall_occupancy
- id: someone left the study
alias: someone left the study
trigger:
- platform: state
entity_id: binary_sensor.pir_hall_study
from: 'off'
to: 'on'
condition:
- condition: state
entity_id: binary_sensor.pir_study
state: 'on'
action:
- service: input_number.increment
entity_id: input_number.hall_occupancy
- service: input_number.decrement
entity_id: input_number.study_occupancy
I’m so glad I’m not the only one with crazy template sensors! I wasn’t sure if it was a good thing to do but I haven’t noticed any issues so far. If It’s ok with you I might use your template and see if adding my new open weather map cloudiness percentage sensor as the base for illuminance estimation returns finer results. I’m no Python programmer.
Hi all. Sorry I haven’t been able to work on this for a while. I made a couple releases today that should hopefully resolve the problems:
2.1.1 – Properly handles the case when the darksky integration isn’t loaded (e.g., you’re not using it in your configuration.)
2.2.0 – Properly handles the YR integration being removed starting with HA release 0.115, and adds support for the met integration.
Which attributes of weather.home does this require? I have a different weather platform and maybe it works as well?
Unfortunately it’s not that generic. It looks at the entity’s attribution
attribute to decide which integration it is and hence how to interpret its state and how to translate that to a number. It’s not all that hard to modify the code to add support for new integrations, but it’s not generic enough to do it simply via configuration parameters.
That’s a shame.
What weather platform would you like to use with this? FYI, based on some other input I’ve received I’m currently working on adding support for AccuWeather & ecobee (which is pretty much done.)
Released 2.3.0 which adds support for AccuWeather & ecobee.
BOM - there is a new custom component. https://github.com/bremor/bureau_of_meteorology
Dunno if you can add it?
Is there an algorithm I could use to calculate this via template sensors?
Funny you should ask…
This is exactly what I was about to look into for my next HA enhancement. Thank you for saving me hours of scripting/testing/failing/repeating!
Would you consider making the brightness and color temp sensors a separate thread. Like Outdoor illuminance template sensor? I would follow that diligently and hopefully add to it when I’m done deciphering your jinja
Sorry just seen this. I’ll do a write up of my dynamic lighting control soon and post a link to the topic here. Thanks for the interest.
There is a HACS addon called adaptive lighting that may be of interest to you and others. It seems to do everything my templates and automations do, although I haven’t looked too deeply into myself.
Released 2.3.1
Adds version
and issue_tracker
to manifest.json per new custom integration requirements.
Released 2.4.0
Add support for OpenWeatherMap
I am using this now for a few days (with OpenWeatherMap in onecall_daily mode). However, it just ramps up to 1000 (not 10000 as your example), stays there the whole day and then down to 10, no matter what the weather was.
I don’t think this is the right behaviour, can you confirm this?
What has your weather.home been reporting as the state? It is working as expected with met.no. What is onecall_daily mode?
Currently it reports as cloudy.
You can see the onecall_daily mode over here: https://www.home-assistant.io/integrations/openweathermap/
I currently also set one with the weather.home, but it shows a different value (2500). I will check how this works…