Profile
Back to NewsBack
GitHub Trending 6 min
Reader Mode
MichielVanwelsenaere/HomeAutomation.CoDeSys3: Home Automation system build in CoDeSys 3 with MQTT communication to any third party Home Automation software

MichielVanwelsenaere/HomeAutomation.CoDeSys3: Home Automation system build in CoDeSys 3 with MQTT communication to any third party Home Automation software

10 hours ago

MQTT enabled CODESYS 3 Home Automation

Releases License

This CODESYS 3.5 project is built for home automation purposes. The goal of the approach is to perform any critical operations like reading inputs, switching lights, controlling sun blinds, etc. inside the PLC itself and make use of MQTT to send events to an MQTT broker. Using MQTT subscriptions it's possible to send commands to the PLC to control -for example- outputs.

The purpose? Redundancy on a software level but also on a hardware level!

  • PLCs are very (very) robust controllers: no PC, SoC, etc. is more robust and failure resistant.
  • Hardware continuity: Home automation providers often renew their modules every X years, modules aren't sold anymore or a full upgrade is required when something breaks. PLC models and their modules are sold decades after their initial release date. For an example, check out the Wago 750 series controllers and modules.
  • Avoid performing critical operations that should work 24/7 inside a less redundant controller (it will fail sooner or later).
  • Keep your wife/girlfriend happy when you're not at home and your RPi, Odroid, Banana Pi, PC crashes (running your MQTT broker, openHAB, Home Assistant, etc.).

Supported Devices & Getting started

The project is developed using the IEC 61131-3 standard in CODESYS. Although CODESYS supports a large number of different device types, this project is specifically tested and developed on the WAGO PFC100/200 device series. There are multiple generations of the WAGO PFC100/200 series, the documentation below aims to get you acquainted with the differences between generations and their implications:

live inside a terminal rather than in CODESYS, and how to make the PLC release the K-bus so the tool can reach them

Architecture

Core processing logic is executed in the (robust) PLC. Meaning that events like reading pushbuttons/switches, updating outputs are executed in the PLC software. To enable integration with external software the PLC sends out events to an MQTT broker when events occur (like pushbutton events, outputs that change state). MQTT subscriptions are enabled as well to allow the external software to control -for example- outputs.

!GeneralArchitecture

Software Architecture

More information on the software architecture here.

Function blocks

Basic function blocks

Basic function blocks for basic IO events and operations. A resistance temperature sensor - a Pt1000 on a WAGO 750-451 - needs the module wiring and one line of code; see reading a temperature sensor.

Modbus RTU over RS485

With many PLCs having an onboard RS485 serial port it is a popular protocol to create a robust Modbus RTU sensor network.

Using Modbus RTU

How to use Modbus RTU differs depending on the PLC/development environment used. The topics below address the usage of Modbus RTU in several development environments:

RS485 function blocks

To translate the byte array received by the Modbus device to their actual value and send their values through MQTT the function blocks below have been developed. Note that a specific function block is required for each type of Modbus RTU device. Each of them implements the I_RS485_DEVICE interface, which is what lets one bus be shared between many of them.

The three Eastron meter blocks announce themselves to Home Assistant over MQTT discovery: give the instance a FriendlyName and it appears as a device of its own with its measurements underneath, no YAML and no init calls. See MQTT self-wiring.

Three more blocks sit underneath:

is, and runs one device's whole transaction — several reads, or a write and the read that confirms it — with the bus held throughout. bus before any of them is polled. It asks each registered device whether it needs something written into it first — a device that ships on a baud rate this bus does not use is inaudible, not slow — and knows nothing about any device beyond that answer. the serial port. It sits behind an interface, so a different Modbus implementation can be substituted without touching any device block.

DALI

Control DALI drivers using the WAGO DALI multi-master module (753-647). Needs the WagoAppDALI library, which WAGO's licence does not allow this repository to ship — install it once per engineering PC before building.

Two caveats, both on the function block's page: **only a G2 WAGO device can drive the module under the CODESYS runtime**, because FbDaliMaster binds to a port instance that only WAGO's own device description provides, and the whole feature is untested on hardware — compile-verified on every build, never run against a real ballast.

DMX

Control DMX drivers.

HVAC

Control your HVAC setup, more detail in the HVAC getting started guide.

Additional functionality

FAQ

Libraries

The following libraries are used in this PLC project and can be found under src\Libraries:

- CommonTypesAndFunctions (stefandreyer/CODESYS-Common) - PRO_JSON (stefandreyer/JSON-Library) - OSCAT_NETWORK_TYPES (stefandreyer/OSCAT-NETWORK) - BASIC_Extension (stefandreyer/OSCAT-BASIC)
  • OSCAT NETWORK (link)
  • OSCAT BASIC (link)
  • OSCAT BUILDING (link)
Special thanks to Stefan Dreyer for his assistance in some of the MQTT aspects of this project and his great work on his open-source CODESYS MQTT library.

Chat with me