Maintainership transferred
Matthijs Kooijman
first off, welcome to this brand new mailing list!
Nearly ten years ago, some people on mikrocontroller.net started
dissecting the HR20 hardware. From that discussion, an alternative
firmware was born, OpenHR20, written mostly by Dario Carluccio and Jiří
Dobrý AFAIU. They maintained the project in a Sourceforge project, where
a lot of interesting developments took place.
Since a while now, the development on Sourceforge has stalled. Some
further development has been done on a github fork by Tomas Kopal and
bruce33.
By now, the project has become somewhat fragmented. In an attempt to get
the project back in a better shape and perhaps get some development
going again, I've offered to take over maintainership and clean up the
source repositories and project pages.
Dario and Jiří have indicated that they are still interested in the
project, but will not be actively developing the project anymore right
now. Tomas is still working on the code, when time permits, so we've
agreed to share the maintainership between the two of us. If there is
anyone else willing to help maintain the code (that is, review patches,
write documentation, do testing), just give a shout and I'll get you
access.
Development will be moved from Sourceforge to github, since that seems
to be an easier way to get things done nowadays. The repository can be
found here:
https://github.com/OpenHR20/OpenHR20
Right now, this is still a copy of the repository as maintained by
Bruce. I'm planning to get things reorganized and cleaned up - more on
that later.
I'd like to thank Dario, Jiří and all other developers for the great
work they have done! Let's see if we can get more awesomeness coming :-)
Gr.
Matthijs
SelfAdmin
Hi Matthijs and Tomas,
I find it great, that you have taken things in your Hand, and at that point I also want to say "thank you" to Dario, Jiri and all other developers.
My activity with HR20-E and "openHR20 V1.0" started a few years ago, with the installation of the first HR20, wired by RS232-connection to a Windows-PC, and an early version of "openHR20 Suite". After solving some problems, this has been a comfortable combination.
I think, that this would be the lowest level for any "newcomer", and only success and progress would give the motivation to continue.
But now I found, that there is a difference between the Parameter-description in "openHR20 Suite V0.2.4.23954" and the actual usage in the flashed "OpenHR20_1.0.zip Last Update: 2014-07-06".
So, if an "e3" or "E:8" Error occurs after installation on a radiator, and he tries to do a correction at the wrong parameters, there will never be a success.
The second level has been to increase the amount to 5 "active" HR20-E, installed on radiators, and to hardwire them all via RS232 to a central located "COM-to-ETHERNET"-Adapter. Now they all could be controlled and configured on a Windows-PC via virtual-COM by "openHR20 Suite", or by "RealTerm" which also offers an alternative connection by their specific IP-Address and Port.
The third step for me has been to install a RaspberryPi3, which normally runs with 4W powerconsumtion without any interruption. It is setup with "fhem", and all HR20-E are connected as "ECMDDevice" via my local ETHERNET.
And this was the step from "single-heating-components" to an integrated "heating-system"
Accesspoints to be found here:
http://fhem.de/
http://fhem.de/fhem_DE.html
Up to now "fhem" is able to watch them, present actual Parameters and charts for each day, and save logfiles.
Also within "fhem" it is possible, to send Control Commands, such as "V" or "D", but no way was found to use Control Commands with more than one Byte, such as "A20" or "B1324".
And this was the reason, to check Google for additional Information, and so I came to GoogleGroups and your "openhr20-development".
I am not a specialist for C-programming, and used the Firmware just as it is.
Now I created an account at github, and found this repository:
https://github.com/OpenHR20/
As far as I can see, my " openHR20 V1.0" from 2014 is old stuff, but with some exeptions it is a running system.
I am more familiar to the external components and connections, and could share my experience.
And in addition to the 5 "active HR20-E" there is one more "inactive" on the workbench, which I used for my testing. It is also connected via RS232 and "COM-to-ETHERNET"-Adapter to "openHR20 Suite", or "RealTerm", or a Test version of "fhem", installed on a Windows10-PC.
And this setup is remaining to do any Tests.
As far as I can see, no connection has been established between "fhem" and "HR20", but both could get profit from this combination within the upcoming "IoT"
How do you think about that?
MFG Manfred
Tomas Kopal
I am sorry for such a late answer, real life keeps me too busy.
Your description looks quite impressive. I personally don't have any
experience with wired connections of HR20 units (wish I had thought
about that earlier, too late for wiring it in my house now), so I am
currently more interested in wireless connection.
But regardless of that, i think that extending communication with fhem
(or any similar framework) could be really interesting. Do you expect
many changes on OpenHR side? I haven't used the protocol over serial
line and I don't know fhem well, but I would expect interconnecting them
would be more to teach fhem about the protocol? Or do you need to extend
the protocol?
Regarding E3 and E8 errors, I am not sure I understand the problem, or
if it is still a problem in the latest code, but again, if you have any
patches, changes, bug reports or anything, you are welcome.
Regards
Tomas