Search

Lazy Man Joe's Ramblings

Category

Stuff

Adding a NUT [Network UPS Tools] sensor to Home-Assistant.io

So in my previous post I showed how to add NUT to Ubuntu and XigmaNAS – with this all working the next step is to add a NUT sensor to Home-Assistant.io

I’m running Home-Assistant in a Docker container, but previously had it running on a Raspberry Pi (using HASS.io) – I will post how I moved from RPi to Docker in future.

Configuration:

It’s fairly easy and you only have to add the following lines to your home-assistant configuration.yaml file:

under the sensors section

sensor:
- platform: nut
name: Eaton UPS
host: 192.168.2.5
port: 3493
alias: EatonUPS
username: mynas
password: your_password_goes_here
resources:
- ups.load
- ups.realpower.nominal
- input.voltage
- battery.charge
- battery.runtime
- ups.delay.shutdown

The username & password settings are the ones you configured when you set up NUT on Ubuntu.

Reload/restart Home-Assistant to make sure the config is updated.

This is what I get:

screenshot 2019-01-07 at 18.20.08

That’s it !

This sensor attributes are now available on your Home-Assistant to query and use in Node-Red flows, etc. !

screenshot 2019-01-07 at 18.27.30

Isn’t it JUST AMAZING ?

Have fun !

Advertisements

Setting up an Eaton 5E650iUSB UPS on Ubuntu [master] & XigmaNAS [slave] with USB monitoring using NUT [Network UPS Tools]

We’re running 2 “old” HP N40L Microservers at home and they’ve been working great for the last few years [I think I got them in 2011 !]

The one is running XigmaNAS  [a free NAS based on FreeBSD] and the other is running Ubuntu 18.10 [we use this to run a few Docker containers].

As we’ve been experiencing so-called “Load-shedding” again in South Africa in the last couple of months, it is imperative to have some sort of backup power to allow the servers to shutdown in a controlled manner [I’ve lost a drive on the NAS in the past due to multiple power outages/spikes :-(]

I purchased an Eaton 5E 650i UPS which has a USB interface.

I’m using the UPS on the Ubuntu machine as the “master” and on XigmaNAS, I’ve configured it as a “slave” – this means when the power goes out and the UPS is running low on battery, the “slave” will shutdown 1st and then the “master”.

Here are the steps I followed to make this work:

Step 1 – install NUT

You can find information on NUT [Network UPS Tools] on their website.

Basic step is:

sudo apt-get install nut

Step 2 – Configure

Driver setup – UPS.CONF

Now you need to configure the /etc/nut/ups.conf file
By default this file does only contains samples [in comments]
Add the following:
[EatonUPS]
    driver = usbhid-ups
    port = auto
    vendorid = 0463
    pollfreq = 30
    desc = "Eaton UPS on MyServer"
For the Eaton UPS, the driver is listed as usbhid-ups on the NUT compatibility site
port is auto for USB
I had to get the vendorid as it would not start up without specifying it.
Vendorid was checked with the following command – lsusb:
$ lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 005: ID 0463:ffff MGE UPS Systems UPS
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
So when you configure it for yourself, you can confirm the vendor ID for your own device using the lsusb command.

User access – UPSD.USERS

Now you have to configure the users who can access the service – edit the /etc/nut/upsd.users file
[upsmon]password = "your_password_goes_here"
upsmon master

[mynas]
password = "your_password_goes_here"
upsmon slave

[admin]
password = "your_password_goes_here"
actions = SET
instcmds = ALL
Format:
[username]
password – your password
and then tell upsmon whether it will be the master or slave user [slave for other ups monitoring on the network]
The [admin] user is for some UPS specific settings changes [like beeper disable – see later]

Allow for multiple monitoring points – NUT.CONF

Configure NUT as netserver – so multiple devices [like LazyNAS] can also monitor it
Edit the /etc/nut/nut.conf file and set mode to netserver [if only for local, you would make it standalone]
MODE=netserver
You now need to let the UPSD service know on which network interfaces to listen – edit /etc/nut/upsd.conf
LISTEN 127.0.0.1 3493
LISTEN 192.168.2.5
Localhost is 127.0.0.1 and our internal network interface is 192.168.2.5

TEST your configuration

Ok now to start all the stuff !
Run this command
sudo upsdrvctl start
Results when successfully started:
Network UPS Tools - UPS driver controller 2.7.4
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
Using subdriver: MGE HID 1.39
Then the moment of truth for checking the status:
Use the upsc command to connect to the service and get info on the EatonUPS UPS
upsc EatonUPS@192.168.2.5
Results:
Init SSL without certificate database
battery.charge: 100
battery.runtime: 1192
battery.type: PbAc
device.mfr: EATON
device.model: 5E 650i
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.parameter.vendorid: 0463
driver.version: 2.7.4
driver.version.data: MGE HID 1.39
driver.version.internal: 0.41
input.voltage: 241.0
outlet.1.status: on
outlet.desc: Main Outlet
outlet.id: 1
outlet.switchable: no
output.frequency: 49.9
output.frequency.nominal: 50
output.voltage: 238.0
output.voltage.nominal: 230
ups.beeper.status: disabled
ups.delay.shutdown: 20
ups.firmware: 03.08.0018
ups.load: 26
ups.mfr: EATON
ups.model: 5E 650i
ups.power.nominal: 650
ups.productid: ffff
ups.start.battery: yes
ups.status: OL
ups.timer.shutdown: -1
ups.vendorid: 0463
Success ! 🙂

Step 3 – Disabling the BEEPER !

By default the beeper is set to ENABLED.
It will beep on start-up and on loss of power AND when it’s about to shutdown – NOISY !!!
So to check the current beeper status, you can run this command [on the localhost]:
upsc EatonUPS ups.beeper.status
To change the status to DISABLED, use the upscmd utility:
upscmd EatonUPS beeper.disable
Username (lazyserver): admin
Password:
OK
This would use the user [admin] /password created in the /etc/nut/upsd.users file earlier
Now the status will be disabled & it won’t disturb you when the power goes out in the middle of the night !

Step 4 – Configure XigmaNAS to also monitor this UPS as a slave device

XigmaNAS has a UPS option under Services -> UPS
screenshot 2019-01-06 at 16.25.09
Configure the following:
Mode: Slave
Identifier: EatonUPS    [this is the name as defined on the Ubuntu machine (lazyserver) for the UPS]
IP Address: 192.168.2.5 [this is the ip address of the machine with the UPS linked to via USB]
Shutdown mode: UPS reaches low battery   [ to ensure it will only shutdown after it’s been on UPS for a while & power did not come back]
Username: mynas  [as defined in the /etc/nut/upsd.users file]
Password: your_password_goes_here  [as defined in the /etc/nut/upsd.users file]
Enable the service (tickbox & save & restart) and check the logs to confirm it is working.
On homepage, you should see status in UPS section at the bottom
screenshot 2019-01-06 at 16.28.33
For more detail you can click on the “Show UPS Information” link and you will see all the detail:
screenshot 2019-01-06 at 16.29.58
That’s it !
Next steps would be to configure XigmaNAS to send you emails, etc. – but that’s standard functionality when you setup XigmaNAS – so not covered here.

References

The following links helped a lot with my setup.

Setting up a DuckDNS Docker Container to handle dynamic IPs for your home server

THE WHY:

We have a fibre connection at home and like most of the home setups, you will be assigned a new external IP address every time your router re-connects, or when your lease is renewed by your ISP (whenever they feel like it :-))

As we want to expose some of our internal server(s) [Docker containers] to the outside world, and be able to access it via a URL which we know, we’ve in the past opted to use NOIP.com. The free version of NOIP.com allows for up to 3 hosts to be configured, on one of the domain names they offer – like mydomain.ddns.net (just an example).

If you want to use your OWN domain, then you need to purchase a PLUS DNS Management package.

ENTER – DuckDNS.org !

DuckDNS.org is a free service (running on AWS) which allows for the creation of known URLs linked to your dynamic IP address (similar to noip.com)

You will typically get a URL like mydomain.duckdns.org – BUT you can update that (via your domain registrar/DNS provider) to point to your own configuration – like http://www.mydomain.com.

You still need to update your IP address with DuckDNS to make sure it has the latest IP address assigned to you and this is where the DuckDNS Docker container comes in handy.

DOWN TO BUSINESS … [HOW ?]:

Ok, after that long-winded intro here is how I configured the following domain – http://www.greystormydesigns.com to point to a locally hosted WordPress container (running on Docker) and hosting my wife’s blog.

Step 1 – Setup a DuckDNS Account

Go to DuckDNS.org
Register to get access [Free]
Once registered, you will get an access token assigned to your account.
You can now also select to add a unique sub-domain to duckdns.org and link it to your account.
We added greystormydesigns.duckdns.org to my account.
screenshot 2019-01-05 at 16.16.34

You also have the option on this screen to manually update the external IP address assigned to you by your ISP.

You now have a URL (greystormydesigns.duckdns.org) which points your IP assigned to your router. (although at this point it probably won’t do anything as you still have to configure a couple of other things to make it all work)

Step 2 – Docker container for DuckDNS updates

As your IP address assigned to you by your ISP changes all the time, you need to let DuckDns.org know about these changes to make sure that the IP on their side always resolves correctly to your environment.

Fortunately there is a docker container to assist with this.

Check hub.docker.com to see the DuckDNS container maintained by the linuxserver.io team [they do some AWESOME stuff ! – I’m using some other containers maintained by them and will cover this in later posts]

NOTE: I won’t go into how to get Docker installed in this post and assume you already have docker up and running.

So from the command line, I used the following to pull the latest DuckDNS container and creating it on Docker:

docker create –name=duckdns –restart unless-stopped \
-e TZ=Africa/Johannesburg \
-e SUBDOMAINS=greystormydesigns \
-e TOKEN=*******-****-****-****-***** \
linuxserver/duckdns

Let’s unpack that a bit:

name = this is the name of your container for your own reference

–restart unless stopped = this tells docker to restart the container if something goes wrong, except if you specifically stopped it

-e TZ = sets the timezone

-e SUBDOMAINS= this is the important bit for DuckDNS – it let’s them know which domain you want to update – you only specify the 1st bit (greystormydesigns.duckdns.org)

-e TOKEN= this needs to be your token assigned to your account when you registered

and then lastly the name of the container to pull from hub.docker.com – linuxserver/duckdns

With all this done, the docker container should be created and ready to be run.

All you now have to do is run the container on docker and it will update the IP address on DuckDNS.org every 5 minutes.

A typical start-up log will look like this:

-------------------------------------
          _         ()
         | |  ___   _    __
         | | / __| | |  /  \
         | | \__ \ | | | () |
         |_| |___/ |_|  \__/
Brought to you by linuxserver.io
We gratefully accept donations at:
https://www.linuxserver.io/donate/
-------------------------------------
GID/UID
-------------------------------------
User uid:    ***
User gid:    ***
-------------------------------------
[cont-init.d] 10-adduser: exited 0.
[cont-init.d] 40-config: executing...
Retrieving subdomain and token from the environment variables
log will be output to docker log
Your IP was updated at Sat Jan 5 16:47:04 SAST 2019
[cont-init.d] 40-config: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.

So that’s it – you now have a docker container running which updates your dynamic IP address on DuckDNS.org every 5 minutes.

We’re almost there – just a couple of small things to complete !

Step 3 – Update you router to allow for port-forwarding to your locally hosted website

Port-forwarding can be tricky (and risky), so please be careful with this setting if you’re not 100% sure what you’re doing. 🙂

I suggest you search google for instructions on configuring port-forwarding on your specific router.

Please note that most routers have this option and you would not have to buy anything …

I have an Asus Router and configured the port-forwarding on the WAN side – pointing to my internal server (192.168.2.5) on port 8080.

So this rule routes all external port 80 calls to the internal network to a server running on 192.168.2.5 port 8080

screenshot 2019-01-05 at 17.00.30

Step 4 – Update the CNAME-record on your domain DNS to point to the DuckDNS.org configuration

As you now have a DuckDNS.org subdomain (greystormydesigns.duckdns.org) pointing to you server, you can add a CNAME record on your DNS provider link these together.

I registered our domain on Doster.com and from the configuration panel, I updated the CNAME Alias entry and added www pointing to greystormydesigns.duckdns.org

screenshot 2019-01-05 at 17.09.43

That’s it !

All should work fine now.

Hitting www.greystormydesigns.com should open the Blog site 🙂

I hope this helps someone in future and that they will support the efforts of the DuckDNS.org team by donating to them !

Have fun !

 

GardenPi – a garden watering solution built on Raspberry Pi, MQTT and Home-Assistant.io [Part 4/4]

Following on from PART 3

Now that Home Assistant is aware of the Garden Zones, we can “program” some automations in Node-Red.

For now I’ve only implemented a rudimentary little flow:

  • I have 4 different flows to handle each of the zones separately, but I do make sure (manually) that they’re not conflicting with each other (i.e. 1 zone’s start-time is AFTER the end-time of the previous zone, etc.)
  • As it’s winter at the moment here in South Africa, I’ve opted to only water the garden 2 x a week and for only 10 minutes in each zone.

 

My flows looks like this:

GardenPi_NodeRed

And the schedule is as follows (currently Mondays and Thursdays):

GardenPi_Zone1_Schedule

And to make it easier for me, I used a “switch”-node to split the flow based on some logic (if the payload is “on” or “off” then go route 1 or 2)

GardenPi_Zone1_SwitchNode

For the “ON” payload, I use the “call service”-node to call the switch and switch it ON (Home-Assistant handles the mqtt messaging in the background):

GardenPi_Zone1_SwitchOn

At the end of the flow I have a “msg”-node for debugging purposes, which I will probably remove in future.

GardenPi_Zone1_Debug

So a bit of a long-winded 4-part post, but wanted to capture all the aspects of the process.

Future work will include adding some “intelligence” like checking the probability of rain, possible sensors in the ground to check humidity, etc.

Anyways – it’s been LOTS of fun and a great learning experience.

 

GardenPi – a garden watering solution built on Raspberry Pi, MQTT and Home-Assistant.io [Part 3/4]

Continued from PART 2

With all the puzzle pieces in place, now we can make Home-Assistant aware of the Garden Zone “switches”, so we can program and use the in automations.

In the switches.yaml file (remember I split the configuration for switches out into their own file), under the platform: mqtt section I added the Garden Zones / Switches:

platform: mqtt
name: "Garden Zone 1"
command_topic: "lazyhome/garden/output/zone1/set"
state_topic: "lazyhome/garden/input/zone1"
qos: 1
payload_on: "ON"
payload_off: "OFF"
retain: true
- platform: mqtt
name: "Garden Zone 2"
command_topic: "lazyhome/garden/output/zone2/set"
state_topic: "lazyhome/garden/input/zone2"
qos: 1
payload_on: "ON"
payload_off: "OFF"
retain: true
- platform: mqtt
name: "Garden Zone 3"
command_topic: "lazyhome/garden/output/zone3/set"
state_topic: "lazyhome/garden/input/zone3"
qos: 1
payload_on: "ON"
payload_off: "OFF"
retain: true
- platform: mqtt
name: "Garden Zone 4"
command_topic: "lazyhome/garden/output/zone4/set"
state_topic: "lazyhome/garden/input/zone4"
qos: 1
payload_on: "ON"
payload_off: "OFF"
retain: true

You can name the switch anything you want, as this will be the user-friendly name in the Home-Assistant homepage.
The important bits are the command_topic and state_topic sections – these need to align to the configuration you have on your Raspberry Pi with it’s mqtt listener.

I also created some “Groups” (groups.yaml) for Home Assistant to group my different switches into logical sections:

Geysers:
name: Geysers
entities:
- switch.bedroom_geyser
- switch.upstairs_geyser
Garden:
name: Garden
entities:
- switch.Garden_Zone_1
- switch.Garden_Zone_2
- switch.Garden_Zone_3
- switch.Garden_Zone_4

Please note that the switches have “_” to replace the spaces in the names

After updating the configuration, restart HASS and your switches should show up in it’s own group 🙂

GardenPI_Zones

And that’s it !

Home Assistant is now aware of the switches AND you can switch them using the on-screen toggles (which kicks off some mqtt messages in the background, which the Raspberry Pi picks up, switching the relevant GPIO pin, which in turn switches the relay !)

Phew !

😀

GardenPi – a garden watering solution built on Raspberry Pi, MQTT and Home-Assistant.io [Part 2/4]

So in GardenPi – PART 1 I covered the hardware & software configs to get going, but that’s not all yet 🙂

We now have a Raspberry Pi running MQTT and we can switch the GPIO pins by sending messages on the queue.

Next steps:

Connect the pins from GPIO to the relay board

This was fairly easy as the 8 port relay board I used had small pins I could connect directly via small cables from the GPIO pins
As the board also make use of 5V, I used the PWR connector (PIN 2 [5V] and PIN 6 [GND] on the Raspberry Pi) to power the relay board.
I would only be using 1 of the relays at a time, so the power usage will be minimal to draw power directly from the Raspberry Pi.

gardenpi-test-before-boxing.jpg

Make sure MQTT starts at power-on of the Raspberry Pi

To make sure we have a consistent experience, we need to make sure MQTT is started on power-on / reboot of the Raspberry Pi.
I used Supervisor for this as it makes it much easier to set up items which need to start when the Raspberry Pi is restarted.
They cover the configuration of Supervisor in the Pi-MQTT-GPIO setup instructions and I followed it – except I DID NOT set up a virtual environment, as my Raspberry Pi will be dedicated to it’s job.
Basically you install Supervisor;
Then create a /etc/supervisor/conf.d/pi-mqtt-gpio.conf file with your config information for pi-mqtt-gpio [/home/pi/config.yml].
My pi-mqtt-gpio.conf looks like this:

[program:pi_mqtt_gpio]
command = /usr/bin/python -m pi_mqtt_gpio.server /home/pi/config.yml
directory = /home/pi
redirect_stderr = true
stdout_logfile = /var/log/pi-mqtt-gpio.log

and my config.yml file looks like this:

mqtt:
host: 192.168.xxx.xxx
port: 1883
user: “xxx”
password: “xxx”
topic_prefix: lazyhome/garden

gpio_modules:
- name: raspberrypi
module: raspberrypi

digital_outputs:
- name: zone1
module: raspberrypi
pin: 5
on_payload: "ON"
off_payload: "OFF"
initial: low

- name: zone2
module: raspberrypi
pin: 6
on_payload: "ON"
off_payload: "OFF"
initial: low

- name: zone3
module: raspberrypi
pin: 13
on_payload: "ON"
off_payload: "OFF"
initial: low

- name: zone4
module: raspberrypi
pin: 19
on_payload: "ON"
off_payload: "OFF"
initial: low

digital_inputs:
- name: zone1
module: raspberrypi
pin: 5
on_payload: "ON"
off_payload: "OFF"
pullup: yes
pulldown: no

- name: zone2
module: raspberrypi
pin: 6
on_payload: "ON"
off_payload: "OFF"
pullup: yes
pulldown: no

- name: zone3
module: raspberrypi
pin: 13
on_payload: "ON"
off_payload: "OFF"
pullup: yes
pulldown: no

- name: zone4
module: raspberrypi
pin: 19
on_payload: "ON"
off_payload: "OFF"
pullup: yes
pulldown: no

4 Zones, each with settings for digital_output and digital_input.

OK – so now hardware connected and Raspberry Pi will start the PI-MQTT-GPIO listener on power-up / reboot.

Connecting the sprinklers

As I was basically replacing the controller for the sprinklers I already had in the garden, all I did was connect each of the Zones’ solenoids/valves to the relay board.
It’s fairly straightforward as you just have to remember the relay is a switch and you need to see whether you’re going to use the “Normally Open” [NO] or “Normally Closed” [NC] side of the relay. (Normally Open would mean that the switch is NOT switched on by default and when you trigger the relay, it will close the circuit; i.e. switch things ON – for Normally Closed it’s the other way round 🙂 )
I used “Normally Open” side of the relay as I wanted the Raspberry Pi to actually switch the solenoid on, which will open the valve and let the water through.
The solenoids make use of 24V AC and I already had a transformer to power them – so re-used that.

rainbird_hv

End result was enclosing the Raspberry Pi and relay board in a small housing, connected to the sprinklers in the garden.

GardenPi-Endresult

Next part we go to Home-Assistant to set up & config.

GardenPi – a garden watering solution built on Raspberry Pi, MQTT and Home-Assistant.io [Part 1/4]

We currently have an off-the-shelf garden watering solution [Hunter], but I’d like to have more control of when, etc. the irrigation is switched on.

I used the following items in my solution:

Hardware:

  • Raspberry Pi 2 B+ [using a 16GB SD card]
  • Raspberry Pi Wifi Dongle
  • 8 Port Relay board

Software:

SETUP

OS

I first started prepping my Raspberry Pi and because I’ll be running it as a headless solution, I used the latest Rasbian Lite OS [download here] (Raspbian Stretch) which doesn’t have the UI and you configure all via the command-line

  1. Using Etcher, I wrote the image onto the 16GB SD card
  2. Take your SD card and boot up the Raspberry Pi
    1. Although I am going headless, I used a keyboard and screen to configure the base OS – I need a way to configure the Wifi and the easiest is when you use raspi-config.
  3. I configured the following once the 1st boot-up was done:
    1.  sudo raspi-config 
    2. Configure your locale, timezone and keyboard layout [I use the en_ZA.UTF-8 locale settings and US keyboard layout]
    3. Also configure your Wifi settings (SSID & Password, Wifi Country)
    4. Change the network name of your Raspberry Pi (mine’s called GardenPi)
    5. I also updated the password for the default pi user (default password is “raspberry” & it’s a good idea to change it 🙂 )
    6. I then forced an update in the locale file (I’ve had some issues in the past and found if you force it, things work better)
      1.  sudo nano /etc/default/locale 
      2. Add the following:
        1. LANG=en_ZA.UTF-8
          LC_ALL=en_ZA.UTF-8
          
LANGUAGE=en_ZA.UTF-8
 
    7. I also enabled SSH as I will be using SSH to manage the RaspberryPi in future.
  4. Reboot your Raspberry Pi, log in using the pi user and the new password you configured.
  5. Check your ip address
    1.  ifconfig 
    2. My result showed my wlan0 adapter on IP 192.168.2.150
  6. You can now make this IP address (192.168.2.150) static on your router to ensure you can easily “find” your raspberry pi when you want to manage it using ssh
  7. I tested my ssh configuration from my Macbook
    1.  ssh pi@192.168.2.150 
  8. As a last step, I always check whether the latest updates are installed on my raspberrypi
    1. sudo apt-get update
      sudo apt-get upgrade

Now you can move on to the software installation !

Software

Python

OK, we 1st need python installed

sudo apt install python-pip 

PI-MQTT-GPIO

Once python is installed, you can install PI-MQTT-GPIO (it will install MQTT as part of the setup] (more details here)

pip install pi-mqtt-gpio 

As I already have MQTT running as part of the rest of my Home-Assistant.io setup, I will now only have to configure pi-mqtt-gpio to publish/subscribe to the MQTT messages.

Update your config.yml file with the necessary info, my info below (with some passwords hidden 🙂 )

NOTE – I’m only showing Zone 1 & Zone 2 settings (output & input)

mqtt:
host: mqtt-host-ip-address
port: 1883
user: "*******"
password: "*****"
topic_prefix: lazyhome/garden

gpio_modules:
- name: raspberrypi
module: raspberrypi

digital_outputs:     #used to send commands to the GPIO pins
- name: zone1
module: raspberrypi
pin: 5       #GPIO pin number - not the board pin, but the GPIO pin
on_payload: "ON"
off_payload: "OFF"
initial: low # This optional value controls the initial state of the pin
retain: yes # This option value controls if the message is retained.

- name: zone2
module: raspberrypi
pin: 6
on_payload: "ON"
off_payload: "OFF"
initial: low

digital_inputs:     #used to read status from GPIO pins
- name: zone1
module: raspberrypi
pin: 5
on_payload: "ON"
off_payload: "OFF"
pullup: yes
pulldown: no

- name: zone2
module: raspberrypi
pin: 6
on_payload: "ON"
off_payload: "OFF"
pullup: yes
pulldown: no

The GPIO pins are referenced as per the following layout:

gpiopinout

So to test PI-MQTT-GPIO, you can run it in console mode (running it from the /home/pi folder):

 python -m pi_mqtt_gpio.server config.yml 

It should show you connecting to the MQTT server, and then subscribing to the messages, etc.

Quick checklist:

  • Raspberry Pi running Rasbian Stretch Lite, with wifi dongle
  • PI-MQTT-GPIO installed (using python & pip)

In PART 2 we’ll bring is all together in Home Assistant.

 

Home-Assistant.io – Grouping your entities / switches in a logical fashion

While adding more & more switches into my Home Assistant setup, I’ve needed to group the items together in a logical manner.

I have switches controlling our geysers, general “playground” switches and I’m also implementing a solution to control our garden irrigation [details to follow soon].

I first split out the switch configuration into their own switches.yaml file:


- platform: mqtt
name: "Bedroom Geyser"
command_topic: "cmnd/Sonoff1/power1"
state_topic: "stat/Sonoff1/POWER1"
qos: 1
payload_on: "ON"
payload_off: "OFF"
retain: true
- platform: mqtt
name: "Upstairs Geyser"
command_topic: "cmnd/Sonoff1/power2"
state_topic: "stat/Sonoff1/POWER2"
qos: 1
payload_on: "ON"
payload_off: "OFF"
retain: true
- platform: mqtt
name: "Switch3"
command_topic: "cmnd/Sonoff2/power1"
state_topic: "stat/Sonoff2/POWER1"
qos: 1
payload_on: "ON"
payload_off: "OFF"
retain: true
- platform: mqtt
name: "Switch4"
command_topic: "cmnd/Sonoff2/power2"
state_topic: "stat/Sonoff2/POWER2"
qos: 1
payload_on: "ON"
payload_off: "OFF"
retain: true
- platform: mqtt
name: "Garden Zone 1"
command_topic: "lazyhome/garden/output/zone1/set"
state_topic: "lazyhome/garden/input/zone1"
qos: 1
payload_on: "ON"
payload_off: "OFF"
retain: true
- platform: mqtt
name: "Garden Zone 2"
command_topic: "lazyhome/garden/output/zone2/set"
state_topic: "lazyhome/garden/input/zone2"
qos: 1
payload_on: "ON"
payload_off: "OFF"
retain: true
- platform: mqtt
name: "Garden Zone 3"
command_topic: "lazyhome/garden/output/zone3/set"
state_topic: "lazyhome/garden/input/zone3"
qos: 1
payload_on: "ON"
payload_off: "OFF"
retain: true
- platform: mqtt
name: "Garden Zone 4"
command_topic: "lazyhome/garden/output/zone4/set"
state_topic: "lazyhome/garden/input/zone4"
qos: 1
payload_on: "ON"
payload_off: "OFF"
retain: true

I then created a groups.yaml file with the following:

Geysers:

name: Geysers
entities:
- switch.bedroom_geyser
- switch.upstairs_geyser

Garden:
name: Garden
entities:
- switch.Garden_Zone_1
- switch.Garden_Zone_2
- switch.Garden_Zone_3
- switch.Garden_Zone_4

Finally I added the following to my configuration.yaml file:

# Add switch config in separate file
switch: !include switches.yaml
# Add group config in separate file
group: !include groups.yaml

The end result looks great !

Groups.png

More info on the Home-Assistant.io GROUP option here – https://www.home-assistant.io/components/group/

Node-RED flow for Geyser management using Sonoff switches and Home Assistant

We have 2 geysers (for other parts in the world it’s called water heaters :-)) in our house and to save some energy (& money), we want to manage when these geysers are switched on.

Typically a geyser will run 24/7 and keep the water heated, even when nobody is home.

So the idea is to put the geysers on a time-schedule for when we’re normally at home, so we only heat the water when we’re going to use it.

To put this in motion, there are a couple of things we need to do:

  1. Connect the Sonoff switch to the geysers [using a Sonoff Dual, so 1 Sonoff & 2 relays]
  2. Configure the Switches in Home Assistant
  3. Configure a flow to ensure the geysers are on at specific times during the week & weekend

Connecting the Sonoff Switch to the Geysers

Geysers tend to draw a lot of power when the element is on and the Sonoff Dual switch is only rated for 16A/10A – which is fine for normal use, but won’t cut it for geyser use.

We need to implement another solution:
– the solution is using a 230V/30Amp relay.

30A-Relay

This will allow us to use the Sonoff switch, but the main load will pass through the relay instead of the  Sonoff switch.

Now we have to connect the geysers in the distribution box to the Sonoff switch [some rewiring required here]

DB-board

That’s it !

[P.S. I already configured the Sonoff on the network, so this wiring was all I needed to do]

Connecting the Sonoff Switch to Home Assistant

To make Home Assistant aware of the switch, we need to add some configuration info into the configuration.yaml file.

I added the following lines: (I moved all the switch configs to a separate switches.yaml file)

Configuration.yaml (add these line)
# Put switch config in separate file
switch: !include switches.yaml

Now in the switches.yaml add the config info for the geyser switches:
– platform: mqtt
name: “Bedroom Geyser”
command_topic: “cmnd/Sonoff1/power1”
state_topic: “stat/Sonoff1/POWER1”
qos: 1
payload_on: “ON”
payload_off: “OFF”
retain: true
– platform: mqtt
name: “Upstairs Geyser”
command_topic: “cmnd/Sonoff1/power2”
state_topic: “stat/Sonoff1/POWER2”
qos: 1
payload_on: “ON”
payload_off: “OFF”
retain: true

As you can see, it uses mqtt (Mosquitto Broker) to communicate with the switches (command_topic & state_topic)

So now these switches will show up in Home Assistant (after a restart of HASS)

HA-Switches

OK now we move to the FUN stuff !

Configure the Node-RED Flow in Home Assistant

We decided that for our purposes the following schedule makes sense:
– Weekdays the geysers need to be on in the morning & the evening
– Weekends we will run the geysers most of the day (as we may shower at any time & tend to be around more)

The flow looks like this:

GeyserFlow

I split the flows into 2 separate ones for possible future changes where the geysers will be on different schedules.

Also, the basic flow is my 1st attempt [put it in place today] – so we may tweak it over time 🙂

Over-ride:

Sometimes we may actually select to switch the geysers on when we want – which we can always do from the Home Assistant front-end.

I’m also thinking of adding a flag to state when we have guests staying over, and then disabling the schedule, etc. [future project :-)]

Another thing I also need to do is have a physical over-ride button connected to the Sonoff switch (there are pins available for this) – this will allow me to manually switch the geysers on in the event the Sonoff loses connectivity to the wifi.

Well, this was an eventful couple of days !

Now deciding on to the next bit of automation ! 🙂

 

Have fun !

Create a free website or blog at WordPress.com.

Up ↑