Getting Started with Home Automation (Part I)
Join the DZone community and get the full member experience.
Join For FreeBeing a developer with a background in electronics, I sometimes miss the physical aspect of writing software. I don't mean physical like touching other people or something, no, more like writing code that does something physically. Like operating a lamp or a motor. So, some time ago I saw my chances fit for a new side project: home automation.
While
investigating what I would need, I Quickly became convinced that
besides programming an installing it myself, the biggest challenge would
be to get all bits and pieces together. There are a lot of systems and
vendors and it is hard to get some objective information, or just
information all together. So I decided to start sharing my experience
here. Maybe it might serve to some good for other brave souls crazy
enough to try the same thing for their homes.
But
first, lets start with a good old rant. Why is the world of home
automation so badly organized? Let me come again; why? If you enter
this world, set aside all open source principles. Do not hope that you
are going to find centralized/useful documentation on how to do things.
Imagine
going back in a time machine, where the Internet is not sometimes
referred to as the 'interwebs'. Where the Internet is still delivered
over slow landlines owned by evil telco's wanting nothing more then your
small fortune. Where marketeers did not yet understand that a platform
can be offered almost free of charge and that there are plenty of ways
to make money. Imagine a world where not everyone speaks German.
German you say? Yes, get used to words as 'Schnittstelle' (not to be confused with the well known Schnitzel) or 'Zählerfernauslesesystem'.
Apparently a lot of these companies are German, and while most
documents are indeed also available in English, some are left
untranslated so you are stuck with the German version. Fact is that most
of these sites need to be browsed in English and a second time in
German locale to make sure all information surfaced. Some documents
simple don't appear otherwise. But it is what it is, so lets suck it up
and proceed.
Apparently a lot of these companies are German, and while most
documents are indeed also available in English, some are left
untranslated so you are stuck with the German version. Fact is that most
of these sites need to be browsed in English and a second time in
German locale to make sure all information surfaced. Some documents
simple don't appear otherwise. But it is what it is, so lets suck it up
and proceed.
As
with every project it all starts with the requirements. This time being
the customer myself, having bad, or no, requirements is not going to be
an excuse. But here also lies the danger. Home automation is very
subjective. Some people want their eggs to be backed automatically in
the morning, others just want a panic button. For me it is a subtle
mixture between what is doable, what is actually needed and the budget.
The must haves:
- All light points in the house should be able to be programmed and controlled via software. And with all lights I mean all of them, no exceptions
- Some power circuits needs to be controllable
- Lights in hallway, toilet, bathroom, garage, storage space, outside side door, outside house need to be operated with motion and or presence sensors. These sensors also needs to be cat proof. I don't want to turn my house into a blinking Christmas tree if my cats decide to play at night
- Buttons need RGB LEDs. If the toilet is occupied I want to see a red light on the switch. Depending on the mode a 'sensor controlled light' is in, I want this being reflect by the LED. The brightness of the LEDs needs to be adjusted as well depending on the available light
- Light sensors with timer functionality. For example; the roof lights need to turn on when it's getting dark, but only after 1900h. If it gets dark during daytime (bad weather or something) the lights should not switch on
- Scene support: lights in the living-room/kitchen need to be dimmed to preset scenes
- Blinds for the windows need to be controlled automatically.They need to be controlled together (the default) but also individually
- Ventilation. If the unit would be to loud at some point, it must be able to be controlled remotely, preferably by a phone
- Support for programming over Ethernet
- API for controlling the entire system via software. For example an app, or a dedicated touch panel
- The interconnection of the components should be using a bus architecture with free topology
Nice to haves:
- Heating. This is a bit of a gray zone, but it at least the possibilities needs to be investigated
- Metrics for gas/electricity/water
For me this is where the
barrier between useful and affordable automation ends. Audio for
example, sure nice things are possible, but this is better controlled
separately. There is plenty of choice in media system with Spotify
integration at far better prices. The thing is that for audio one wants
to have freedom of choice and not be bound to a single (expensive)
product.
Next the hardware. Easier said then done, so first let's try to identify some categories
PLCs
A barebone PLC, for example the Simatic S7 from Siemens. They are the
SAP of automation. You can build nearly anything with them and they are
very robust/stable.
However, the thing is that they are barebone. For example, programming is done with STL, which is very low level, comparable to assembler. On the image below you can get an idea how this looks.
However, the thing is that they are barebone. For example, programming is done with STL, which is very low level, comparable to assembler. On the image below you can get an idea how this looks.
Agreed,
you can also opt for a graphical way of programming, like LAD (ladder)
but it remains pretty low level. But that's not all. These things have a
high cost, which is understandable if you see in which kind of
factories they are being used.
There are also other manufacturers which are S7 compliant, such as VIPA, but the price still remains high.
But
the biggest downside is probably that there are no ready build HOME
components. If you want a push button with LEDs, no problem, but then
you have to build it yourself. I like a challenge but this would be a
bit too much for me.
Mini PLCs
Siemens Logo! is such an example
While
they are cheaper, they still suffer the same drawbacks as its bigger
brothers. There are also no real home components and having something
simple as LED feedback on a button (e.g. a 'occupied' LED) means you'll
have to run an extra wire and an need an additional output just to steer
this one LED.
While
there is profibus (really expensive, but ok) for Simatic, Logo! has no
bus system. This means that if you want 16 switches you'll at least need
17 wires running in your 'data' cable. Double that amount if you want
to use LEDs
Don't get me wrong; Logo! (or PLCs) do have a place in home automation. First there is the ease of installation. You don't need cross switches or wiring switches directly to switching points as with a traditional installation. It will be well suited for basic stuff like push buttons (instead traditional toggle switches), programming panic buttons, simple motion detectors etc They are also more favorable over contactors/relays as they dynamically programmed and prices will be almost the same.
Home automation PLCs
Then there are what I call 'home automation PLCs, one of them is the Loxone Miniserver
It
is a CPU just like Logo! or Simatic, but more focused on home
automation out of the box. It comes shipped with a webserver and phone
app allowing instant remote access from your browser/phone. There are
also several already build components which you can use straight away.
And most of all, it comes with KNX/EIB support (more on that later).
But
to use it as the main home automation solution it would suffer the same
disadvantages as the previous ones; limited intelligent components(°)
and no bus system.
(°) limited, but there are at least extensions like a an IP cam based intercom, RGBW controllers, wireless extension and more (check it out) these home components are not available with traditional PLCs
Real home automation
With
"real" I don't mean that these system would be more stable or mature,
not at all. But they are more home oriented and therefore a closer match
as to what one would need for home automation.
To make it easy I divided them in the closed systems; such as Niko (Belgian company) home control (NHC) or BTicino (Italian) etc. These are examples of a closed standard and only the manufacturer in question produces components for it.
Then there are the open systems such as KNX/EIB.
The latter is an open standard and every one is free to build
components compatible with this standard. This means that you don't have
a vendor lock-in; you can mix different brands and components, as long
as they are KNX/EIB compatible. For example, one can have a MDT pushbutton combined with a Jung dim actuator and a Basalte thermostat. Just as NHC, KNX uses a bus (EIB) with a free topology.
Ok,
then what is the best solution? There is no objective answer in which
is better. It basically depends on budget, taste and mindset. For
example; vendor lock-in is mostly not a good idea. But if you chose a
good vendor that "has it all" it can also have advantages. If you go to
your local Niko dealer, someone can probably explain all components. You
get everything (information, ordering, support) from a single place. No
need to endlessly browse the Internet comparing manufacturers or
products. On the other hand a closed standard might impose future risks:
what if Niko decides to stop producing NHC? They already did that with
it's predecessor: Niko bus. Agreed, they solved it with NHC/NB bridge
which allows to add NHC components to an existing NB installation. But
not all functionality is usable this way. So if you bought Niko bus
some years ago you are already limited in adding new components.
KNX
excels in the fact that it has no central processor (unlike PLCs). It
is message driven and each sensor/actor has it's own processor. They
communicate with each other using telegrams (~messages). A sensor or an
actor generates can subscribe to a so called 'group address' (like a
multicast address) and it will then be able to pick up telegrams sent to
that address by other sensors or actors. Based on the configuration
they can decide to do something with the telegram or ignore it. But
there lies also it's weak point: each
component is responsible for generating or processing telegrams, but it is
limited to the logic offered by that component. For example; a light
point needs to be switch on conditionally based on the value of a light
sensor and the wall-clock time. This clearly involves clock logic. While
perfectly possible with KNX, you'll need a separate actor which is able
to generate telegrams based on clock schedules. This starts to become a
pricing issue as each KNX actor is a processor on its own making them
not cheap.
But there is also a solution. The so called KNX/EIB 'servers'. They
allow more advanced and centralized programming and form an extension to
the traditional KNX sensors and actuators. An example of this is Gira's
home server. However, it's price tag is really, really high
at €2.200. Luckily,
this is where Loxone comes in. Loxone offers the same functionality but
at a reasonable price. It can even do more as it is a traditional CPU
with KNX/EIB integration. To program your KNX components via Ethernet,
you also need an IP gateway. This is again an extra (special) actor.
With Loxone you get all of that combined in a single module. So by
adding Loxone we get follow things in return:
- A 'soft entry' into home automation system. It allows for remote access via an API and apps thanks to it's built in webserver. Since it's KNX/EIB compliant, Loxone can be used as the programmatic interface to EIB, not needing extra KNX components
- KNX/EIB gateway; using Loxone one can program KNX/EIB components using it as a gateway
- The inputs on the Loxone are not really usable when using EIB. However, the outputs are. By using them you are also saving a 8 digital output KNX actor
- Actual programming with logic circuits, controllers, smart components, you can even program in pico C if that would be required
A KNX gateway and
8DO KNX actor already cost more then the entire Loxone setup. So it's a
win-win deal: less money for more functionality.
So
in the end I decided that an open system (such as KNX/EIB) in
combination with a home automation PLC (Loxone Miniserver) combines the
best of two worlds. KNX/EIB offers an open standard and freedom of
choice in vendors and components. It also decentralized, message driven
and open ended architecture which I felt comfortable with. Loxone adds
the central processing power and interface to other platforms
(web/mobile). It also allows to program all logic you would even need
for your home automation at a reasonable price.
There
is however one thing to keep in mind. While Loxone Miniserver is
KNX/EIB compliant, it cannot be programmed like other KNX components. In
other words, Loxone is programmed separately with different software
and different 'programming techniques'. But this actually makes sense.
The way a KNX/EIB is programmed does not lend itself for complex logic.
After all, KNX/EIB programming is more 'configuring'.
The
Loxone development environment is better suited for this, taking full
advantage of its possibilities. Do note that a Gira Home server for
example is also programmed in a different way than traditional KNX/EIB components, so this is just
natural.
In
the next part I'll show the components I'm planning to use to meet the
requirements and the test board together with the initial programming I
did to be able to test everything from my desk.
Light (web browser)
LEd
IT
Published at DZone with permission of Koen Serneels, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
A Complete Guide to AWS File Handling and How It Is Revolutionizing Cloud Storage
-
Observability Architecture: Financial Payments Introduction
-
Design Patterns for Microservices: Ambassador, Anti-Corruption Layer, and Backends for Frontends
-
Comparing Cloud Hosting vs. Self Hosting
Comments