KNX is an open home and building automation standard. This makes the protocol very interesting as it ensures interoperability between devices from different manufacturers. It also avoids vendor lock-in as is the case with many other home automation systems.
Some software projects such as KNXD and Calimero Server, make it possible to communicate on a KNX bus from a PC. They can be used on a standard desktop PC, but more interestingly also on SBCs such as the Raspberry Pi. This makes it possible to make a small Embedded Linux system which operates in a KNX system.
Most projects I saw on the internet using KNXD or Calimero Server, used a bus coupler and interfaced it with wires to a Raspberry Pi or some other system. This sparked the idea to make a Raspberry Pi HAT which can be used to interface directly with a KNX bus. No wires, just plug and play.
The goal of the project is to build Raspberry Pi HAT to interface with a KNX bus. Running OpenHAB on the RPi would be cool!
The Raspberry Pi HAT is built around the NCN5130 transceiver from ON Semiconductor. It has a part of the MAC layer implemented, which makes it easier to develop software for it. Communication is done through either UART or SPI. Every piece of software I've seen communicates over UART, so we will ignore the SPI portion.
No isolation was used between the Raspberry Pi and the transceiver. It would increase the development effort significantly and I did not see the advantage as of now. Maybe in the future if it seems necessary it can be added, but I don't think so...
As the Raspberry Pi is the most popular SBC out there, it was easy to select it as the preferred platform. The KNXD software is also compatible with the Raspberry Pi as well as OpenHAB.
The ultimate goals is to get KNXD working with the HAT and interface OpenHAB with KNXD. This would make it possible to control stuff on a KNX network using OpenHAB.
Everything seems to be working well with OpenHAB!!!
It took me quite some effort to get it fully working. There are many little details that need to be right or else it just won't work. Enabling logging for both KNXD and OpenHAB really helps in finding the root cause of the issue.
After installation KNXD will start automatically as a service. The options that KNXD uses to start are defined in /etc/knxd.conf
My configuration is currently:
Note that while debugging it is interesting to stop the service with the command "systemctl stop knxd.service" and run KNXD from the command line. This way you can enable debugging with the -t option.
Once KNXD is running, you will see it pop up as a possible interface in ETS. This makes it possible to use the Raspberry Pi + HAT as a wireless KNX programming device. You can monitor and program networks wirelessly!
Note that the option -E specifies the addresses KNXD assigns to clients that connect to it through tunneling and such. Do not assign these addresses to physical devices on your KNX bus. This will create collisions which keep you wondering day and night why it won't work...
Getting OpenHAB to communicate with KNXD is fairly easy. After installing the KNX addon, you can instantiate a KNX/IP Gateway in the Things tab under Configuration. As KNXD and OpenHAB are running on the same Raspberry Pi, the Network Address is just the local host 127.0.0.1 If you run both on a different system, the Network Address has to be the one of the system running KNXD. Of course both systems must be in the same network.
All the other settings are ok by default, except for the Local Device Address. First I thought this had to be the individual address that is assigned to KNXD. But that caused a lot of trouble. After browsing on the internet I found that it is best to leave it at 0.0.0 and have KNXD assign the address by itself.
Once the connection has been made with KNXD, it is possible to set up a KNX Device. My device is a KNX switch. Select the right bridge to communicate with. Normally there will only be one bridge, which is the one we just set up with KNXD.
The address, is the individual address of your KNX device. OpenHAB will poll this address to see if the device is up and running on the bus. If you just want to send messages on the bus and not have OpenHAB poll your actuator on the bus, leave the Address blank. Here you don't have to define yet what your device does. That is done by assigning channels.
Once both of these are set up, OpenHAB should show them as online:
When everything shows up as online it means that OpenHAB is able to reach everything on the KNX bus. The hardware part is mostly done here now. This means all the hardware is working properly and the software can interact with it.
Assigning group addresses to communicate on the bus, is done by clicking on your device and adding a channel. The channel can be a switch, blind,...
Every channel gets assigned a group address and can then be assigned to a control element in the HABPanel or some other UI in OpenHAB.
In the control tab you can control your newly assigned channel. This is only used for testing. Controlling your installation is done through one of the OpenHAB UIs you can build. If you push the button next to your element you should see some messages appearing on the KNX bus. On the image below you can see the on/off commands being sent.
The messages that come before the on/off commands, are coming from OpenHAB. They are used by OpenHAB to poll the status of your device. This is then used to show in the UI if the device is online or not.
As now everything is working, I'll look into making a step by step guide on how to set everything up.
It seems that I swapped the pin out of the Raspberry Pi header. Pin 1 should be Pin 2 and vice versa. So in the schematic I had to mirror the header around the y-axis. The schematics and the PCB on GitLab have been updated.
I guess that means that I have to put the shield upside down onto the Raspberry Pi to work with it. It looks silly, but hey it works ;-)
Installing KNXD was pretty straight forward. The installation instructions on their Github page are very clear. After fiddling around with it, I got it working with the shield! At first it didn't work, but I selected the wrong baud rate. KNXD by default communicates at 19200bps and an even parity bit. So the jumpers on the shield must both be set to 0.
To test if everything is working I connected a simple KNX power supply to the shield.
I also connected a KNX USB interface to the bus, but I don't have ETS on my Linux PC, so it is useless for now...
When starting KNXD from the command line it is easy to see if everything is working by adding the option:
If KNXD detects an error during startup (due to an incorrect baud rate for example) it will report what it received and what it expected to receive. After a couple of failed attempts KNXD will exit.
If the communication is successful, the process will keep running and report what you can see in the figure above. Every couple of seconds it will request the transceivers status by sending 0x02. If everything is normal, it should respond with 0x07. This way the Raspberry Pi knows that everything is up and running.
Now that it is possible to get KNXD communicating with the shield, we can configure KNXD to listen on a socket and try to get OpenHAB to communicate with it. But first lets get this Pi connected to my home network so I can SSH into it instead of having to hook up an external screen.
It seems like we are getting somewhere :-)
One thing that might be good to note for an update of the shield, is to add a power LED. It really helps to see if things are powered or not. Even though the shield is upside down currently :-P
After some measurements I found out that on one pin of the two pins there was no oscillating signal. It seems I made a mistake while drawing the schematic in KiCAD. I've selected a crystal symbol which has only two pins. These two pins got connector to pads 1 and 2 of the footprint. But the crystal is connected between pads 1 and 3 of the footprint. The only option is to do some patching using some wire.
First cut the tracks:
Then re-wire using some patching wires:
I did not bother to connect the other two pads to GND. They are now floating. This is bad for EMC, but at the moment I don't really care. As long as it works I'm happy :-)
This is the first PCB I've soldered using a stencil. It was the best option as soldering a QFN by hand is really difficult.
Applying the solder past is much easier than I thought. The most crucial part is aligning the stencil. Once it is perfectly aligned, you hold it firmly in place and smear the paste all over it using a credit card. Filling all the holes in the stencil goes pretty well.
After applying the solder paste, I've used my cheap USB microscope with a 3D printed stand to place all the components.
Using this setup worked pretty well to get all the components in place.
Then using a hot air gun all the components got soldered really well!
The only component that required some extra work was the NCN5130. At first I misaligned it on the pads and pushed it into place. This caused the solder paste to smear out a bit on once side. So I had some shorts here. To solve this, I applied a lot of flux on all four side and re-heated it using my hot air gun. This caused most of the solder to flow correctly into place. There were still some shorts, but they were quickly solved by removing them with some soldering wick and a soldering iron.
I don't have much experience with PCB manufacturers. The only manufacturer I've used in the past is Eurocircuits. However for hobby projects they are really expensive. So I looked for other alternatives.
One popular and cheap PCB manufacturer I came by is JLCPCB. It is a Chinese manufacturer which also does PCB assembly. I've looked at their assembly service, but they can only use components they have in stock and it's rather expensive for my taste. After two weeks the PCB and the stencil arrived. The quality of both were looking really good!
For the components I looked at Mouser. They deliver free for order over 50 euros in Europe. As I was ordering soldering paste and flux also it was fairly easy to go over 50 euro. For some specific components I got some samples from Wurth Elektronik for which I am really thankful!
As almost every Electronics project, it starts with designing the hardware. I've kept the schematic entry as simple as possible. Copying the largest part from the typical application diagram in the datasheet.
Some parts still have to be dimensioned:
Fanin resistor. This resistor determines the maximum amount of current the device is allowed to pull from the KNX bus. KNX is very strict the amount of current that can be consumed and at what rate. They specify that you should select a Fanin which matches closely with the current consumption of your application. Even though I'm not planning to power any peripherals, I've selected the maximum current setting of 40 mA just in case ;-)
Vfilt buffer capacitor. This buffer capacitor is essential in a KNX system. It is used to handle load changes. When for example and LED is switched on, the device current consumption increases instantly. However the KNX standard forbids that the current at the bus side changes instantly. So the buffer cap must deliver the instantaneous current. Then the transceiver is responsible for recharching the capacitor at a fixed current rate. The current slope on the bus is dependant on the Fanin setting selected with the Fanin resistor. Another task of this capacitor is keeping the MCU alive long enough when the bus power goes away. This is necessary as the MCU must be able to write away essential data to non-volatile memory when the bus power drops. In this situation the Raspberry Pi is powered independent from the KNX bus and thus not data needs to be saved. The only requirement is that load changes need to be handled well. As there a no peripherals introducing load steps, I selected a low capacitor value (47 uF) in order to keep it small. It is possible to use an even smaller one, but I wanted some margin just in case I want to power external circuitry in the future.
DC-DC converter inductors. The transceiver has two DC-DC converters. One converter always generates 3.3 V and is also used to power the transceiver itself. The other one can be set to a voltage between 1.2 V to 21 V. Both are capable of delivering 100 mA (if the input power allows for this of course). It is however not possible to use both to deliver 100 mA at the same time as the KNX bus cannot deliver this amount of power. For the second DC-DC converter I've chosen 9 V. This allows to power for example and Arduino in the future. To select the right inductor, I've used RedExpert from Wurth Elektronik. A very simple and useful tool to select the right inductor for a variety of converters. Here you can find the design. I've selected 744043221 as it has lower total losses and is almost the same size as 744042221 (just a little bit higher).
ADC: The NCN5130 has an ANAOUT pin which outputs some diagnostic information. On this pin there is an analog voltage which represents a system parameter. For example the bus voltage or current can be monitored this way. Through UART it can be changed what is monitored through the pin. Honestly I've been lazy here. I've just selected an ADC which was in the KiCAD libraries. As I was not really that interested in the diagnostic output, the accuracy did not really matter for me. I've settled with the ADC081C021CIMM from Texas Instruments. It's a simple I2C ADC.
The Raspberry Pi is not being fed from the KNX bus as there is not enough available power. As the device must be able to operate even at bus voltages as low as 21 V, the maximum available bus power is 21 V x 40 mA = 840 mW. And that is assuming that the NCN5130 is 100% efficient which is not the case...
To calculate the most important component values, there is a handy calcualtor sheet.