Erste (eigene) Daten von der Heizung

Mein Güte, war das ein Kampf. Die meisten Probleme hat unerwartet javax.comm (das ist die Java-API für den Zugriff auf serielle Schnittstellen) gemacht. Das Ding warf mir dauernd die tolle IOException "Not all params are supported by kernel" um die Ohren. Das Problem ist offensichtlich bekannt. Die dort im Forum geposteten Workarounds riechen allesamt nach gruseligen Race-Conditions in der SUN-Implementierung. Ohnehin scheint sich SUN nicht mehr um diese Bibliothek kümmern zu wollen. Nach einiger Recherche bin ich auf die Alternative RXTX gestossen. Und entgegen der Aussage auf der jamod-Webseite liess sich das modbus-Teil auch damit compilieren (Parameter "build.serial.gnu=true" in build.properties gesetzt und den ganzen Forrest-Kram aus build.xml entfernt). Der Zugriff auf die serielle Schnittstelle funktionierte - die Anlage lieferte Daten zurück. Einen anonymen Byte-Strom. Abgesehen vom aktuellen Datum konnte ich darin nichts erkennen. Mehr oder weniger zufällig hab ich die Daten dann mal mit DataInputStream#readFloat() beackert - in der Hoffnung, dabei Werte zu finden, die wie Temperaturen aussehen. Und tatsächlich tauchten ab Byte 56 eine Hand voll Zahlen zwischen 20 und 50 auf. Schnell ausgedruckt, in den Heizungsraum gerannt und mit den Werten vom Display verglichen. Volltreffer. Die 13 wichtigsten Temperatur-Werte der Anlage. Mehr wollte ich gar nicht ;)

Inzwischen hab ich mir eine erste Version mit Webfrontend gebastelt, die im 5-Minutentakt aktuelle Werte von der Anlage holt und anzeigt. Als nächstes kommt noch eine Seite zum Konfigurieren des seriellen Ports (Device, Baudrate, Parity, etc.). Und dann natürlich ein Archiv-Service, der die Messwerte in eine Datenbank schreibt sowie ein Chart-Renderer, um den zeitlichen Verlauf der Werte grafisch im Webfrontend anzuzeigen.

Ich werd's dann hier auf der Webseite veröffentlichen. Achso - ist natürlich ein Jameica-Plugin ;)

Trackbacks

Trackback-URL für diesen Eintrag

Dieser Link ist nicht aktiv. Er enthält die Trackback-URI zu diesem Eintrag. Sie können diese URI benutzen, um Ping- und Trackbacks von Ihrem eigenen Blog zu diesem Eintrag zu schicken. Um den Link zu kopieren, klicken Sie ihn mit der rechten Maustaste an und wählen "Verknüpfung kopieren" im Internet Explorer oder "Linkadresse kopieren" in Mozilla/Firefox.

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Jens am :

Wiedermal einen Tick schneller. Ich habe auch versucht den Bytestrom zu durchblicken. Diesen habe ich einfach erstmal mitgelauscht wenn die Orginal Software von Waterkotte lief. Mal sehen ob bei mir auch ab Byte 56 "sinnvolle" Werte im Float format drin stehen ... Bis zu diesem Byte hat meine Geduld nicht gereicht. Wiedermal THX für die Infos. Damit kann ich viell. doch bald die Heizungsnanlage mit der Haussteuerung verbinden.

Olaf am :

In welcher Programmiersprache schreibst du das eigentlich gerade?

Jens am :

Also grundsätzlich sollen die Daten auf einer S7-Steuerung landen. Die anonymen Bytes landen über einen Kommunikationsprozessor in einem Byte-Array den ich dann nach belieben wandeln / auslesen kann. Da die SPS vom Speicher her sehr begrenzt ist werden die Daten dann an einen Server weitergeleitet (hauptsächlich zur Archivierung). Auch wenn der Weg Heizung Rechner sicherlich "einfacher" wäre, wollten wir trotzdem den Weg über die SPS gehen. Grund: bisher läuft alles über die SPS (komplettes Gebäude), frei nach dem Modell SensorAktorebene/Steuerung/Rechnerebene ...

Olaf am :

OK, das ist ja nochmal ein ganzes Stueck komplexer als bei mir ;)

Jens am :

Das orginal Programm macht zyklisch 4 Befehlsanfragen. Das Modbusprotokoll kann man auch rauslesen. Nur passen die Adresszugriffe nicht mit in der XML Datei überein.

Anfrage:
1. 01 03 0F 31 00 7D D7 30
2. 01 03 17 01 00 25 D0 65
3. 01 03 00 01 00 7D D4 2B
4. 01 03 07 D1 00 76 95 61

Als Antwortbekomm ich halt jede Menge Bytes. Nur Ab Byte 56 lese ich mit sämtlichen Wandlungen keine sinnvollen Float zahlen heraus. Auch Byte bzw. Wortweise gedreht kommt z.Z. nix sinnvolles raus. ... Aber ich bleibe dran! So schwer kanns schließlich nicht sein

Olaf am :

Ja, genau diesen Mitschnitt des Original-Programms hatte ich auch rausgefunden. Offensichtlich kann man nicht alle Werte auf einmal lesen. Daher holt die Software sie in Segmenten. Deine Anfrage Nr. 3 ist die erste (beginnt bei Offset 00 01 und fragt IMHO 125 Register ab). Die naechste ist dann Nr. 4, die bei Offset 07 D1 beginnt, aber nur 118 Register abfragt.

Ich frage bisher nur das allererste Segment ab - also "01 03 00 01...". Und hier auch nur die ersten 60 Register. Ich sende also "01 03 00 01 00 3c" (zzgl. CRC-Checksumme). Und in dem Byte-Strom, der da zurueckkommt, fand ich ab Byte 56 erste Werte. Vorher muss man von dem Response aber noch die ersten 2 Byte abschneiden - die Anlage schickt in der Antwort ebenfalls nochmal Slave-ID und Function code (also "01 03") mit. Da ich aber eine fertige modbus-Implementierung ("jamod") nutzen, muss ich das nicht selbst machen - das uebernimmt die Bibliothek fuer mich.

Jens am :

Heureka ... Ich hab's gefunden. Und zwar über die Betriebsstundenzähler. Diese werden aber in der Software abgerundet. Daher konnte ich rückwärtskonvertierend nicht genau den selben HEX Code finden. Also hab ich die am besten passenden 4 Byte gesucht und wieder in ein Float gewandelt. Dabei ist nur zu beachten dass diese Wortweise gedreht sind. Dann stimmt das ganze Überein. Jetzt ist es nur noch reine Fleißarbeit die Werte zuzuordnen. ... Nochmals vielen Dank für die hervoragende Vorarbeit!

Olaf am :

Vielleicht sollten wir mal ein Wiki aufmachen oder die Offsets der gefundenen Werte anderweitig austauschen/veroeffentlichen? Dann muessen wir nicht alles doppelt suchen ;)

Olaf am :

PS: Ueber die Sache mit den gerundeten Werten bin ich auch gestolpert. Selbst die Soll-Temperaturen. Hier z.Bsp. Warmwasser-Soll: Konfiguriert hab ich 48 °C, die Anlage liefert aber 48,1x zurueck.

Frank Münster am :

Hallo,
im Netz gibt es schon einige, die mit der Waterkotte gekämpft haben. Die Datenströme sind mit CRC16 geprüft. Man kann sowohl alle Daten auf einmal, oder eben nur spezielle Werte abfragen.
Schaut mal hier:
http://www.ip-symcon.de/forum/f28/comport-waterkotte-abfragen-2092/
http://www.haustechnikdialog.de/Forum/Default.aspx?t=6144&print=1&page=2
und
http://www.ai1.schnier.com/index.html (auch in JAVA implementiert).

Vielleicht hilft euch das ja weiter.
Ich hab' das ganz (noch recht experimentel) unter Linux (eisfair2) und perl am laufen.

Grüße
Frank

Olaf am :

Ich weiss ;)

Ich hatte bereits vor einiger Zeit Kontakt mit dem Autor des Java-Tools unter www.ai1.schnier.com - er hatte mir den Quellcode seiner Referenz-Implementierung geschickt. Allerdings funktioniert diese nur mit dem alten Steuergeraet Resuemat CD4. Das neue WPCU verwendet einen komplett anderen Befehlssatz - in dem auch die bisherigen Erkenntnisse mit den CRC-Checksummen nichts mehr bringen. ABER: sie verwendet stattdessen ein Standardprotokoll namens modbus, mit dem ich es inzwischen geschafft habe, die Daten auszulesen.

BTW: Die letzten Kommentare im haustechnikdialog.de-Forum stammen uebrigens von mir ;)

Frank Münster am :

...upps, sorry, da hab' ich wohl etwas zu wenig gelesen. Ist schon etwas her, dass ich mich damit befasst habe. Bin jetzt eigentlich über Hibiscus zu Jameica gekommen und dann (logischweise) zu deiner Bastelseite gelangt, nicht über die Waterkote-Story. Hab' damals gar nicht so realisiert, dass die CD4 und Ai1 so unterschiedlich sind.
Trotzdem noch Gutes gelingen und viel Spaß beim basten.

Olaf am :

> Hab' damals gar nicht so realisiert, dass
> die CD4 und Ai1 so unterschiedlich sind.

Noch viel gemeiner. Von der Ai1 gibt es zwei verschiedene Versionen, die augenscheinlich identisch sind. Lediglich die Tasten am Bedienfeld sehen etwas unterschiedlich aus. Die alte Version enthielt als Steuergeraet das CD4. Und die neue (inzwischen heisst sie "Ai1+") eines mit dem Namen "WPCU". Ist sehr irritierend, weil sich die Geraete wirklich nur in der Anordnung der 5 Steuertasten geringfuegig unterscheiden. In einer Version sind sie nebeneinander angeordnet - in der anderen Version als Kreuz. Und trotzdem sind das technisch zwei voellig verschiedene Steuergeraete, die - zumindest auf dem seriellen Port - in keinster Weise zueinander kompatibel sind.

Flipsi72 am :

5023.14 mit CD 4:

[WP] perl daemon MySQL DB Webapplikation

Sowohl lesend, als auch schreibend möglich, die Daten zu ändern. Läuft auf Sheevaplug.

Frickelei - aber seit 15 Monaten stable...

lg,
Philipp

Olaf am :

Coole Installation ;)

Dummerweise hab ich aber das neue Steuergeraet WPCU drin, welches nur noch optisch was mit dem Resuemat CD4 gemeinsam hat. Beim Zugriff auf den COM-Port spricht das Ding eine komplett andere Sprache. Ich hatte da absolut nichts gefunden, was schonmal jemand implementiert hatte. Daher musste ich selbst bauen.

Flipsi72 am :

Na sei froh, dass es bei Dir ein standardisiertes Protokoll ist. Ich habe die Waterkotte Software dazu verwendet, um mit einem seriellen Sniffer den Datenstrom "händisch" zu analysieren. Das war echt mühsam!

Olaf am :

Ja, so hatte ich auch angefangen ;)
Anfangs war bei mir auch das Resümat CD4 verbaut. Das war quasi das Testgeraet vom Heizungsinstallateur, weil das mitegelieferte eine Defekt hatte. Mit dem hatte ich eine Weile testen koennen - bis dann das neue WPCU geliefert wurde. Ich hab das neue auch deshalb gebraucht, weil da eine Erweiterung zur Ermittlung der Arbeitszahl eingespielt werden kann. Damit hab ich mir dann noch eine saftige Foerderung vom Staat holen koennen ;)

Die Kommentarfunktion wurde vom Besitzer dieses Blogs in diesem Eintrag deaktiviert.