Geertjan is a DZone Zone Leader and has posted 468 posts at DZone. You can read more from them at their website. View Full User Profile

Interview: Java Heating System Regulator

04.20.2008
| 11751 views |
  • submit to reddit
GreenFire is an open source Java-based heating system regulator. Adam Bien, its creator, tells us all about it in this interview.

Adam is based in Bavaria, Germany. He is the author of several books, a popular speaker at international conferences, and a Java champion. He is the originator and developer behind GreenFire, the open sourced Java-based heating system regulator, one of the nominees for the upcoming JAX Innovation Awards. GreenFire makes use of a wide variety of technologies and techniques, which Adam outlines in this interview.

Adam, firstly, what is GreenFire?

GreenFire is an open-source Java EE 5 application/platform aimed at managing heating systems in a convenient and intelligent way. Greenfire runs in my house—it is mission critical because... winters are cold in Bavaria.

Greenfire is able to control heating remotely and provides a simple Java API to do so. Every five minutes Greenfire checks all the sensors and the weather forecast and then decides what to do. It then sets the heating mode, "On", "Off", etc.

In the end, it writes all decisions and sensor data to a Java DB database. This is interesting for reports:

Greenfire runs on GlassFish v2, but initially on JBoss. It was built with Eclipse, then migrated to NetBeans IDE. I saved about 10-30% in my home's primary energy consumption. My heating bill decreased as well.

What's its history?

If you get a new heating system, it has to be tuned. The configuration isn't complex, but you have to observe the system for a while. I was unhappy with the default behavior in my home—solar energy wasn't being leveraged to the extent that I had expected. I use a combination of solar energy and wood to heat the house. But, before Greenfire, wood heating provided much of the heat, thus precious solar hours were lost.

I started to change the different modes manually—and it worked. So, for example, I switched off the heating on a nice spring morning, and let the sun do its work. However, this approach was error-prone. From time to time, I forgot to switch it on again—and then the next day we found ourselves with cold water and room temparature. I began to think about automating the whole process.

Around the same time, I had identified an "admin interface" in the heating system. It had a hiden COM interface. I started to "hack" the application. After a weekend of work, I was already able to read the system's basic parameters for the external and internal temparature.

Currently, the system is already about three years (since about 2005/2006) in production. It works really well and I began to think about open sourcing it. That process is still in progress. Some modules are still waiting for refactoring and optimization before check-in.

How did it come to be named "GreenFire"?

Its first name was "ParaControl", a composite of Paradigma (the vendor of my heating system) and Control. Later I didn't like the name because I wanted to provide vendor-neutral functionality and wasn't sure about the legal issues. Then the first candidate was "SunFire". This name would have been perfect—however, it was already heavily used.

What are its main features?

The features were built incrementally. The idea for most of the features was born after the heating and weather data was available:

  • Monitoring of the heating status, external / internal temparature, current solar power, total solar power etc.
  • Reporting of all archived data
  • Remote control (On/Off/Warm Water)
  • Integration with standalone clients via JMS and Shoal
  • Scripting interface for business logic
  • Monitoring Widget (see my blog: http://blog.adam-bien.com)
  • RSS feed for mobile phones—works well with iPhone
However, all the features are just collateral stuff—the main goal is leveraging the highest possible level of C02-neutral resources and so save energy in my home environment.

Can you walk us through a detailed scenario where it is currently used?

There are actually several scenarios:

  • Summer: During the summer, Bavaria has enough solar energy for heating the water. There is even too much sun, so the system could overheat. To protect it, most heating system vendors just set the collectors off. GreenFire uses the superfluous energy and heats the basement with it. It takes several weeks—and the basement becomes several degrees warmer (to about 23°C). This is actually a good way to store energy for autumn. You can leverage serveral hundred kW more with this strategy. The basement remains warm until December/January.
  • Spring/Autumn: On the first day with enough sun, GreenFire sets the heating off, and tries to fully leverage solar energy. When it becomes too cold, it switches back to the default mode and allows the usage of, for example, wood pellets for heating. There are actually about 8 weeks in the year during which GreenFire turns off the main heating. You could achieve the same by controlling the heating manually, however you will have to stay home to do so.
  • Winter: You cannot save much energy during winter by managing the heating in an intelligent way. All of the energy is used for heating. However, if I'm using my wood burning stove GreenFire monitors it and leverages the superfluous energy as well.

Please tell us about its architecture.

I built the whole system in my spare time, so I was really interested in "Time To Market". I started with the integration module, which talked directly to the heating system. It is abstracted by an interface, so you could easily integrate it with any heating system you want. The interface is exposed via RMI to an EJB 3. RMI runs in an isolated JVM, so if it crashes GlassFish will still operate.

Another EJB 3 with a timer service is responsible for the "heartbeat". Every five minutes it gathers data from the integration module and the weather forecast module. Then it passes the data to the broadcaster. The broadcaster sends the data internally via JMS to all the listeners. One particular listener is the "brain"—it is another EJB 3 that downloads a Groovy script from a URL and passes the data to the script. The EJB 3 expects a result that is the suggested "mode" for the heating (On/Off/Auto/Warmwater only, and so on).

Another interesting module is the "bridge". It translates the JMS-messages to XML and uses Shoal to distribute the data in the local LAN. This is really convenient because then you can easily start up a local Swing application which will receive the data every five minutes as well. I've started to work on a JavaFX client too—inspired by the NetBeans Weather Java FX Application.

The other modules, such as RSS and widget are basically "listeners" that participate in the "heartbeat".

Here is an overview:

What's the reason that you chose some of the various technologies you're using?

  • Groovy integration. This was a natural choice. The first algorithms were hardcoded in Java. The unit testing was just easier in Groovy. After that, it was very easy to migrate the working Java code into Groovy. It was actually nothing more than "copy and paste". At the same time, I already had a working sample for the pattern "Fluid Kernel" (http://p4j5.dev.java.net). So the effort to integrate Groovy was almost zero.
  • Shoal integration. I started with JMS Topics. It worked well, however the set up is a little bit more complex. You have to at least provide a jndi.properties file and know the IP adress of the server. Shoal was just more suitable for my purposes. I wasn't really interested in transactional reliability or durable subscription. I had a working example as well. I contributed some code to http://fishfarm.dev.java.net, so I knew it worked.
  • Mobile integration. I wanted to monitor the status of my house in a convenient way. It turned out that an RSS feed works really well, at least on my Nokia Phone and on my wife's iPhone:

  • SunSPOT integration. These are perfectly suitable for my purposes. They already come with temparature sensors and IO-ports. I know nothing comparable. I experimented a little bit with another device, which had to be programmed in C, however it just consumed too much time and GreenFire is a spare time project.

Can you show an example Groovy script?

VERSION = "Version 0.6, 05.11.2006"
logger.info(VERSION)
println(VERSION)

tpoShouldHigh = configurationItem.getTPOHigh()
tpoShouldLow = configurationItem.getTPOLow()

twoShouldHigh = configurationItem.getTWOHigh()
twoShouldLow = configurationItem.getTWOLow()
solPowerLow = configurationItem.getSolPowerLow()

tpoIs = heatingStateItem.getTPO()
twoIs = heatingStateItem.getTWO()
tpuIs = heatingStateItem.getTPU()

heatingModeIs = heatingStateItem.getHeatingMode()
solPowerIs = heatingStateItem.getMomentaneLeistung()

OFF = configurationItem.getHeatingModeOff();
ON = configurationItem.getHeatingModeOn();

logger.info("Current TPO: " + tpoIs + " Current TWO: " + twoIs)
logger.info("TPO (should) High: " + tpoShouldHigh + " TWO (should) High: " + twoShouldHigh)
logger.info("TPO (should) Low: " + tpoShouldLow + " TWO (should) High: " + twoShouldLow)

if(heatingModeIs != 0){ // Change only if heating is not in AUTO mode

// the buffer shouldn't be hotter than 72
if(tpoIs > 72 || twoIs > 72){
suggestedMode = ON
logger.info("Too hot (70) suggested change: " + suggestedMode)
return;
}
if(solPowerIs < solPowerLow){
suggestedMode = OFF
logger.info("The solar power is too low. Suggested change: " + suggestedMode);
return;
}
if(tpoIs > tpoShouldHigh || twoIs > twoShouldHigh){
suggestedMode = ON
logger.info("Too hot suggested change: " + suggestedMode)
}else if(twoIs < twoShouldLow || tpoIs < tpoShouldLow){
suggestedMode = OFF
logger.info("Too hot suggested change: " + suggestedMode)
}else{
suggestedMode = heatingStateItem.getHeatingMode()
logger.info("Nothing to do. Just keeping the current mode: " + suggestedMode)
}
}else{ // Heating is in the AUTO state. But cooling is needed anyway
if(tpoIs > 68 || twoIs > 68){
suggestedMode = ON
logger.info("Temperature greater than 68: " + suggestedMode)
}else{
suggestedMode = heatingModeIs
logger.info("Heating is in AUTO state. Keeping the state.")
}
}

So what percentage of GreenFire is Java and what percentage is Groovy?

95% Java, 5% Groovy, BUT the essential business logic was written in Groovy. GreenFire downloads the script from a HTTP (later from an JPA-entity) server every five minutes. So, I'm able to change the algorithm very quickly—without redeploying the application. I can correct potential problems every 5 minutes—it is really robust...

In the beginning of this interview, you said you started with Eclipse and JBoss, but then migrated to NetBeans IDE and GlassFish. Why?

When I started with GreenFire, Java EE 5 was an early draft—and JBoss the first usable container with experimental EJB 3 support. I used Eclipse with Maven to build the modules. I switched to NetBeans IDE because of better integration of:

  • Database (the Explorer)
  • Visual JSF and Swing Designer
  • Java FX demos and support
  • Really good GlassFish integration (monitoring, local and remote deployment)
  • Built-In support for Java EE 5 deployment

I was able to really quickly develop and deploy GreenFire. In my spare time I like to try the "bleeding edge technologies". So I often use the latest IDE, frameworks, etc. This is my way to explore new things. This is not a problem with NetBeans IDE—you can just download the whole bundle every day. If a daily build doesn't work, I just wait another day or use the latest RC. This strategy just isn't applicable with Eclipse—you have to not only install Eclipse, but corresponding plugins as well. You need at least six or seven for GreenFire. This was just too time consuming for a spare time project.

I switched from JBoss to GlassFish just because of the GlassFish administration capabilities. You can easily administer GlassFish using a web interface. Here, for example, is the GlassFish console:

It is not so easy with JBoss...

What kind of developments will GreenFire undergo in the future?

I have too many ideas! I have summarized the most realistic features in the following below:

  • Easier script/profile management. Currently GreenFire runs in winter and summer mode. I need to switch the scripts back and forth. However, I would like to simplify management and provide a user interface for this purpose. In addition, I would like to provide additional profiles, such as vacation, work, and so on.
  • Water pump integration. Every German house has a circulation pump for warm water. The purpose of this device is to provide immediate availability of warm water. However, the pump is controlled by a timer, so it runs whether you need warm water or not. Every time it runs the warm water temparature drops several degrees, which in my case means wasting several kW of energy. I would like to integrate the control of this pump with GreenFire.
  • Further SunSPOT integration. GreenFire determines its actions based on the weather forecast, the current collector power, and the thermos temparature. I would like to integrate the internal temperature, external temparature, as well as the sun's radiation in various rooms as well. I will use SunSPOTs for this purpose.
  • Wood pellet price feed integration. I would like to intercept the price-feeds of several wood pellet providers. Because GreenFire knows how many wood pellets were burned, it should be able to suggest the best price/condition via email.
  • Comparative reporting. I have gathered weather data for about 3 years in Java DB, which happens every five minutes. It would be nice to correlate the data, so that you would be able to see the temparature and energy costs of the current day one or two years ago.
  • Air ventilation integration. My house is actively ventilated. The ventilator runs 24 hours per day. I think this should not be necessary. I would like to control the ventilator as well, with a SunSPOT and some electronic relays.

I'm thinking about decentralizing the whole system into loosely-coupled SunSPOTs. They could communicate in a P2P manner. This would be especially interesting for users without a central server.

Would you like contributions, such as code, from the community?

Sure. A main motivation when participating in open source is learning from others and of course benefitting from code contributions. I underestimated the level of interest in this topic. I gave a session at the OOP 2008 conference in Munich about GreenFire... and the room was overcrowded. I received several e-mails after the session with suggestions/questions.

I would expect some patches and ideas from interested developers first. After this step, I would decide whether commit rights to the repo should be granted or not. This approach works really well in my other open source projects, such as p4j5.dev.java.net and qlb.dev.java.net.

In the long term I imagine I'd be able to provide an open library of scripts and strategies for GreenFire. So, new ideas/strategies could be easier shared and leveraged that way.

How do I get started with it?

For now, about 80% of the code is in the open source repository. You can check out the projects into NetBeans IDE and start working/deploying. I'm thinking about providing a binary (EAR)distribution as well. For this purpose, I will have to mock the heating system, otherwise it will be unusable for most developers.

Finally, it turns out that GreenFire has been nominated for a JAX award. What's your connection with that conference and how did the award come about?

I really like the JAX conference—I've been speaking there since 2001, which was the first JAX conference. This year I will give a workshop about pragmatic architectures and design of Java EE 5 applications. I will try to show as much code as possible. On the Thursday I will give a session about Maintainable RIAs, and explain some Presentation Tier Patterns.

I received an email last week about the nomination. It was a big surprise. GreenFire is competing with many European companies and open source projects. But I'm looking forward to it. And, at the very least, GreenFire is a good contribution to the environment...

Related Resources

AttachmentSize
adam-conference.jpg10.79 KB
architecture.jpg42.99 KB
greenfire.jpg5.28 KB
rss-sample.jpg43.36 KB
glassfish_console.JPG31.25 KB
report_overview.JPG46.46 KB
iphone.jpg47.98 KB
Published at DZone with permission of its author, Geertjan Wielenga.

Comments

Steven Baker replied on Sun, 2008/04/20 - 10:19pm

Very average peice of software.

Hardly worth mentioning in my opinion. 

Geertjan Wielenga replied on Sun, 2008/04/20 - 11:10pm

I hope you're kidding, zynasis. :-) Also, if you're serious, I'd like you to know that it is incredibly rude to say something like that without giving the smallest hint as to why you are saying that. So far, in my time on Javalobby, I have not seen a worse comment than yours.

Steven Baker replied on Sun, 2008/04/20 - 11:29pm

Please, from what I can see here there is hardly anything to this.

Polling, making adjustments and reporting/control via a web page.

Most semi serious applications already do this in one way or another.

 

Also, who calls a component "brain". Is this a simple way of slamming all the business logic into a single component? Seperate the business logic from the presentation. 

I stand by my comment.

adam bien replied on Mon, 2008/04/21 - 1:16am in response to: Steven Baker

"Very average peice of software."

I don't think it is average - I even don't know another system which manages a heating system in such a a way. I would call it rather "simple", than "average". It is amazing how much you can achieve (=save energy) with such a  simple  approach.

I wouldn't like to write a "rocket science" class software. I'm even thinking about further simplifying it - and run it directly on SunSPOTs.

 But if you thinking it is too average - just contribute an AI-module. In case it works (=save energy :-)) I will integrate it!

 Thanks for your comment!,

 

adam

adam bien replied on Mon, 2008/04/21 - 1:09am in response to: Steven Baker

"Polling, making adjustments and reporting/control via a web page."

 Not a WebPage - this is still in work. I access the offline database via reports.

"Most semi serious applications already do this in one way or another."

You know another heating control? 

 

"Also, who calls a component "brain". Is this a simple way of slamming all the business logic into a single component? Seperate the business logic from the presentation"

 

In my opensource activities I like to use fancy names. You know a better name? Heart would be appropriate as well.  The logic isn't in the component at all (this is the trick)  - it is downloaded from outside...

"Seperate the business logic from the presentation"

In this case it is totally separated - there is actually no connection between both. The RSS-View (your "WebPage") is feeded by a JMS-Queue. There is no dependeny between both.

"I stand by my comment."

No problem. But keep in mind: my intention was to manage heating control in a very efficient manner. I'm just wasn't interested in building complex software. Keep It Simple. In the next refactoring I'm going to further simplify it. So it will be even more "average" in your eyes :-). 

However - if you are another great ideas / algorithms how to save energy - you are welcome... 

 

Geertjan Wielenga replied on Mon, 2008/04/21 - 1:55am in response to: Steven Baker

[quote=zynasis]

Please, from what I can see here there is hardly anything to this.

Polling, making adjustments and reporting/control via a web page.

Most semi serious applications already do this in one way or another.

[/quote]

 

So, you agree that the application does what it is meant to do. How is that "average"? Isn't that at least "good"? Is complexity a required attribute for something being "good"? So, Adam should make his application much more complex and only then would his application be worth mentioning? He needed an application to control his heating system. It does that in a very ingenious way, leveraging a wide range of technologies. I'd be very happy to interview you, zynasis, about the applications you've made. :-) Really.

 

Steven Baker replied on Mon, 2008/04/21 - 2:29am in response to: Geertjan Wielenga

im not interested in ticketting myself, but a small amount of info is that my history is in billing software.
from my point of view, this is the same old same old, and nothing really new/revolutionary.

adam bien replied on Mon, 2008/04/21 - 3:42am in response to: Steven Baker

[quote=zynasis]im not interested in ticketting myself, but a small amount of info is that my history is in billing software.
from my point of view, this is the same old same old, and nothing really new/revolutionary.
[/quote] You are right GreenFire is nothing new or even revolutionary. The interesting point is, that you can save energy with only little effort.

I would go further, than your opinion: Java SE / EE are nothing new. Smalltalk Ruby, were/are very similar to Java (even a superset). Appserver is nothing new - CICS is very similar.

So you are very right!

Harel Malka replied on Mon, 2008/04/21 - 5:31am

Adam, don't forget that any space launch after the first suyuz/sputnik is also 'nothing new', any computer after the first behemoths of the 50s-60s is old news, the internet 'has been done before', and the human race is passe. 
Funny how bitter people can get.

I found your system very interesting from a home-hacking point of view. It sounds like a good fun project to do.
 

David Gilbert replied on Mon, 2008/04/21 - 5:39am in response to: Steven Baker

[quote=zynasis]

Very average peice of software.

Hardly worth mentioning in my opinion.

[/quote]

Well, I'll discount your opinion because I think this is one of the most interesting posts to appear on JavaLobby for some time. And I'm off now to look at my home heating system and see whether I can monitor / control it in the same way.

Geertjan Wielenga replied on Mon, 2008/04/21 - 6:08am in response to: David Gilbert

[quote=dgilbert]

And I'm off now to look at my home heating system and see whether I can monitor / control it in the same way.

[/quote]

I tried the same thing yesterday, but failed. Maybe Adam can give us a hint about how to make that first fundamental connection from Java to a home heating system. Or, at least, how to figure out whether that is possible with one's home heating system.

James Sugrue replied on Mon, 2008/04/21 - 9:46am

This piece of technology is really interesting, and there's nothing wrong with applying proven techniques to a new field. The idea of a smart home is something that appeals to us all and it's great to see some open source Java libraries helping with home automation. 

Congratulations on the JAX award nomination!

 

Mike P(Okidoky) replied on Mon, 2008/04/21 - 10:19am

Nice to see a positive project.

I'm interested to know what type of adaptive control techniques it has.   http://en.wikipedia.org/wiki/Control_theory

What's this "tuning" all about?  When it's first introduced, how long does it take to "home in" in to an optimum bahavior, and will it continue to adapt.  For instance, on a sunny day, there is more heat coming in to the house, so what it has "learned" so far, might need further adjustments.  And what it might "unlearn" one day it might have to "relearn" later.  How much energy is wasted while the system tinkers and "tunes", and retunes?

 

Serguei Mourachov replied on Mon, 2008/04/21 - 5:57pm

This appliaction is really good example of overengineering that creates so bad reputation for Java nowdays.

You don't need all the JEE crapware to solve such a simple problem. 

adam bien replied on Tue, 2008/04/22 - 1:53am in response to: Serguei Mourachov

Serguei - it wasn't J2EE - but Java EE 5. It is really lean - no overhead. If you wish - just checkout the code and make it leaner :-). I'm already curious.

Timotheos Motwary replied on Sun, 2009/01/04 - 7:43am

Very very interesting.

I don't see anything bad in using EE5 for such a problem; it definately adds more possibilities!

Congrats!

 

Bendjamin Stokson replied on Thu, 2009/11/26 - 7:31am

Polling, making adjustments and reporting/control via a web page. Most semi serious applications already do this in one way or another. I control my infrared heater from IPOD.

Kookee Gacho replied on Thu, 2012/05/31 - 6:31am

Today, Java is used everywhere in computers, in mobile devices, in sim cards and in many other fields. -Arthur van der Vant

Anelina Martin replied on Tue, 2013/12/24 - 1:06am

Water heaters are the needs of every house specially in winters when the temperature goes down that time hot water provide great relief. Java heating system changes the working mechanism of water warmer now we have more stable system which can monitor all the things on regular bases. Even by installing extra kits to the heating up systems we can add more functionality  .    It also help in maintaining the water warmer  with exact facts and figures.  

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.