In the old times, measuring data manually sometimes meant braving the elements:
Now, nearly all measurements are automated:
In order to calculate the seasonal performance factor of the heat pump system we have still used the ‘official’ energy reading provided by the heat pump’s display.
Can’t this be automated, too?
Our Stiebel-Eltron WPF7 basic is a simple brine/water heat pump without ‘smart’ features. Our control units turns it on and off via a latch contact.
But there are two interesting interfaces:
- An optical interface to connect a service PC.
- Wired connections to an internal CAN bus – a simple fieldbus used for example in vehicles.
We picked option 2 as it does not require an optical device to read off data. Our control unit also uses CAN bus, and we have test equipment for wired CAN connections.
I always want to use what we already have, and I had a Raspberry Pi not yet put into ‘productive’ use. As usual, you find geeks online who did already what you plan: Reading off CAN bus data provided by a Stiebel-Eltron heat pump using a Raspberry Pi.
In this first post, I am covering the test hardware setup. Before connecting to the heat pump I wanted to test with CAN devices I am familiar with.
Credits
I am indebted to the following sources for information and tools:
On Stiebel-Eltron heat pumps’ CAN bus plus Raspberry Pi
On Raspberry Pi and CAN bus in general / for other applications:
CAN converter
RPi has so-called GPIO pins that let you control devices in the real world. Talking to a CAN device requires an extension board to be connected to these pins.
My challenge: I had the older version – ‘Model B‘ – with 26 GPIO pins only. The successor model B Plus had 40 pins. While the pin assignment was not changed, newer CAN extension boards (like this from SK Pang) were too large physically for the old Pi (The older, smaller board from SK Pang had been retired). I was glad to find this small board on ebay.
Edit, 2016-08-24: I replaced the board shown below by SK Pang’s retired PiCAN board – see part 2.
My Pi plus extension board:
Wiring the test CAN bus
The image shows the CAN board attached to the Pi, with CAN High, Low, and Ground connected. Following standards, CAN bus needs to be terminated on both ends, using a 120Ω resistor. As our wires are quite short and we had never observed issues with not / falsely terminated short CAN busses so far, we did not add proper termination (BTW: Thanks to ebay seller ZAB for providing the proper resistor!)
In the final setup, the other end of the CAN cable has to be connected to heat pump’s internal bus.
For testing purposes, I am building a CAN bus with three member devices:
- Test control unit UVR1611 by Technische Alternative. This test unit does not control anything. A single temperature sensor is connected to check if logging works as expected.
- The unit’s data logger BL-NET: The logger and the control unit communicate via CAN bus and logging data can be transferred to a PC via ethernet. For more details on using control units and loggers by Technische Alternative see this post.
- My Raspberry Pi plus CAN board – connected to BL-NET.
I am using software WinSol on a PC connected via Ethernet to the data logger – to configure logging (BL-NET’s IP address) and to check if the temperature sensor works. BL-NET is set to log data every minute, so that I am sure that CAN packets are available on the bus often. More on WinSol and BL-NET here.
Activating CAN capabilities
Operating system update: I had first used the Raspberry Pi in 2014 using the Raspbian operating system, and I used a pre-installed SD card. Newer versions of the Raspbian Linux operating system do support CAN interfaces, so I just had to upgrade the kernel, described e.g. in CowFish’s instructions (see Software Installation section)
Operating system config: The CAN interface needs the underlying SPI bus – which has to be activated in the Pi’s configuration. This is described in detail on the blog of board vendor SK Pang.
Setting bit rate and bringing up the CAN interface
In order to check if software has been installed correctly, a virtual CAN interface can be configured as a rehearsal:
sudo modprobe vcan sudo ip link add vcan0 type vcan sudo ip link set vcan0 up
This interface is not used, so sniffer software (as Wireshark, see below) will not show any communication.
If a physical CAN interface is activated if no CAN bus is physically connected an error cannot find device can0 is expected.
The critical parameter for the physical CAN bus is the bit rate of the bus. For an existing bus, you need to figure out its bit rate from documentation.
According to messpunkt.org the bit rate for the heat pump’s is 20kbit/s. UVR1611’s bus uses bit rate is 50kbit/s, so the interface is configured with
sudo ip link set can0 type can bitrate 50000 sudo ifconfig can0 up
Troubleshooting wrong bit rate
If this is not configured correctly, you will not get errors but you will simply not see any packets. Checking the CAN configured with a wrong bit rate …
sudo ip -s -d link show can0
… showed that CAN state is BUS OFF …
… a state the device can enter if there have been too many errors on the bus according to this documentation the CAN protocol family in Linux.
If the bit rate is set to 50000, packets are visible now.
Watching packets flowing by
I’ve installed Wireshark sniffer on the PI…
sudo apt-get install wireshark
… and selected the can0 interface. Packets are flowing, and Wireshark parses them correctly as CAN Protocol!
If you know ‘how to speak CAN’ other devices on the bus can be polled for measurement values, using tools, like the Jürg’s CAN Progs or SK Pang’s Test tools linked at the bottom of this article.
In the next post in this series I will cover the setup of the Raspberry Pi CAN sniffer for the heat pump’s CAN bus.
elkemental Force 