Since I want to migrate all domotica software to my raspberry PI (or perhaps PI’s) it is time to say good bye to my windows mosquitto instance running on my current windows domotica server. Of course I will use docker to run mosquitto also.
I searched the web a bit, and perhaps I didn’t search well enough, but I couldn’t find an up-to-date repository for a mosquitto image that will run on the Raspberry PI. The ones I found, were all a year or more old and for example based on debian jessie whereas debian stretch is the standard now.
So, based on a existing docker file I found on the web, I created a new mosquitto docker image for the Raspberry PI. I have uploaded it to my repository so it can be used by myself, and perhaps others who have looked for one too 🙂
The image can be found here.
As I mentioned in my previous post I already have a mount to my NAS in which I want to store my domoticz data. The mount on the PI is
On this mount I created the necessary sub folders for mosquitto. For mosquitto to work a basic config file should be put in the config folder. As a bare minimum it should have the following contents.
pid_file /var/run/mosquitto.pid persistence true persistence_location /mosquitto/data log_dest file /mosquitto/log/mosquitto.log
The mosquitto image can be installed as follows. I have added the –reatart option so the container is automatically started when for example the PI has been rebooted.
docker run --name=mosquitto \ --restart unless-stopped \ -d \ -e TZ=Europe/Amsterdam \ -p 1883:1883 \ -v /home/pi/dockerdata/mosquitto/config:/mosquitto/config \ -v /home/pi/dockerdata/mosquitto/data:/mosquitto/data \ -v /home/pi/dockerdata/mosquitto/log:/mosquitto/log \ dromer1967/arm32v7-mosquitto
And behold, mosquitto is running in docker on the PI.
After having used the Razberry on the Raspberry PI for quite some time now, I am growing tired of having to power cycle the PI every month of so because the Razberry stops working. Also the API to the Razberry has changed several times which forces me to change my software as well or to keep working with an older no longer supported API.
So I have decided to move away from the Razberry and use the Aeon Labs Z-Stick (gen-2) on a new PI 3. It seems that the Z-Stick solution is much more stable. If this works the way I hope I perhaps might migrate to a gen-5 Z-Stick as well. But since I already have a Gen-2 let’s use that to start with.
I am thinking about using Domoticz for its integrated Open ZWave library support to control my ZWave network. Since all of my domotica uses MQTT for communication I might use the MQTT possibilities of Domoticz too.
I will do some experimenting on this first before deciding to use Domoticz or perhaps some other Open ZWave implementation. Or even build my own MQTT gateway using the Open ZWave library.
Perhaps I will share some posts on how to get that working or how it turns out to work (or not).
When I started to automate my home late 2009, I foremost wanted to be able to control my city heating in a comfortable and scheduled manner on a room by room basis.
Budget was (and still is) an important concern and after some investigation I stumbled upon a system made by the German manufacturer ELV (based of the FS20 system). With this system each room has its own thermostat which subsequently controls the radiators in that room. The system was wireless and inexpensive so I decided to invest in it to set a first step on the (never ending as it seems) home automation path.
I wrote some windows services (in .NET) to control the system, and used google calendar to schedule the temperature in each room. There was need for a google calendar, opposed to the standard schedule present in the system, because I needed a schedule that lasted more than a week because every other week I stayed at my girlfriend’s place and the heating in my house could be turned off (well set to 15 degrees Celsius) then.
The system operated reasonably well for several years but had its quirks. Because it was wireless and not entirely bidirectional, one could never be sure if temperatures were actually set at the correct level. My software (obviously) took care of that through some sort of polling mechanism. But once in a while the system decided that is was overflowed and went dead for hours or sometimes even more than a day.
I could live with it reasonably well, but more recently the quirks seemed to increase in frequency and exceeded my irritation threshold.
So I decided to look for a new system. But this time it should definitely be bidirectional and still wireless (did not want to put wires to all my radiators and thermostats).
And since it is a new system I also decided to redesign the architecture of my home automation software to a more modern and flexible one. With the new system I wanted
- Wireless operation
- Full bidirectional support
- The ability to control it through (custom) software
- Communication through UTP instead of USB so the device could run independent of other hardware/servers.
Based on this list, and again the budget as a primary concern, I decided to try the Max! system from manufacturer eQ-3. One could say it is sort of the successor of my current system and this time bidirectional controlled and still inexpensive.
Because I already used some ZWave devices with an Aeon Labs USB stick, I decided to give that an upgrade too. Mainly because I wanted to get rid of the USB device in my server (which prohibits me from installing Windows 2012 Hyper-V Server because that does not support USB devices, well not easily anyway) and also wanted a chance (and excuse :P) to play around with a Raspberry PI, I bought a Raspberry PI type B (with 512MB RAM) computer together with the Razberry daughter board which enables ZWave on the Raspberry.
Since I am a .NET man myself, I wanted to use .NET on the Raspberry to control the Razberry. So there is where the MONO runtime comes into the picture. But installing that on a Raspberry is an entirely different kind of challenge on which I probably will post in a separate post.
On the architectural side of things, I wanted more flexibility in my system to glue different components or even systems together. I found some interesting posts about using the MQTT message protocol for Home Automation and decided to use that in the new system. I also looked on the net for existing systems which I could use or partly reuse, but they either seem to be written in ‘unwanted’ languages like python, perl, basic, java, jscript or they do not use a flexible communication protocol like MQTT.
With MQTT, and Mosquito as the message broker, I could write gateways for the Razberry and Max! which would translate the functions on the devices to a device and hardware independent communication protocol.
This would give me separation of concerns and the ability to write multiple small components who would communicate with each other through the MQTT protocol and therefore be agnostic of each other including the hardware on which the component runs. Some of the components could be (and probably will be)
- A gateway to the Max! system. This gateway would receive and send MQTT messages and translate them to functions on the Max! system.
- A gateway to the Razberry. This gateway would receive and send MQTT messages and translate them to ZWave functions on the Razberry.
- A calendar publisher component, which reads a google calendar and publishes scheduled events as MQTT messages.
- A Heating/Thermostat controller component, who receives MQTT calendar messages and send corresponding MQTT messages to the thermostats.
This system would be flexible and easy to enhance. The plan is to use .NET on the Raspberry to create all of the above components so the entire Home Automation system can run on the Raspberry. This will include Mosquito as an MQTT message broker and probably MySQL for the storage of data.
At the moment I have bought some hardware (both Max! and Razberry) and investigating the further possibilities. I intend to publish my software as open source so others can use (part of) it if they want to. Since the communication protocol will be based on MQTT messages, it is easy to expand the system with gateways for other hardware and modules to control other things. Like for instance a module which would publish dawn/dusk events as MQTT messages so they can be used (in another controller) to turn on/off some lights in the house.
I guess this will be a work in progress for the oncoming months and I hope to reflect the progress of my new Home Automation System in posts to come!