Адам базируется в Баварии, Германия. Он является автором нескольких книг, популярным докладчиком на международных конференциях и чемпионом по Java. Он является создателем и разработчиком GreenFire , регулятора системы отопления на основе Java с открытым исходным кодом, одного из номинантов на предстоящую премию JAX Innovation Awards . GreenFire использует широкий спектр технологий и методов, которые Адам рассказывает в этом интервью.
Адам, во-первых, что такое GreenFire?
GreenFire — это приложение / платформа Java EE 5 с открытым исходным кодом, предназначенное для удобного и интеллектуального управления системами отопления. Greenfire работает в моем доме — это важно для миссии, потому что … в Баварии холодные зимы.
Greenfire может дистанционно управлять отоплением и предоставляет для этого простой Java API. Каждые пять минут Greenfire проверяет все датчики и прогноз погоды, а затем решает, что делать. Затем он устанавливает режим нагрева: «Вкл.», «Выкл.» И т. Д.
В конце он записывает все решения и данные датчиков в базу данных Java DB. Это интересно для отчетов:
Greenfire работает на GlassFish v2, но изначально на JBoss. Он был построен с использованием Eclipse, а затем перенесен в среду IDE NetBeans. Я сэкономил около 10-30% в первичном потреблении энергии в моем доме. Мой счет за отопление также уменьшился.
Какова его история?
Если вы получаете новую систему отопления, она должна быть настроена. Конфигурация не сложна, но вы должны некоторое время наблюдать за системой. Я был недоволен поведением по умолчанию в моем доме — солнечная энергия не использовалась настолько, насколько я ожидал. Я использую комбинацию солнечной энергии и дров для отопления дома. Но до Greenfire отопление дровами обеспечивало большую часть тепла, поэтому драгоценные солнечные часы были потеряны.
Я начал менять разные режимы вручную — и это сработало. Так, например, я выключил отопление прекрасным весенним утром и позволил солнцу сделать свою работу. Однако этот подход был подвержен ошибкам. Время от времени я забывал включать его снова — и затем на следующий день мы оказались с холодной водой и комнатным температурным режимом. Я начал думать об автоматизации всего процесса.
Примерно в то же время я обнаружил «интерфейс администратора» в системе отопления. У него был скрытый интерфейс COM. Я начал «взламывать» приложение. После выходных я уже смог прочитать основные параметры системы для внешнего и внутреннего измерения.
В настоящее время система уже около трех лет (примерно с 2005/2006) в производстве. Это работает очень хорошо, и я начал думать об этом. Этот процесс все еще продолжается. Некоторые модули все еще ждут рефакторинга и оптимизации перед регистрацией.
Как оно получило название GreenFire?
Его имя было «ParaControl», композит Paradigma (производитель моей системы отопления) и Control. Позже мне не понравилось название, потому что я хотел предоставить независимую от поставщика функциональность и не был уверен в юридических вопросах. Тогда первым кандидатом был «SunFire». Это имя было бы идеальным, однако оно уже использовалось.
Каковы его основные особенности?
Функции были построены постепенно. Идея для большинства функций родилась после того, как стали доступны данные по отоплению и погоде:
- Мониторинг состояния нагрева, внешней / внутренней температуры, текущей солнечной энергии, общей солнечной энергии и т. Д.
- Отчетность всех архивных данных
- Пульт дистанционного управления (вкл / выкл / теплая вода)
- Интеграция с автономными клиентами через JMS и Shoal
- Скриптовый интерфейс для бизнес-логики
- Виджет мониторинга (см. Мой блог: http://blog.adam-bien.com)
- RSS-канал для мобильных телефонов — хорошо работает с iPhone
Тем не менее, все функции являются лишь побочными эффектами — главная цель — максимально использовать уровень нейтральных по отношению к СО2 ресурсов и тем самым экономить энергию в моей домашней обстановке.
Можете ли вы рассказать нам подробный сценарий, где он используется в настоящее время?
На самом деле есть несколько сценариев:
- Лето: летом в Баварии достаточно солнечной энергии для нагрева воды. Солнца слишком много, поэтому система может перегреться. Чтобы защитить его, большинство поставщиков систем отопления просто отключают коллекторы. GreenFire использует избыточную энергию и обогревает ею подвал. Это занимает несколько недель — и в подвале становится на несколько градусов теплее (примерно до 23 ° C). На самом деле это хороший способ накопить энергию на осень. Вы можете использовать больше сотен кВт с этой стратегией. Подвал остается теплым до декабря / января.
- Весна / Осень: в первый день с достаточным количеством солнца GreenFire выключает отопление и пытается полностью использовать солнечную энергию. Когда становится слишком холодно, он переключается обратно в режим по умолчанию и позволяет использовать, например, древесные пеллеты для отопления. В течение года GreenFire выключает основное отопление. Вы можете добиться того же, управляя отоплением вручную, однако для этого вам придется оставаться дома.
- Зима: Вы не можете сэкономить много энергии зимой, управляя отоплением разумным способом. Вся энергия используется для отопления. Тем не менее, если я использую свою дровяную печь, GreenFire контролирует ее и также использует избыточную энергию.
Пожалуйста, расскажите нам о его архитектуре.
Я построил всю систему в свободное время, поэтому меня очень заинтересовал «Time To Market». Я начал с модуля интеграции, который говорил непосредственно с системой отопления. Он абстрагирован от интерфейса, поэтому вы можете легко интегрировать его с любой системой отопления, которую вы хотите. Интерфейс доступен через RMI для EJB 3. RMI работает в изолированной JVM, поэтому в случае сбоя GlassFish все равно будет работать.
Другой EJB 3 со службой таймера отвечает за «сердцебиение». Каждые пять минут он собирает данные из модуля интеграции и модуля прогноза погоды. Затем он передает данные вещателю. Вещатель отправляет данные изнутри через JMS всем слушателям. Один конкретный слушатель — это «мозг» — это другой EJB 3, который загружает скрипт Groovy из URL и передает данные в скрипт. EJB 3 ожидает результат, который является предлагаемым «режимом» для отопления (только вкл. / Выкл. / Авто / тёплая вода и т. Д.).
Еще один интересный модуль — «Мост». Он переводит JMS-сообщения в XML и использует Shoal для распространения данных в локальной сети. Это действительно удобно, потому что тогда вы можете легко запустить локальное приложение Swing, которое будет также получать данные каждые пять минут. Я также начал работать над клиентом JavaFX, вдохновленным приложением NetBeans Weather Java FX.
Другие модули, такие как RSS и виджет, в основном являются «слушателями», которые участвуют в «сердцебиении».
Вот обзор:
По какой причине вы выбрали некоторые из технологий, которые вы используете?
- 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