I was looking for options to control and improve the performance of our heating system.
Now we have:
• a building which fulfills german KfW70 requirements
• a heating system based on Froeling P4 wood pellets with 15 kW power
• two thermal collectors of 15 qm, producing hot water and supporting the heating system
• a photovoltaic system of ~5 kW
Interested in Home Automation, but not willing to play nonsense games (like talking to Alexa, switch the music on when coming home, etc.) I decided to optimize the collaboration of the Froeling heater with my solar systems.
I quickly realized that one can do nearly everything with a Raspberry-based system. Spending “a few” hours with Mr. Google I found the right community which already had managed to reverse-engineer the control system of P4 and to build a Pi environment that can communicate and control the complete P4 interface.
(many thanks to Horchi for his project page: [GitHub - horchi/linux-p4d: Deamon which fetch sensor data of the 'Lambdatronic s3200' and store to a MySQL database]. However, it is a stand-alone service with its own web interface, and there is no connection to home automation systems.
My goal was to switch the heating cycles of the P4 based on information about the weather conditions of the day. Most days early and late in the winter season, there are a few hours with sun, bringing enough solar intensity to keep the buffer of the heating system (1000L) on acceptable level. But with a standard, timer-based programming of heating cycles, you end up with cold rooms for the days without sun. It is not a good solution to manually reprogram switching times every morning, based on the actual weather forecast. So this would be a good exercise to connect a few players in order to improve the situation.
After some nights with many frustrations and a few positive experiences, I had at least the raspi system running, which now could interact with the Froeling P4 heater system.
In the next step, I had to look for more intelligent systems, which allow to link information from different platforms into one control system. And of course, after googling another few weeks, it is clear that there is only one option: OpenHAB!
Of course, I had no idea at this point, what it means to dig into the details of the tasks necessary for this project.
Here are the more detailed goals:
- Use local weather forecast.
- Use Information about the actual solar intensity, which is directly at hand from my own photovoltaic system
- Logging all internal data of the heating system state in order to optimize the parameters.
- Control the activity of the burner, dependent on shorttime expectation of weather conditions and local sun intensity
- A mobile user interface
Openhabian on Raspberry3:
installation was very easy, and I found the first tutorial which deserves the name:
How to set up graphana and Influx for use with openhabian
For the weather conditions, I decided to use Weather Underground. It has a straightforward integration with a binding in Openhab 2.0. It offers maps with available weather stations in your neighborhood, which can be accessed for extensive local weather reports, after you have applied for an API key, which is very easy.
(Edit Dec. 2019: Weather Underground is no longer available. Now I use the Binding OpenWeatherMap instead. )
My photovoltaic system has a “SolarLog” Interface, so I tried to find a way to get access to the logging data. It turned out that there is the alpha version of a SolarLog Binding.
However, until now, you must be very lucky to find this binding in a google search, and manage to install it in Openhab2. I would strongly appreciate if this binding could be released for ordinary use.
(Edit Dec. 2019: The Binding was finally released in 2018 and works reliably since 2 years, many thanks to Johann Richard!)
In the project P4D a raspberry daemon provides a direct interface to the Froeling heater.
Unfortunately, up to now nobody has programmed a binding for the Froeling system, and I am not a good enough programmer for such a task, so I had to find another way.
All state values of the heating systems can be stored in a SQL data base, which is set up during installation of the p4d daemon.
From this database, I can read values and assign them to Items by a direct call of a SQL request via commandline Commands on Raspi kicked off in Openhab rule files.
Example:
FG_Vorlauf_ist.postUpdate(Float::parseFloat(executeCommandLine("/home/pi/21_vorlauf_ist.sh", 1000).substring(31)))
where the SQL command line in this example for parameter “21” contains:
#!/bin/bash
mysql -h 192.168.x.xxx -P 3307 -u openhab -p password -e "use database; select samples.time, samples.value from samples WHERE samples.address = 21 ORDER BY time DESC LIMIT 1"
For the other direction, heating parameters can be controlled by predefined command strings set up for the daemon. For this case, one can use the EXEC Binding and define a Thing, i.e. “Set_Schwelle_Puffer_ein” with the following command string for the Thing:
/p4d/linux-p4d/scripts/setp.sh %2$s
This allows to address any parameter of the Froeling heater and change its value, i.e.
“2037 20” sets the lower threshold value for the buffer temperature (which has the name “2037”) to value 20.
As I need only 3 parameters for control and 3-5 parameters for monitoring state informations, the task of defining the relevant variables is tricky, but doable.
With those prerequisites, I could start to do something useful and define my first rule, which should be something like:
• IF (shortterm weather will allow solar heating OR sun is presently shining) THEN disable burner
• Shortterm weather: From OpenWeatherMap I get strings with various states like “Sunny”, “Partly cloudy”, etc.
By the use of ordinary transformation files, these strings are transformed into numerical scale for the adjustment of the threshold values as defined above.
(The remaining problem was how to handle a blank in a string? This seems so simple that it is covered nowhere. After a few hours I found this solution: “partly\ cloudy").
• Sun is shining: this is measured by the actual AC power reading of the SolarLog, which is directly usable via the binding.
Setting up time-dependent rules is very tricky for beginners. Yet, there was one forum post which actually stopped me from throwing the towel:
Thank you , Rick!
It turns out that a lot of troubles with time conversions can be avoided by turning the variables into plain strings!
I really like the possibility to visualize all the data in Grafana, although this package posed its own challenges to my understanding of user interfaces. But meanwhile, I am able to even handle SQL data from my heater in its MariaDB data base and I can combine them with Influx persistence data of the rule set, as can be seen here:
P4 Dashboard
Summary
This text will be hidden
Of course, this way of communication with Froeling P4 sounds really strange and it would be much easier if an ordinary binding would be available. Maybe, somebody out there is able to start such a project.
