Home Assistant Outside Light Control Using MET.no Weather Integration

I show you how I implement the Home Assistant Weather application Meteorologisk Institutt (MET.no) and how I use that for outside light control.

I compare the current Default integration with the old one, and prepare you for the complete shutdown of the former DarkSky API from free public use.
If you haven’t heard, Apple has purchased DarkSky in March of 2020. It appears the intention of Apple is to remove the free API that HA users have enjoyed, making DarkSky part of the Apple Orchard exclusively.
At this point in March 2021, the Android app is no longer a product and the free API can no longer be signed up for. The stated Sunset for accessing the DarkSky API from formerly signed up customers is ‘The End of 2021.’
DarkSky Blog Post
CNBC Article

Even though there are no longer new sign ups allowed, there are still plenty of us relying on using DarkSky to fire automations and control happenings in HA. Personally I have/had an automation that fed my outdoor lights based on the Sun integration built into HA and DarkSky where I used the % cloud cover to predict when the outdoor lights should be enabled. That needs to change. Today we are going to dress-up the MET.no integration with some awesome animated fonts, and we will use the provided cloud cover information to create a new automation for my lights. Enough Railing about giant fruit… Let’s see what’s current…

When you load HA, one of the ‘default’ integrations is the weather. Kind of a basic thing everybody wants to know about. The default implementation is a bit boring, however. There is a custom integration that will spice that right up for you. Remember that custom integrations are integrations that are not fully screened by Home Assistant and could cause you problems, but in this case it’s really just a font set, and rather safe to install. So, that said, install the animated-weather-card custom integration.
I installed mine thru HACS custom integration which makes it easier to install and maintain. Please see the docs on these to install them. If you have questions, hit me up on my Discord in the links below. I can help you thru it. Once you install that, you get cool animated pictures for your lovelace UI. I really like these!

If you are reading this in YouTube Description, the story is continued on my website. YT has problems with some code formatting, so I put all that kind of stuff there. See the link below. There is code examples on setting up Home Assistant Binary Sensors, Automations, and Tasmota firmware devices to make this work.

Lights automation:

I will first show you how I used DarkSky to accomplish this, so that you know the baseline. I suggest you do not use the DarkSky implementation, as it will only work if you already have an account and until the end of 2021. Here is my original (DarkSky) automation. Notice that it is no longer being used, and I still have it here to show you what I had in place originally.

binary_sensor:
  #####################################################
  # Weather                                           #
  #####################################################
  - platform: template
    sensors:
      dark_outside_d_s:     #DEPRICATED...
        unique_id: cf63de19-95f6-4faf-bae0-31b5f18b639d
        friendly_name: 'Is it Dark outside Dark Sky'
        value_template: >-
          {% if (states.sun.sun.attributes.elevation | int < 5) %}
            true
          {% elif (states.sensor.dark_sky_cloud_coverage.state | int > 90) %}
            true
          {% elif ( (states.sun.sun.attributes.elevation | int < 10) and (states.sensor.dark_sky_cloud_coverage.state | int > 40)) %}
            true
          {% elif ( (states.sun.sun.attributes.elevation | int < 12) and (states.sensor.dark_sky_cloud_coverage.state | int > 50)) %}
            true
          {% elif ( (states.sun.sun.attributes.elevation | int < 15) and (states.sensor.dark_sky_cloud_coverage.state | int > 80)) %}
            true
          {% else %} 
            false
          {% endif %}

Going thru this, you will see that is looks at sun angle and cloud cover % to predict when it ‘should’ be dark enough to allow lights to turn on. It was set to be conservative towards turning the lights on sooner, as WAF factors required this in my case. It is a binary sensor that simply indicates if it’s ‘DARK’ or not.

This is how I am accomplishing the same-ish thing with MET.no. I do not have % cloud cover in this integration, and decided it was not needed anyway. I am using the provided data of ‘cloudy’ and ‘partlycloudy’ to give me enough information to provide nearly the same functionality.

binary_sensor:
  - platform: template
    sensors:
      dark_outside:
        unique_id: 05836502-ee80-4449-8c97-6f20350c6642
        friendly_name: 'Is it Dark outside'
        value_template: >-
          {% if (states.sun.sun.attributes.elevation | int < 5) %}
            true
          {% elif (is_state('weather.home', 'cloudy')) %}
            true
          {% elif ( (states.sun.sun.attributes.elevation | int < 15) and (is_state('weather.home', 'partlycloudy')) ) %}
            true
          {% else %} 
            false
          {% endif %}

If the sun angle is below 5 degrees, it’s dark no matter the cloud cover. If MET.no decides it’s “cloudy”, the WAF truth table says the lights need to be on as well. If it’s “partlycloudy”, and the sun angle is less that 15 degrees, guess what, dark enough and the lights are enabled.

In both of these binary_sensor examples, you will notice the ‘unique_id:’ list item. I add this item everywhere I can within HA as this helps keep entities unique and more accessible within the HA UI. In my case a generated UUID from an Extension in VSCode, but any unique string would be fine here.

In my implementation, this binary sensor info is sent to MQTT for my lights to use and act upon. I have a short automation to do this:

automation:
  ####################################################
  # Dark out?                                        #
  ####################################################
  - id: c4d89216-e97a-470b-82e9-cb9e4ef6e601
    initial_state: on
    alias: MQTT Dark Switch
    trigger:
    - platform: state
      entity_id: binary_sensor.dark_outside
    action:
    - service: mqtt.publish
      data_template:
        retain: true
        topic: "Outside/cmnd/EVENT"
        payload: >-
          {% if trigger.to_state.state == 'on' %}
            DARK
          {% else %}
            DAY
          {% endif %}

That makes the information available and retained on my MQTT broker, and the binary sensor makes the information available everywhere else in HA. Retain is important, as when the device boots, if it’s day out, the broker will tell this to the device and enable the lights with no other interaction. If Retain is false, the devices default to DARK and enables the lights (safest fallback condition).

Controlling lights:

Most of my lighting control is Tasmota based, so I use rules in the lights to decide when the lights are allowed to turn on. This example was done with Tasmota 9.2.0, so you should be at at least that version to do this.

Here is an example of my back porch light, but I do this in several places outside and in mostly natural lighted areas inside the house as well. All the devices that are to be affected by this sensor have to have a Tasmota configuration tweak, and need to be in the same GroupTopic.

GroupTopic:

I have named my GroupTopic ‘Outside’ for my setup, but you can pick any name you like. You can set 4 GroupTopics on every Tasmota device. I suggest you leave the GroupTopic ‘tasmotas’ alone, as that is very handy when working with multiple Tasmota devices in the same network. Setting the GroupTopic is done using the command GroupTopic4 in the Tasmota console. I found pushing to #4 will fill in the next available slot that is empty, or will overwrite #4.

Rule command copy-paste:

GroupTopic4 Outside

The response is a list of the available GroupTopics and then the device reboots. You can see the list of GtoupTopics again with this:

Rule command copy-paste:

GroupTopic

When this is there, the device is listening to that topic, and will respond when something is published to that topic in your broker

The Rules:

Rule1: on POWER1#state=1 do POWER2 1 endon

Rule command copy-paste:

rule1 on POWER1#state=1 do POWER2 1 endon

Rule2: on System#Boot do event#DARK endon on event#DAY do Backlog rule1 0; POWER2 0 endon on event#DARK do Backlog rule1 1; POWER2 0 endon

Rule command copy-paste:

backlog rule2 on System#Boot do event#DARK endon on event#DAY do Backlog rule1 0; POWER2 0 endon on event#DARK do Backlog rule1 1; POWER2 0 endon; rule2 on

As you can see by the Tasmota Template, I have set this device to have a fake relay (GPIO16) and a real relay (GPIO12). Button 1(GPIO0) will trigger the fake relay at all times. The red LED (GPIO13) will turn on whenever the device sees the button1 pushed. The real relay (GPIO12) connected as relay2. There is no button2 so the only way the light comes on is thru the rule.

BEFORE any buttons are pushed, IE at boot or upon change of the ‘Outside’ topic, rule 1 will be turned on or turned off. As button1 (In this case a PIR) fires, it will do nothing when rule1 is not enabled, or it will activate relay2 if rule1 is on.

Send “DARK” to the topic “Outside”, and this device enables rule1 and turns off the light (to prevent ambiguity). Rule 1 is then enabled. On the next button press, rule1 will turn the light on.

Send “DAY” to the topic “Outside”, and this device disables rule1 and turns off the light (to make sure it doesn’t get stuck on). On the next button press, rule 1 is disabled and rule 1 is not available to turn the light on. Nothing happens.

On this particular light, I have also have a PulseTime set for relay2 for 300 seconds, meaning the light turns off in 5 minutes after being turned on without intervention. Along with this I have set switchmode 13 so that it will get triggered on, but off is up to the pulsetime variable time only.

Rule command copy-paste:

Backlog PulseTime2 300; SwitchMode 13

So that’s how I keep the lights off in the yard during the day, and how I have integrated the Default Home Assistant Weather Integration. I hope you’ve found this helpful. Feel free to comment on the video, ask questions in my Discord Channel, or comment on the web article.