To install MySQL (or more accurately MariaDB) on your DietPi \ Debian distribution all you need to do is run the following command:

sudo apt install mysql-server

This will download and install all the required packages and dependencies to get up and running quickly. Note you will need to do some additional configuration (below) in order to manage and access your MySQL instance remotely.

Creating User Accounts

While connected to your device via ssh, run the below command to start the mysql prompt:

mysql

Create a new user with the following command, replacing the values for username and password with your own values.

Octoprint

As mentioned above, in order to monitor Octoprint from Home Assistant you will need the Octoprint MQTT plugin as this allows Octoprint to publish relative information about your printer and any running jobs.

You can install the plugin through Octoprints built in plugin manager, and configure it to point to your home MQTT server (or cloud server if you are not hosting your own).

I would suggest picking a meaningful topic when setting up MQTT, especially if you are running more than 1 3D printer. In my case I will set this topic to octoprint/anet_a8/:

We can confirm that our configuration is correct by subscribing to either # or octoprint/anet_a8/# in your preferred MQTT client (in my case I am using MQTTBox).

Home Assistant

The first thing we need to do is add the Octoprint component's configuration into your configuration.yaml file.

After a quick restart of Home Assistant you should see your new sensors.

Grouping and Customization

I prefer to group similar sensors together in Home Assistant to make it easier to get to the information that I want to see. Below I am creating a new card called Anet A8 which contains all the sensors that I want to see...

This results in the following card appearing in Home Assistant after a restart.

If you are wondering where to get the entity names specific to your 3D printer (e.g. sensor.anet_a8_job_percentag) you can get them through the states panel under the Developer Tools section of your Home Assistant instance.

Customizing Entities

The next thing I want to do is rename some of the automatically generated names to ones that make more sense to me. To do this I added the following configuration to my customize.yaml file:

3D Printer View

The last thing left to do is create a 3D Printer view in Home Assistant (i.e. a TAB on the top row) which will be used to only display information from my 3D printer, to do this I added the following configuration to the groups.yaml file.

Seeing that we have already done a lot of work with sensors and basic configuration in Home Assistant I am just going to list the configuration I used, along with the relevant configuration commits on GitHub. If you would like more information on why things are done a certain way feel free to browse all the posts leading up to this one.

Let's get started.

Dark Sky

Dark Sky is a weather data provider with a free API (based on usage). It integrates well into Home Assistant, and unless otherwise configured will use your default co-ordinates to fetch local weather data.

You will need a developer account to use the sensor, with the registration process being quick and easy to follow, once you have a key you are good to go.

Configuring Dark Sky

First, add your API key to secrets.yaml like so:

darksky_api: xxx

Next, create a new sensor as shown below in the configuration.yaml file (feel free to swap out any monitored conditions you want):

System Monitor

System Monitor allows you to collect performance counters from your host computer (regardless of the platform).

There are a lot of good code examples on the documentation page for most OS's - in my case I am running Home Assistant on linux (Raspberry Pi to be more precise) so depending on what you are using, your configuration may look a little bit different.

Configuring System Monitor

First we will need to define the sensor in configuration.yaml like so:

In Closing

Right now (and if you have been following these posts) our Home Assistant dashboard is getting pretty cluttered (we will be doing something about that soon). I still have yet to scratch the surface of this product, but I am getting some immediate benefit with what I have done so far.

In the next post we will be adding support for OctoPrint to Home Assistant, followed by creating views (tabs essentially) and breaking up our configuration into smaller, more manageable parts.

I hope that you found this post interesting and, as always, I welcome any feedback, comments or suggestions you may have.

]]>This is one post in a series of getting up and running with Home Assistant from scratch.

Today I would like to cover the History component of Home Assistant, and show you how to ignore certain entities or domains altogether through it.

It is these names (I like to think of them as the entities fully qualified name) that we use to configure certain aspects of Home Assistant - like create groups, views or automatons. A fully qualified name of an entity follows the <domain>.<entity_id> naming convention.

Domains

Entities are grouped together into collections known as domains in Home Assistant, making them easier to manage, and helps provide some insight into what a particular entity does (e.g. deck is less helpful when compared to light.deck).

Again we have already seen domains in action when creating the custom light group back in this post, with the groups we created again being added to the group domain.

This concept is useful in Home Assistant (as you will see later) as it allows you to exclude / include a dynamic collection of entities rather than listing them one at a time.

World Clock Sensor

I am going to add the world clock sensor to Home Assistant to allow me to keep tabs on the time in Canada and South Africa, we do this by adding the following lines to the configuration.yaml file ...

This will result in the following new panel on your Home Assistant dashboard, GitHub commit here.

The sensor is working as expected.

History Component

The history component will track everything that is going on within Home Assistant and allows the user to browse through it. It depends on the recorder component for storing the data and uses the same database setting.

As you can see the history component is great as it allows us to query the state of any component in Home Assistant from the past, what is not so great is the fact that every component in Home Assistant is tracked automatically, including every state change. For something that changes as often as a clock, or for entities we don't care about this is a waste of storage and can slow down your database (depending on where it is hosted).

We are already getting data stored in history for our clock, let's stop that!

Ignoring a specific entity

Unfortunately for me the world clock sensor is part of the sensor's domain so we cannot exclude it by the domain name - if we were to do this we would loose all sensor information, what we need to do in this case is exclude our clocks by entity name.

To exclude an entity from the history component is as simple as adding it to the exclusion list like shown in the documentation:

After validating your configuration to ensure that you didn't make any typos, restart Home Assistant for the changes to take effect. If done correctly you will no longer have any new history entries being recorded for your world_clock components.

Note: You will need to wait a day or so for the data to be removed from the history view, this is because we stopped new data from being recorded and did not delete the recorded data from the DB.

Ignoring a domain

In some cases you may not want to collect history for a group of entities in Home Assistant, for me this is all items in the group domain. As mentioned earlier domains are the leading bit in an entity name (e.g. mediaplayer.loungespeaker - the domain is media_player), you can get an idea of all the domains you are using through the States View.

Like with single entities, you can exclude a domain through the exclude option on the history component, so in my case I can exclude all groups with the following configuration:

history:
exclude:
domains:
- group

After a quick validation of my configuration, a restart of Home Assistant (and some time for the history to roll over to the next day) - I no longer have any group history :)

In Closing

As always, I hope that you found this post interesting and helpful. I am always looking for any feedback, comments or suggestions to help provide better content.

This is one post in a series of getting up and running with Home Assistant from scratch.

Today we are going to make our Home Assistant deployment a bit smarter by adding in presence detection. For this I am going to be making use of the Google Maps Location Sharing component as I find it to be more reliable than my old self-hosted OwnTracks instance, and both my wife's phone and mine already have Google Maps installed with location sharing enabled (so there is no need to install another application on Rae's phone).

Core Configuration

Below are the steps required to get up and running with the Google Maps Location Sharing component.

Note: I strongly recommend creating a new Google account to be used with Home Assistant for this, mainly due to the fact that you will need to share your location with it.

I noticed when I initially created the account it took a day or so before HASS was able to log into the new account properly to retrieve out device location. I would suggest creating the account, following the steps below and giving it a day or so for your settings to take effect.

Once your account is created, open up Google Maps on your phone, enable location sharing and share your location with your new account - be sure to share your location as ongoing.

HASS Configuration

Enabling Google Maps Location Sharing in Home Assistant (HASS) is as simple as adding the following 2 lines into your secrets.yaml file...

.. validating your configuration and restarting Home Assistant, when Home Assistant comes back up you should see all people sharing their location with your new Google account as shown below.

known_devices.yaml

Home Assistant will generate a new file called known_devices.yaml (if there isn't already one) which it uses to store information about discovered devices. The contents of the file should look something like this:

This file (known_devices.yaml) is specific to your Home Assistant setup and should not be committed to source control, it is safe to add to your .gitignore file.

If you wish to change the display names for your tracked users, this is the file to do it in, simply enter in the desired name for the user into the name property, reload Home Assistant and voila.

Looking a whole lot better!

Zones

Home Assistant allows us to configure custom zones through the zone component.

Zones allow you to specify certain regions on earth. When a device tracker sees a device to be within a zone, the state will take the name from the zone. Zones can also be used as a trigger or condition inside automation setups.

Let's see this in action by defining a Gym zone to see how active I am (spoiler - not very).

Creating a Gym zone

First thin you will need in order to define a zone is the longitude and latitude co-ordinates for your desired zone, I find the best way to get these values is by finding the desired are on Google Maps and extracting the values from the URL.

https://www.google.co.za/maps/@53.5292089,-113.291217,18.25z

So my latitude should be 53.5292089 and longitude should bee -113.291217 - give or take. I can now create my custom zone in the configuration.yaml file like so:

This is one post in a series of getting up and running with Home Assistant from scratch.

Today I would like to cover switching from the default SQLite database that Home Assistant uses over to MySQL - there is a slight performance update when making this switch, not to mention that it frees up valuable resources on my Raspberry Pi.

Why use MySQL?

My main driver for switching from SQLite to MySQL is performance and resources. If you have been following this series you will know that I am running my Home Assistant setup on a Raspberry Pi (through hass.io) for ease of use. This works amazingly well, however the throughput of the default database suffers due to the limited resources on the Pi.

I already have a MySQL Community Edition server running on my home network complete with weekly backups of some select databases. So for me it makes sense to create a new home_assistant schema on my server and gain the performance benefits over SQLite.

The process

The process to switch over to MySQL is pretty straight forward, and requires only 3 lines of configuration in Home Assistant (2 if you are not using a secrets.yaml file), and will comprise of the following steps:

Create a new database (schema) called home_assistant

Create an elevated user (with remote login) called hass_user associated with the new schema

Configure Home Assistant to point to your MySQL server

Restart Home Assistant and enjoy

Creating the database

Creating the database is as simple as connecting to your server through MySQL Workbench and clicking the create new schema shortcut, giving the schema a name and clicking create.

Once done you should have a new schema called home_assistant ready to go.

Creating the hass_user account

To create the hass_user account simply click on the Users and Privileges link found under the Navigator pane followed by the Add Account button at the far bottom.

Be sure to generate a strong password for the account, along with allowing all hosts % to connect as this user - this is important as the user account will be coming in from your Home Assistant server and not your MySQL servers localhost.

In terms of privileges for the account be sure to select what makes sense for your user (I was not 100% sure what to grant, so I gave my account DBA rights). I would suggest limiting the privileges for your setup, but my MySQL server does not face the internet, and the box it is running on is pretty boring to potential attackers.

Click OK to create the user account.

Configuring Home Assistant

We will need to configure the recorder component and tell it to store \ retrieve all state ans history information from MySQL instead of the default SQLite database.

In order to do this we will need to create a connection string for MySQL using the following structure:

mysql://<user>:<pass>@<host>/<schema>

In my case I would end up with a MySQL connection string looking something like this:

mysql://hass_user:PASS@10.0.0.50/home_assistant

I highly recommend storing any sensitive information like connection strings in your secrets.yaml file, and then referring the secret value in your configuration, to do this we will add our new connection string to the secrets.yaml like so ...

db_mysql: mysql://hass_user:PASS@10.0.0.50/home_assistant

... and then configure the recorder component in our configuration.yaml file like so (note: you may need to add in the recorder component to your file as it is omitted from configuration by default):

recorder:
db_url: !secret db_mysql

Once done be sure to validate your configuration and restart Home Assistant.

Enjoy the boost

After Home Assistant comes back up you should see that there are some new tables in your database, along with all the current state information for your home setup.

That's it, you are now using MySQL - now would be a good time to remove the default "home-assistant_v2.db" file from your Raspberry Pi.

Home Assistant will feel really fast now, this is mainly due to the fact that you have lost all your state information and will need to build it back up. However things should remain pretty quick even when things are back to normal (data wise) as shown here:

Hopefully you see the same performance gains as I did with the switch over to MySQL.

In Closing

Although this change is not a requirement for your home setup, and depending on the size / amount of data you are collecting and reporting on may not be required I still highly recommend it. It makes management of your database a lot easier and helps reduce the amount of resources being used on your Home Assistant host device. On the flip side this can be another potential point of failure for your setup, but it is unlikely as MySQL is super stable from my personal experience.

This is one post in a series of getting up and running with Home Assistant from scratch.

In this post we will be covering getting up and running with MQTT on Home Assistant - for the purposes of this post I will be working on the assumption that you have a local MQTT broker running on your home network. If you do not, you could always follow this post, or Google to find a tutorial for your OS.

What it MQTT

MQTT stands for Message Queuing Telemetry Transport and was originally developed by IBM roughly in 1999 as a light-weight, light-overhead messaging protocol. Since its inception the protocol has been adopted and standardised into the MQTT we know it as now - (more here http://mqtt.org/faq).

MQTT is basically a means of passing on messages from one device to another (or many) through a Pub Sub pattern allowing connected clients to pick and choose the messages that they are interested in hearing about. All messages flow through a broker of some sort which is responsible for maintaining the state of all connected clients and ensuring delivery of messages between them. With the broker doing all the heavy lifting the client-side code is extremely lightweight making it an ideal candidate for connected devices (IoT).

MQTT supports secure communication through SSL, but in most home setups the non-secure method is preferred (unless you are exposing your broker to the internet) as it uses a bit more memory \ processing power to encrypt and decrypt the messages.

Another cool feature of the MQTT standard is the support for QOS levels on your messages (read more here) which can range from a simple fire and forget message to guaranteed delivery of a message to the broker \ clients. This coupled with the ability to persist the last message in a topic is extremely useful in Home Automation as it allows you to ensure something important happens (e.g. locking your front door) but can ease up on the not so important things (like outside temperature = 23*).

The last feature offered by MQTT which is useful is the concept of birth messages and last will and testaments that a client is able to register when they first connect to the broker. The broker will send these messages on the client's behalf should it fail to check in (last will) or when they reconnect (birth). These messages are invaluable for Home Automation as it provides a simple form of heartbeat monitoring for connected clients.

Adding MQTT

Adding MQTT to Home Assistant is as simple as following the steps outlined in the MQTT documentation - however I do suggest breaking up your changes to store your sensitive configuration (i.e. passwords, IP Addresses, etc.) in your secrets.yaml file and then referencing them in the main configuration.yaml file.

To add MQTT to our current setup we will need to add the following lines to our secrets.yaml file:

After validating your configuration you are good to restart Home Assistant so it can download the required modules for MQTT to run.

If everything went well you should be able to see \ call the mqtt.publish service:

Troubleshooting

Should you run into trouble setting up MQTT, or do not see the mqtt.publish service above I would highly suggest looking at your Home Assistant log file for clues. Initially I had originally entered in the incorrect MQTT broker port, and was alerted to it through the following error message.

You are able to configure the default logging level used in Home Assistant through the logger component, my setup is normally configured as so ...

logger:
default: debug

… however you can set the logging level at a component level by simply including it’s namespace along with the logging level under the logger component. Let’s use the following message as an example:

After a quick reloading of the core components your new log entries should start appearing.

In Closing

I hope that you found this post both informative and helpful, and I am always open to any feedback that will help me produce better quality content. MQTT will open up a lot of doors when it comes to Home Automation (especially on the custom side of things) and will become invaluable as we start to expand the functionality of our home setup.

Objectives

In preparation for an upcoming blog post on the recorder and history component we are going to need some historical data to work with. I would like to keep tabs on the performance of our internet connection using the speedtest.net component, we will be doing this in the following steps:

Add the Speedtest.net sensor to Home Assistant

Create a group to display the measured values

Trigger initial data collection through a service

Customize our group

Process

Let's get started.

# 1 - Speedtest.net sensor

Looking at the speedtest sensor's documentation adding the sensor as a new platform under the sensor node. Once added there are a couple of options available on the conditions that you would like to monitor, in my case I am going to be collecting information about ping, download and upload speeds.

To do this we will need to add the following configuration to the configuration.yaml file:

The above configuration will run a speed test every 15 min (0, 15, 30 and 45 past the hour), these counters will be stored via the recorder & history components.

After a quick configuration check and reload of Home Assistant we can see our new counters in the status area:

# 2 - Create a group

I would prefer to have these counters displayed as a card in Home Assistant rather than in the status area. To do this we can simply create a group, list the components that we would like to see in the group and reload the core components of Home Assistant.

To create our group we will first need the component id's of our new counters, you can get the id's through the states view under the developer tools.

# 3 - Triggering data collection

At the moment we don't have any data from Speedtest (as it only collects every 15 min) so we can trigger the collection manually to get get our initial counters.

Most components in Home Assistant expose services which can be called either through code or via custom automation rules. Services can range from something as simple as getting \ setting a state on a component or running a complex command for the targeted entity.

You can easily see a list of all available services that you can call in Home Assistant through the services developer tool which is listed under the Developer tools section in the main menu.

The service we are interested in calling is the sensor.update_speedtest service, to do this select it from the drop down list and click the call service button to execute it.

Some services may require additional parameters to function correctly, if that is the case (as with the recorder component) the service will list all available parameters and a description for each one. Passing parameters to a service is as simple as creating a JSON object containing each parameter that you want to post as a property.

{ "keep_days": 7, "repack": false }

# 4 - Customizing our counters

Lastly I would like to do some basic customization of the collected counters, namely I would like to rename them and add a custom icon per value.

We can make these changes in the customize.yaml file by adding the following lines:

# 5 - Committing Changes

Final thoughts

This was one of the last posts where I will dive into so much detail around simple configuration tasks in Home Assistant. I will elaborate any topics that require it, but for now please keep the following in mind:

configuration.yaml - stores all configuration relating to adding new components and sensors to Home Assistant

Objectives

Today's objective is pretty straight forward, we are going to be adding some Philips Hue lights to our Home Assistant setup in order to control them from the Home Assistant application, and later use them in automation rules.

Groups

We will be working with groups in this post, and as the name suggests groups are a collection of things in Home Assistant that you would like to appear together on the same card in the Web UI.

By default, groups are defined in the groups.yaml file, which can be found in your Home Assistant's configuration folder. Groups are defined in YAML and follow the strict nesting structure of the markup.

You add entities (devices) to groups by using their fully qualified name (e.g. light.bedroom_light) which Home Assistant will parse and display. You can get an entities fully qualified name through the states section of the developer tools (at the bottom of the main menu):

Once there, find the entity that you are interested in adding to your group and copy it's Entity name.

Process

Let's get started.

#1 - Connecting the Hue Bridge

As per the norm, Home Assistant has made it really easy to connect to your Hue Bridge providing that Zero-configuration networking is enabled and your Hue Bridge is on the same network as Home Assistant. When you open Home Assistant in your browser you should see your Hue Bridge listed under the discovered devices card:

Click configure and follow the simple on-screen steps which require you to press the sync button on the Hub...

... followed by submit on the popup and waiting a few seconds.

It's that simple, and after a second or so you should see all your lights:

# 2 - Grouping lights together

As you can see above, all my lights were successfully imported into Home Assistant along with what seem to be doubles of each bulb. These "doubles" are actually the rooms (groups) I have defined in the Philips Hue application, and are intended to quickly turn on / off all the lights in a defined room.

I really don't need both the rooms and lights for my setup, and would prefer to simply have a group containing only the lights that I want to control. Thankfully this is a simple task to achieve through a group in Home Assistant, all we need for this to work is a name for the group and a list of the devices (lights) we want to group together.

As mentioned above you can get the names of your devices through the state view (under the developer tools section of the menu), as shown here:

To group the selected lights together all we need to do is simply add the following lines to the groups.yaml file making sure that we watch our spacing and get the entities names correct:

After validating our configuration and reloading Home Assistants Groups we are presented with the following:

# 3 - Customizing our lights

I am a visual person, and as such prefer to have the icons representing each light to differ from each-other for quick identification when scrolling through my Home Assistant devices. I would like each light to look different, and preferably to have an icon that represent more closely the shape of the light fixture.

Luckily for us such customization is possible in Home Assistant through the cuztomize.yaml file. In this file you are able to customize some basic characteristics of devices in Home Assistant, and event hide ones that should you want to. The syntax is simple (and well documented) making it easy to get up and running quickly. In my case I used the following configuration for my lights:

# 4 - Committing changes

The last thing left to do now is ignore any files that expose personal data, and commit our changes to GitHub.

If you haven't done so already you will need to add .config_entries.json to your git.ignore file before pushing your changes to GutHub (or whatever source control you are using). As the name suggests this file contains configuration specific to the devices in your Home Automation setup, and could potentially contain sensitive information such as an API key, MAC Address and so on:

I strongly suggest ignoring these types of files and manually backing them up on a schedule.

Final thoughts

There is just something magical about the consistency that Home Assistant has when it comes to its user interface (compared to the quickly thrown together application made by the hardware manufacturers). Add to that, the fact that Home Assistant is able to determine the capabilities of the connected device and present you the appropriate options makes it all that much better:

This is the UI for a Hue bulb:

This is the UI for a standard white bulb:

This is a good start to expanding out our Home Automation and will allow for some pretty awesome automation rules in the not too far future. There is a lot of power packed into Home Assistant, and we have a lot more ground to cover.

As always, I hope that you found this post useful and I welcome any feedback / questions below.

Obtaining your Plex Token

The first thing we will need to do is get a long-lived Plex token for Home Assistant to use when making calls to your Plex Media Server. If you look at the Plex Component page you will see that they refer to this method to get a token, however this is a temporary token and will expire after some time - so this is of no use to us.

What we want is a more permanent token, which is documented over here in the Plex documentation, and basically requires us to log into Plex using Postman and our Plex account, extracting and storing the more permanent “authentication_token” returned with a successful login.

Let’s do that now, first we will need to open Postman and configure it as shown below:

Click send to make the request. If you entered in everything correctly you should be greeted with a successful login:

In the response body you will see a property called “authentication_token” - this is what we want. Take note of the token as we will be using it in the next step.

Adding Plex to Home Assistant

As mentioned above the Home Assistant side of things is way simpler, provided that your HASS server is on the same network as your Plex Media Server and discovery (GDM) is enabled in Plex (as far as I know this is the default setting).

When you navigate over to HASS you should see a card similar to the one below telling you that Home Assistant has found an instance of Plex running on it’s network.

Click the configure button, and enter in the token collected above into the appropriate field as shown below:

Click confirm, and you are done. After a few seconds you should see a new card per plex enabled device currently on your network:

Any device currently watching something on Plex should pop up as a card like so:

Now you have the option to play, pause, stop, skip and change the volume on the streaming device:

Nice and simple.

Don’t commit personal files

Once Plex has been added to Home Assistant, and providing that you are following along with this series, a couple of new files should have been added to your Home Assistant directory, namely:

entity_registry.yaml - device registry kept by Home Assistant to help identify devices and customize their display names (you can find out more about the entity registry here)

These files are required for Home Assistant to do it’s thing, but should not be made public if you are using GitHub to manage your configuration like I do. We will need to add these two files to the .gitignore file to prevent accidental publication of your Plex token and home entities information, this is as simple as adding the following lines to your .gitignore file:

Do a manual backup

Until we cover an automated backup flow for your personal files in Home Assistant, now would be a good time to do a manual backup of the following files to a safe location - just in case.

entity_registry.yaml

secrets.yaml

plex.conf

This will allow you to quickly recover from accidental file deletion \ corrupt SD Card easily when paired with your public GitHub repository.

Final Thoughts

We finally have something to look at on our Home Assistant deployment (besides the welcome and discovery cards), but this is just the beginning.

In the next few posts we will be adding more and more components to Home Assistant in preparation for a post covering Groups and Views, which is one of the most useful features in Home Assistant.

There is still a lot of theory to go over, but at this series progresses I am going to be moving to a more high-level approach to it all, only diving in deep for important \ crucial concepts, otherwise linking to the official Home Assistant documentation.

As always I welcome any feedback, comments and questions.

]]>This is one post in a series of getting up and running with Home Assistant from scratch.

Objectives

Today I am going to be covering secrets and security in Home Assistant along with a semi-decent workflow to use with your Home Assistant deployment which will allow for easy management and

This is one post in a series of getting up and running with Home Assistant from scratch.

Objectives

Today I am going to be covering secrets and security in Home Assistant along with a semi-decent workflow to use with your Home Assistant deployment which will allow for easy management and rollback of your configuration.

Core Concepts

Before we dive right into locking down Home Assistant (known going forward as HASS) there are a few concepts we need to bed down first. Once you are familiar with the below HASS becomes a whole lot less scary and complex, and you should be making changes to your configuration in no time flat.

Components

Home Assistant could be though of as a framework for collecting, aggregating, managing and displaying data from IoT (or smart home) devices. The way this is achieved is through the use of custom components written for the "thing" in question.

Home Assistant components cover a wide plethora of devices from a simple store bought device (e.g. Phillips Hue) to something custom like an ESP8266 running custom code communicating over MQTT. Regardless of the thing you want to control Home Assistant will most likely have a component for it - this could be a generic component (e.g. MQTT Light) or a fully fledged one (e.g. Philips Hue Light).

Components are defined and configured through the configuration.yaml file, and is done so by adding in the component-specific keyword followed by any additional settings required. When Home Assistant starts up it loads this configuration file and sets up all your user-defined components. These loaded components are then managed bu Home Assistant and displayed to you through the web interface.

YAML

YAML is the preferred configuration file format used by Home Assistant, which in essence is a human-readable configuration file format which is unforgiving when it comes to the usage of spaces (think of Python).

YAML aims to have all configuration files consistent through its strict spacing rules (which can be a pain to debug), but that pain is worth it - believe me.

All the configuration we will be doing in Home Assistant will be done through this format, and by the end of this series I have no doubt that you will be used to it.

NOTE: In YAML spacing is everything!

Configurator

Configurator is an add-on that is available for Home Assistant when running their "all-in-one-image" on something like a Raspberry Pi or other supported single board computer.

In a nutshell Configurator is a web based text editor which allows you to make changes to your Home Assistant setup without the need to access the configuration files through some other mechanism (e.g. FTP / SSH/ File Share). It is simple to use and is great for making quick changes to your Home Assistant setup.

Configurator can be accessed through the Hass.io -> Configurator add-on as shown above.

Securing the web interface

The web interface for Home Assistant is controlled through the HTTP component.

In order to lock it down we will need to add the following configuration property under the http component section in your Home Assistant configuration.yaml file:

http:
api_password: "<password>"

Note: the additional (2 spaces) before api_password, if these are omitted you will run into issues.

Once done, save your changes and validate your configuration - this is done by navigating to Configuration on the side menu -> General -> Check Config. If your configuration is correct you should see the following response:

It is now safe to click the Restart button below to restart Home Assistant and apply your changes.

Home Assistant should now prompt you for your password.

That's all there is to securing your setup!

Using Secrets

The secrets.yaml file can be found in the same directory as your configuration.yaml file and is intended to store sensitive information for your setup.

This extremely simple, yet unbelievably powerful concept makes it easy (and safe) to share your configuration with the community without any sensitive information (e.g. your password). You can simply omit this file when you share your configuration with someone else.

I think that it is best to see this sort of thing in action though, so let's move our web interface password out of our configuration.yaml to allow us to "share" our configuration.

Add the following line into secrets.yaml:

http_password: your_password

Then modify configuration.yaml to use the secret version of your password instead of hard-coding it into your main configuration file.

http:
api_password: !secret http_password

Validate your configuration (like we did above) and restart Home Assistant.

Everything should still work as expected, that's all there is to it.

Version Controlled Configuration

The last thing I would like to cover today, although it's not required, is adding your configuration to some form of source control system (e.g. git). This will give you the freedom to confidently make changes to your home setup and roll back to any older version of your configuration should you feel the need to. This will give you more freedom with your setup as you will always have a fall back should something go wrong.

Personally I will be storing my configuration on a public GitHub repository to serve as my personal backup and as a supplementary repository for this series. I will be using Gitkraken on my Windows computer and managing the configuration through a mapped file share (set up in the last post using Samba). This is more for convenience for me than anything else as I already have Git setup on my computer with my SSH keys.

Create your repository

Head over to GitHub and create a new repository for your configuration to live in:

Once created check it out with Gitkraken to any folder on your computer, we will be moving it shortly.

Be sure to open, initialize, commit and push your changes back to GitHub - don't worry Gitkraken will prompt you for these steps, once done your first commit should be live:

Copy your current configuration

Copy everything from your Home Assistants configuration folder (e.g. \\10.0.0.103\config) into the root folder where you checked out your GitHub repository.

NOTE: If you run into access issues try changing the following registry key \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\AllowInsecureGuestAuth to 1 - it did wonders for me.

Once we have our files in the folder we will need to add a .gitignore file to exclude our secrets.yaml file and any other non-essential files from being committed. To create the .gitignore file open a command prompt window, navigate to your repository folder and run this command.

"" > .gitignore

Open the .gitignore file and add the following exclusions to the file.

Overwrite HASS Config Files

Now that we are happy with our git setup we can move all our files back over to our Home Assistant server making sure to replace any conflicting files. Essentially we are just moving the .gitignore and .get file and folder over.

Close Gitkraken, delete your temporary repository (checked out above), map your remote configuration folder (in my case H:) and open it back up in Gitkraken.

Now any changes you make to Home Assistant via Configuration can be tracked and committed to version control.

Final Thoughts

Although this was a long post, we only covered the 3 S's of our Home Assistant setup (security, secrets and source control), in addition to that I covered some basic concepts that we will use going forward in an effort to save time later on. Armed with this you now know enough to be dangerous :).

In the nest post we will finally look at doing something with the UI and perhaps adding in a device or two.

As always I welcome any feedback, comments and questions.

]]>This Series

This series of posts will cover setting up my Home Assistant setup from scratch back to, and beyond my old setup I was running back in South Africa. Our little family picked up and moved to Canada at the end of 2017 and recently purchased a property, now

This series of posts will cover setting up my Home Assistant setup from scratch back to, and beyond my old setup I was running back in South Africa. Our little family picked up and moved to Canada at the end of 2017 and recently purchased a property, now I have free reign to re-imagine my Home Automation setup from the ground up. Rather than me just doing it, I though that it would be beneficial to document everything for someone just starting out and finding everything a bit overwhelming.

Please be sure to keep checking back on this post as I will be updating the list below with all future posts relating to this topic.

Installation

This post will cover the bare bones installation of Home Assistant on a Raspberry Pi 3 using the Hass.io image. In addition to the installation I will cover the setup of some core plugins to ensure that you get the most out of your Home Assistant installation.

Hardware

With my initial Home Assistant setup I was running everything on Windows which worked perfectly fine. However I have been wanting to test out Hass.io as it offers a simpler way of managing your Home Assistant installation, updates and configuration.

For a case I am using one of my own designs as I am planning on mounting it on a pegboard along with all my other Single Board Computers (SBC), this way the cable management is a lot better and it keeps my desk free of additional clutter.

Note Use a class 10 or above SD card for this installation, anything slower becomes unbearably noticeable in the long run.

Flashing the Software

For this installation I am going with Hass.io, which is a all in one image for your SBC and installation could not be simpler. All you need to do is burn the image to your SD card using an application like Win32 Disk Imager or Etcher like so:

Ensure that the correct SD card is selected, then hit the Write button to burn the image.

That's all there is to flashing, nice and simple.

First Boot

Once you have the Hass.io image on your SD card insert it into your Raspberry Pi, connect a network cable (WiFi is not a great idea for HASS imho), screen and power cable to boot your Pi. You should see the following screen when Home Assistant is configuring itself. If you do not see this, it is possible that your image may have not been burnt correctly and you may need to try again.

If you navigate over to http://hassio.local:8123 by default, or http://PI'S-IP-ADDRESS:8123 you should see the following welcome screen:

As stated above this can (and will) take a while to complete, initially I though that my RasPi has frozen and rebooted it only to have to go through the whole waiting process again (be patient!). After about 20 min the browser should refresh and present you with a vanilla installation of Home Assistant.

Add-ons

Now that we have a functioning installation of Home Assistant, it's time to take advantage of the nifty features offered by Hass.io. The biggest draw for me is the ability to install add-ons which extend the functionality of your installation and allow for quick and easier configuration of common features you would have otherwise would have done manually.

For this installation I am going to start off with some of the more common plugins that most people will need right out of the box, these are namely:

To install add-ons you will need to click the side menu button -> Hass.io -> Add-on store (Tab) to display a list of the currently available add-on's under the Community Hass.io Add-ons repository. You are free to add 3rd party repositories to get even more out of your installation, bur for now I will stick with the defaults.

#1 - Configurator

The Configurator add-on gives you the ability to edit your Home Assistant configuration files in your browser with no need to mess around with file shares. This is great when you want to make a quick change to Home Assistant.

Installation is straight forward, just click the install button and wait for the task to complete. Once installed you will need to set a desired username / password under the configuration section.

{
"username": "<username>",
"password": "<password>",
}

In addition to setting up credentials for yourself you will also need to ensure that you white-list your home IP Range for access (if you do not do this you won't be able to access the web UI), again this is a setting under the configuration section.

"allowed_networks": [
"10.0.0.0/16"
],

In my case I am allowing all IP Addresses in the 10.0.0.0/16 range.

Once that's done ensure that Start on boot and Auto update are enabled, then click Start to fire up Configurator.

If all went well, clicking Open Web UI should launch a new browser tab, prompt you for your credentials and show you the editor.

#2 - SSH Server

By default SSH access is disabled on the Hass.io image, and this is where the SSH Server add-on comes in handy. This will install an Open SSH server on your device and allow you to SSH into your SBC to make changes, install software or control Home Assistant via their command line tools.

Installation is as simple as selecting the add-on from the store. Once installed you will need to set a password via the Config section (remembering to save).

{
...
"password": "<password>"
}

Like we did with Configurator, ensure that Start on boot and Auto update are enabled, then click Start.

Using a tool like Putty or MobaXterm attempt to connect to your RasPi (using it's IP Address) and the root user account along with the password that you specified. If all goes well you should see the following welcome screen.

#3 - Samba share

The last add-on that I want to cover for now is Samba, although it is not technically required when using Configurator it is extremely useful should you want to manually back up your files from your Windows computer. I normally use the backup feature of Hass.io along with a weekly manual backup of the generated files and using Samba makes it a lot easier for me.

Once you have installed Samba from the Add-on store we will need to make the following configuration changes under the Config section:

{
...
"username": "<username>",
"password": "<password>"
}

Ensure that Start on boot and Auto update are enabled then start the add-on. Open an explorer window and navigate to your servers address, when prompted for credentials enter them in and enjoy!

Deployment

Once you are happy with the base setup of your Home Automation platform, it is time to move it off your desk into a more permanent location. For me this is on my pegboard along with a whole host of other devices (we will cover later on), and thanks to my case it is "neatly" out of the way.

Although this was a long post we only scraped the surface of Home Assistant and have a long way to go before my setup is back to functioning normally. I plan to document every step of my setup no matter how small and trivial it may seem as if I can help out one person just starting out it will be all worth it.

Don't forget to bookmark this post if you would like to follow along as I will be updating the posts section with each new entry.

Feel free to leave any comments / feedback / questions below and I will do my best to get to them.

]]>While migrating some of my blog posts over from my old blog to this one I stumbled upon a program I wrote in 2011 when I started learning C# (to give you an idea of the age of this guy, it was written in .net 2.0!).

While migrating some of my blog posts over from my old blog to this one I stumbled upon a program I wrote in 2011 when I started learning C# (to give you an idea of the age of this guy, it was written in .net 2.0!).

With some nostalgia I opened the project in VS and ran it, to my surprise it worked with no issues.

While looking through the original source code I cringed at all the bad practices in play (and the nasty 4 space tabs!) - i decided it was high time to upgrade the project to run under .net 4.5, add some comments to the code, fix the poor naming conventions used and add it to source control.

What does it do?

In a nutshell the Alert Maker application does just what its name says, it will allow the user to write a custom event log entry into a targeted Windows event log. This was useful to me at the time as I was developing custom management packs for SCOM 2007 R2 and I needed a quick way to trigger of monitored events.

In addition to being able to write custom messages to an event log I had also added the ability to create your own event source to use when writing these entries (again this was needed for my management pack development).

Usage

Usage is pretty simple, all you need to do is complete the “Form” by selecting \ filling in the information you wish the see in the targeted event log like so:

Once you are happy with the selected values, click the Create Event button to fire it off. Your event should land in the targeted log file under the desired source:

That’s pretty much all there is to it, hopefully you found this little trip down memory lane somewhat interesting, or at worst case found a use for this application.

Feel free to fork the code and make any changes you want to it, I also accept pull requests :)

Step 2: Download Tasmota

You are going to need the latest stable build of the Tasmota firmware, you can download it from the below link (please be sure to download the Source Code (zip) release).

https://github.com/arendst/Sonoff-Tasmota/releases

Once downloaded, extract the contents of the zip file to a local folder on your computer and ensure that your Arduino IDE is closed - we are going to be updating your Arduino's libraries folder with the ones included in the Tasmota zip file. To do this you will need to copy all contents from ...

C:\<extracted-folder>\Sonoff-Tasmota-x.xx.x\lib

... into ...

C:\Users\<user>\Documents\Arduino\libraries

... making sure that you replace any existing versions of any of the required libraries you may have - this saves a huge headache when it comes to compiling the firmware later on.

NOTE: ensure that you replace any existing libraries with the ones provided!

Step 3: Configure Tasmota

This is the section where all the magic happens, and shows how much work has been put into the actual Tasmota firmware by the developers. Unlike my original flashing guide this method is 100 times simpler and more robust should your network become completely unreachable to your Sonoff device.

The only configuration change we are going to make to the Tasmota firmware is tell it to enter into WIFI_MANAGER mode whenever it is unable to connect to any of the configured WiFi networks, in this case the Sonoff will enter Access Point (AP) mode and host it's own WiFi network for you to connect to and configure the device. No more hacking about in configuration ever!

We will need to open the "project" in the Arduino IDE, locate and open the sonoff.ino sketch file in the unpacked Tasmota firmware folder, in my case it was found here:

C:\Users\Richard\Downloads\Sonoff-Tasmota-5.12.0\sonoff\sonoff.ino

Once open locate the userconfig.h file in the open tabs as shown below:

Locate the following line ...

#define WIFI_CONFIG_TOOL WIFI_WPSCONFIG

... and replace WIFI_WPSCONFIG with WIFI_MANAGER like shown below.

#define WIFI_CONFIG_TOOL WIFI_MANAGER

That's all we need to do for our configuration, it's that simple.

Pro Tip: Make a Flash Cable

I find that the simplest way to flash my Sonoffs is to make my own flashing cable using 4 (or 5) Dupont cables. I normally use a female header to align them, and join them together using some super glue and a bit or cardboard.

Once I have made my "programming header / cable" I use one of my Arduino UNO boards with the processor removed as an ISP flasher. The connection from my cable to the Arduino UNO board is as shown in the below diagram (please note the orientation of the Sonoff board).

This method of connecting to the Sonoff saves me a lot of time / solder and male header connectors - just be sure that you are making a good electrical connection to the programming headers when flashing the sketch!

Step 4: Verify the Firmware

The next thing we need to do before attempting to flash the Tasmota firmware to our device is to compile it. Depending on your computers performance this could take a while, and provided on whether you copied the libraries or not, you may need to address some compilation issues.

Before we can compile we will need to make sure that our Arduino IDE is configured correctly for the Sonoff device - please ensure that your settings are as shown below:

Once you have verified, and are happy with your board configuration press the tick to start compiling / verifying the firmware (this can take a while). Hopefully everything goes well and you end up with a success as shown below.

Step 5: Connect your Sonoff

Next we will need to connect an ISP to the programming headers on your Sonoff device, depending on what ISP you are using this can vary slightly, however the general principal is the same. As mentioned earlier I am making use of an old Arduino UNO board with the processor removed as my programmer. Below you can see how I hooked it all up.

NOTE: Read below before powering up your ISP / Sonoff

In order to flash the Tasmota firmware we are going to need to place the Sonoff into flashing mode when powering it up, this is pretty simple and is achieved by the following steps:

Ensure that your Sonoff is disconnected from mains!

Ensure that your Sonoff is off

Press and hold down the button of the Sonoff

Connect power to the Sonoff (i.e. plug in your ISP) while keeping the button pressed

Wait 5 seconds and release the button

If done correctly the light on the Sonoff should remain off, if it is flashing your timing was out and you will need to disconnect the power and try again.

Step 6: Upload the firmware

When the connection has been made, and the Sonoff is in flashing mode (done by holding down the push button when powering up the device), press the upload button in the Arduino IDE to flash Tasmota to your device. The upload will take a while to complete and should output as shown below:

After the upload has completed your Sonoff should reboot and blink the green status LED indicating that it was unable to connect to a WiFi network, and as a result is in configuration / access point mode.

Step 7: Connect and configure

When your Sonoff first powers on it won't be able to connect to your WiFi network and will put itself into Access Point mode, this is indicated by the rapidly flashing green LED above. When the Sonoff is in AP mode it will create its own WiFi network that you can connect to with your phone / laptop and configure, in my case the sonoff-2399 network was created.

Connecting to this WiFi network should launch your web browser and bring up the Tasmota configuration page, here you are free to configure the Sonoff device as you would normally do, once complete just restart the Sonoff and it will boot up using the new settings and connect to your home WiFi network.

Pro Tip: Use Fing for a good time

If you are like me and want to assign a static IP Address to your Sonoff once it has booted, or do not know what the initial IP Address assigned to it by your router is you can make use of Fing on your mobile device to discover your Sonoff:

Once you know the IP and MAC address of the Sonoff you can make it static on your router :)

Final thoughts

Although this was a long post I do feel that the overall process of flashing the Sonoff was a log simpler and quicker, thanks to the following factors:

This is a quick reference post to get you up and running with anESP8266 / ESP32 using the Arduino IDE.

Step 1 - Get Arduino

You can download the latest version of Arduino here, be sure to select the correct version of the IDE for you computer.

https://www.arduino.cc/en/Main/Software

Once you have downloaded the IDE, install it as you would any other application.

Step 2 - Add ESP8266 package Source

Open the Arduino IDE and navigate to File -> Preferences.

Locate the Additional Board Manager URL's section...

... and enter in the following json feed URL

http://arduino.esp8266.com/stable/package_esp8266com_index.json

This is the latest package feed for the ESP8266 project (the micro-controller powering your Sonoff switch) and is required to flash the Tasmota firmware.

Step 3 - Install the boards package

Next you will need to install the ESP8266 boards package which includes all the required files & tooling needed to compile and upload your sketches to your micro-controller.

To do this navigate to Tools -> Board: xxx -> Boards Manager.. from the Arduino IDE's main menu.

Search for and install the esp8266 boards from the ESP8266 Community, the download is approximately 200 Mb so it may take a while to complete depending on your internet connection.

Step 4 - Blink

After you have installed the ESP8266 boards you should now load up the obligatory Blink / Hello World tutorial from the newly installed board examples.

Ensure that your board settings are correct for your ESP - this can vary a lot depending on your development board, but thankfully there are a lot of pre-configured settings for all of the common ESP boards.

Finally hit the upload button and wait for the upload to finish. If your board is blinking the built in LED you are done, if not now would be a good time to do some troubleshooting. The most common issue in my experience with sketch uploading failing is due to some incorrect parameters for the board, here Google is your friend and should have you back up and running in no time!