In the last post, I showed how to use Raspberry Pi as CAN bus logger – using a test bus connected to control unit UVR1611. Now I have connected it to my heat pump’s bus.
Credits for software and instructions:
Special thanks to SK Pang Electronics who provided me with CAN boards for Raspberry Pi after having read my previous post!!
Wiring CAN bus
We use a Stiebel-Eltron WPF 7 basic heat pump installed in 2012. The English website now refers to model WPF 7 basic s.
The CAN bus connections described in the German manual (Section 12.2.3) and the English manual (Wiring diagram, p.25) are similar:
H, L and GROUND wires from the Pi’s CAN board are connected to the respective terminals inside the heat pump. I don’t use the optional power supply as the CAN board is powered by Raspberry Pi, and I don’t terminate the bus correctly with 120 Ω. As with the test bus, wires are rather short and thus have low resistance.
In the first tests Raspberry Pi had the privilege to overlook the heat pump room as the top of the buffer tank was the only spot the WLAN signal was strong enough …
… or I used a cross-over ethernet cable and a special office desk:
Now Raspberry Pi has its final position on the ‘organic controller board’, next to control unit UVR16x2 – and after a major upgrade to both LAN and WLAN all connections are reliable.
Bringing up the interface
According to messpunkt.org the bit rate of Stiebel-Eltron’s bus is 20000 bit/s; so the interface is activated with:
sudo ip link set can0 type can bitrate 20000 sudo ifconfig can0 up
Watching the idle bus
First I was simply watching with sniffer Wireshark if the heat pump says anything without being triggered. It does not – only once every few minutes there are two packets. So I need to learn to talk to it.
Learning about CAN communications
SK Pang provides an example of requesting data using open source tool cansend: The so-called CAN ID is followed by # and the actual data. This CAN ID refers to an ‘object’ – a set of properties of the device, like the set of inputs or outputs – and it can contain also the node ID of the device on the bus. There are many CAN tutorials on the net, I found this tutorial very useful.
I was able to follow the communications of the two nodes in my test bus as I knew their node numbers and what to expect – the data logger would ask the controller for a set of configured sensor outputs every minute. Most packets sent by either bus member are related to object 480, indicating the transmission of a set of values (Process Data Exchange Objects, PDOs. More details on UVR’s CAN communication, in German)
So I need to know object ID(s) and properly formed data values to ask the heat pump for energy readings, and I must not break something by changing values.
Collecting interesting heat pump parameters for monitoring
I am very grateful for Jürg’s CAN tool can_scan that allow for querying a Stiebel-Eltron heat pump for specific values and also for learning about all possible parameters (listed in so-called Elster tables).
In order to check the list of allowed CAN IDs used by the heat pump I run:
./can_scan can0 680
can0 is the (default) name of the interface created earlier and 680 is my (the sender’s) CAN ID, one of the IDs allowed by can_scan.
Start of output:
elster-kromschroeder can-bus address scanner and test utility copyright (c) 2014 Jürg Müller, CH-5524 scan on CAN-id: 680 list of valid can id's: 000 (8000 = 325-07) 180 (8000 = 325-07) 301 (8000 = 325-07) 480 (8000 = 325-07) 601 (8000 = 325-07)
In order to investigate available values and their meaning I run can_scan for each of these IDs:
./can_scan can0 680 180
Embedded below is part of the output, containing some of the values (and /* Comments */). This list of parameters is much longer than the list of values available via the display on the heat pump!
I am mainly interested in metered energies and current temperatures of the heat source (brine) and the ‘environment’ – to compare these values to other sensors’ output:
elster-kromschroeder can-bus address scanner and test utility copyright (c) 2014 Jürg Müller, CH-5524 0001: 0000 (FEHLERMELDUNG 0) 0003: 019a (SPEICHERSOLLTEMP 41.0) 0005: 00f0 (RAUMSOLLTEMP_I 24.0) 0006: 00c8 (RAUMSOLLTEMP_II 20.0) 0007: 00c8 (RAUMSOLLTEMP_III 20.0) 0008: 00a0 (RAUMSOLLTEMP_NACHT 16.0) 0009: 3a0e (UHRZEIT 14:58) 000a: 1208 (DATUM 18.08.) 000c: 00e9 (AUSSENTEMP 23.3) /* Ambient temperature */ 000d: ffe6 (SAMMLERISTTEMP -2.6) 000e: fe70 (SPEICHERISTTEMP -40.0) 0010: 0050 (GERAETEKONFIGURATION 80) 0013: 01e0 (EINSTELL_SPEICHERSOLLTEMP 48.0) 0016: 0140 (RUECKLAUFISTTEMP 32.0) /* Heating water return temperature */ ... 01d4: 00e2 (QUELLE_IST 22.6) /* Source (brine) temperature */ ... /* Hot tap water heating energy MWh + kWh */ /* Daily totaly */ 092a: 030d (WAERMEERTRAG_WW_TAG_WH 781) 092b: 0000 (WAERMEERTRAG_WW_TAG_KWH 0) /* Total energy since system startup */ 092c: 0155 (WAERMEERTRAG_WW_SUM_KWH 341) 092d: 001a (WAERMEERTRAG_WW_SUM_MWH 26) /* Space heating energy, MWh + kWh */ /* Daily totals */ 092e: 02db (WAERMEERTRAG_HEIZ_TAG_WH 731) 092f: 0006 (WAERMEERTRAG_HEIZ_TAG_KWH 6) /* Total energy since system startup */ 0930: 0073 (WAERMEERTRAG_HEIZ_SUM_KWH 115) 0931: 0027 (WAERMEERTRAG_HEIZ_SUM_MWH 39)
Querying for one value
The the heating energy to date in MWh corresponds to index 0931:
./can_scan can0 680 180.0931
The output of can_scan already contains the sum of the MWh (0931) and kWh (0930) values:
elster-kromschroeder can-bus address scanner and test utility copyright (c) 2014 Jürg Müller, CH-5524 value: 0027 (WAERMEERTRAG_HEIZ_SUM_MWH 39.115)
The network trace shows that the logger (using ID 680) queries for two values related to ID 180 – the kWh and the MWh part:
Interpretation of these four packets – as explained on Jürg’s website here and here in German:
00 00 06 80 05 00 00 00 31 00 fa 09 31 00 00 01 80 07 00 00 00 d2 00 fa 09 31 00 27 00 00 06 80 05 00 00 00 31 00 fa 09 30 00 00 01 80 07 00 00 00 d2 00 fa 09 30 00 73 |---------| || |---| || |---| |---| 1) 2) 3) 4) 5) 6) 1) CAN-ID used by the sender: 180 or 680 2) No of bytes of data - 5 for queries, 7 for replies 3) CAN ID of the communications partner and type of message. For queries the second digit is 1. Pattern: n1 0m with n = 180 / 80 = 3 (hex) and m = 180 mod 8 = 0 (hex) Partner ID = 30 * 8 (hex) + 00 = 180 Responses follow a similar pattern using second digit 2: Partner ID is: d0 * 8 + 00 = 680 4) fa indicates that the Elster index no is greater equal ff. 5) Index (parameter) queried for: 0930 for kWh and 0931 for MWh 6) Value returned 27h=39,73h=115
I am not sure which node IDs my logger and the heat pump use as the IDs. 180 seems to be an object ID without node ID added while 301 would refer to object ID + node ID 1. But I suppose with two devices on the bus only, and one being only a listener, there is no ambiguity.
Logging script
I found all interesting indices listed under CAN ID 180; so am now looping through this set once every three minutes with can_scan, cut out the number, and add it to a new line in a text log file. The CAN interfaces is (re-)started every time in case something happens, and the file is sent to my local server via FTP.
Every month a new log file is started, and log files – to be imported into my SQL Server and processed as log files from UVR1611 / UVR16x2, the PV generator’s inverter, or the smart meter.
(Not the most elegant script – consider it a ‘proof of concept’! Another option is to trigger the sending of data with can_scan and collect output via can_logger.)
Interesting to-be-logged parameters are added to a ‘table’ – a file called indices:
0016 RUECKLAUFISTTEMP 01d4 QUELLE_IST 01d6 WPVORLAUFIST 091b EL_AUFNAHMELEISTUNG_WW_TAG_KWH 091d EL_AUFNAHMELEISTUNG_WW_SUM_MWH 091f EL_AUFNAHMELEISTUNG_HEIZ_TAG_KWH 0921 EL_AUFNAHMELEISTUNG_HEIZ_SUM_MWH 092b WAERMEERTRAG_WW_TAG_KWH 092f WAERMEERTRAG_HEIZ_TAG_KWH 092d WAERMEERTRAG_WW_SUM_MWH 0931 WAERMEERTRAG_HEIZ_SUM_MWH 000c AUSSENTEMP 0923 WAERMEERTRAG_2WE_WW_TAG_KWH 0925 WAERMEERTRAG_2WE_WW_SUM_MWH 0927 WAERMEERTRAG_2WE_HEIZ_TAG_KWH 0929 WAERMEERTRAG_2WE_HEIZ_SUM_MWH
Script:
# Define folders
logdir="/CAN_LOGS"
scriptsdir="/CAN_SCRIPTS"
indexfile="$scriptsdir/indices"
# FTP parameters
ftphost="FTP_SERVER"
ftpuser="FTP_USER"
ftppw="***********"
# Exit if scripts not found
if ! [ -d $scriptsdir ]
then
echo Directory $scriptsdir does not exist!
exit 1
fi
# Create log dir if it does not exist yet
if ! [ -d $logdir ]
then
mkdir $logdir
fi
sleep 5
echo ======================================================================
# Start logging
while [ 0 -le 1 ]
do
# Get current date and start new logging line
now=$(date +'%Y-%m-%d;%H:%M:%S')
line=$now
year=$(date +'%Y')
month=$(date +'%m')
logfile=$year-$month-can-log-wpf7.csv
logfilepath=$logdir/$logfile
# Create a new file for every month, write header line
if ! [ -f $logfilepath ]
then
headers="Datum Uhrzeit"
while read indexline
do
header=$(echo $indexline | cut -d" " -f2)
headers+=";"$header
done < $indexfile ; echo "$headers" > $logfilepath
fi
# (Re-)start CAN interface
sudo ip link set can0 type can bitrate 20000
sudo ip link set can0 up
# Loop through interesting Elster indices
while read indexline
do
# Get output of can_scan for this index, search for line with output values
index=$(echo $indexline | cut -d" " -f1)
value=$($scriptsdir/./can_scan can0 680 180.$index | grep "value" | replace ")" "" | grep -o "\-*[0-9]*\.\?[0-9]*$" | replace "." ",")
echo "$index $value"
# Append value to line of CSV file
line="$line;$value"
done < $indexfile ; echo $line >> $logfilepath
# echo FTP log file to server
ftp -n -v $ftphost << END_SCRIPT
ascii
user $ftpuser $ftppw
binary
cd RPi
ls
lcd $logdir
put $logfile
ls
bye
END_SCRIPT
echo "------------------------------------------------------------------"
# Wait - next logging data point
sleep 180
# Runs forever, use Ctrl+C to stop
done
In order to autostart the script I added a line to the rc.local file:
su pi -c '/CAN_SCRIPTS/pkt_can_monitor'
Using the logged values
In contrast to brine or water temperature heating energies are not available on the heat pump’s CAN bus in real-time: The main MWh counter is only incremented once per day at midnight. Then the daily kWh counter is added to the previous value.
Daily or monthly energy increments are calculated from the logged values in the SQL database and for example used to determine performance factors (heating energy over electrical energy) shown in our documentation of measurement data for the heat pump system.
elkemental Force 
Wow, I am very impressed :)