Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi

[Stefano I. (donaldd)]

Hi Norbert

Ad 1)

From the ht_pitiny-board to the FW120 I have <20cm and from the FW120 to 
the heating system I have ~10m

Ad 2)
I am not sure about the thickness, but the cord is thin

Ad 3)
There are no other resistors on the connections

I will replace the cord between the board and the FW120 in the weekend 
to see if there is a difference


Regards

Stefano

[Norbert S. (junky-zs)]

Hallo schwiete,
>Dann werde ich mal ein Interface loeten und schauen was das so auf dem Bus 
>abgeht.
Bist Du an dieser Baustelle weitergekommen?

niffko schrieb:
>Das Bedienteil sendet periodisch(wichtig!) eine Art WW-Statustelegramm an
>den Master.

Folgendes konnte ich herausfinden:
Es gibt ein Telegramm (mit Ziel:an alle) welches nach einem Tastendruck: 
'Warmwasser sofort' und sonst periodisch alle 10 Minuten gesendet wird.
Beispiele
      B0 B1 B2 B3 B4 B5 B6 B7 B8 CRC Break
 -->> 90 00 ff 00 00 d3 08 00 00 8e 00  <<-- Warmwasser sofort aktiv
 -->> 90 00 ff 00 00 d3 00 0a 00 ba 00  <<-- Warmwasser sofort deaktiv
Byte5 ist immer (d3)hex
Byte6 enthält u.A. den Status der 'Warmwasser sofort' Taste.
Byte6/Bit4 := (08)hex -->> Warmwasser sofort aktiv
Byte6/Bit4 := (00)hex -->> Warmwasser sofort deaktiv.

Wie Du schon geschrieben hast reagiert die Heizung nicht oder nur unter 
bestimmten Bedingungen (Eco-Taste aus, Warmwasser-Programm im Sparmodus 
ect.).
Ich nehme an, das sich dies jedoch per 'Telegramm' erzwingen lässt indem 
man kurzzeitig die geforderte Warmwasser-Solltemperatur erhöht.
Ob dies so funktioniert muss ich aber noch zu testen.

Gruß Norbert

[Stefan S. (kami)]

Hallo zusammen,

bin gerade ganz neu in das Thema eingestiegen.

Ich besitze eine Junkers ZSB 14-4C.. Therme mit FW120 Regler.

Kann ich dafür auch diese Modul verwenden? Und kann ich es parallel zum 
Regler anschliessen? Hat einer Erfahrungen damit? Lese bei mir überall 
Heatronic 4 Bus? Ist das was anderes?

Vielen Dank.

Gruß kami

[Norbert S. (junky-zs)]

Hallo Stefan,
ein paar Antworten zu Deinen Fragen.
>Lese bei mir überall Heatronic 4 Bus? Ist das was anderes?

Heatronic4 ist eine Weiterentwicklung des Heatronic3-Bus. Die 
Schnittstellen-Parameter (9600Baud, 8N1, 15V-10V Spannungs 
(RX)-/Stromsignalisierung(TX)) sind aber gleich geblieben.
Es sind neue bzw. erweiterte Telegramme hinzugekommen. Dies ist jedoch 
'nur' eine Frage der Software auch dies korrekt zu dekodieren.
Die hier vorgestellten Adapter arbeiten somit alle auch mit dem 
Heatronic4 Bussystem zusammen.

Hinweis:
Heiko hat genau Deine Anlagen-Konfiguration mit ebenfalls Heatronic4. 
Siehe auch: Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"
Somit brauchst Du keine Bedenken zu haben das garnichts geht im 
Gegenteil, es geht nur nicht alles.
Jedoch wir arbeiten dran.

>Und kann ich es parallel zum Regler anschliessen?
Ja unbedingt, dies ist sowieso die beste Art sich am Bus zu kontaktieren 
weil:
1. Damit wird vermieden das man bei Heatronic4 den 'falschen HT-Bus' 
erwischt. Hinweis: Bei Heatronic4 gibt es ein Modul HT3/HT4i welches in 
der Regel direkt im Wärmeerzeuger eingebaut ist und den 
Telegramm-Verkehr beeinflusst.
2. Es weitere Module je nach System gibt (z.B. IHM:= HybridManager bei 
Wärmepumpen) die ebenfalls den Telegramm-Verkehr beeinflussen.

Wenn man den/die Adapter also direkt an den Modulen FWxyz/FRxyz, ISM1/2 
oder IPM1/2 anschliesst macht man nicht viel verkehrt.

Anschluss am Bus siehe auch:
Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"

Gruß Norbert

[Stefan S. (kami)]

Hallo zusammen,

ich habe nun von Norbert mein pitiny Board bekommen und am Raspberry 
angeschlossen. Die LED blinkt erstmal grün.
Nun habe ich gestern versucht einen Anschlusspin für die Busleitung an 
meiner Heizung zu finden. Daran bin ich leider gescheitert. Ich habe mal 
ein paar Bilder von meiner Heizung gemacht. Vielleicht kann mir ja 
jemand sagen, wo ich den Bus am besten abnehme. der FW120 Regler sitzt 
vorne an der Heizung. Wenn man ihn runternimmt dann hat man da 3 
Stecker.

Vielen Dank.

Gruß kami

[Norbert S. (junky-zs)]

Hallo,

folgende Informationen habe ich zum Thema: Heatronic4i und Bus-Anschluss 
gefunden.
Die 'neue' Heatronic4i Steuerelektronik ist als komplette ausklappbare 
Einheit im Heizgerät eingesetzt und hat ein eigenes Display mit 
zugehöriger Menue-Führung. Die Zündelektronik ist nicht mehr auf dieser 
Platine enthalten.
Ebenfalls sind (leider) die Bus-Bezeichnungen geändert. Waren die 
Klemmen beim Heatronic3-Bus noch mit 'B' bezeichnet, so heißt es jetzt 
bei Heatronic4i 'EMS'.
Zur einfacheren Lockalisierung habe ich Bilder beigefügt aus denen das 
Anschluss-Logo 'EMS' und die zugeörige Klemmenleiste (links, 
Niederspannung) hervorgehen.
Der 2-Draht Bus ist somit das orangene Klemmenpaar (1/2) rechts neben 
dem grünen Klemmenpaar.
Die Adapter 'ht_pitiny' und 'ht_piduino' sind verpolungssicher (interne 
Brückenschaltung), bei den Adaptern 'HT3_miniAdapter' und 
'HT3_microAdapter' muss man weiterhin auf richtige Polung achten.

Die Signalierungs-Parameter sind zum Glück gleich geblieben (wenn auch 
nicht alle Telegramm-Inhalte) aber der 'ht_pitiny' - Adapter arbeitet 
auch am Heatronic4i-Bus.
Falls jemand noch weitere Informationen hat dann bitte posten. Ich 
selber habe nur die Heatronic3 - Version in meinem System.

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo,

wer die Steuerung der Junkers-Heizung mit 'MBLan', 'Netcom' oder 
'ht_transceiver (ht_pitiny / ht_piduino)' plant sollte zuvor das 
Fertigungsdatum des Reglers und der System-Module (ISM etc.) 
kontrollieren.
Das Fertigunsdatum des Reglers kann man wie folgt bestimmen:
1. Menue-geführt (Fachmannebene;Menue-Taste länger als 3 Sekunden 
drücken)
 FACHMANN EBENE: System Info
   Fertigungsdatum des Reglers

Diese Angaben sind der FW100 Bedienungsanleitung entnommen, werden aber 
für andere Fx-Regler in ähnlicher Form vorhanden sein.

2. FD-Code (Fertigungsdatum) auf der Innenseite der Reglerabdeckung
Dazu den abgelesenen Wert: (FDxyz) mit beigefügter Tabelle vergleichen 
und das Datum bestimmen.
Bei den System-Modulen ist am jeweiligen Typenschild das Fertigungsdatum 
zu entnehmen.

Zusätzlich muss natürlich ein 2-Draht Bus (Heatronic3 / Heatronic4i) 
vorhanden sein.

Für die Steuerung der Heizung mit einem 'MBLan' ist minimal das 
Fertigungsdatum 'September 2008' := FD889 erforderlich.
Der Regler 'FR50' kann nicht mit dem MBLan gesteuert werden.

Für die Steuerung der Heizung mit 'Netcom50', 'Netcom100' oder 
'ht_transceiver (ht_pitiny/ht_piduino)' ist minimal das Fertigungsdatum 
'November 2009' := FD991 erforderlich.

Diese Einschränkungen gelten nur für die STEUERUNG der Heizung mit 
HT-Buskommandos.
Diese Einschränkungen gelten NICHT für den Empfang von HT-Bussignalen 
und den hier vorgestellten Adaptern sofern der 2-Drahtbus (Heatronic3 / 
Heatronic4i) vorhanden ist.

Gruß Norbert

[schwiete (Gast)]

Hallo,

habe inzwischen (Monate später ;-) eine Schaltung mit einem 555 
gebastelt die mir den NTC unter 40°C drueckt. Danach geht die 
Speicherladung auch sofort los. Damit koennen wir erstmal baden :-)
Finde das Verhalten vom FW100 aber immer noch sehr merkwürdig: Man 
stellt eine Warmwasser-Solltemperatur ein, die Hystere ist nicht 
einstellbar und der Regler entscheidet selber wann er mit der 
Speicherladung beginnt. Wie weit fällt denn bei euch so die 
Warmwassertemperatur ab?

Gruß
schwiete

[Dennis (Gast)]

Hi,

>Man stellt eine Warmwasser-Solltemperatur ein,
>die Hystere ist nicht einstellbar und der Regler
>entscheidet selber wann er mit der
>Speicherladung beginnt.

ja darüber habe ich mich letzte Woche auch gewundert.

Bei mir ist es zwar eine FW200, aber:
Eingestellt: 48°, Ladung beginnt erst bei ca. 44°C

[Dennis (Gast)]

Hallo,

was ich mal fragen wollte: Kann man irgendwo (Norbert?) ein fertig 
aufgebautes HT3-Interface für Raspi kaufen?

Gruss

[Norbert S. (junky-zs)]

Hallo,

@ schwiete
>Finde das Verhalten vom FW100 aber immer noch sehr merkwürdig: Man
>stellt eine Warmwasser-Solltemperatur ein, die Hystere ist nicht
>einstellbar...
Etwas Einfluss hast Du auf die Hysterese, wenn Du die Taste 'eco' am 
Heizgerät deaktivierst (zumindest ist diese Taste bei meinem Gerät 
vorhanden).

@ Dennis
>...ein fertig aufgebautes HT3-Interface für Raspi...
Welches Interface meinst Du. Es gibt ja inzwischen 4 unterschiedliche 
Adapter-Typen (siehe Bilder).

1. HT3_mini- und HT3_micro-Adapter   -> nur für den Daten-Empfang
2. ht_piduino und ht_pitiny      -> für Empfang und Senden von 
HT-Busdaten

Falls Du also Deine Heizung steuern willst, kann ich Dir nur den 
ht_pitiny empfehlen. Die anderen Adapter habe ich nicht, ein Nachbau 
sollte aber möglich sein.
Sende mir eine PM, Details dann dort.

Gruß Norbert

[Rüdiger B. (Gast)]

Hallo Norbert,

ich bin auch daran interssiert meiner Heizung etwas mehr zu entlocken 
und vorzugeben.
(Da würde sich der HT_piuino anbieten)
Da ich aber noch nicht weiß, auf welcher Hardware die Auswertung laufen 
soll, würde ich es gern etwas modularer halten.


1. Eine kleine Platine, nur mit dem Interface
Diese könnte man auch immer universell weiter verwenden.

2. Würde ich gerne ein fertiges Arduino Modul verwenden.
Somit kann man bei Speicherproblemen in der Zukunft einfach mal ein 
anderes Modul nehmen und bindet nicht unnötig Zeit.
USB schnittstelle wäre auch schon an Board.
Man könnte es somit einfach an allem möglichen betreiben und ist nicht 
mehr auf den RPi beschrängt.

Jetzt ergeben sich somit einige Fragen:
A) Würdest du bitte die Eagle Datein von dem HT_piduino und dem 
HT_pitiny hier bereitstellen?
So könnte man da die Schnittstell herausnehmen und könnte zwischen DIL 
und SMD wählen.

B) Wie groß schätzt du die Chancen, dass der Code auf einem Arduino (mit 
der IDE) lauffähig ist?

C) Wie groß wäre der Auffwand den Code zu portieren?

Vieleicht wäre es aber einfacher, den Arduino mit AVR-Studio zu 
Schreiben.

Vielen Dank für Deine Arbeit, sonst wären diese Diskussionen und 
Gedanken nicht möglich.

Gruß Rüdiger

[Rüdiger B. (Gast)]

Ach, ich hab noch eine Frage vergessen.

Wie wäre es, wenn das Interface auch 5V Level könnte?
Was müsste an der Schaltung geändert werden?
Wäre eine Jumperlösung möglich?

Danke
Gruß Rüdiger

[Norbert S. (junky-zs)]

Hallo Rüdiger,

> Da ich aber noch nicht weiß, auf welcher Hardware die Auswertung laufen
> soll, würde ich es gern etwas modularer halten.
Da kann ich Dir nur eine Adapter-Platine für den Arduino(TM) empfehlen 
auf die dann der ht_piduino-Adapter gesteckt wird.
Auf dem ht_piduino-Adpater werden halt der Atmega328 und der Quarz nicht 
bestückt. Details siehe Schaltplan oben.
Wenn Du dann noch die entsprechenden Arduino-Buchsen nimmst, ist nicht 
alles mechanisch verbaut sondern Du kannst ja noch weitere Platinen 
(stagging) aufstecken.

> USB schnittstelle wäre auch schon an Board.
Motherboard für USB und ht_piduino/ht_pitiny siehe URL:
 Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"

> Würdest du bitte die Eagle Datein von dem HT_piduino und dem
> HT_pitiny hier bereitstellen
ht_piduino und ht_pitiny sind mit gEDA (gschem) und nicht mit Eagle 
erstellt. Dateien kann ich auf github.com bereitstellen.

> Wie groß schätzt du die Chancen, dass der Code auf einem Arduino (mit
> der IDE) lauffähig ist?
ht_piduino und Arduino Uno haben ja den gleichen Prozessor und das Flash 
ist halbvoll. Es sind Software-Anpassungen nötig (Includes etc.) sollte 
aber machbar sein. Allerdings sollte man nicht jede Routine aus der 
IDE-Library unbeleckt übernehmen, insbesondere nicht die Realisierung 
des SW-UART. Deshalb habe ich diese Routine selber geschrieben.

> ...Interface auch 5V Level könnte?
Siehe Schaltplan, habe dort auf J1-Pin1 die 5 Volt des Arduino gelegt. 
Die Optokoppler können bis 16V Betriebsspannung arbeiten.

Gruß Norbert

[Rüdiger B. (Gast)]

Hallo Norbert,
kann es sein, dass die PDF Anleitung in deinem Repository defekt ist?
Ich kann Sie jedenfals nicht öffnen.

Danke
Gruß Rüdiger

[Norbert S. (junky-zs)]

Hallo Rüdiger,

>kann es sein, dass die PDF Anleitung in deinem Repository defekt ist?
Wahrscheinlich hast Du die Doku mit dem Browser laden wollen. Da sagt 
dann git: "will nich" weil die Datei zu groß > 2MByte ist.

Am besten ist es das ganze Projekt inklusive Doku zu laden, das kann 
dann auch git am schnellsten:
1. Linux
  git clone https://github.com/norberts1/hometop_HT3.git
2. Windows / Linux
  Download ZIP

Das darin enthaltene PDF-File 'HT3_Adaption.pdf' ist OK.

Gruß Norbert

[Rüdiger B. (Gast)]

Ja, du hattest Recht.
Wenn ich es so mache, wie du beschrieben hast, dann geht es.
Danke

Gruß Rüdiger

[Hansbausn (Gast)]

Moinsen,

so, habe die Platine zusammengelötet und auch die Kaltetests erfolgreich 
durchgeführt. Jetzt muss noch der Raspberry konfiguriert werden und an 
die Heizungsanlage angeschlossen werden. Den Klemmleiste für den Bus am 
FW100 und ISM1 habe ich schon gefundne. Allerdings sind am FW100 die 
Klemmen belegt und gehen zum ISM1, so dass dort auch beide Klemmen 
belegt sind. Kann ich mich einfach mit drunter Klemmen oder gibt das 
Ärger ? Auch kann ich  anhand der Klemmen nicht die Polarität erkennen. 
Schieße ich die Anlage ab, wenn ich beim ersten Mal die Falsche Richtung 
erwische. Wenn sie richtig rum sind, sollte die grüne LED lustig vor 
sich hin flimmer ?!

Danke schon mal


Hans

[Norbert S. (junky-zs)]

Hallo Hans,

> Kann ich mich einfach mit drunter Klemmen?
Ja, parallel zu den B-Klemmen.

> oder gibt das Ärger ?
Normalerweise nicht, nur wenn Du Schnürsenkel statt ordentlicher Litze 
zum Verdrahten nimmst. 2 * 0,75 mm2 ideal.

> Schieße ich die Anlage ab, wenn ich beim ersten Mal die Falsche Richtung
> erwische.
Nein, da der Adapter galvanisch getrennt vom Heizungs-Bus ist. Es sei 
denn es ist ein Fehler in der Verdrahtung, aber die hast Du ja geprüft.
Der Adapter selber hat eine Diode vor dem Optokoppler der bei falscher 
Polung diesen schützt.

> Wenn sie richtig rum sind, sollte die grüne LED lustig vor
> sich hin flimmer ?!
Ja

Gruß Norbert

[Nils R. (augur)]

Moin.

Ich hab nun über den Raspberry eine Visualisierung auf meinem HS gebaut 
und feststellt, dass die Angabe von Vorlauf ist und Vorlauf soll 
meistens nicht übereinstimmen. Dabei stimmt aber Vorlauf soll mit 
Rücklauf meistens überein. Kann es sein, dass die Steuerung den Rücklauf 
steuert und nicht den Vorlauf?

Anbei mal die Darstellung von einem Tag.

Viele Grüße,
Nils

[Adam K. (adamkorski)]

Nils R. schrieb:
> Dabei stimmt aber Vorlauf soll mit
> Rücklauf meistens überein.

Ich sehe bei Dir alles i.O.  Nach ca. 8 und 11 Uhr hast Du stark mit 
Sollwert gespielt. Marke, dass Kessel mit volle Post WW heizt und dann 
von Restwärme der Vorlauf bei kleiner Wärmeabnahme aufgeheizt wird. 
Mehr kann man erklären, wenn Du auch Kessel- und Pumpenleistung anhängen 
kannst.
Probiere noch Parameter Aufheizgeschwindigkeit auf Sparsam einstellen. 
Jetzt hast Du sicherlich Normal oder Schnell.

[Nils R. (augur)]

Hi.

Danke für die Ausführung, dass schaue ich mir mal an.

Jedoch geht es mir erst mal darum, dass Vorlauf Soll und Rücklauf 
anscheinend zusammenhängen. Vorlauf Ist weicht doch immer eher von der 
Soll-Größe ab. Daher wollte ich mal die Frage stellen, ob dies nicht 
ggf. falsch benannt ist.

Viele Grüße,
Nils

[Müller Timo (Gast)]

Überweisung ging jetzt endlich raus und freu mich auf die platine

versteh ich das richtig das ich die Heizung jetzt auch per Handy steuern 
kann? über den hat Receiver?
welche app dazu?
oder wie muss ich mir das vorstellen?

[Norbert S. (junky-zs)]

Hallo Timo,

> versteh ich das richtig das ich die Heizung jetzt auch per Handy steuern
> kann?
Dies ist möglich wenn Du FHEM auf Deinem RapsberryPi installiert und 
konfiguriert hast. Zusätzlich muss das Prerelease von 89_HEATRONIC.pm 
auf dem RaspberryPi installiert sein.

Siehe dazu:
Beitrag "Re: Heizungs-Datenerfassung (HT3)"
Beitrag "Re: Heizungs-Datenerfassung (HT3)"
https://github.com/norberts1/fhem

Ein Zugriff von Haus-extern auf Deinen RaspberryPi ist Voraussetzung 
dafür.
Ansonsten geht die Steuerung natürlich immer Haus-intern über Laptop / 
Tablet.

Gruß Norbert

[Markus J. (mjotter)]

Hallo,

ich habe ein ipm2, daran hängt durch einen Wärmetauscher getrennt eine 
Fußbodenheizung. Leider vermisse ich die Felder V_mischerstellung" und 
T_vorlauf_misch_HK. Also eigentlich die Werte, die ich im Bedienteil 
fotografiert habe (Anlage alle_mischer.jpg).

Woran hängt es? Werden die Telegramme
A0 00 FF 00  Lastschaltmodul#1 (IPM)
A1 00 FF 00  Lastschaltmodul#2 (IPM)
nicht vearbeitet?

Wie kann ich eigentlich das File ht_binlog.log lesen? Ist Newline ein 
neuer Datensatz? Ich habe noch ein perl-script test.pl angehängt. Es 
wandelt das ht_binlog.txt in hex um, und lässt die Newline stehen.
 perl test.pl /tmp/ht_binlog.log | grep 'a1 00 ff'
Ergibt
00 00 22 00 10 00 90 a1 ff 00 01 00 0c dd 00 a1 10 ff 00 00 0c 02 dc 00 
90 00 21 00 a1 00 ff 00 00 0c 02 03 64 01 2c 22 b9 00 a1 00 2a 00 32 00

Hinten ist das ein gültiges telegramm?
a1 00 ff 00 00 0c 02 03 64 01 2c 22 b9 00

Müsste das dann nicht erkannt und zusammen in die Datenbank in die 
HT3_db.sqlite in die Tabelle heizkreis2 gehen?

Grüße

[Norbert S. (junky-zs)]

Hallo Markus,

die Telegramme für das IPM-Modul werden erst ausgewertet wenn Du das 
Konfigurationsfile 'HT3_db_cfg.xml' angepasst hast.
Folgendes ändern:

<anzahl_heizkreise>2</anzahl_heizkreise>   (Zwei Heizkreise)
...
    <systempart name="heizkreis1">
    ...
    <unmixed>False</unmixed>   <!-- True/False -->

gleiches für den zweiten Heizkreis
    <systempart name="heizkreis2">
    ...
    <unmixed>False</unmixed>   <!-- True/False -->

Danach den Proxy neu starten und zusätzlich das script 'rrdtool_draw.pl' 
für die Ausgabe der rrdtool-Grafik im cronjob mit geändertem Parameter 
'2' aufrufen.
 -->  /bin/perl rrdtool_draw.pl  /home/pi  /home/pi 2
Der Parameter '2' gibt die Anzahl der Heizkreise an. Rest bleibt so.

Die Werte für die Mischer in den Programm 'HT3_Analyser.py' und 
'HT3_SystemStatus.py' werden nach der Änderung angezeigt .

Bitte kontrolliere die Anzeigen der rrdtool-Grafik für die Heizkreise. 
Es kann sein das dort noch etwas fehlt. Ich selber habe kein IPM-Modul 
deshalb ist es gut wenn Du dies testen kannst.

Das Bin-File sehe ich mir noch an.

Gruß Norbert

[Markus J. (mjotter)]

Hallo Norbert,

der zweite Heizkreis wird schon befüllt... Siehe Anhang.

Es fehlen aber die Mischerdaten. (Geöffnet, gemischte Temperatur, ...) 
Sowohl im HT3_Analyser.py als auch im HT3_SystemStatus.py.

Vielen Dank für die schnelle Antwort.

Grüße

[Norbert S. (junky-zs)]

Hallo Markus,

> Es fehlen aber die Mischerdaten
In der SQ-Lite Datenbank sollten diese Werte enthalten sein.
Allerdings nicht in der rrdtool-Grafikausgabe, da das 
script'rrdtool_draw.pl' diese Werte nicht abfragt.
Dieses Script ist recht statisch und achtet nicht auf die aktuelle 
Konfiguration. Vielleicht lässt sich daran noch was verbessern.

> Fehlen sowohl im HT3_Analyser.py als auch im HT3_SystemStatus.py
Die Mischerwerte sollten hier nach Änderung der Konfiguration angezeigt 
werden. Beide Tools greifen auf das 'lokale' Konfigurations-File zu. 
Eventuell liegt da der Grund drin falls Du diese Tools auf einem anderen 
Rechner als dem proxy-server laufen lässt.

Ich habe mir Dein 'ht_binlog.log' File angesehen, jedoch nicht die 
Telegramm-Sequenzen wiedergefunden die ich für einen ht_pitiny-Adapter 
erwartet hätte.
Diese Telegramme fangen alle an mit: #HR.....
Ich nehme an das Du die Schnittstelle nicht auf die richtige Baudrate 
(19200 bei ht_pitiny) eingestellt hast bevor Du Dein Perl-Script 
gestartet hast.

Du kannst besser das Tool: ht_binlogclient.py für die binäre 
Datenerfassung verwenden. Dies verwendet das Konfigurations-File:
  ./etc/config/ht_proxy_cfg.xml
Wenn darin die Daten korrekt sind klappt die binäre Datenerfassung mit:
  ./ht_binlogclient.py meinbinärfile.log

Falls Du weiterhin Anzeigeprobleme hast kannst Du mir ein Binär-Logfile 
zukommen lassen.

Gruß Norbert

[Markus J. (mjotter)]

Hallo Norbert,

ich hatte wohl mit dem netclient herumgespielt.
./ht_netclient.py -ht_cfg 3
./ht_netclient.py -ht_rst 1
jetzt kommt auch ein log mit #HR heraus. Vorher hatte ich 2 drin.

Das perl-Script formatiert mir nur das binlog. Sobald 23 48 52 ?? ?? 
kommt (#HR..) mache ich danach eine newline.

Trotzdem das gleich Ergebnis:

perl test2.pl ht_binlog.log | grep 'a1 00 ff 00'
a1 00 ff 00 00 0c 02 01 1f 00 f2 1a f3 00 e6 23 48 52 11 02
a1 00 ff 00 00 0c 02 01 1f 00 f2 1a f3 00 e6 23 48 52 11 02
a1 00 ff 00 00 0c 02 01 1f 00 f2 1a f3 00 e6 23 48 52 11 02
a1 00 ff 00 00 0c 02 01 17 00 f2 11 b8 00 45 23 48 52 11 02
a1 00 ff 00 00 0c 02 01 1f 00 f2 1a f3 00 e6 23 48 52 11 02
a1 00 ff 00 00 0c 02 01 17 00 f2 11 b8 00 45 23 48 52 11 02

Passt das Log? Bei den kurzen Telegrammen kann ich keinen Sinn erkennen. 
Oder habe ich  ein Problem, und der ht_pitiny empfängt Blödsinn? Ich 
habe den ht_pitiny an den Bus des imp2 angeschlossen (ca. 30cm vom imp2, 
vorher ca. 1 Meter vom Brenner).

Ich bekomme prinzipiell sinnvolle Anzeigen. Mit dem netclient konnte ich 
auch den Modus ändern (./ht_netclient.py -b frost)

Grüße

[Markus J. (mjotter)]

Hallo Norbert,

noch was:
das HT3_Logger.py und ht_proxy.py auf einem Raspberry B  jeweils 11 % 
CPU ziehen ist normal?

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
 2060 pi        20   0 45228  22m 7072 S  11,8  6,1  67:24.33 
HT3_Logger.py
 2046 pi        20   0 76344 9544 4080 S  11,4  2,5  54:59.84 
ht_proxy.py

Grüße

[Norbert S. (junky-zs)]

Hallo Markus,

das Telegramm ist schon OK. Die Formatierung mit '/n' ist noch nicht 
richtig.

Die eigentliche 'Payload' für dieses Telegramm ist 14 Byte lang (inc. 
Break).
Deine falsche Formatierung:
a1 00 ff 00 00 0c 02 01 1f 00 f2 1a f3 00 e6 23 48 52 11 02
Korrekte Formatierung (Telegramm des IPM):
a1 00 ff 00 00 0c 02 01 1f 00 f2 1a f3 00
  Darin bedeutet:
  1f    := Mischer 31% offen
  00 f2 := Vorlauftemperatur = 24,2 Grad Celsius
  00 am Ende := Null für das erkannte Break-Signal.

die folgende Bytes sind:
e6 := CRC über Header + Payload
23 48 52 11 02 := Ist Header des nächsten Telegramms.

Beschreibung dieser Telegramme ist zu finden unter: 
ht_transceiver_messages.html.
Diese Doku ist in: hometop_ht_transceiver/docu

> das HT3_Logger.py und ht_proxy.py auf einem Raspberry B  jeweils 11 %
> CPU ziehen ist normal?
Ja, das ist im grünen Bereich. Es werden ja vom ht_pitiny ALLE 
Telegramme an die Auswertung gesendet auch die ganz kurzen 
Polling-Telegramme.
Dies macht vor allem diese 'CPU-Last' aus.

Zeigen jetzt bei Dir die Programme HT3_Analyser.py und 
HT3_SystemStatus.py die Mischerdaten korrekt an?
Falls nicht sende mir einfach ein unformatiertes binär.log Deiner 
Anlage.

Gruß Norbert

[Markus J. (mjotter)]

Hallo Norbert,

bisher kommt nichts an:

sqlite> select
   ...> T_vorlauf_misch_HK,
   ...> T_steuer_FB,
   ...> V_betriebs_art,
   ...> V_mischerstellung,
   ...> T_vorlauf_misch_HK,
   ...> V_spare_1,
   ...> V_spare_2,
   ...> sum(1) anz,
   ...> max(Local_date_time) max_Date
   ...> from heizkreis2
   ...> group by T_vorlauf_misch_HK,
   ...> T_steuer_FB,
   ...> V_betriebs_art,
   ...> V_mischerstellung,
   ...> T_vorlauf_misch_HK,
   ...> V_spare_1,
   ...> V_spare_2;
T_vorlauf_misch_HK  T_steuer_FB  V_betriebs_art  V_mischerstellung 
T_vorlauf_misch_HK  V_spare_1   V_spare_2   anz         max_Date
------------------  -----------  --------------  ----------------- 
------------------  ----------  ----------  ---------- 
-------------------
0.0                 0.0          2               0                  0.0 
0           0           2936        2015.12.14 05:09:16
0.0                 0.0          3               0                  0.0 
0           0           8764        2015.12.14 20:18:54

Das binlog hatte ich oben schon angehängt (zusammen mit meinem 
perl-script)

Kannst du mal draufsehen? Ich glaube die Mischerdaten gehen verloren, 
und werden nicht gespeichert..

Grüße

Markus

[Norbert S. (junky-zs)]

Hallo Markus,

> Kannst du mal draufsehen? Ich glaube die Mischerdaten gehen verloren
Ich habe das Logfile analysiert und folgendes festgestellt:
Die Zuordnung zwischen den IPM-Telegrammen und den Heizkreisen passt für 
Deine Anlage nicht.
In Deiner Anlage ist das Telegramm: 'a1 00 ff 00 ...' wohl dem 
Heizkreis2 zuzuordnen.
Dies ist aber im aktuellen Software-Release noch anders.
Bitte korrigiere daher Deine Software wie folgt:
Modul: ~/HT3/sw/lib/ht3_decode.py
Zeile: 400 ff
Inhalt anpassen:
        if firstbyte == 0xa0:
            nickname="HK1"
        elif firstbyte == 0xa1:
            nickname="HK2"
        elif firstbyte == 0xa2:
            nickname="HK3"
        elif firstbyte == 0xa3:
            nickname="HK4"
        else:
            nickname="HK1"

(HK3 und HK4 bei Dir nicht vorhanden, nur der Vollständigkeit halber)

Nach dieser Anpassung ist auch die Mischer-Anzeige in der GUI vorhanden 
(siehe Bild) und die Daten werden in die sqlite-DB geschrieben. 
Allerdings werden die Daten noch nicht grafisch mit dem rrdtool 
ausgegeben.

Gruß Norbert

[Juri K. (iuser)]

Hallo,

als erstes großes Dank an Norbert für die gemachte Arbeit! Echt 
beeindruckend.
Ich habe seit kurzem meine alte Junker Therme durch eine neue ZWR18-7 
ersetzt bekommen. Die Alte hatte ich seit 2 Jahren noch komplett analog 
erst vom FHEM und später vom OpenHab gesteuert. Da gab es aber außer 
ei/aus nicht viel zu steuern.
Jetzt möchte ich mich an den neuen Versuchen und wenn die Steuerung 
klappen sollte, auch ein OpenHAB Binding dafür erstellen. Das Problem 
ist aber, dass ich zwar programmieren kann, aber absolut keine 
Erfahrung in der Elektronik habe. Und für das erste Projekt ist der 
Adapter schon eine ziemliche Herausforderung ist.
Deswegen die erste Frage - kann man evtl. das Aufbau des Adapters auf 
irgendeine Weise vereinfachen, z.B. durch Einsatz von (teureren) Blöcken 
o.ä?
Zweite Frage ist – der OpenHab Server läuft im Moment auf der Paspberry 
2 – kann man den Adapeter an dieselbe PI anschließen? Reicht es von der 
Performance oder soll man lieber eine separate PI dafür nehmen.
Welchen der beiden Adapter soll ich dafür nehmen – pitiny oder piduino?

Danke und Gruß
Juri

[Norbert S. (junky-zs)]

Hallo Juri,

> kann man evtl. das Aufbau des Adapters auf irgendeine Weise vereinfachen?
Nur wenn man auf wichtige Dinge wie 'Galvanische Trennung' verzichtet. 
Ansonsten sehe ich keine Möglichkeiten.

> OpenHab Server läuft im Moment auf der Paspberry2 – kann man den Adapeter an
> dieselbe PI anschließen?
Anschliessen immer, ob es läuft kann ich nicht sagen da ich kein OpenHab 
habe. Wenn Du ca. 30% mittlere CPU-Last frei hast dann läuft wohl auch 
beides parallel.

> Welchen der beiden Adapter soll ich dafür nehmen – pitiny?
ht_pitiny, siehe:
Beitrag "Adapter fuer Raspberry Pi (Junkers HT3, Buderus EMS u.A.)"

Gruß Norbert

[Markus J. (mjotter)]

Hallo Norbert,

vielen Dank jetzt funktioniert es.

Die Visualisierung gefällt mir nicht so gut, da diese statisch sind.
Für den Stromzähler verwende ich hier:
http://volkszaehler.org/
Das ganze ist nicht einfach ein aktive Oberfläche, hier lassen sich 
Messwerte ausblenden, einblenden, unterschiedliche Farben festlegen, 
etc. Und vor allem zoomen.

Ich habe ein Script gebastelt, das die Datenbank (Sqlite) in die 
volkszaehler Datenbank (mysql) "pumpt". Momentan wird für die 
selektierten Sensoren jeweils alle Werte kopiert. In den nächsten Tagen 
mache ich noch eine Version, die nur die letzten Tage/Stunden/Minuten 
kopiert.

Grüße

Markus

[Nils R. (augur)]

Hi.

Ich hab jetzt mein MB-LAN2 und den Raspberry parallel angeschlossen und 
ein Jumper gesetzt, damit die Adresse geändert wird.

Eigentlich lief alles 3-4 Tage und nun bekomme ich Fehlermeldungen vom 
Bus. Diese wären wir folgt:
-
Störung 01
IPM Kodierung 2 Störung in der BUS-Kommunikation
10
-
Störung 12
FW200
Systemkonfiguration:
BUS-Teilnehmer fehlt IPM mit Kodierung 1 nicht erkannt, Anschluss und 
Kopierung prüfen

Kann dies damit zusammenhängen, dass ich den MB-LAN2 und Raspberry 
zusammen angeschlossen habe? Habe die in Reihe an den Bus geklemmt.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,

> Kann dies damit zusammenhängen, dass ich den MB-LAN2 und Raspberry
> zusammen angeschlossen habe? Habe die in Reihe an den Bus geklemmt.
Kontrolliere bitte die Verbindungen. In Reihe ist falsch, parallel ist 
richtig, siehe Bild aus dem MB-LAN2 Handbuch.
Ich habe selber das MB-Lan2 und den ht_pitiny parallel am Bus und dies 
funktioniert.
Dazu ist der ht_pitiny-Adapter auf die Geräteadresse := 10dez. 
einzustellen.
Dies geht wie folgt (ht_proxy.server muss laufen!):
 1. ht_pitiny und MB-Lan2 vom ht-Bus trennen und kontrollieren ob das 
Heizungs-System dann korrekt läuft.
 2. Einstellen der Geräteadresse und Reset des Adapters mit:
 2.1 ./ht_netclient.py -ht_adr 10
 2.2 ./ht_netclient.py -ht_rst 1

Siehe auch Docu Seite 35.

Hinweis: Eventuell vorhandene Brücken zwischen TP-In und TP-Out auf dem 
ht_pitiny-Adapter entfernen (Raspberry-Pi neu starten).

Danach ist der ht_transceiver (ht_pitiny) auf die Geräte-Adresse 10dez. 
eingestellt.
Verkabelung kontrollieren (siehe Bild) und nur den ht_pitiny am ht-Bus 
laufen lassen. Empfang und Senden der Daten muss gehen.
MB-Lan2 dann korrekt anschliessen, dies muss dann auch zusammen laufen.

Gruß Norbert

[Nils R. (augur)]

Hi Norbert.

Bisher lief beides korrekt ein paar Tage zusammen, auch mit der 
abgewandelten Verkabelung. Ich hab nun die Geräteadresse geändert und 
nun kommt kein Fehlercode mehr. Wahrscheinlich war es das schon. Die 
Verbindung zwischen TP In/Out nehme ich noch raus. War die früher nicht 
mal muss mit dem Anschluss des MB-Lan2?

Viele Grüße,
Nils

PS. Fehler ist wieder da... :-( dann gehe ich mal an die Verkabelung.

[Norbert S. (junky-zs)]

Hallo Nils,

> Die Verbindung zwischen TP In/Out nehme ich noch raus. War die früher
> nicht mal muss mit dem Anschluss des MB-Lan2?
Ja um die Geräte-Adresse auf (7F)hex zu erzwingen (Native-Mode, kein 
Senden nur Empfangen).
Jetzt ist ja die Adresse einstellbar.
Die Verbindung muss raus und der Adapter einmal stromlos gemacht werden 
bzw. Reset erhalten, sonst läuft der Adapter weiterhin im Native-Mode.

Hattest Du bisher nur den ht_pitiny am ht-Bus (ohne MB-Lan2) und damit 
keine Probleme gehabt?

Gruß Norbert

[Nils R. (augur)]

Ja, bisher schon. Jetzt hab ich mich mal aufgerafft beides 
anzuschließen, da ich die Zeiten anpassen wollte (sonst kann das Teil ja 
nicht so viel). Vorher gab es nie ein Problem, wo die Geräte einzeln 
angeschlossen waren.

Interessanterweise hab mein Heizungstechniker den HT-Bus nicht wie 
angefordert angeschlossen, sondern alle Geräte in Reihe. Ich hab das nun 
entsprechend der Vorgabe angepasst. Mal sehen, wie lange es nun 
funktioniert.

Die Geräteadresse wird im EPROM gespeichert?

Viele Grüße,
Nils

PS. Und wieder Fehler....Mist. Ich lass den Raspberry mal vom Strom und 
teste mal nur mit MB-LAN2.

PSS. Auch wieder der Fehler. Nun kommt das MB-Lan2 weg. (sollte ich auch 
die Kabel abmachen?)

[Norbert S. (junky-zs)]

Hallo Nils,

> Die Geräteadresse wird im EPROM gespeichert?
Ja, ist somit auch nach einem Reboot oder Spannungsausfall vorhanden.

> Nun kommt das MB-Lan2 weg. (sollte ich auch die Kabel abmachen?)
Normalerweise reicht es die Spannungsversorgung dafür abzuschalten.
Aber das MB-Lan2 als Fehlerursache kommt mir schon komisch vor, zumal 
die Fehlermeldungen nichts mit dem MB-Lan2 sonder mit dem IPM 
(Schaltmodul) zu tun haben.

Ich würde mal beides MB-Lan2 und Adapter vom ht-bus entfernen 
(abklemmen) und mal 2 bis 3 Tage das Heizungssystem laufen lassen.
Wenn kein Fehler mehr auftritt dann erst mal das MB-Lan2 anschliessen 
und sehen wie dies sich verhält.

Gruß Norbert

[Nils R. (augur)]

Hi.

Werde ich genauso machen. Weißt du ob man die beiden 
Verkablungsvarianten kombinieren kann? Aktuell habe ich folgendes:

FW200 -> (In) IPM (Out) -> MB-Lan2
                        -> Raspberry
                        -> Solar

Hinter dem IPM ist es als Stern verkabelt, dieser selber hat zwei 
Anschlüsse. Alles andere funktioniert, nur der IPM in der Mitte nicht 
zuverlässig. Eine Verteilerdose habe ich nicht genutzt sondern alles vom 
Ausgang des IPM angeschlossen. Brauche ich eine speziellen Verteiler 
dafür?

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,

ich habe leider kein IPM-Modul und keine Unterlagen darüber, aber aus 
Deinem Bild entnehme ich das dies Modul zwei mal zwei Klemmen (In/Out 
mit 'B' bezeichnet) hat.
Ich weiss aber nicht wofür dieser Out-Anschluss sein soll, denn das IPM 
ist ja kein Mittler zwischen den Modulen sondern ja auch nur ein 
weiteres Modul.

Du wirst sicher Unterlagen vom IPM haben aus der die Funktion von den 
In- und Out-Anschlüssen hervorgeht.
Sicher sind dort auch Anlagenschema und Installations-Anweisungen 
enthalten die weiterhelfen.
Im Bild ein Schema für eine einkreisige Regelung mit dem IPM die ähnlich 
Deinem Bild sind.
Allerdings würde ich das MB-Lan2 und den ht_pitiny Adapter direkt am 
FW200 Regler anschliessen und nicht über das IPM2 - Modul schleifen.

Gruß Norbert

[Nils R. (augur)]

Hi Norbert.

In den Schemata, welche mir vorliegen, sind die IPM Module in Reihe 
geschaltet. Laut Anleitung werden aber auch andere Module nicht 
ausgegrenzt (wie bei der Anleitung vom MB-Lan2 erwähnt).

Ich werde das aber morgen mal umbauen und eine Abzweigdose installieren. 
Dann ist das ganze auch schöner verkabelt mit Klemmen.

Viele Grüße,
Nils

PS. Mit stromlosen Raspberry läuft die Anlage seit ein paar Stunden nun 
ohne Fehler...vielleicht tritt eine Masseschleife oder ähnliches auf und 
das IPM hat deshalb Probleme...aber morgen wird nochmal umgebaut...

[Nils R. (augur)]

Sooo, ich glaube ich hab das Problem gefunden. Nachdem ich mir überlegt 
habe, welches Gerät denn neu hinzugekommen ist, hab ich den 
Netzwerkswitch identifiziert. Mit dem MB-LAN2 wieder direkt ans Netz und 
keine Probleme mehr. Werde nun den Raspberry wieder anschließen erst mal 
ohne Netz mitlaufen lassen.

Ich hoffe ein neuer Switch macht dann keine Mucken mehr.

Viele Grüße,
Nils

[Ronny K. (ronny_k)]

Hallo,

habe den HT_Pitiny Adapter nachgebaut. Danke nochmal an Norbert für die 
viele Mühe und die Unterstützung hier und die gute Anleitung.

Allerdings läuft bei mir die Software nicht auf dem Attiny.
Ähnliches Problem wie schon früher hier im Thread von 'strauch' 
thematisiert: Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"

Ich habe also die Fuses durchprobiert (hfuse D5 oder D7) in Kombination 
mit efuse F5 oder FF. lfuse immer EE

Variation der Reihenfolge:
fuses, flash , eeprom
fuses, eeprom, flash

Jeweils immer poweroff&poweron
Verify ist immer ok.

DIE LED BLINKT NICHT !

Habe mit einem Oszi an den Pins 2 und 3 des ATtiny gemessen und dort 
keinen 10MHz Sinus vom Quarz gesehen.
- Platine nochmals mit Lupe überprüft (Sichtprüfung) - keine 
Auffälligkeiten
- Platine mit Durchgangsprüfer gemessen, um Kurzschlüsse oder 
Unterbrechungen (besonders am ATtiny) zu finden - keine Auffälligkeiten

- Quarz gegen einen aus der Krabbelkiste getauscht (4,395 MHz)
- mit Oszi an Pins 2 bzw 3 gemessen --> Sinussignal mit der 
Quarzfrequenz, grüne LED blinkt nicht

Jetzt dachte ich, dass der Quarz defekt ist, habe mir also einen neuen 
besorgt und eingelötet. Kein Sinussignal an Pins 2 bzw 3.
"Springt" auch nicht an, wenn ich mit dem Finger oder Metall die Pins 
des Quarzes abwechselnd berühre.
Habe die beiden 22pF Kondensatoren am Quarz ausgelötet und gemessen. 
Habe einen Wert von 22nF statt 22pf ermittelt (mit Multimeter) und mir 
neue besorgt. Diese hatte ich im Laden extra nachmessen lassen und sie 
hatten 22pF. Neue Kondensatoren nochmal zu Hause nachgemessen und sie 
hatten wieder 22nF. Hatte also ein Problem mit meinem Messgerät zu 
Hause. Nachdem ich es neu kalibriert habe, hat es mir 25pF bei den alten 
und neuen Kondensatoren angezeigt. Die Kondensatoren waren es also 
nicht.

Ich werde mir jetzt mal einen neuen ATtiny besorgen.
Oder hat noch jemand eine andere Idee, woran es liegen könnte?

Danke

Ronny

[fsigloch (Gast)]

Hatte mal Probleme mit BODLEVEL, Mit 2,7 Volt gings dann.

Gruß Ferdinand

[Norbert S. (junky-zs)]

Hallo Ronny,

ich vermute mal Du hast keinen SMD-Quarz sondern einen bedrahteten Quarz 
genommen. Bei diesem Typ muss man aufpassen das man das Gehäuse nicht 
plan auf die Platine montiert sondern ein wenig Luft lässt.
Das Gehäuse macht sonst einen schönen Kurzschluss zwischen den 
Anschluss-Fahnen am ATtiny Pin2 und Pin3.
Aber dies kannst Du ja nachmessen. Falls nötig Quarz entfernen und 
folgenden Test durchführen:

Zum Test kannst Du auch die Fuses so einstellen das der ATtiny mit 8MHz 
INTERN läuft.
Klar, Du musst zuvor die Verbindung zum Heizungsbus entfernen aber dies 
hast Du sicher schon gemacht.
Die Fuses für diesen Test wie folgt einstellen:
 Ext.: F5
 High: D5
 Low : E2
Die grüne LED sollte jetzt blinken, zwar nicht ganz so schnell wie mit 
10MHz aber moderat blinken.

Gruß Norbert

[Bernhard L. (blf)]

Hallo zusammen,

seit bald 3 Jahren verfolge ich das Thema, anfangs noch unter dem Thread 
Beitrag "Junkers HT-Bus Heatronic 3 Schnittstelle", da im Herbst 2012 unserer 
Brennwertkessel Junkers CSW 30-3A in Betrieb genommen wurde.

Die Anlage: Zum Brennwertkessel kommt noch eine Solarstation mit einem 
415-Liter Speicher (SP400 SHU), geregelt mit einer ISM 1.
Als externer Regler (Montage im Wohnzimmer) wird der FW120 verwendet.

Im Herbst 2013 habe ich mich dann getraut, den Heatronic-Bus anzuzapfen 
und über einen Spannungsteiler direkt in den RX-UART eines Raspberry Pi 
zu gehen. Die Datenaufbereitung habe ich mit Perl erledigt, Diagramme 
mit Gnuplot erstellt. Leider gab es noch reichlich Fehler in den 
Telegrammen, aber um die Anlage besser zu verstehen, Probleme der 
Solaranlage zu identifizieren und Einstellungen sinnvoll zu verändern, 
hat es schon eine Menge geholfen.

An dieser Stelle schon mal ganz herzlichen Dank an alle, die hier die 
Ergebnisse ihrer Experimente mitgeteilt und Schaltpläne, Bilder oder 
Software zur Verfügung gestellt haben !!! Ohne das wäre bei mir nichts 
gegangen - was Elektronik und Programmieren angeht, bin ich ein kleiner 
Anfänger.

Da ich mich mit den fehlerhaften Diagrammen nicht so ganz abfinden 
wollte und die Ursache zunächst am Spannungsteiler vermutete, habe ich 
es im Frühjahr 2015 stattdessen mit dem HT3_Miniadapter (s.o.) versucht. 
Ergebnis: Die Fehler waren genau die selben wie vorher. Bis vor kurzem 
hatte ich dennoch die Hardware im Verdacht ...

... bis ich dann vor ein paar Tagen einmal statt meines Perl-Skripts den 
HT3_CSW_analyser.py von Norbert gestartet habe und siehe da: Alle 
Telegramme werden erkannt, die Fehler sind verschwunden! Inzwischen habe 
ich auch den HT3_Logger.py ausprobiert, der funktioniert jetzt auch. 
Also war mein schlechtes Perl-Skript schuld an den Fehlern.

Norbert, ganz herzlichen Dank für die Bereitstellung der Codes, 
Schaltpläne und die hervorragende umfangreiche Dokumentation!
2 Kleinigkeiten sind mir beim Ausprobieren der Software aufgefallen:
- Die Brennerleistung wird in % angegeben, was bei meinem Gerät nicht 
ganz hinkommt. Die Leistung müsste entsprechend der Tabelle 28 der 
Installationsanleitung von Junkers 
http://www.heizungsdiscount24.de/shop/images/products/media/Junkers-CSW-30-3-A-7712231476-UR_05_Installationsanleitung-Junkers-CerapurSolar-CSW-30-3-A.pdf 
(Seite 49) umgerechnet werden. Z.B. ist mein Gerät zum Heizen auf eine 
Belastung von 12 kW gedrosselt worden, was der Anzeige am Display '50' 
entspricht (wird dann auch im Telegramm als '50' angezeigt). Ich habe 
den Zusammenhang von Anzeige und Belastung folgendermaßen genähert: 
Belastung/kW = Anzeigewert*0.36577 - 6.3158.
- Ein Problem hatte ich beim Starten des HT3_Logger.py. Fehlermeldung 
siehe Anlage.Nach Auskommentieren der Zeile 137 in ht3_worker.py hat es 
funktioniert.

Beim Solarspeicher (SP400 SHU) bietet es sich an, zusätzliche 
Temperatursensoren zu installieren (bei mir DS18B20 an 1wire-Bus), wenn 
man den "Ladezustand" des Speichers abschätzen möchte (--> angehängte 
JPGs). In den Daten vom HT3-Bus habe ich bisher nur die Temperaturdaten 
des unteren Temperatursensors gefunden (in b0 00 ff 00). Die Temperatur 
des Sensor in Speichermitte wird möglicherweise gar nicht über den Bus 
gesendet sondern nur im Heizgerät direkt für die Regelung verwendet. Die 
Analoganzeige im Speicher oben kann eigentlich nur dem Installateur 
nutzen, damit er sich nicht die Finger verbrennt, wenn er Wasser 
ablassen muss.

Schönen Gruß
Bernhard

[Ronny K. (ronny_k)]

Hallo Ferdinand,

kannst Du mir sagen, wie ich BODLEVEL auf 2,7V stelle? Über Fuses?

[Ronny K. (ronny_k)]

Hallo Norbert,

Norbert S. schrieb:
> Hallo Ronny,
>
> ich vermute mal Du hast keinen SMD-Quarz sondern einen bedrahteten Quarz
> genommen. Bei diesem Typ muss man aufpassen das man das Gehäuse nicht
> plan auf die Platine montiert sondern ein wenig Luft lässt.
> Das Gehäuse macht sonst einen schönen Kurzschluss zwischen den
> Anschluss-Fahnen am ATtiny Pin2 und Pin3.
Habe einen SMD-Quarz. Der hat eine schwarze Kunststoffscheibe zur 
Isolierung. Hatte aber auch schon den Quarz mit längeren Anschlussfahnen 
versehen, weil ich dachte, dadurch schwingt er besser an, weil mein 4 
MHz Quarz auch lange Fahnen hatte.

> Aber dies kannst Du ja nachmessen. Falls nötig Quarz entfernen und
> folgenden Test durchführen:
>
> Zum Test kannst Du auch die Fuses so einstellen das der ATtiny mit 8MHz
> INTERN läuft.
> Klar, Du musst zuvor die Verbindung zum Heizungsbus entfernen aber dies
> hast Du sicher schon gemacht.
> Die Fuses für diesen Test wie folgt einstellen:
>  Ext.: F5
>  High: D5
>  Low : E2
> Die grüne LED sollte jetzt blinken, zwar nicht ganz so schnell wie mit
> 10MHz aber moderat blinken.

Habe ich gerade probiert. Grüne LED blinkt nicht. Ich messe dauerhaft 
0,3V am entsprechenden ATtiny-Ausgang.
>
> Gruß Norbert

Danke,

Ronny

[Ronny K. (ronny_k)]

Ronny K. schrieb:
> Hallo Ferdinand,
>
> kannst Du mir sagen, wie ich BODLEVEL auf 2,7V stelle? Über Fuses?

Sehe gerade im Datenblatt, das hfuse D5 schon BODLEVEL 2.7V 
entspricht...

Das sollte es also nicht sein.

Ronny

[fsigloch (Gast)]

Muss nicht auch LOW:  EE sein, damit der Quartzozillator mit 10 MHz tut 
?

Gruß Ferdinand

[Norbert S. (junky-zs)]

Hallo,

@Ferdinand
> Muss nicht auch LOW:  EE sein, damit der Quartzozillator mit 10 MHz tut ?
Ja, die korrekte Einstellung der Fuses ist:
  Ext.: F5
  High: D5
  Low : EE
Dann sind u.A.externer Quarz und BODLEVEL 2.7V richtig eingestellt.

@Ronny
Ferndiagnosen sind immer etwas schwierig aber ich versuche es mal:
1. Die Fuses im Adapter hast Du auf die obigen Werte setzen können 
(N-mal) und somit läuft der externe Quarz!!!!
Grund: weil ohne den Quarz ein Flashen nicht möglich ist wenn man einmal 
von interner auf die externe Takterzeugung umgeschaltet hat!
Ob die Frequenz stimmt ist dann eine andere Sache.
Mit einem Scope und Tastkopf hat man u.U. Messprobleme da die 
zusätzlichen Kapazitäten den Schwingkreis beeinflussen.

2. Der ATtiny lässt sich Flashen, somit funktioniert der zumindest 
dafür.
3. Die grüne LED (D9) ist richtig bestückt und funktioniert auch !!??

Bleibt nur noch der Reset bzw. die Resetschaltung über. Hast Du die 
Diode (D10) und Widerstand (R16) korrekt bestückt !!??
Am Pin4 des ATtiny841 muss High-Pegel anliegen.
Dort kannst Du auch manuell einen Reset ausführen, eventuell hat ja der 
Pullup-Widerstand (R16) keinen Kontakt.

Wenn all dies nicht fruchtet schicke mir den Adapter zu.

Gruß Norbert

[Ronny K. (ronny_k)]

Norbert S. schrieb:
> @Ronny
> Ferndiagnosen sind immer etwas schwierig aber ich versuche es mal:
> 1. Die Fuses im Adapter hast Du auf die obigen Werte setzen können
> (N-mal) und somit läuft der externe Quarz!!!!
> Grund: weil ohne den Quarz ein Flashen nicht möglich ist wenn man einmal
> von interner auf die externe Takterzeugung umgeschaltet hat!
Aha - ich dachte, es gibt dann ein Fallback auf den internen, wenn der 
externe Quarz nicht anschwingt.
> Ob die Frequenz stimmt ist dann eine andere Sache.
> Mit einem Scope und Tastkopf hat man u.U. Messprobleme da die
> zusätzlichen Kapazitäten den Schwingkreis beeinflussen.
>
> 2. Der ATtiny lässt sich Flashen, somit funktioniert der zumindest
> dafür.
> 3. Die grüne LED (D9) ist richtig bestückt und funktioniert auch !!??
Habe die Leiterbahnen und Vorwiderstand (1K) nachgemessen. Die 
Verbindungen vom ATtiny bis zur LED sind ok. Wie gesagt, ich messe dort 
ständig 0,4V - was ich merkwürdig viel finde. Bei L-Pegel sollten dort 
gegen 0V anliegen. Auch menn ich länger am ATtiny LED Grün Ausgang 
messe, sehe ich dort nie mehr als 0,4V. Also blinkt da nichts, selbst 
wenn die LED falsch herum drin wäre (was ich mehrfach geprüft habe). 
Kathode (Chipträger) an Minus (Pin am Platinenrand). Habe auch schon die 
LED getauscht.
>
> Bleibt nur noch der Reset bzw. die Resetschaltung über. Hast Du die
> Diode (D10) und Widerstand (R16) korrekt bestückt !!??
> Am Pin4 des ATtiny841 muss High-Pegel anliegen.
H liegt an Pin 4 an (3,3V).
> Dort kannst Du auch manuell einen Reset ausführen, eventuell hat ja der
> Pullup-Widerstand (R16) keinen Kontakt.
Habe mal probehalber auf L gezogen (Kurzschluss nach GND). Keine 
Reaktion.
>
> Wenn all dies nicht fruchtet schicke mir den Adapter zu.

Ich schneide erst mal den ATtiny raus und teste einen anderen, bevor ich 
Dich damit belästige.

Vielen Dank erst mal.
>
> Gruß Norbert
VG,
Ronny

[fsigloch (Gast)]

Hi,

ich hatte mal Probleme mit dem EESAVE. Nach (wichtig vorher) korrekter 
Fuse- Einstellung habe ich nur das EEPROM neu geflasht, dann blinkte die 
grüne LED freudig.

Gruß Ferdinand

[Ronny K. (ronny_k)]

fsigloch schrieb:
> Hi,
>
> ich hatte mal Probleme mit dem EESAVE. Nach (wichtig vorher) korrekter
> Fuse- Einstellung habe ich nur das EEPROM neu geflasht, dann blinkte die
> grüne LED freudig.
>
> Gruß Ferdinand

habe ich mal getestet: Fuses gesetzt:

root@junkers:/home/pi# avrdude -cgpio -pattiny841 -U lfuse:w:0xEE:m -U hfuse:w:0xD5:m -U efuse:w:0xFF:m
avrdude: AVR device initialized and ready to accept instructions
...
avrdude: 1 bytes of lfuse verified
...
avrdude: 1 bytes of hfuse verified
...
avrdude: 1 bytes of efuse verified
avrdude: safemode: Fuses OK
avrdude done.  Thank you.

nur EEPROM geflasht:

root@junkers:/home/pi# avrdude -v -pattiny841 -cgpio -Ueeprom:w:pitiny.eep

avrdude: Version 5.10, compiled on Jun 18 2012 at 12:38:29
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is "/root/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : unknown
         Using Programmer              : gpio
         AVR Part                      : ATtiny841
         Chip Erase delay              : 4500 us
         PAGEL                         : P00
         BS2                           : P00
         RESET disposition             : possible i/o
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65     6     4    0 no        512    4      0  4000  4500 0xff 0xff
           flash         65     6    32    0 yes      8192   16    512  4500  4500 0xff 0xff
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00

         Programmer Type : GPIO
         Description     : Use sysfs interface to bitbang GPIO lines

avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x1e9315
...
avrdude: verifying ...
avrdude: 512 bytes of eeprom verified
avrdude: safemode: lfuse reads as EE
avrdude: safemode: hfuse reads as D5
avrdude: safemode: efuse reads as FF
avrdude: safemode: Fuses OK

avrdude done.  Thank you

Hat leider nichts bewirkt. Trotzdem danke für den Hinweis.
VG,
Ronny

[Norbert S. (junky-zs)]

Hallo,

für die Programmierung eines 'ht_pitiny'-Adapters habe ich ein Script 
geschrieben.
Dieses programmiert das ht_pitiny-Board in der Reihenfolge:
 - 1. Fuses
 - 2. Flash
 - 3. EEProm
Damit ist ein Software-Update bzw. auch eine Neubetankung eines 
ht_pitiny-Boards mit dem RaspberryPi möglich.
Zu finden ist dies Script 'prepare_pitiny_board.sh' auf github unter:
  https://github.com/norberts1/hometop_ht_transceiver/tree/master/sw
oder gleich komplettes Projekt mit:
  git clone https://github.com/norberts1/hometop_ht_transceiver.git

@Ronny
Habe dieses Script an drei ht_pitiny-Boards getestet, zwei davon sind 
neu bestückte Boards. Alle drei Boards funktionieren.
Somit scheidet ein Software-Problem aus.
Probiere das Script aus und wenn Du dann noch immer Probleme haben 
solltest kann nur ein Hardware-Fehler Deines selbst bestückten Boards 
vorhanden sein.

Ps.: Bitte nicht zu viele avrdude - dumps ins Forum stellen, man sieht 
ja die Bäume im Wald nicht mehr.
PM an mich funktioniert ja auch:=)

Gruß Norbert

[fsigloch (Gast)]

Hi,

so wie ich als kleiner Beobachter sehe, muss efuse F5 sein und nicht FF.

Mit Script von Norbert wird es dann blinken :-)

Gruß Ferdinand

[Ronny K. (ronny_k)]

Hallo,

habe das Script genutzt - kein blinken. Die Befehle hatte ich so auch 
schon einzeln benutzt.
Jetzt habe ich nochmal das komplette GIT Projekt runtergeladen und siehe 
da --> ES BLINKT !!!
Scheint also bei der ersten Übertragung was schief gegangen zu sein 
(hatte das ja schon mal per 'git clone ...' geholt)

Vielen vielen Dank an alle!
(ich muss jetzt schnell den HT-Bus anklemmen und mal gucken, was da 
rüber kommt)
Ronny
:-)

[Willi (Gast)]

Hallo Leute,
habe gerade diesen tollen Artikel gefunden.
Da ich auch eine Junkers zu hause habe, würde ich gerne diese Schaltung 
für Raspbery nachbauen. Möchte gerne im HT3 Bus schreiben/lesen.

@Norbert Hast du zufällig noch eine übrige raspi_ht_piduino Platine?

Gruß
Willi

[Norbert S. (junky-zs)]

Hallo Willi,

danke für Dein Interesse!

Ich habe nur noch ein paar bestückte und geprüfte 'ht_pitiny'-Adapter.
Leer-Platinen habe ich keine mehr.
Bitte im Forum anmelden und E-Mail an mich.

Gruß Norbert

[Juri K. (iuser)]

Hallo allerseits,

ich bin neulich über den ESP-12E gestolpert. Den kann man u.a. für 
„remote serial“ verwenden und wie z.B. hier
https://wiki.openwrt.org/doc/howto/esp8266-serial-bridge beschrieben. 
Wenn man die ht_punity damit ausrüstet, kann der Modul die Funktion von 
ht_proxy übernehmen und ht_putiny würde unabhängig von raspberry 
agieren. Was hält Ihr von der Idee?

Gruß
Juri

[Nils R. (augur)]

Nils R. schrieb:
> Ich hoffe ein neuer Switch macht dann keine Mucken mehr.

So, läuft ohne Probleme. War echt der Switch.

Noch eine Frage. Da bei mir Soll und Ist Temperatur so abweichen und 
Soll immer sehr nah an der Rücklauftemperatur, kann ich die Werte in 
meiner FW200 irgendwo ablesen, um die Werte mit denen im Logger zu 
vergleichen?

Ich denke Soll steuert eher den Rücklauf.

vg Nils

[Norbert S. (junky-zs)]

Hallo Nils,

> kann ich die Werte in meiner FW200 irgendwo ablesen ...?
Ja, laut Bedienungsanleitung der FW200 ist dies teilweise möglich.
Dazu in das Info-Menu gehen und dort bekommst Du Daten vom
Heizgerät:
  Aktuelle Vorlauftemperatur
Heizkreis 1/2  (Systemabhängig)
  Gewünschte Raumtemperatur
  Aktuelle Raumtemperatur
Die Rücklauftemperatur wird allerdings nicht angezeigt, auch nicht in 
der Fachmann-Menuebene.
Detail-Infos gibt es dann nur noch mit dem Service-Key (HW/SW) der alle 
Systeminformationen auslesen kann.

Gruß Norbert

[Bruno (Gast)]

Hallo Norbert,

hast du vielleicht noch einen fertigen ht_pitiny?
Würde diesen gern per USB am pi unter fhem benutzen, um meine Heizung 
auszulesen und zu steuern.

Danke und viele Grüße
Bruno

[Norbert S. (junky-zs)]

Hallo Bruno,

> hast du vielleicht noch einen fertigen ht_pitiny?
Ja

> Würde diesen gern per USB am pi unter fhem benutzen...
Der ht_pitiny-Adapter kann nicht direkt mit USB verbunden werden sondern 
ist erst einmal nur für den RaspberryPi Stecker vorgesehen.
Über ein Motherboard und einen USB <-> UART Wandler kann er jedoch auch 
über USB kommunizieren (Empfang und Senden).
Ein Motherboard habe ich z.Zeit nicht kann aber eins auf 
Lochraster-Board aufbauen.
Details zum Motherboard siehe:
 Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"

Bitte PM an mich, dort dann mehr Details.

Gruß Norbert

[Nils R. (augur)]

Norbert S. schrieb:
> Hallo Nils,
>

> Ja, laut Bedienungsanleitung der FW200 ist dies teilweise möglich.
> Dazu in das Info-Menu gehen und dort bekommst Du Daten vom
> Heizgerät:
>   Aktuelle Vorlauftemperatur
> Heizkreis 1/2  (Systemabhängig)
>   Gewünschte Raumtemperatur

So, hab mir die Werte angeschaut und leider hat die Heizung gerade 
getaktet. Daher war es schwierig zu prüfen. Jedoch zeigt meine Heizung 
für jeden Heizkreislauf eigene Vorlauftemperaturen an und nicht eine 
aktuelle. Kannst du damit was anfangen? Hab ich in einer Konfiguration 
ggf. was vergessen zu setzen?

Viele Grüße,
Nils

[Nils R. (augur)]

Hi.

Ich hab Vorlauftemperaturen (Soll/Ist) auch pro Heizkreis in der FW200. 
Können diese auch im Logger mitgeschnitten werden bzw. kennst du das 
schon?

Hier mal Fotos von den Werten: 
https://dl.dropboxusercontent.com/u/44624098/Heizung.zip

Daher weicht mein Ist-Vorlauf Wert auch so stark ins negative vom Soll 
ab.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,

> Hab ich in einer Konfiguration ggf. was vergessen zu setzen?
Dein Heizsystem hat zwei Heizkreise, somit musst Du die Anzahl der 
Heizkreise im Konfigurations-File entsprechend setzen:
    <anzahl_heizkreise>2</anzahl_heizkreise>

Weiterhin VERMUTE ich das Du in den Heizkreisen (oder in einem nur) 
Mischer hast, somit musst Du zum jeweiligen Heizkreis das zugehörige 
Flag setzen:
      ....
  <systempart name="heizkreisX">   <<-- X := 1...2 (bei DIR)
      <unmixed>False</unmixed>     <<-- Gemischter Heikreis
oder
      <unmixed>True</unmixed>      <<-- Ungemischter Heikreis

> Ich hab Vorlauftemperaturen (Soll/Ist) auch pro Heizkreis in der FW200.
> Können diese auch im Logger mitgeschnitten werden?
Ja, alle Werte die als Telegramme versendet werden und auch dekodiert 
wurden werden in die Datenbanken geschrieben. Dabei ist es egal ob man 
den 'HT3_Logger.py', 'HT3_Analyser.py' ODER 'HT3_SystemStatus.py' im 
Rennen hat. Alle dekodieren identisch, nur die Anzeigen (GUI) sind 
unterschiedlich bzw. gar nicht vorhanden.
Hinweis:
Natürlich sollten diese Applikationen nicht gleichzeitig laufen, da 
sonst je nach Konfiguration mehrere die gleichen Daten in die gleiche 
Datenbank schreiben.

Allerdings werden nicht alle angezeigten Werte der Regler-Display's als 
Telegramm-Werte gesendet. Dann ist natürlich auch kein Loggen möglich.

Gut wäre es wenn Du Dein System mit einer Übersicht (Systemgrafik) 
beschreiben kannst und eventuell noch ein Logfile erzeugst.
Insbesondere der Wert: 'Externe Vorlauftemperatur' ist mir neu und ich 
vermute das Du mehrere Wärmeerzeuger in Deinem Heizkreis hast !??
Auch solltest Du Dir das System mit den grafischen Tools: 
HT3_SystemStatus.py oder HT3_Analyser.py ansehen. Die angezeigten Werte 
werden auch geloggt.

Gruß Norbert

[Nils R. (augur)]

Hi Norbert.

Die Werte sind entsprechend gesetzt...anbei mal das Config-File.

Hab an HK1 Radiatoren und an HK2 einen gemischten Fussbodenheizkreis (so 
wie im Config-File). Zudem ein Solarmodul mit Speicher, vielleicht ist 
das der weitere Wärmeerzeuger mit IPM2. Die Systemgrafik sollte 
eigentlich die Installation von mir widerspiegeln. 1 gem. Heizkreis + 1 
Speicher
+ 1 Zirkulation

Wie kann ich dir denn ein Log erstellen oder benötigst du eines aus dem 
Log-Ordner?

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,

> Wie kann ich dir denn ein Log erstellen?
Für ein Binär-Logfile folgendes durchführen:
1. falls Du den ht_proxy.py laufen hast
  ~/HT3/sw/ht_binlogclient.py meinlogfile.log

  Das File liegt dann unter: ~/HT3/sw/var/log

oder
2. falls Du direkt am Comport erfasst, zuerst den HT3_logger.py stoppen 
dann:
  cat /dev/ttyAMA0 > meinlogfile.log

Das Konfigurations-File ist OK und passt zu Deinem System 
(Übersichtsbild).
Was man dort allerdings nicht sieht ist die Solar-Anbindung.
Dort muss noch irgendwo ein ISM1 - Modul an die Heizung bzw. 
Heatronic-Bus angeschlossen sein.

Dies wird man dann Deinem Binär-Fogfile entnehmen können. Die 
entsprechenden Solar-Telegramm müssen darin enthalten sein.

Gruß Norbert

[Nils R. (augur)]

Hi Norbert,

so ein Modul hab ich auch, ja. Die Logging-Daten kommen dafür auch an.

Anbei ein binäres Log wie bestellt.

Ich hab ein paar Temperatursensoren an den Rohren gesehen. Könnte das 
zur "externen" Temperatur passen? Würde auch den Wortlaut erklären.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,

danke für das Logfile.
Was ich sehen konnte ist die fehlende bzw nicht vollständige Dekodierung 
für den Heizkreis2. Dort werden 'T-Vorlauf Mischer' und 
'Mischerstellung' nicht angezeigt.
Damit dies ohne grosse Software-Änderungen klappt bitte folgende 
Änderung am Konfigurationsfile durchführen:
Pfad: ~/sw/etc/config/
File: HT3_db_cfg.xml
Einträge anpassen für Heizkreise 2...4 :
    <systempart name="heizkreis2">
        <buscodierung>2</buscodierung>   <!-- 1,2,3,4 -->
...
    <systempart name="heizkreis3">
        <buscodierung>3</buscodierung>   <!-- 1,2,3,4 -->
...
    <systempart name="heizkreis4">
        <buscodierung>4</buscodierung>   <!-- 1,2,3,4 -->

Die Telegramme für den Heizkreis2...4 werden dann korrekt zugeordnet.
Die SystemStatus- bzw. Analyser-Anzeige sieht dann wie im Bild aus.

> Ich hab ein paar Temperatursensoren an den Rohren gesehen.
> Könnte das zur "externen" Temperatur passen?
Dies könnte die Vorlauf-Temperatur an der Hydraulischen Weiche (HW) 
sein.
Laut Deinem Systembild sind die Temperatur-Sensoren wie folgt:
 MF2  := MischerFühler HK2 -->> T-Vorlauf Mischer
 TB2  := Temperaturbegrenzer HK2 (keine Anzeige da nicht im Telegramm)
 VF   := Vorlauf-Fühler an der Hydraulischen Weiche (HW)
 SF   := Speicherfühler
 AF   := Aussenfühler

Einen separaten Rücklauf-Fühler gibt es nicht sondern der ist im 
Heizgerät vorhanden.
Die Zuordnung der Werte werde ich noch weiterhin kontrollieren.

Gruß Norbert

[Nils R. (augur)]

Norbert S. schrieb:
> MF2  := MischerFühler HK2 -->> T-Vorlauf Mischer
>  TB2  := Temperaturbegrenzer HK2 (keine Anzeige da nicht im Telegramm)
>  VF   := Vorlauf-Fühler an der Hydraulischen Weiche (HW)
>  SF   := Speicherfühler
>  AF   := Aussenfühler

Hi Norbert,

Zuordnung habe ich geändert. War noch nach der Installation so und hatte 
es nicht beachtet.

Von der Auflistung der Temperaturen würde es hinkommen, ich hab das aber 
nur das Bild genommen, was am Besten passt. Am 8.3. kommt mein Monteur 
zur Wartung, ggf.  kann ich auch mal fragen, was wie installiert ist.

Generell von den Fotos ist es m.E. wie folgt:

?? := Vorlauf Gerät
VF?? Vorlauf Extern
VF := Vorlauf HK1
MF2 := Vorlauf HK2
SF := Speicherfühler
AF := Aussenfühler

Viele Grüße,
Nils

[Nils R. (augur)]

Moin.

Ich hab die Einstellungen in der Config nun geändert, aber leider hat 
sich auch nach einem Neustart des Raspi in dem HTML Output des RRDTool 
nichts geändert. In der Systemanzeige habe bei den Temperaturen immer 0 
(ggf. hab ich nicht lange genug drauf geschaut?)

Angehängt mal Screenshots und die Config. Hast du noch einen Tipp?

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,

> Hast du noch einen Tipp?
Ja, Du verwendest noch die ältere Software: 0.1.7.1.
Dort ist die Zuordnung der Heizkreise noch fest im Code gesetzt und 
nicht dynamisch aus der Konfiguration bzw. aus den Telegrammen 
abgeleitet.

Habe gerade gestern die Version: 0.1.8.2 auf github.com veröffentlicht. 
Diese behebt genau dieses und andere Dekodierprobleme.

Ich kann Dir daher nur dieses Update ans Herz legen, wobei Du ja 
weiterhin die vorhandenen Datenbanken verwenden kannst.

Meine Empfehlung daher, neues Release: 0.1.8.2 von github.com in einen 
Ordner Deiner Wahl und die vorhandenen Datenbanken (hauptsächlich 
rrdtool-DB), Konfiguratios-Files und rrdtool-Anzeigescript 
'rrdtool_draw.pl' dort hinein kopieren.


> ..., aber leider hat sich auch nach einem Neustart des Raspi in dem HTML
> Output des RRDTool nichts geändert.
Dies liegt weniger an der Datenbank sondern mehr am script: 
rdtool_draw.pl.
In diesem Script sind nicht die Abfragen und das Zeichnen der 
Mischer-Informationen enthalten.
Der Grund ist: Nicht jeder hat ein Schaltmodul IPM und einen HK-Mischer 
in seinem System und ich wollte dort den kleinsten gemeinsamen Nenner an 
Informationen ausgeben.
Das Script ist auch statisch (bis auf Anzahl d. Heizkreise).
Daher muss man für die Mischer-Datenausgabe manuell Hand anlegen.

Gruß Norbert

[Nils R. (augur)]

Hi Norbert,

das ist ja kein Problem. Die rrd Anpassung mache ich dann beizeiten.

Mit der neuen Version klappt es auch, dass die Mischer-Werte angezeigt 
werden. Kann ich dich wegen den andere Temperaturwerten noch in 
irgendeiner Form unterstützen?

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,

prima das es jetzt läuft.

> Kann ich dich wegen den andere Temperaturwerten noch in
> irgendeiner Form unterstützen?
Ja, wäre gut wenn Du die dekodierten Werte und die Heizkreiszuordnung 
mit den Werten des FW200 vergleichen kannst.
Z.B. ist mir der Wert: 'T-Ist (Regler/Wand) ' doch recht hoch und da 
frage ich mich ob das richtig ist.
Speziell dieser Wert hängt vom Einbau/Anbauort des Reglers ab. Kann 
natürlich sein das der bei Dir im Heizungsraum hängt und somit die 
Temperatur dort anzeigt.
Da Du ja keine Fernbedienung hast liefert nur der Regler FW200 diesen 
Wert.

Fehlende Werte des FW200 sind auch noch von Interesse.

Gruß Norbert

[Nils R. (augur)]

Hi.

Ich hab alles abfotografiert und dir zeitgleich ein Binärlog erstellt.

Der Regler ist im dem Kessel verbaut. Mein MB-Lan2 zeigt auch so hohe 
Werte, das ist wahrscheinlich einfach so.

Viele Grüße,
Nils

[Stefan S. (kami)]

Hallo zusammen,

ich habe ja nun schon seit einiger Zeit den Pitiny erfolgreich am 
Laufen. Geht alles super mit der Auswertung und Erfassung. Nun möchte 
ich mich mal an die Ansteuerung der Junkerstherme machen. Ich habe 
gesehen, das man dabei die Heiztemperatur setzen kann und auch auch die 
Modi Frost,Heizen,... auswählen kann. Ich würde aber gerne die 
Warmwasser-Sofortfunktion aktivieren und gerne wissen was noch so 
möglich sein könnte oder wie man Zusatzfunktionen einbinden kann.

Vielen Dank.

Gruß kami

[Stefan S. (kami)]

Hi,

jemand ne Idee zu meiner obigen Frage?

Danke.

Gruß kami

[Ralf K. (elral)]

Hallo zusammen,

nach über einem Jahr habe ich es am Wochende dann endlich geschafft, 
meinen Pitiny Adapter fertig zu stellen. Die benötigten Bauteile habe 
ich mir bei Reichelt mittels des in der Anleitung verlinkten Warenkorbes 
bestellt. Leider fehlen im Warenkorb die BAT54S, die fehlten mir dann am 
Wochenende. Momentan habe ich diese ersteinmal durch 1N4148 (SMD) 
ersetzt, war zwar etwas frickelig, aber ging. Ich hoffe es zumindestens, 
denn mir ist aufgefallen, dass der Bereich um die 4 911er Widerstände 
doch recht warm wird.
Das lesen des Buses funktioniert problemlos, die grüne LED (ersetzt 
durch eine 3mm LED, die SMD war mir dann doch  zu fummelig) leuchtet im 
Takt der Protokolle, die rote LED blitzt hin und wieder auf.
Allerdings kann ich leider nicht auf den Bus schreiben (benutze 
mittlerweile FHEM mit dem Heatronic Modul), mag das wohl mit den warmen 
Widerständen zu tun haben? Dazu müßte ja dann immer der Transistor Q2 
durchgeschaltet sein, oder ich habe die Diode D6 falsch herum eingelötet 
(wie mir gerade beim schreiben auffällt). Beides werde ich heute noch 
kontrollieren.
Ich frage mich aber, ob die Daten erkannt werden können wenn der Bus 
dauerhaft mit 910Ohm/4=~225Ohm belastet wird.

Darüber hinaus würde mich interessieren, ob Du, Norbert, noch planst, 
weitere Befehle zum schreiben auf den Bus zu implementieren. Das ändern 
der Vorlauftemperatur sollte doch bestimmt auch von Junkers vorgesehen 
sein.

Danke und Grüße

Ralf

P.S.: 225Ohm bei 15V sind immerhin 1 Watt, kein Wunder dass es dann warm 
wird ...

[Norbert S. (junky-zs)]

Hallo,

@Ralf

> Leider fehlen im Warenkorb die BAT54S, die fehlten mir dann am
> Wochenende.
Sorry, habe ich korrigiert (den Atmel ATtiny 841 gibt es leider nicht 
bei Reichelt!)
NEUER Link:
 http://www.reichelt.de/?ACTION=20;AWKID=1189494;PROVID=2084

> oder ich habe die Diode D6 falsch herum eingelötet
Dies vermute ich auch, der Transistor wird ja nur kurz für einen Burst 
aktiv (wenn Du den richtigen Typ:PNP verbaut hast).

> Ich frage mich aber, ob die Daten erkannt werden können wenn der Bus
> dauerhaft mit 910Ohm/4=~225Ohm belastet wird
Die Zentrale kann bis ca. 10 Module mit Saft versorgen und die 
Telegramme werden mit einem Signalhub von 5 Volt gesendet. Da spielt es 
keine Rolle ob da 15/10 Volt oder mal gerade 14/9 Volt am Teilnehmer 
ankommen.

> ob Du, Norbert, noch planst, weitere Befehle zum schreiben auf den Bus zu
> implementieren.
Ja, ist geplant und wird realisiert sobald ich die Informationen dazu 
habe.

> Das ändern der Vorlauftemperatur sollte doch bestimmt auch von Junkers
> vorgesehen sein.
Es wird von den Modem 'nur' eine Soll- Temperatur bzw. Soll- 
Temperatur-Niveau vorgegeben. Der Regler macht daraus erst die 
Soll-Vorlauftemperatur die er zum Heizgerät kommandiert.
Die Soll-Vorlauftemperatur kann nicht direkt durch ein Modem-Kommando 
gesetzt werden.

@Stefan
> Ich würde aber gerne die Warmwasser-Sofortfunktion aktivieren und gerne
> wissen was noch so möglich sein könnte oder wie man Zusatzfunktionen
> einbinden kann.
Ja, den Wunsch habe ich und sicher viele andere auch.
Leider ist da auch mit einem MB-Lan2 oder NetCom100 nicht so üppig viel 
möglich. Dies liegt weniger an den Modems oder dem ht_transeiver sondern 
mehr an den Reglern was dort intern realisiert wurde.
Die leidgeprüften MB-Lan2 Besitzer können dies sicher bestätigen.

Trotzdem, die Suche geht weiter und die Hoffnung stirbt zuletzt!

Gruß Norbert

[Ralf K. (elral)]

Hallo Norbert,

die Diode war tatsächlich falsch eingelötet. Nun werden die Widerstände 
auch nicht mehr warm, aber schreiben kann ich leider immer noch nicht. 
Ich werde jetzt zwar die restliche Bestückung noch mal prüfen, aber hast 
Du ggf. eine Strategie die Funktion zu testen? Ein Prüfmodus wäre jetzt 
nicht schlecht, der laaaangsam (so zum messen mit dem Multimeter) den 
Transistor ein-/aus schaltet ;)

Schon mal Danke und Grüße

Ralf

[Norbert S. (junky-zs)]

Hallo Ralf,

> Ein Prüfmodus wäre jetzt nicht schlecht, der laaaangsam (so zum messen
> mit dem Multimeter) den Transistor ein-/aus schaltet ;)
Ja geht, Pin 4 des Sende-Optokopplers U2 auf Masse legen (ist ja Open 
Collector). Der Transistor Q2 muss dann leitend und Spannung an den 
Widerständen R9-R12 vorhanden sein.
Umgekehrt muss er natürlich zuverlässig sperren wenn kein Bus-Signal 
vorhanden ist und Pin 1 und Pin2 (TP HT-TX) des Sende-Optokopplers 
liegen dann auf High-Level.
Die Rote LED blitzt ja auf wenn Bus-Signal vorhanden ist und somit ist 
der Atmel auch aktiv.
Zusätzlich kann man den Debug-Modus im ht_proxy.server aktivieren. Damit 
werden dann die Kommandos zum ht_transceiver in das Logfile geschrieben.

Mit welchem Programm steuerst Du den ht_transceiver an: FHEM und/oder 
ht_netclient.py ?
Beides funktioniert mit ht ht_proxy.server (auch parallel, zeitversetzt) 
wenn es richtig konfiguriert ist.

Gruß Norbert

[Ralf K. (elral)]

Hallo Norbert,

cool, dann weiß ich ja was ich heute abend vor mir habe :)
Da ich bereits Daten bekomme, hatte ich den ATtiny bereits 
ausgeschlossen.

Nachdem ich den Raspi mit FHEM neu aufgesetzt habe, steuere ich den 
pitiny nur noch mit FHEM an. Ggf. muss ich dann Deine SW noch nach 
installieren.

Danke und Grüße

Ralf

[Stefan S. (kami)]

Hi Norbert,

erstmal vielen Dank für die Info. Mein FB-Regler sendet aber doch an die 
Heizung irgendeine Meldung, die die Heizung auswertet oder?

Kann man das nicht irgendwie auffangen und auswerten? Habe mit sowas 
zwar keine Erfahrung. Aber vielleicht hast du ja eine Idee. Der 
Funktionsumfang zum Ansteuern ist ja leider noch nicht so umfangreich :)

Gruß kami

[Ralf K. (elral)]

Hallo Norbert,

die HW scheint in Ordnung zu sein. 12 V am HT3 Eingang ergibt einen 
Strom von 2,3mA, bei GND an Pin4 des Optokopplers erhöht er sich auf 
48,3mA. Das ergibt einen Widerstand von ca. 260 Ohm, also durchaus in 
der Nähe von ca. 230 Ohm.
Dann muss ich wohl mal Deine SW installieren, wird aber wohl erst nach 
Ostern da ich am WE noch mal eine Woche in Urlaub bin.

Danke und Grüße

Ralf

P.S.: Das liegt nicht daran, dass mein Regler in der Therme eingebaut 
ist?

[Norbert S. (junky-zs)]

Hallo Ralf,

Somit ist die Hardware wohl in Ordnung.

> P.S.: Das liegt nicht daran, dass mein Regler in der Therme eingebaut ist?
Nein, der hängt ja auch dort am Heatronic-Bus.

> Dann muss ich wohl mal Deine SW installieren,...
Wie meinst Du das?
Du brauchst ja auf jeden Fall den ht_proxy.server (auch mit FHEM) um mit 
dem ht_transceiver (ht_pitiny) Heizungsdaten senden zu können.
Aber ich denke mal den hast Du am rennen.

Eventuell ist noch eine Kontrolle der FHEM-Konfiguration nötig.

Gruß Norbert

[Ralf K. (elral)]

Hallo Norbert,

> Du brauchst ja auf jeden Fall den ht_proxy.server (auch mit FHEM)

ööhhmmm, das war mir nicht bewusst, hatte ich auch nirgendwo gelesen. 
Stefan schrieb gestern Abend im FHEM Forum, das er den benutzen würde 
und es klappt, klang für mich aber nicht nach "muss" Bedingung. Der 
hat_proxy.server ist Bestandteil von Deiner SW nehme ich mal an. Der 
läuft für sich alleine? Ich lese nochmal Deine Installationsanleitung.

Danke und Grüße

Ralf

[Ralf K. (elral)]

Hallo Norbert,

lesen hilft ungemein :)
In Deiner Anleitung steht ja alles ausführlich. "Irgendwie" hatte ich 
den Part immer überlesen da ich den ht_proxy als für mich nicht relevant 
angesehen hatte.
Jetzt werde ich mich mal dran setzen und möglichst nur den ht_proxy in 
Betrieb nehmen.

Danke und Grüße

Ralf

[Norbert S. (junky-zs)]

Hallo,

wichtiger Hinweis an alle Raspberry3- und ht_transceiver-Adapter Nutzer.

Je nach verwendetem Gehäuse des Raspi3 und aufgestecktem ht_pitiny- bzw. 
ht_piduino-Adapter kann es passieren das beim aufstecken der oberen 
Gehäuseschale die MicroSD Karte verbogen und im schlimmsten Fall 
zerbrochen wird.
Ursache ist die zu geringe Aussparung/Ausfräsung am Pin-Header in der 
oberen Gehäuseschale. Zumindest war dies bei meinem Gehäuse der Fall.
Sicher sind noch andere Adapter-Typen von diesem Problem betroffen.
Im Zweifel vor dem Aufstecken der oberen Gehäuse-Schale den Abstand 
nachmessen.

Die Bilder zeigen die nötige Ausfräsung an der oberen Gehäuseschale von 
ca.3mm. Dies verhindert das beim Aufstecken des Gehäuses der Adapter 
samt Raspberry3 nach unten gedrückt und die MicroSD Karte verbogen wird.

Gruß Norbert

[Ted S. (Gast)]

Hallo!
Tolle Sache! Ist der Umfang, den ich mit dem Raspi sehen (und ggf. 
steuern) kann, abhängig von der Regelung? Ich überlege, ob ich die CW400 
nehmen soll oder ob die CW100 ausreichen würde.
Viele Grüße
Ted

[Norbert S. (junky-zs)]

Hallo Ted,

> Ist der Umfang, den ich mit dem Raspi sehen (und ggf. steuern) kann,
> abhängig von der Regelung? Ich überlege, ob ich die CW400 nehmen soll
> oder ob die CW100 ausreichen würde.
Der Regler ist ja auf das Heizsystem (Anzahl Heizkreise etc.) 
konfiguriert.
Somit wird auch das angezeigt was im Heizsystem vorhanden ist, da nur 
dafür die zugehörigen Telegramme vom HT-Bus gesendet werden.
Wenn Du mehr als einen Heizkreis hast ist ohnehin der CW400 angesagt.
Der CW100 kann 'nur' einen Heizkreis bedienen.

Falls Du eine Umrüstung durchführen willst so muss der Regler zum 
Heizgerät passen, siehe:
https://junkers-de.resource.bosch.com/media/de_nj/endkunde/03_produkte/konnektivitaet/apps_3/junkers_control_/NEU_CT_100-_Kompatibilitaetsliste.pdf
Für Details ist der Fachmann oder andere Foren gefragt. Da kann ich Dich 
nicht beraten.

Was die Steuerung der Heizung angeht so unterscheiden sich die beiden 
Regler nicht grundlegend und dies sollte kein Auswahlkriterium sein.

Gruß Norbert

[Stefan S. (kami)]

Hallo Norbert,

Frohe Ostern. Bin gerade auf der Suche nach einem Fehler. Habe gerade 
den raspberry auf kernel 4.1.20-v7+ geupdated und neugestartet. Es 
laufen zwar alle HT-PySkripte und auch die rote LED am pitiny blinkt und 
die grüne ist an aber irgendwie komme jetzt keine neuen Daten mehr rein. 
Alles andere läuft normal nach dem neustart. Woran kann das liegen?

Gruß kami

[Stefan S. (kami)]

Hi,

ich habe mal etwas gesucht. Es gab wohl für den RPi 3 ein paar 
Umstellung was das UART angeht.

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=141195

Ich glaube damit hängt das zusammen. Ein Downgrade auf 4.1.19-v7+ führt 
dazu dass alles wieder läuft.

Vielleicht Norbert kann du dir deinen Code ja nochmal anschauen, ob es 
irgendwie gefixt werden kann, das auch die neueren Versionen laufen.

Vielen Dank.

Gruß Stefan

[Ralf K. (elral)]

Hallo Norbert,

ich habe während meines Urlaubes den ht_proxy zum laufen bekommen, 
schreiben konnte ich aber weiterhin nicht, weder mittels FHEM noch mit 
dem netclient. Heute habe ich dann vor Ort gesehen, dass die rote LED 
auch nicht mehr aufblitzte, könnte aber schwören das sie es am Anfang 
machte. Ich hatte mir aber schon AVRDude installiert und eben dann den 
pitiny neu geflasht.
Und siehe da, ich kann sowohl von FHEM als auch von netclient aus 
schreiben! In der Anzeige des Reglers steht auch Netcomm aktiv.
Was mir aber unklar ist, wie dieser Modus wieder verlassen wird. Bzw. 
wird weiterhin das eingestellte Wochenprogramm ausgeführt?

Als nächstes habe ich den pitiny Adapter auf den neu aufgesetzten Raspi 
3 gesteckt, den alten selbstgebauten Adapter wieder auf mein 
Produktivsystem. Dabei ist mir beim pitiny auf dem Raspi 3 aufgefallen, 
dass es immer wieder mal zeitliche Abschnitte gab in dem die grüne LED 
langsam blinkte. Ich werde das mal weiter beobachten. Es kann sein das 
es mit dem Stromversorgungsstecker zusammenhängt. Der steckt wohl wegen 
des Gehäuses etwas locker in der Buchse.

Ein frohes Rest Osterwohnende und viele Grüße

Ralf

[Ralf K. (elral)]

Hallo Stefan,

beim Raspi 3 liegt jetzt wohl der Bluetooth Adapter auf dem UART. Dieser 
muss ersteinmal deaktiviert werden, damit der UART wieder nutzbar ist.
Ich bin nach dieser Anleitung gegangen: 
https://forum.fhem.de/index.php/topic,50340.0.html
Unter Jessie kann auch mittels raspi-config die kernel und Boot Ausgaben 
auf die UART unterdrückt werden, die cmdline.txt muss damit nicht mehr 
editiert werden.
Und da es die inittab unter Jessie nicht mehr gibt, ist statt dessen 
"sudo systemctl disable [e-mail]" zu verwenden.

Ich hoffe ich konnte etwas weiter helfen.

Viele Grüße

Ralf

[Stefan S. (kami)]

Hi,

ich habe noch nicht auf Jessie geupdatet kann man das irgendwie einfach 
machen ohne ein neues Image aufzuspielen?

Die Anleitung von dir hat leider nicht geklappt ich kriege immer noch 
keine daten. Verwende zurzeit eine Firmware mit rpi-update mit folgender 
ID:

f406502f5628d32e6ca5dadac34ff7ca59f8e27f

Vielleicht hast du ja noch eine Hilfestellung.

Danke Gruß Stefan

[Norbert S. (junky-zs)]

Hallo,

@Ralf
> In der Anzeige des Reglers steht auch Netcomm aktiv.
> Was mir aber unklar ist, wie dieser Modus wieder verlassen wird. Bzw.
> wird weiterhin das eingestellte Wochenprogramm ausgeführt?
Die Anzeige 'NC' (NetComm) am Regler erscheint sobald Du die Betriebsart 
der Heizung einmal durch Kommando gesetzt hast.
Die Anzeige 'NC' selber kann nur manuell durch Drehen am 
Betriebsarten-Schalter im Regler gelöscht werden.
Unabhängig davon ist auf jeden Fall die Betriebsart aktiv, die Du 
zuletzt kommandiert hast. Nur der 'auto'-Mode lässt die 
Programm-Steuerung zu. Alle anderen Betriebsarten (comfort/eco/frost) 
bleiben statisch bestehen.

@Stefan
> Die Anleitung von dir hat leider nicht geklappt ich kriege immer noch
> keine daten.
Hast Du schon einmal mit minicom versucht Daten von der Schnittstelle zu 
erhalten?
Denke dran das die default aktivierte tty-System-Datenausgabe 
abzustellen ist.

Gruß Norbert

[Thomas Linke (Gast)]

Hallo zusammen,

nun habe ich den Thread weitestgehend gelesen und bin sehr angetan, wie 
weit die "Ermittlungen" schon gediehen sind. Eine begnadete Lötöse bin 
ich nicht, deshalb die Frage, ob nicht jemand eine bestückte 
Adapterplatine herumliegen hat und an mich veräußern würde?

Herzlichst

Thomas Linke

[Stefan S. (kami)]

Hallo,

so ich habe jetzt auf Jessie geupgradet. Ich habe deine Anleitung 100% 
befolgt und meine Config sieht so aus:

cmdline.txt:

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 
cgroup_enable=memory elevator=deadline rootwait

config.txt:

dtoverlay=pi3-disable-bt-overlay
dtparam=i2c1=on
dtparam=i2c_arm=on
dtparam=spi=on

Es klappt aber leider gar nicht.

Inzwischen geht es auch nicht mehr mit den anderen Kernel.

Folgende Devices sind bei mir vorhanden: ttyAMA0 und ttyS0

Hast du noch einen Rat?

Vielen Dank.

Gruß Stefan

[Ralf K. (elral)]

Hallo Stefan,

leider nicht so richtig. Versuche doch noch mal SPI auszuschalten, ein 
SPI Pin kann ja den Empfang blockieren (suche mal weiter oben).
Ich frage mich auch gerade, ob Du überhaupt einen Raspi 3 hast (wegen 
des Bluetooth Adapters).
Meine cmdline.txt (Raspi 3, Jessie):
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 
elevator=deadline fsck.repair=yes root wait
und meine config.txt:
# For more options and information see
# http://www.raspberrypi.org/documentation/configuration/config-txt.md
# Some settings may impact device functionality. See link above for 
details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels 
visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if 
console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's 
size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being 
output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio 
work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, 
blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware 
interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented 
/boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on
start_x=0
dtparam=spi=on
dtparam=i2c_arm=off
#device_tree=

# Allow the normal UART pins to work
dtoverlay=pi3-disable-bt-overlay

Und wenn alles nichts hilft, neu installieren (nach Datensicherung!).

Grüße

Ralf

[Stefan S. (kami)]

Hallo,

habe nun alles wieder am Laufen. Es ist recht einfach. Aktuell braucht 
man nur ein rpi-update auf die neuste Version machen und folgende 
Einstellungen müssen dann in der config.txt auftauchen:

dtparam=spi=on
dtoverlay=pi3-disable-bt

Mehr nicht. Dann rennt alles super.

Gruß kami

[Norbert S. (junky-zs)]

Hallo,

habe keine Adapter (ht_pitiny bzw. ht_piduino) mehr zur Verfügung!

Damit trotzdem Adapter bzw. PCB's erstellt werden können habe ich die 
zugehörigen Gerberfiles auf github.com abgelegt, siehe:
  https://github.com/norberts1/hometop_ht_transceiver/hw/...

Wie gehabt bleibt alles Opensource und jeder der die Möglichkeit hat 
PCB's zu erstellen und zu bestücken mag dieses tun.
Vielleicht hat ja jemand die Möglichkeit Adapter auch anderen 
bereitzustellen.
Mir fehlt inzwischen die Zeit ein wenig dazu, da die Software, 
Dokumentation und neue Hardware bearbeitet werden wollen.

Gruß Norbert

[Juri K. (iuser)]

Hi,

der Link ist falsch.
soll https://github.com/norberts1/hometop_ht_transceiver/tree/master/hw
heißen.

[Martin L. (martin_l585)]

Ich hätte noch ziemliches Interesse an einem Adapter. Falls jemand noch 
einen übrig hat, oder diese herstellen kann würde ich mich um eine 
Kontaktaufnahme freuen.

Gruß, Martin.

[Stefan S. (kami)]

Hallo Norbert,

mal eine Frage, ich möchte gerne den pitiny mit einem Odroid C2 Board 
einsetzen. Kann ich den da so draufstecken und läuft der Hardwaremässig? 
Also muss ich vielleicht nur noch was an der Software einstellen? Oder 
brauche ich die SPI? Gibt es sonst eine andere Lösung am Odroid den 
pitiny zu nutzen? Was für Einschränkungen könnte es geben?

Gruß Stefan

Pinbelegung GPIO vom Odroid C2:

http://odroid.com/dokuwiki/doku.php?id=en:c2_hardware

[Norbert S. (junky-zs)]

Hallo Stefan,

> mal eine Frage, ich möchte gerne den pitiny mit einem Odroid C2 Board
> einsetzen. Kann ich den da so draufstecken und läuft der Hardwaremässig?
Da ich kein Odroid C2 Board habe, kann ich dies nicht wirklich prüfen.
Es werden jedoch 'nur' wenige Pins / Signale verwendet, wobei die 
wichtigsten (Spannung 3.3V und UART RX/TX) gleich sind.

Das SPI Interface wird 'nur' für einen Software-Update des 
ht_pitiny-Adapters benötigt. Wenn Du dies nicht machen willst sind 
trotzdem die Pins 23 (SPI-SCK) und Pin 24 (Reset) wichtig.
Pin23 (SPI-SCK) sollte auf Input (Signal floating) geschaltet/schaltbar 
sein und der Pin24 (Reset) auf High (3.3V).
Da diese beim Odroid C2 Board ebenfalls auf den GPIO gelegt sind ist 
dies per Software ja steuerbar.

Die wichtigen Pins sind gleich:
Pin1  3.3Volt
Pin6  GND
Pin8  UART TX
Pin10 UART RX
Siehe dazu noch die URL's:
  http://pinout.xyz/
  http://pinout.xyz/pinout/arduino_spi

Die Software (in Python) ist wohl nur wenig bis gar nicht anzupassen.

Probiere es mal aus und poste Deine Erfahrung.

Gruß Norbert

[Stefan S. (kami)]

Hi Norbert,

vielen Dank für die schnelle Antwort.

Klar teste ich das erstmal. Gab es den irgendwelche Firmware-Updates 
seitdem du mir den pitiny zugeschickt hast (Wenn du noch weißt wann das 
war :) )

Wie kann ich denn die Pins so auf dem Odroid einstellen?

Ich bin mir da nicht so sicher. Kannst auch gerne erklären, wie du das 
auf dem Pi3 machen würdest, dann suche ich mir das für Odroid raus. An 
sich müsste ja wirklich alles zu kopieren sein.

Schönen Tag noch.

Gruß Stefan

[Norbert S. (junky-zs)]

Hallo Stefan,

> Gab es den irgendwelche Firmware-Updates seitdem du mir den pitiny
> zugeschickt hast?
Nein, ist immer noch der gleiche SW-Stand für den ht_pitiny.
Siehe unter URL: https://github.com/norberts1/hometop_ht_transceiver
Ist auch z.Zeit kein Update vorgesehen und läuft ja.

> Wie kann ich denn die Pins so auf dem Odroid einstellen?
Im Verzeichnis: ~HT3/sw/etc/sysconfig gibt es die Python-Scripte:
  spi_clk_off.py und spi_clk_on.py
Die bemuckeln die GPIO-Pins damit die SPI-Pins entsprechend eingestellt 
werden. Die scripte sind aber für RaspberryPi ausgelegt.

Jedoch gibt es auch beim Odroid eine GPIO-Library: 'WiringPi' die sowas 
können soll. Die obigen Scripte sind dann anzupassen damit die das tun 
was gefordert ist.
Details zu dieser Library für Odroid kenne ich jedoch nicht.

Gruß Norbert

[Ronny (Gast)]

Hallo,

wollte mal in die Runde fragen, ob jemand das was ich vorhabe, eventuell 
schon umgesetzt hat:

Ich suche ein einfaches Client-Script, das Werte (Temperaturen, Stati) 
via ht_proxy ausliest. Dieses Script würde ich dann per Cron-Job 
periodisch ausführen (alle 5 Minuten oder so). Mir geht es darum, 
einzelne Werte als Systemvariable per wget in die Homematic schreiben, 
damit ich dort darauf reagieren kann. Die wget Aufrufe sind mir klar, 
das mache ich auch schon an anderer Stelle.
Aber irgendwie fehlt mir eine Idee, wie ich mit Python die Werte vom 
Proxy bekomme.

Es sollte direkt auf dem Proxy-Raspi laufen.

Hat jemand einen Denkanstoß?

Danke,

Ronny

[Juri K. (iuser)]

Hi,

wenn ich es richtig verstehe, kannst du die Daten nicht abfragen, 
sondern muss auf die Aktualisierung warten. Aber wenn Du nicht unbedingt 
realtime Daten brauchst, würde ich einfach die Daten von dem ht_logger 
in die DB schreiben lassen und dann per eigenen Script lesen und an die 
Homematic posten.

Gruß
Juri

[Ronny (Gast)]

Hallo Juri,

> wenn ich es richtig verstehe, kannst du die Daten nicht abfragen,
> sondern muss auf die Aktualisierung warten.

hast recht - daran hatte ich nicht gedacht. Dann werde ich die SQLite DB 
doch als Puffer nutzen müssen.
Das kriege ich hin.

VG,

Ronny

[Tim M. (timmmey)]

Hallo zusammen,

Zunächst schon mal vielen Dank für die Mühen die in dieses Projekt 
geflossen sind. Ich habe den piduino-Transceiver mal in Angriff 
genommen. Bei der Bestellung der Leiterplatte zeigte sich direkt das 
erste Problem: Im Layout befinden sich zwei Bohrungen, deren Pads (s. 
Anhang) nicht mit der Massefläche verbunden sind. Dieses wurde direkt 
vom Ätzer korrigiert.

Beim Aufbau musste ich leider feststellen, dass die Grafiken  im 
Git-Repo leider nicht wirklich konsistent zum Layout, bzw. zueinander 
sind. Ist mir natürlich erst aufgefallen, als ich die ersten Teile 
falsch eingelötet hatte :)

Jetzt hab ich aber noch eine Stelle unbestückt. Da soll sich laut 
Platinen-Layout ein Widerstand R10 befinden. Leider finde ich überhaupt 
keine Informationen dazu, was für einer das sein soll. Und leider ist 
auch kein Widerstand übrig geblieben, so dass er passen müsste :)

Ich hab auch schon versucht den Chip ohne den Widerstand zu flashen 
(avrdude mit linuxgpio-Interface auf dem Raspberry 1B). Leider scheint 
es zu keiner Verbindung zu kommen, zumindest ändert sich die HardwareID 
des Chips jedes Mal.

Ich würde mich über Hilfe freuen!

[Norbert S. (junky-zs)]

Hallo Tim M.

> erste Problem: Im Layout befinden sich zwei Bohrungen, deren Pads (s.
> Anhang) nicht mit der Massefläche verbunden sind. Dieses wurde direkt
> vom Ätzer korrigiert.
Das Layout zeigt die TOP-Seite und die Vollfläche liegt komplett auf 3.3 
Volt. Und diese beiden Anschlüsse müssen auch auf 3.3 Volt liegen. Masse 
ist da falsch.
Es sind somit Widerstand R2 und R11 falsch angeschlossen (müssen 
Pullup's sein). Deshalb bleibt die CPU auch ständig im Reset und die 
Programmierung mit avrdude funktioniert nicht korrekt.

> Jetzt hab ich aber noch eine Stelle unbestückt. Da soll sich laut
> Platinen-Layout ein Widerstand R10 befinden.
R10 ist entfallen und war als Parallelwiderstand für R9 mit jeweils 470 
Ohm vorgesehen. R9 ist jetzt mit 220 Ohm und 1Watt der Ersatz.

> Beim Aufbau musste ich leider feststellen, dass die Grafiken  im
> Git-Repo leider nicht wirklich konsistent zum Layout, bzw. zueinander
> sind.
Ja, sorry. Die Gerberfiles im Repro haben Rev. 0.1, der Schaltplan und 
Stückliste Rev. 0.2
Beide Versionen unterscheiden sich nicht in der Funktion sondern nur im 
Wegfall von R10 und etwas anderer Platzierung der Bauteile.

Siehe beiliegendes Bild des Prototypen (Rev. 0.1) für die erforderlichen 
Lötstellen an die 3.3 Volt TOP-Vollfläche.

Gruß Norbert

[Ronny K. (ronny_k)]

Hallo,

habe das Problem, dass ich in der SQLITE DB nicht den neuesten Eintrag 
nach Datum/Zeit selektiert bekomme. Es wir immer der älteste ausgegeben, 
egal ob ich DESC oder ASC sortiere. Ich vermute, dass es mit dem 
Datumformat in der DB zusammenhängt (Trennung mit Dezimalpunkt statt mit 
Minus):
sqlite3 -line HT3_db.sqlite "select Local_date_time, T_speicher from 
warmwasser ORDER BY strftime('%Y-%m-%d %H:%M:%S',Local_date_time) DESC 
LIMIT 1;"
Local_date_time = 2016.06.20 00:00:09
     T_speicher = 57.7
sqlite3 -line HT3_db.sqlite "select Local_date_time, T_speicher from 
warmwasser ORDER BY strftime('%Y.%m.%d %H:%M:%S',Local_date_time) DESC 
LIMIT 1;"
Local_date_time = 2016.06.20 00:00:09
     T_speicher = 57.7
sqlite3 -line HT3_db.sqlite "select Local_date_time, T_speicher from 
warmwasser ORDER BY strftime('%Y.%m.%d %H:%M:%S',Local_date_time) ASC 
LIMIT 1;"
Local_date_time = 2016.06.20 00:00:09
     T_speicher = 57.7

Andere Variante mit der "datetime" Funktion:
sqlite3 -line HT3_db.sqlite "select Local_date_time, T_speicher from 
warmwasser ORDER BY datetime(Local_date_time) DESC LIMIT 1;"
Local_date_time = 2016.06.20 00:00:09
     T_speicher = 57.7

Andere Variante mit Sortierung nach UNIXTIME (%s) klappt auch nicht:
sqlite3 -line HT3_db.sqlite "select Local_date_time, T_speicher from 
warmwasser ORDER BY strftime('%s',Local_date_time) DESC LIMIT 1;"
Local_date_time = 2016.06.20 00:00:09
     T_speicher = 57.7


Die aktuele Zeit wird mit Minus als Trenner ausgegeben:
sqlite3 -line HT3_db.sqlite "select datetime('now');"
datetime('now') = 2016-06-20 18:52:48

Hat das jemand gelöst und wenn ja - wie?

Danke,

Ronny

[Tim M. (timmmey)]

Hallo Norbert,

vielen Dank für die schnelle Antwort.
Ich meine natürlich die 3.3V Vollfläche. Zumindest haben die besagten 
Pads noch einen fast nicht wahrnehmbaren Rand auf der Top-Seite (s. 
Anhang oben) , welche dafür gesorgt hätten, dass z.B. R2 an der 
Oberseite gerade kein Kontakt mit der Vollfläche hat. Den hat er aber 
bei mir.

Hab es gerade nochmal durchgemessen. Der AtmelPin1 liegt direkt an 
RPI-Pin-24 und es liegen auch ca. 3.3V an.  Hast du vielleicht noch eine 
Idee woran es liegen könnte?

[Norbert S. (junky-zs)]

Hallo Tim M.

> Hast du vielleicht noch eine Idee woran es liegen könnte?
Ferndiagnosen sind immer etwas schwierig.
Alle Verbindungen OK? Bestückung OK? Diode D10 richtig rum eingesetzt? 
Manueller Reset möglich?
Programmierung trotzdem nicht möglich?
Atmel 328 tauschen falls Du den auf Sockel gesetzt hast.

Falls dies auch nicht hilft bleiben nur noch avrdude, GPIO-Porttreiber 
und deren Konfiguration über.
Versuche daher mal statt zu Programmieren den Atmel 328 mit avrdude 
auszulesen. Da sollte was sinnvolles ohne Fehler rauskommen.

Gruß Norbert

[Tim M. (timmmey)]

Hallo Norbert,

bingo! Eine zweite avrdude-Version war noch auf dem Pi installiert. Mit 
der richtigen Version funktioniert auch das flashen. Hab mir die hex und 
eep-File mit AtmelStudio erzeugt und auf dem Pi kopiert (sind nicht im 
git, oder?) und die Fuses nach der fuses.odt gesetzt. Avrdude beschwert 
sich zwar, dass die Efuse auf 7 und nicht FF steht, aber das sollte kein 
Problem sein, oder? (die höheren Bits sind glaub ich nicht belegt, oder 
hab ich das falsch im Kopf?). Zumindest blinkt jetzt die grüne LED.

Vielen Dank für die Hilfe, ich vielleicht schaffe ich es morgen ja mal, 
den Pi an den Bus zu bringen :)

Viele Grüße
Tim

[Norbert S. (junky-zs)]

Hallo Tim M.,

prima, wieder einen Schritt weiter!
> Avrdude beschwert sich zwar, dass die Efuse auf 7 und nicht FF steht,
> aber das sollte kein Problem sein, oder?
In der Doku auf github.com sind die Werte für die Fuses beschrieben.
Am besten Du holst Dir das ganze Projekt, dann hast Du auch das 
zugehörige HEX-File die Sourcen und ...
Wie gehabt mit git get's so:
"git clone https://github.com/norberts1/hometop_ht_transceiver.git";

Das Hex-File ist unter:
https://github.com/norberts1/hometop_ht_transceiver/blob/master/sw/piduino/piduino_cpp/piduino_cpp/Release/piduino_cpp.hex

Habe heute auch die ht_piduino gerber-Files auf github.com aktualisiert 
auf die Version 0.2. Somit passen Schaltplan und Layout zusammen.
Aber auch mit dem Layout 0.1 arbeitet Dein ht_pitiny!
Danke für Deine Info.
Bemerkung:
 Zwei Augen sehen viel, viele Augen sehen mehr :-)

Gruß Norbert

[Ronny K. (ronny_k)]

Hallo,

die Sortierung funktioniert jetzt. Man benötigt die "datetime" Funktion 
nicht:
sqlite3 -line HT3_db.sqlite "select Local_date_time, T_speicher from 
warmwasser order by Local_date_time DESC limit 1;"
Local_date_time = 2016.06.22 21:01:22
     T_speicher = 67.0

Grüße,
Ronny

[Ted S. (Gast)]

Hallo,
auch ich habe für für die Junkers ZSB 14 entschieden, mit Heatronic 4i. 
Gemäß Post von Heiko funktioniert sie. Gibt es noch weitere Erfahrungen, 
geht evtl. etwas nicht bzw. gibt es weitere Funktionen?
Viele Grüße

[Norbert S. (junky-zs)]

Hallo Ted S.

> Gibt es noch weitere Erfahrungen, geht evtl. etwas nicht bzw. gibt es
> weitere Funktionen?
1. Der Heatronic 4i- basiert ja auf dem Heatronic 3-Bus und die 
Protokoll-Art und Baudrate ist die selbe.
Es sind neue Telegramme hinzu und vorhandene erweitert/geändert worden. 
Diese werden im vorhandenen Release (github.com) auch teilweise 
dekodiert und die wichtigsten Werte werden angezeigt/gespeichert.
Die Software ist in Arbeit und wird weiterhin verbessert.

2. Wichtig ist aber auch welcher Regler-Type im System vorhanden ist. Es 
gibt da Unterschiede zwischen den Reglern der Fxyz- und der neuen 
Cxyz-Serie.
Die Basis-Telegramme der Cxyz-Serie werden dekodiert, und diese sind im 
vorhandenen Release enthalten.
Jedoch ist die Dekodierung weiterer Telegramme nötig und auch in Arbeit.

3. Die Steuerung der Heizung ist ja mit den ht_transceiver-Adaptern 
möglich und für die Fxyz-Regler im Release mit enthalten.
Für die neuen Cxyz-Regler ist dies noch nicht im Release enthalten und 
noch in Arbeit.

Gruß Norbert

[Klaus (Gast)]

Hallo zusammen,

ein tolles Projekt !
Ich habe bis jetzt nur den einfachen Adapter zum "lauschen" installiert 
und
verschaffe mir gerade einen groben Überblick.

Die sourcen habe ich mit git ausgecheckt. Ich plane aber, das ganze eher 
drahtlos und die Auswertung vielleicht mit JAVA zu realisieren.
Nun meine Fragen:

- Gibt es irgendwo noch Infos über das "Grundrauschen" auf dem Bus. Also 
das Polling vom Busmaster und die entsprechenden Antworten ?

- Im Datum/Zeit Telegramm wird der Wochentag beginnend am Montag mit 01 
codiert:
Wochentag (01=Montag; 02=Dienstag;...)

Bei meiner Heizung mit einem CW400 ist es:
00=Montag; 01=Dienstag;...


Vielen Dank im Voraus

Klaus

[Juri K. (iuser)]

Klaus schrieb:
> Ich plane aber, das ganze eher
> drahtlos und die Auswertung vielleicht mit JAVA zu realisieren.

Hallo Klaus,

ich habe auch vor, die Anbindung in java nachzubilden, genauer gesagt - 
als java OSGi bundle für openhab. Das hätte als Vorteil, dass man sich 
um die Auswertung, Speichen usw. überhaupt nicht kümmern muss, weil im 
openhab schon alles vorhanden ist. Man müsste nur die reine Decodierung 
Proxy->openhab Events und openhab Kommandos->Proxy implementieren.

Allerdings bin ich auch noch nicht weit fortgeschritten. Evtl. könnten 
wir es aber zusammen umsetzen.

Gruß
Juri

[Jochen (Gast)]

Norbert S. schrieb:
> 3. Die Steuerung der Heizung ist ja mit den ht_transceiver-Adaptern
> möglich und für die Fxyz-Regler im Release mit enthalten.
> Für die neuen Cxyz-Regler ist dies noch nicht im Release enthalten und
> noch in Arbeit.

Hallo Norbert,

bedeutet das, das ich zur Junkers Therme (z.B. ZSB14-4) zwingend einen 
F/Cxyz-Regler benötige - selbst wenn diese über den 
ht_transceiver-Adapter gesteuert werden könnte?

Ich frage deshalb weil ich gerade vor der Wahl der Junkers-Therme für 
meinen Neubau stehe (GC9000iW vs. ZSB14-4).

Wenn ein F/Cxyz-Regler vorhanden ist und gleichzeitig der 
ht_transceiver-Adapter einen Steuerbefehl absetzt, wird der dann nicht 
später vom Regler überschrieben?

Gruß

  Jochen

[Juri K. (iuser)]

Hallo Jochen,

ja, Du brauchst auch den Regler (wurde bereits hier oder im Nehbenthread 
besprochen) - die Steuerung übernimmt der Regler, Du kannst lediglich 
deren Parameter (z.B. Wunschtemperatur) über den ht_transceiver-Adapter 
einstellen.

Gruß
Juri

[Norbert S. (junky-zs)]

Hallo,

@Jochen
Den REGLER brauchst Du auf jeden Fall (siehe oben), der ht_transceiver 
macht ja 'nur' eine Steuerung des Systems ohne Regeleigenschaften und 
funktioniert vergleichbar einem MBLan2 oder NetCom100 Modul von Junkers.

> Ich frage deshalb weil ich gerade vor der Wahl der Junkers-Therme für
> meinen Neubau stehe (GC9000iW vs. ZSB14-4).
Bei einem GC9000iW brauchst Du kein weiteres Interface zur Steuerung 
(weder ht_transceiver, MBLan2 oder NetCom100) da im Heizgerät schon eine 
Schnittstelle zu Deinem Router eingebaut ist oder werden kann.

@Klaus
> - Im Datum/Zeit Telegramm wird der Wochentag beginnend am Montag mit 01
> codiert: Wochentag (01=Montag; 02=Dienstag;...)
> Bei meiner Heizung mit einem CW400 ist es: 00=Montag; 01=Dienstag;...
Ja, bei der neuen Reglergeneration Cxyz fängt die Woche mit 00=Montag 
an. Bei den Fxyz Reglern ist dies noch mit 01=Montag.
Junkers hat sich da wohl viel Mühe gegeben Inkompatibilitäten zum EMS2 
Bus und Buderus abzubauen. Jetzt bleiben zwar die 'alten' Junker-Module 
auf der Strecke, aber ein Schelm der dabei eine Absicht vermutet.

> - Gibt es irgendwo noch Infos über das "Grundrauschen" auf dem Bus.
> Also das Polling vom Busmaster und die entsprechenden Antworten ?
Ja, zum Einen für die Telegramme im Projekt und Verzeichnis:
   ~/HT3/sw/etc/html/HT3-Bus_Telegramme.html
und für Buderus EMS2 (sehr ähnlich mit Junkers) unter:
  http://emswiki.thefischer.net/doku.php
Aber wie so häufig im Leben (siehe Bedienungsanleitungen) sind die 
Dokumente nicht mehr auf Stand oder/und unvollständig.
Dies auch weil die neuen Informationen zuerst in die Software fliessen 
und dann in die Dokumentation. Und genau bei der Software ist gerade 
meine Baustelle.

@Juri
> Man müsste nur die reine Decodierung Proxy->openhab Events und openhab
> Kommandos->Proxy implementieren.
Ist es da nicht besser wenn nur EINE Instanz die Dekodierung macht und 
die einzelnen Daten an wissensbegierige Clients liefert?
Dies ist zumindest meine Vorstellung und ich habe Software-Entwürfe dazu 
in der Schublade.
Es bleibt also weiterhin beim ht_proxy.server der RAW-Daten an Clients 
liefern kann. Es kommt also 'nur' noch ein weiterer Client hinzu, der 
die dekodierten Heizungs-Daten an Abfragende liefert (OpenHAB, ....).

Wer allerdings gerne graue Haare bekommen will sei herzlich hiermit 
aufgefordert die Dekodierung selber in die eigene Software zu giessen.
Ich träume allerdings immer noch davon das die nachgelagerte Software 
gar nicht weiss welche Heizung von welchem Hersteller da am werkeln ist.
Aber vielleicht wache ich irgendwann auf und ich habe keine Haare mehr 
:-)

Gruß Norbert

[Juri K. (iuser)]

Norbert S. schrieb:

> @Juri
> Ist es da nicht besser wenn nur EINE Instanz die Dekodierung macht und
> die einzelnen Daten an wissensbegierige Clients liefert?
Das wäre natürlich besser, man müsste aber dafür den Encoder-client so 
schlank wie möglich halten und mit einer Standard-Schnittstelle 
ausstatten, wie z.B. MQTT. Idealerweise sogar in den proxy (als modul?) 
integriert. Danach wäre die Integration in Openhab, FHEM oder sonst wo 
ein Kinderspiel.
Wenn du daraufhin arbeiten möchtest, würde ich Dich auch unterstützen, 
auch wenn ich meine Python Kenntnisse dafür gründlich „erfrischen“ 
müsste.

Gruß
Juri

[Klaus (Gast)]

Hallo,

@Norbert
Vielen Dank für den link auf emswiki. Da hab ich sobald Zeit da ist 
etwas zu tun ....

Ich möchte noch mal kurz meine Ideen erläutern. Ich habe einen 
Heizungskeller, der "weit" vom Wohnraum entfernt ist. Konkret heisst 
das, er ist via LAN oder WLAN nicht erreichbar. Im Wohnraum kommt der HT 
bus mittig aus der Wand und da hängt mein CW400. Auch hier habe ich das 
Problenm, das das nächste LAN Kabel weit weg ist. Ausserdem müsste ich 
dann noch einen Switch  haben, da das Kabel durch den Fernseher belegt 
ist.

Unter dem CW400 den Bus abgreifen und quer durchs Zimmer gefällt mir 
(und der weniger technikaffinen Ehefrau ;-))auch nicht. Warum also nicht 
drahtlos ?

1. WLAN
Das müsste doch mit einem ESP8266 zu machen sein ?
Der hat einen eingebauten UART und ist über die Arduino IDE zu 
programmieren. Z.Zt. läuft mein adapter mit einem Arduino nano (2€ beim 
Chinamann) zur Break Erkennung. Zusätzlich kann man da noch die RX/TX 
level invertieren. Das heisst in der HW kann man die Transistorierten 
Inverterstufen einsparen und drekt von den Optokopplern an den 
Microkontroller gehen.

ESP8266  als Server:
Die clients können sich am ESP8266 anmelden und bekommen den Datenstrom 
vom HT bus.

ESP8266 als client:
Im netzwerk gibt es einen Server (den Raspi), der vom ESP8266 den Stream 
bekommt.

In beiden Fällen müsste man "nur" dem Phyton modul beibringen, von einem 
Socket zu lesen, anstatt von der seriellen Schnittstelle. Ich hab von 
Phyton nicht viel Ahnung, aber ich denke, das müsste ohne viel Aufwand 
machbar sein ?

Damit kann man alles, was von Norbert bereits erarbeitet wurde 
verwenden. Man hätte nur die Leiterbahnen vom piduino zum Raspberry Pi 
durch WLAN ersetzt.

2. Das gleiche müsste natürlich auch mit BT laufen. Der neue Raspi hat 
ja BT on board. BT Module mit Arduino sind auch für ein paar Euros zu 
bekommen.

Jetzt aber die spannende Frage: Das ESP Modul wird mit 3,3V versorgt und 
zieht lt. Datanblatt um die 200mA. das macht rund 0,7 Watt Leistung.

Mit einem DC-DC step-down Konverter wären das umgerechnet auf 10V 
(minimale Busspannung) etwa 70mA (bei vernünftigen Wirkungsgrad). Kann 
man diese Leistung dem HT Bus entnehmen ?

Dann hätte ich ein unscheinbares kleines Kästchen über meinem CW400 
hängen, der die Daten sendet und aus dem Bus mit Strom versorgt wird.

Die BT Lösung ist sparsamer. Gibt es denn verlässliche Werte, wieviel 
Leistung die Module dem HT Bus entnehmen dürfen ?

Das CW 400 ist m.E. unverschämt teuer. Für 400€ bekommt man eine 
Briefmarke als Monochrome Display. Jedes billige 80€ Tablet ist Luxus 
dagegen. Warum also nicht ein Tablet für die Darstellung der Daten ?

Daher meine Frage bzgl. Java. Die Android App ist natürlich ein 
weiteres, grösseres Projekt.

Und noch etwas bzgl. Warmwasser-Einmal-Ladung.
Das Thema ist schon mal besprochen worden und es gibt eine Lösung mit 
einem NE555 die "... den NTC unter 40°C drückt". Gibt es dazu auch noch 
Infos ? Ich würde ev. einen 2. Lauscher mit Arduino am WW-Kessel 
installieren, der auf die Einmalladung vom CW400 wartet, und dann eine 
"tolle" Schaltung aktiviert, die "den NTC unter 40°C drückt".
Wie geht das ?
Wird mit einem Relais oder FET ein Widerstand zum NTC in Reihe 
geschaltet, um eine tiefere Wassertemperatur zu simulieren ?

Gruß

Klaus

[Norbert S. (junky-zs)]

Hallo Klaus,

ich habe den Eindruck Du kannst meine Gedanken und Wünsche lesen :-)

Habe den DC-DC Wandler und den ESP8266 bei mir auf dem Schreibtisch 
liegen. Bin da aber aus Zeitgründen noch nicht weitergekommen.

Juergen O. hat für EMS - Buderus genau dafür eine Platine entwickelt die 
man direkt an den Heizungsbus hängen kann. Eventuell hat er noch 
Platinen. Diese Hardware kann man wohl ohne Änderungen auch am 
Junkers-Bus betreiben.
Er hat sein Projekt auch auf github abgelegt, Link musst Du mal ein 
wenig suchen.

Link zu 1. WLAN
Beitrag "Re: EMS > ESP8266-12 WLAN-Modul"

> In beiden Fällen müsste man "nur" dem Phyton modul beibringen, von einem
> Socket zu lesen, anstatt von der seriellen Schnittstelle. Ich hab von
> Phyton nicht viel Ahnung, aber ich denke, das müsste ohne viel Aufwand
> machbar sein ?
Ja, kein Problem.

> Das CW 400 ist m.E. unverschämt teuer.
Nicht nur der, auch die anderen Module wie MBLan2 ...
Ich kann mir da durchaus z.B. auch eine selber gebaute Fernbedienung mit 
Touch-Display und aussagekräftiger Heizungs-Systemübersicht vorstellen. 
Der eingebaute NTC und die Schnittstellen zur Aussenwelt (Router) machen 
den Einsatz im Wohnzimmer (als Führungsraum) schmackhaft und ist auf 
jeden Fall billiger als eine gekaufte Fernbedienung (Betrieb allerdings 
nicht direkt am/vom Heizungsbus sondern wie bisher galvanisch getrennt).

> Und noch etwas bzgl. Warmwasser-Einmal-Ladung. Gibt es dazu auch noch
> Infos ?
Es gibt ein Telegramm welches als Status-Bit den Tastendruck 'Warmwasser 
Sofort-Anforderung' enthält.
Der Rest ist dann 'nur' noch ein bisschen Software drumrum um mit ein 
wenig Hardware dies in eine Aktion umzusetzen.
Bin gerade dabei die Software für ein neues Release zu überarbeiten und 
kann da eine geeignete Schnittstelle zu einem GPIO-Port des Raspberry 
einbringen.

Gruß Norbert

[Klaus (Gast)]

Hi Norbert,

schön das wir uns einig sind :-)

Noch eine Anmerkung zur WarmWassrProblematik. Das Telegramm mit dem
'Warmwasser sofort' bit habe ich gefunden. Meine Frage bezog sich mehr 
auf die Realierung des "bischen Hardware" am Kessel. Meine Idee ist, 
einen Arduino mit deiner Bus-Eingangsschaltung auf das 
WarmWasserTelegram "warten" zu lassen.

In Reihe zum NTC des WWKessels liegt ein weiterer Widerstand, der im 
Ruhezustand über ein Relais kurzgeschlossen ist. Das sollte auch der 
Ruhekontakt des Relais sein, damit es wärend Problemen in der 
Spannungsversorgung etc. und Händewaschen keine Brühwürstchen gibt :-)

Kommt jetzt das entsprechende Telegramm, wird das Relais für x Sekunden 
geöffnet, der Widerstand steigt und die Wassertemperatur für den Regler 
in der Heizung fällt.  Der Arduino kann auch die Brenner Info auswerten 
und das relais wieder abfallen lassen, sobald der Brenner läuft. In 
beiden Fällen muss aber doch die Elektronik irgendwo zwischen 
Warmwasserkessel und Brenner installiert werden ?

Das heisst der pin auf dem Raspi nützt nur etwas, wenn der Pi auch 
irgendwo im Heizungskeller installiert ist, oder man ein Kabel vom Pi 
zum kessel ziehen kann.

Meine Bedenken sind nur im transienten Verhalten des Reglers beim 
Schalten. Die Temperatur sinkt ja nicht, sondern sie "springt".
Wenn der Regler das nicht verträgt, müsste man sich einen 
kontinuierlichen Abfall z.B. mit einem FET einfallen lassen. Hier wäre 
eine Info von

schwiete (Gast) (Siehe Posting vom 05.10.2015 15:11 ) interessant.

Die SW würde ich mir schon zutrauen. Das wäre eine absolute LowCost 
Variante, die darüber hinaus unabhängig vom restlichen Projekt läuft, 
sofern der eingesetzte Regler die "WarmWasser Sofort" Funktion 
unterstützt.

PS: Ich schreibe immer "Arduino" weil ich das Programmieren mit der IDE 
genial einfach finde. Natürlich geht für uns auch jeder andere mit UART.


Grüße

Klaus

[Norbert S. (junky-zs)]

Hallo Klaus,

> Meine Bedenken sind nur im transienten Verhalten des Reglers beim
> Schalten. Die Temperatur sinkt ja nicht, sondern sie "springt".
> Wenn der Regler das nicht verträgt, müsste man sich einen
> kontinuierlichen Abfall z.B. mit einem FET einfallen lassen.
Durch einen Kondensator über die Kontakte des Relais kannst Du das 
'Springen' des Signals vermeiden bzw. reduzieren.
Ein Leckstrom armer Kondensator mit >= 35 Volt aus der Grabbelkiste 
reicht da (jedoch keinen Elko verwenden).

Ein FET ist nicht erforderlich, der macht die Sache nur komplizierter da 
dieser u.U. das Mess-Signal beeinflusst.

Gruß Norbert

[Stefan S. (kami)]

Hi,

habe ich das richig verstanden, das man die WarmWasserSofortfunktion 
aktivieren kann mit den HT-Tranciever?

Wäre ja echt super.

Gruß kami

[Norbert S. (junky-zs)]

Hallo Stefan,

> habe ich das richig verstanden, das man die WarmWasserSofortfunktion
> aktivieren kann mit den HT-Tranciever?
Nein, das hast Du falsch verstanden. Dies geht nicht weil die 
Steuerungen in den Heizungen und die Regler (zumindest Heatronic3 und 
Fxyz) nicht darauf reagieren.
Der HT-Transceiver kann alles auf dem Heizungs-Bus senden, nur die 
Module hören einfach nicht hin, fast wie im richtigen Leben :)

Die Beeinflussung geht also wie Klaus oben beschrieben hat mit 
Hardware-Eingriffen oder man hat eine ganz neue Heizung mit EMS2 Bus und 
den Reglern der Cxyz-Serie. Dann geht wohl auch das Warmwasser zu 
verdrehen.

Habe dazu Details im FHEM-Forum beschrieben:
 https://forum.fhem.de/index.php/topic,19445.msg470464.html#msg470464

Gruß Norbert

[Klaus (Gast)]

Hallo , ich noch ein letztes Mal für heute.

Wenn ich das richtig verstanden habe, würde die WW Funktion mit der 
zusätzlichen HW am Kessel doch auch mit dem HT-Tranciever funktionieren 
?

Der PI sendet über den Tranceiver den WW befehl auf den Bus. Die Heizung 
versteht ihn nicht aber am Kessel "lauscht" der Arduino, der dann über
das Relais den NTC manipuliert. => Der Brenner springt an, weil das 
Wasser zu kalt ist . Wir würden praktisch den HT bus und das Protokol 
nutzen um am orginalen System vorbei eine Nachricht zu versenden. Oder ?

Damit der PI sendet, kann man einen GPIO nehmen, oder via HTTP, oder 
....



vG

Klaus

[Norbert S. (junky-zs)]

Hallo Klaus,

> Wenn ich das richtig verstanden habe, würde die WW Funktion mit der
> zusätzlichen HW am Kessel doch auch mit dem HT-Tranciever funktionieren?
Es kommt darauf an was Du erreichen willst:
1. Warmwasser sofort auf Tastendruck/Befehl vom Regler CW400 in Deinem 
Wohnraum.
2. Fernsteuerung von sonst wo her über den ht_transceiver.

Für 1. brauchst Du den ht_transceiver nicht, da lauscht der Arduino rein 
passiv auf das zugehörige Telegramm und schaltet das Relay zur 
Aktivierung falls Warmwasser sofort gewünscht ist.

Zu 2. und Fernsteuerung ist ein Kommando über den HT-Bus an den Arduino 
denkbar wenn man dem Arduino eine FREIE HT-Busadresse (Geräteadresse) 
zuteilt auf die er dann lauscht.
Dann kam man dies auch fernsteuern, ganz ohne Aufwand ist dies jedoch 
nicht.

Allerdings stellt sich mir ohnehin die Frage ob dies bei Dir alles 
erforderlich ist, da Du ja einen neuen Regler CW400 hast und Deine 
Heizung bzw. das Heizgerät wohl auch nicht so alt ist.
Somit brauchst Du den ganzen Aufwand eventuell gar nicht treiben da die 
Kommandos über den EMS2 Bus an Dein hoffentlich neues Heizgerät gesendet 
werden können und ausgeführt werden.
Bitte deine Unterlagen durchforsten wie alt das Heizgerät ist und was 
für einen Bus es hat (am besten EMS2).

Gruß Norbert

[Klaus (Gast)]

Hallo,

also das WW Problem ist ja schon fast einen eigenen Thread wert :-)

Im Ernst:

Ich habe ein einfaches Zeitprogram für mein WW konfiguriert.

Tagsüber normal, nachts abgesenkt. Zusätzlich ist die "ECO" Funktion
am Brenner aktiviert. Dadurch stellt sich ein Hysterese von etwa 10° 
ein.

Erwischt man nun mit seinem Badewunsch einen Zeitpunkt kurz vor der 
unteren Schwelle (Tsoll - 10°) ist es mit der WW Enmalladung nicht 
möglich, den Brenner zu starten.

Nach meinen Tests kann man die Einmalladung nur starten, wenn sich das 
WW Programm im Status "Aus" befindet. Aber vielleicht habe ich noch eine 
Konfiguration übersehen ?

Ich habe auch noch eine Datei angehängt, die unbekannte Nachrichten 
enthält.
Vielleicht hat jemand schon eine Idee, wozu die gut sind ?

Grüsse

klaus

[Norbert S. (junky-zs)]

Hallo Klaus,

habe mir Dein File angesehen und dies mit Kommentaren versehen (siehe 
Anlage).
Die meisten Telegramme stammen von der 'neuen' Regler-Generation Cxyz 
(also CW100/400 etc.).
Die Telegramm-Auswertung ist ja noch in Arbeit und wenn das Release 
soweit rund ist werden diese Telegramme auch ausgewertet.

> also das WW Problem ist ja schon fast einen eigenen Thread wert :-)
Also für mich ist dies nur eine Baustelle von vielen und meine Priorität 
liegt bei der Auswertung möglichst vieler Telegramme und auch bei der 
Steuerung der Cxyz-Regler mit dem Transceiver.

Gruß Norbert

[Stephan T. (stephant)]

Hallo Norbert,

ich habe gerade den Miniadapter mit dem Pitiny ersetzt (brauche jetzt 
bestimmt stärkere Brille nach dem Löten der SMD-Winzigkeiten :-).

Nach der Änderung der Baudrate ist die Datenerfassung sofort 
weitergelaufen.
Das hat also schon mal hervorragend geklappt.

Nun habe ich den Pitiny ja natürlich zum Steuern mit FHEM vorgesehen, 
denn lesen konnte der Mini ja auch schon. Aber ich habe den CW400 und 
eben keinen FW mehr. Etwas weiter oben hast Du geschrieben, dass der CW 
in einem späteren Release drin ist. Hast Du da schon eine Beta, die ich 
testen kann? Denn an einem CW kannst Du ja selber nichts testen, glaub 
ich. Also würde ich gern "helfen".

Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Stephan,

habe Dir gerade eine Testversion an Deine PM gesendet.

> (brauche jetzt bestimmt stärkere Brille nach dem Löten der SMD
> -Winzigkeiten :-)
Sorry, war nicht meine Absicht und nur den beengten Platzverhältnissen 
geschuldet. Aber offensichtlich sind Dir keine Bauteile auf den 
Fussboden gefallen, denn dann wird es erst interessant :-)

Gruß Norbert

[Klaus Z. (klaus65)]

Neues vom Warmwasser Klaus

Am WE war meine Frau nicht da. Also optimale Möglicjkeit um WW zu 
testen.
Habe also am Freitag Abend das WW komplett abgestellt.
Am Sa Abend war dann die Temperatur auch auf 25°C gefallen. Jetzt über 
den CW400 eine "Einmalladung" gestartet. Und siehe da, der Brenner geht 
an.

Momentan werte ich alle Telegramme aus der "HT3-Bus_Telegramme.html" 
aus.
Wärend der Einmalladung ist das "Einmalladung" bit1 in Byte 9 vom 
Kessel-Telegramm: Warmwasser (Tabelle 6: 88 00 34 ...) nicht gesetzt.

Das Paket aus : "Tabelle 17: Bedeutung A0...A7 00 34 00" kommt bei mir 
gar nicht.

Es sieht so aus, als wäre die komplette "Einmalladung" im CW400 
programmiert, der dann nichts anderes tut, als die Warmwasser 
Solltemperatur anzuheben.
Und zwar auf den Wert, der beim WW Normalbetrieb konfiguriert ist.
Das würde erklären, warum die Funktion im normalen Betrieb ohne jede 
Wirkung bleibt.
Wenn man also die von mir (und "kami")gewünschte Funktion haben möchte, 
kommt man wahrscheinlich ohne Hardwarebasteln am
Temperatursensor vom WW Kessel nicht herum.

@Norbert
Ich würde mich auch an den Tests für die neuen Regler (bei mir CW400) 
beteiligen, falls du mir die Beta zur Verfügung stellst.

[Stephan T. (stephant)]

Hallo Klaus,

wenn die Einmalladung nur über das Anheben der WW-Temp auf Normal 
funktioniert, dann müsste es doch auch wirken, wenn der Transceiver das 
abschickt. Allerdings ist ja fraglich, wie der CW400 darauf reagiert, 
wenn er die Telegramme nicht schickt, sondern empfängt. Im Zweifelsfall 
sendet der Transceiver 60 Grad und der CW 30 Grad immer schön im 
Wechsel.
Allerdings soll die Junkers-App durchaus Anpassungen am WW erlauben.
Genauso wie den Wechsel der Betriebsart auf Absenken (was man am CW gar 
nicht manuell machen kann).
Nur weiß niemand, welche Telegramme dafür nötig sind. Genau genommen 
müsste jemand, der sowohl einen Adapter (muss ja kein Transceiver sein) 
als auch einen MB-LAN(2) als auch einen CW400 hat die Kommandos der App 
mitloggen.

Hat jemand der hier Mitlesenden einen MB-LAN(2) und CW400?

Denn möglicherweise verwendet die App Telegramme, welche so nicht 
zwischen Regler und Therme ausgetauscht werden.

Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Klaus Z.,

> Wärend der Einmalladung ist das "Einmalladung" bit1 in Byte 9 vom
> Kessel-Telegramm: Warmwasser (Tabelle 6: 88 00 34 ...) nicht gesetzt.
Die Beschreibung in HT3-Bus_Telegramme.html enthält noch nicht die 
Telegramme der neuen Regler Cxyz.
Es wird sicher ein anderes Telegramm gesendet welches diesen Zustand 
anzeigt.

> Ich würde mich auch an den Tests für die neuen Regler (bei mir CW400)
> beteiligen, falls du mir die Beta zur Verfügung stellst.
Mein Ziel ist es möglichst bald ein Release bereitzustellen. Dies wird 
wohl in den nächsten Tagen soweit sein.

@Stephan T.
> Allerdings ist ja fraglich, wie der CW400 darauf reagiert, wenn er die
> Telegramme nicht schickt, sondern empfängt.
Empfänger und Ausführender der Kommandos (egal ob vom Transceiver oder 
MBLan) ist immer der Regler. Speziell bei WW-Kommandos hängt dies aber 
wohl auch noch von der Heizungs-Steuerung und den erlaubten und 
möglichen Telegrammen ab -> Thema: Heatronic3 /4i oder EMS2 - Bus.

Gruß Norbert

[Stephan T. (stephant)]

Norbert S. schrieb:
> Empfänger und Ausführender der Kommandos (egal ob vom Transceiver oder
> MBLan) ist immer der Regler.

Hallo Norbert,

 ich meinte damit, dass ich mir vorstellen könnte, dass zwischen App und 
Regler Telegramme laufen, die man zwischen Regler und Heizung niemals 
sieht. Denn die Heizung sendet ja keine Befehle an den Regler, nur 
umgedreht.
Wenn es also um Steuerbefehle für die WW-Temp geht, dann werden diese 
wohl vom Regler gesendet, aber nicht empfangen.
Oder hab ich da was falsch verstanden?

[Norbert S. (junky-zs)]

Hallo Stephan,

> ...dass zwischen App und Regler Telegramme laufen, die man zwischen
> Regler und Heizung niemals sieht.
Es gibt keine direkte physikalische Verbindung zwischen App und 
Heizungs-Regler. Für diese Umsetzung ist ja das MBLan2 als 'Gateway' 
zuständig.

> Denn die Heizung sendet ja keine Befehle an den Regler, nur umgedreht.
Ein klares Jein. Das Heizgeräte-'Steuermodul' liefert die mit Signalen 
modulierte Versorgungsspannung an die angeschlossenen Module. Dieses 
Modul ist also Master (Taktschläger für das Polling) für alle anderen 
Module am Bus. Alle 'Slave'-Module empfangen diese Spannungs- 
'Signalisierung' und bei Übereinstimmung der eigenen Geräteadresse 
senden auch diese 'Client'-Module ihre Daten kontrolliert als 
Stromänderung auf dem Bus.
Der 'Master' wandelt diese Stromänderung wieder in eine byteweise 
Spannungsänderung als Echo um, damit die Module am Bus überhaupt eine 
Signalisierung mitbekommen.
Daraus folgt: alle Module am Bus erhalten alle Telegramme am Bus und 
picken sich das raus was sie brauchen, auch das MBLan2 und die hier 
vorgestellten Adapter.

> Wenn es also um Steuerbefehle für die WW-Temp geht, dann werden diese
> wohl vom Regler gesendet, aber nicht empfangen.
Wieder ein klares Jein. Steuerbefehle werden in der Regel an den Regler 
:-) gesendet (nach obigem Muster) der die Befehle weitergibt an das 
Heizgeräte-Steuermodul.

Steuerung der WW-Erzeugung ist mit zugehörigen Befehlen möglich, jedoch 
nicht für jedes Heizungssystem der Junkers-Serien.
Möglich ist dies wohl mit den neuen Cxyz-Reglern und dem Bus EMS2.
Wenn jedoch das Heizgeräte-Steuermodul noch den Heatronic3-Bus hat, dann 
geht diese Steuerng der WW nicht.
Dies habe ich selber mit dem MBLan2 an meinem Heizungssystem 
(Heatronic3, FW100) so festgestellt.
Auch der Ersatz des FW100 mit einem Cxyz Regler bringt keine 
Verbesserung, da ja immer noch die Heatronic3-Bussoftware in der 
Heizgeräte-Steuerung werkelt!

@Stephan
Was macht eigentlich die Steuerung der Heizung mit Deinem 
ht_pitiny-Adpater und dem CW400.
Läßt sich Deine Heizung mit der zugehörigen Testsoftware steuern ?

Gruß Norbert

[Stephan T. (stephant)]

Norbert S. schrieb:
>> Wenn es also um Steuerbefehle für die WW-Temp geht, dann werden diese
>> wohl vom Regler gesendet, aber nicht empfangen.
> Wieder ein klares Jein. Steuerbefehle werden in der Regel an den Regler
> :-) gesendet (nach obigem Muster) der die Befehle weitergibt an das
> Heizgeräte-Steuermodul.

Genau das meinte ich ja. Ich hatte den Eindruck, dass Klaus auf die 
Kommunikation zwischen CW400 und HT4 schaut, um einen Befehl zur 
Einmalladung abzufangen und nachzubilden. Da aber laut seiner Aussage 
einfach nur die Solltemperatur angehoben wird, muss es dafür schlicht 
einen Befehl geben, den man HIER nicht finden kann, sondern nur zwischen 
App und Regler. Denn die App wird wohl kaum über mehrere Minuten 
kontinuierlich WW-Solltemp-Telegramme schicken.

> @Stephan
> Was macht eigentlich die Steuerung der Heizung mit Deinem
> ht_pitiny-Adpater und dem CW400.
> Läßt sich Deine Heizung mit der zugehörigen Testsoftware steuern ?

Nun, bislang recht ernüchternd. Wie ich ja schon per Mail geschrieben 
habe, hat das Ändern von Comfort- oder Eco-Temperaturen keinen Effekt, 
denn ich habe noch nicht gefunden, wo Temperaturen mit diesem Namen 
wirken sollen.
Es gibt in der Zeitsteuerung keine Comfort- oder Eco-Werte, sondern nur 
"Abgesenkt".
Was aber auf jeden Fall funktioniert, ist das Ändern der aktuellen 
Solltemperatur. Nur ist das im Sommer relativ egal und bringt erst was, 
wenn man es in der Heizperiode beim Verlassen des Hauses auf die 
Absenk-Temperatur setzen kann. Ach, und setzen auf Manual geht auch, 
wobei dies beim Verlassen des Hauses nicht sinnvoll ist, weil es ja 
nachmittags nicht wieder die Heizung anwirft.

Hast Du denn den CW400 ersteigern können? Ich frage ja ganz 
uneigennützig, denn dann kann ich auf ein FHEM-Update hoffen, was dann 
auch für den CWxxx angepasst ist :-))))

[Erwin G. (bastler_erwin)]

Hallo Norbert,

ich habe mein HT3-Adapter fertig aufgebaut (siehe angehängte Bilder) und 
möchte prüfen ob dieser auch funktioniert (elektrisch mit Mulltimeter 
und 10-15V Spannung auflegen habe ich schon getestet - geht). Am HT-BUS 
angeklemmt, die LED' RX und TX bliken.
Arduino habe ich mit dem Programm von dir "Piduino" programmiert, FUSES 
gesetzt. Dieser scheint auch zu funktionieren, bin aber nicht sicher. 
Nun ist mein Vorhaben statt RasPI ein PC anzuschließen. Ich habe deine 
Soft auf PC laufen aber es zeigt mir keine Daten. Mein Verdacht ist, 
dass ich die Konfiguration der Schnittstelle falsch eingestellt habe. 
Die serielle Schnittstelle wird zwar geöffnet aber in der Software 
tauchen keine Werte auf. Meine Frage geht das überhaupt so und wenn ja 
wie muss ich die Schnittstelle in der Software konfigurieren?

[Norbert S. (junky-zs)]

Hallo  Erwin G.,

> Dieser scheint auch zu funktionieren, bin aber nicht sicher.
Welche Werte die Fuses für einen Atmel328 haben sollen ist in der Doku 
beschrieben. Wenn die Werte so passen ist dies schon OK.

> Mein Verdacht ist, dass ich die Konfiguration der Schnittstelle falsch
> eingestellt habe.
Baudrate muss auf: 19200 für die ht_transceiver-board-Software 
eingestellt sein.
Die aktivierte USB-Schnittstelle muss im Konfigurationsfile eingestellt 
werden:
        <serialdevice>/dev/ttyUSB0</serialdevice>
        <inputtestfilepath></inputtestfilepath>
        <baudrate>19200</baudrate>

Kontrolliere auch mal mit Tool: lsusb ob denn /dev/ttyUSB0 die richtige 
USB-Schnittstelle ist.

Wenn dies dann alles so passt muss dann nach dem Einschalten des Arduino 
eine Printausgabe zu sehen sein: "Piduino 0.0.5" und die "email-adr".
Diese Ausgabe kommt natürlich nur einmal direkt nach dem Einschalten.

Gruß Norbert

[Erwin G. (bastler_erwin)]

Hallo Norbert,

vielen dank für die schnelle Antwort.

Die FUSES habeich laut Doku gesetzt (das passt).
Die Brücke zwischen Pin 8 und 9 bei Arduino geszt (Passiver modus ohne 
Senden).

In der Konfigurationsdateien HT3_db_cfg.xml habe ich folgendes stehen:

<data_interface>
 <comm_type>ASYNC</comm_type>
      <proto_type>RAW</proto_type>
      <parameter name="ASYNC">
  <serialdevice>COM2</serialdevice>
        <inputtestfilepath></inputtestfilepath>
        <baudrate>19200</baudrate>
        <config>"8N1"</config>  <!-- only 8N1 available -->
      </parameter>
      <parameter name="SOCKET">

Entschuldigung, ich habe vergessen zu erwähnen, dass ich Windows7 hab. 
Ich vermute, dass COMx an dieser stelle bei Windows richtig ist (Port 
wird ja geöffnet, die RX-LED am UART-USB adapter direck nach dem Start 
fengt an zu Blinken).

Von dir erwähnte Ausgabe kommt! Aber die ausgabe konnte ich nur in 
Arduino "serieller Monitor" sehen. An welcher Stelle im HT3_Analyser 
wird die Ausgabe eingeblendet?

Eine Sache noch: damit bei mir das Programm die COM schnittstelle öffnen 
kann musste ich die Zeile 137 in der Datei ht3_worker.py 
auskommentieren. Wenn ich die Zeile einkommentiere, dann habe ich Fehler 
" 'serial' object has no attribute 'setInterCharTimeout' "

Bis jetzt ist mir gelungen nur HT3_Analyser zu starten.
Ich muss dazu erwähnen, das ist das erste Mal wo ich mit Python zutun 
habe.
Zur Info:
Fertigungsdatum der Heizung im Service-Menü 12.2008 und des FW100 
Reglers 06.2008.

Im Anhang noch Log-Datei von RealTerm, dort ist die Ausgabe auch 
vorhanden.


Vielen dank für die Hilfe.

Gruß
Erwin

[Erwin G. (bastler_erwin)]

Hallo Norbert,

noch ein kleiner Nachtrag.
Im Anhang ist die Ausgabe von dem Fehler nach dem Start von HT3_Analyser 
Software.
Kannst du erklären was da passiert?


Vielen Dank.

Gruß
Erwin

[Norbert S. (junky-zs)]

Hallo Erwin,

> Kannst du erklären was da passiert?
Die Fehlermeldung besagt, das der Typ der seriellen Schnittstelle nicht 
zu 'seriellPosix' passt und deshalb der Thread beendet wird.
Gründe sind hauptsächlich die vielen kleinen Unterschiede zwischen 
Windows und Linux.
Du kannst zwar dieses Python-Programm unter Windows aufrufen, jedoch 
führen eben diese Unterschiede zu Fehlern.
Ich muss gestehen das diese Anpassung an Windows noch eine offene 
Baustelle ist die ich noch nicht gesichert geschweige denn geschlossen 
habe.
Auch wenn es Dir gelingt diesen einen Stolperstein zu beseitigen so 
kommen gleich weitere hinzu.
Ich denke da z.B. an die Datenbanken sqlite und rrdtool und einfach auch 
an Pfadnamen. Auch dieses wird so unter Windows nicht 'Out off the Box' 
laufen.
Es wird noch dauern bis ich die Applikationen unter Windows laufen habe.

Sind bei Dir Linux-Erfahrungen vorhanden?
Falls ja kann man ja auch unter Windows in einer virtuellen Maschine 
(VirtualBox etc.) Linux installieren und die Applikationen laufen 
lassen.
Du kannst dann trotzdem mit einem Browser von Windows aus auf die 
grafischen Ausgaben zugreifen.

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo Erwin,

noch ein Hinweis:
Falls Du keine Möglichkeit findest bei Dir Linux zu installieren bzw. zu 
nutzen so benutze als Zwischenlösung die Software am Anfang des Threads:
 Beitrag "Re: Heatronic 3 Adapter und Analysesoftware"

Das File: HT3_CSW_analyser.py kannst Du noch für Windows auf die 
COM-Schnittstelle anpassen und den Analyser laufen lassen.

Du musst dazu in der Fkt: def openport(): den richtigen Com-Port 
eintragen.
z.B.:
    try:
        port = serial.Serial("COM2", 19200 )
    except:

Gruß Norbert

[Erwin G. (bastler_erwin)]

Hallo Norbert,


> Falls Du keine Möglichkeit findest bei Dir Linux zu installieren bzw. zu
> nutzen so benutze als Zwischenlösung die Software am Anfang des Threads:
>  Beitrag "Re: Heatronic 3 Adapter und Analysesoftware"
>
> Das File: HT3_CSW_analyser.py kannst Du noch für Windows auf die
> COM-Schnittstelle anpassen und den Analyser laufen lassen.

ich bin erst jetzt duzu gekommen dein Vorschlag auszuprobieren und habe 
erst mal mit Windows probiert, es funktioniert!!!Im Anhang habe ich 
screenshot angehängt.
Vielen dank für die Unterstützung.

>Es wird noch dauern bis ich die Applikationen unter Windows laufen habe.
Ich finde es ist nicht schlimm, ich habe mit Arduino unter Windows 
angefangen zu programmieren und so bin ich dabei geblieben. Ich bin froh 
das es eine abgespecke Variante von HT3_Analyser gab, diese reicht 
vollkomen. Letzendlich ginge es mir dadrum den Adapter auf Funktion zu 
prüfen.

>Sind bei Dir Linux-Erfahrungen vorhanden?
>Falls ja kann man ja auch unter Windows in einer virtuellen Maschine
>(VirtualBox etc.) Linux installieren und die Applikationen laufen
>lassen.
>Du kannst dann trotzdem mit einem Browser von Windows aus auf die
>grafischen Ausgaben zugreifen.

Ich habe zwar keine großartige Kentnisse in Linux, aber nach dem ich 
festgestellt habe, dass mein Adapter funktioniert würde ich diesen 
Schritt machen und unter Linux die Software ausprobieren.
Ich habe einen alten Notebook mit Debian drauf und ich habe zweiten mit 
Windows und VM-Palyer mit Ubuntu. Ich hatte mal unter linux (Debian) ein 
C Programm geschrieben und ich denke, dass ich mit Python unter Linux 
auch hinkriege.

Mein Ziel ist ein kompaktes Adapter zu bauen inklusive Kontroller (eine 
Platine und so klein wie möglich), der mir über WLAN, Ethernet oder 
Modbus (evtl. Prifubus ode CAN noch nicht genau entschieden) gebündelt 
Daten liefert (gemeint alle Daten sammeln und mit wenigen 
Paketen/Telegrammen an Zielsystem übertragen/bereitstellen).
Ich habe gelesen, dass du auch ähnlichen Plan hast (Stichwort ESP8266).
Ich habe so ein Modul rum ligen und würde auch ausprobieren. Das wird 
aber bei mir nicht so schnell passieren.

Vielen dank nochmal für die Unterstützung.
Ich schreib, wenn mit Linux weiter gekommen bin.

Schönes Wochenende.

Gruß
Erwin

[Erwin G. (bastler_erwin)]

Hallo Norbert,

ich bin mit dem Test etwas weiter gekommen. Ich habe Ubuntu installiert 
und deine Software zum laufen gebracht (auch mit proxi, Datenbak und 
HTML, siehe screenshot1, HT3_Heizung und HT3_Warmwasser).
Was noch unklar ist, ob ich die Heizung steuern kann.
Ich habe es probiert, aber erfolglos.

Du hast mal geschrieben dass:
> Für die Steuerung der Heizung mit einem 'MBLan' ist minimal das
> Fertigungsdatum 'September 2008' := FD889 erforderlich.
> Der Regler 'FR50' kann nicht mit dem MBLan gesteuert werden.

> Für die Steuerung der Heizung mit 'Netcom50', 'Netcom100' oder
> 'ht_transceiver (ht_pitiny/ht_piduino)' ist minimal das Fertigungsdatum
> 'November 2009' := FD991 erforderlich.

 meine heizung ist:
>Fertigungsdatum der Heizung im Service-Menü 12.2008 und des FW100
>Reglers 06.2008.

Heißt das, ich kann nicht mit 'ht_transceiver' steuern?

Ich habe eine Service- und Bedieneranleitung für Netcom100 auf der 
Junkers seite gefunden, die gibt's schon seit 08.2008 (siehe Anhang). 
Geht es evtl. doch?

Noch eine Sache:
Ich habe zwei Telegramme die mit Fragezeichen (siehe screeenshot2 und 
3).
Bei dem Telegramm 88 00 33 habe ich ein wert entschlüsselt, es ist die 
Anzeige Temperatur-Soll für Warmwasser (siebte Stelle).

Sind diese Telegramme unbekannt?

[Erwin G. (bastler_erwin)]

Noch zur info:

Ich habe die Ansteuerung mit dem Befehl 'ht_netclient.py -t 15.5 -tmod 
frost -hc 1' probiert. Bei der Abfrage, die direkt danach kommt habe ich 
mit 'y' und 'n' probiert (ohne erfolg). Auch den Befehl 'ht_netclient.py 
-tc1 21.5 -hc 1' probiert.

Gruß
Erwin

[Norbert S. (junky-zs)]

Hallo Erwin,

> meine heizung ist:
>> Fertigungsdatum der Heizung im Service-Menü 12.2008 und des FW100
>>Reglers 06.2008.
Das Fertigungsdatum Deines Reglers FW100 ist zu alt (FD886 <- steht auf 
der Innenseite der Frontklappe).
Deshalb kannst Du Deine Heizung nicht steuern, da der Regler die 
Kommandos umsetzen soll und in Deinem Fall dies nicht macht.
Das Fertigungsdatum Deiner Heizung ist in Ordnung und für eine Steuerung 
geeignet.
Vielleicht kannst Du ja einen gebrauchten Regler in der Bucht erwerben 
der das passende Fertigungsdatum hat.
Ich selber habe dort vor Kurzem eine Fernbedienung FB100 erworben und 
damit auch neue Erkenntnisse erhalten.

> ... habe die Ansteuerung mit dem Befehl 'ht_netclient.py probiert. Bei
> der Abfrage, die direkt danach kommt habe ich mit 'y' und 'n'probiert
> (ohne erfolg).
Hinweis: Die Antwort mit 'y' ist nur für Regler der Serie Cxyz 
vorgesehen und dies kann ohnehin für Fxyz-Regler nicht funktionieren. 
Deshalb bei Fxyz-Reglern dort immer 'n' eingeben.

> Bei dem Telegramm 88 00 33 habe ich ein wert entschlüsselt, es ist die
> Anzeige Temperatur-Soll für Warmwasser (siebte Stelle).
> Sind diese Telegramme unbekannt?
Die Dekodierung ist bisher im Release nicht enthalten. Die bringe ich 
mit ein.
Deine Beobachtung hilft da ungemein weiter. Vielleicht findest Du noch 
weitere Telegramme bzw. Werte die zu Dekodieren sind!

Gruß Norbert

[Erwin G. (bastler_erwin)]

Hallo Norbert,

vielen Dank für die Infos.
Ich muss jetzt überlegen, ob ich einen anderen Regler zulege oder nicht.
Der FW100 kostet 149€, ist nicht gerade billig.

Ich habe gesehen dass es noch den FW120 gibt und CW100(soll Nachfolger 
sein).
Wenn ich zu der Entscheidung komme für den Regler Geld auszugeben, ist 
es evtl. besser ein FW120 oder den CW100 zu holen? (Preisunterschied 
30€) Was würdest du empfehlen?
Gib es da steuerungstechnisch Unterschiede oder sind die aus dieser 
Sicht gleich? Ist der CW100 überhaupt kompatibel zu ZSBR/ZSBE ?
So wie das Gehäuse aussieht, passt es nicht mehr in das Heizgerät, aber 
evtl. an die Wand?

Die beiden Telegramme die ich entdeckt habe, werde ich bei Gelegenheit 
weiter entziffern und melde sobald ich was neues habe.

Vielen Dank für die Hilfe.

Gruß
Erwin

[Stephan T. (stephant)]

Hallo Erwin,

laut Junkers ist der CWx00 rückwärtskompatibel "zu Heizgeräten mit 
Zwei-Draht-Bus und löst die Fx-Reglerfamilie ab". Sollte also gehen.

Ich würde trotzdem zum FW120 raten, da Junkers mit dem CW die 
Kommen/Gehen-Taste wegrationalisiert hat und somit alle Steuerung 
(bislang) nur auf den Heizteil wirkt, aber weder Zirkulation noch 
Warmwasser beeinflusst.

Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Erwin,

ich kann Dir so wie Stephan auch nur zu einem FW100/FW120 raten.
Den CW100 würde ich Dir auch nicht empfehlen, der kann ja noch weniger 
als der FW100 und ist auch noch teurer.
Ich sehe da gerade ein günstiges Angebot für einen FW100 (ohne 
Aussenfühler, den hast Du ja schon).
Wichtig ist dabei natürlich das Fertigungsdatum des Reglers.
Ansonsten gibt es keine grossen Unterschiede zwischen FW120 und FW100, 
ausser das beim FW120 weniger Programme möglich sind.
Wenn Du also mehr Schaltzeiten brauchst würde ich den FW100 nehmen.

Gruß Norbert

[Erwin G. (bastler_erwin)]

Hallo Stephan,
Hallo Norbert,

Vielen dank für eure Infos.
Dann werde ich wohl für eins von beiden (FW100/FW120) entscheiden.

@Norbert.
Ich habe die Anleitungen beider Geräte (FW100/FW120) verglichen in der 
Hoffnung zu finden um welche Unterschiede bei Zeit-Programmen es sich 
handelt, konnte aber nichts finden. Laut Dokumentation sind die wohl 
gleich. Weist du noch, welche Zeit-Programme fehlen bei FW120?

Ich habe mir das FW100 etwas genauer angeschaut. Dieser hat im unteren 
Bereich einen 4-poligen Anschluss, der an eine serielle Schnittstelle 
erinnert. Kann man, oder hat jemand schon versucht einfach die Firmware 
zu aktualisieren, statt neues zu kaufen? Wenn die Hardware von FW100 und 
FW120 gleich ist, könne man aus FW100 ein FW120 machen und umgekehrt 
(theoretisch).

Gruß
Erwin

[Stephan T. (stephant)]

Hallo Erwin,

eine Firmware erhält bei Junkers nicht einmal der eigene 
Werkskundendienst. Auch die tauschen immer komplette Geräte/Platinen 
wenn es eine andere Software gibt. Und werden dann nicht einmal 
informiert, was sich denn mit der neuen Software geändert hat.

Also selbst wenn es technisch möglich wäre: Wo willst Du die Firmware 
herbekommen?

Gruß,
Stephan

[Norbert S. (junky-zs)]

Hallo Erwin,

> Ich habe die Anleitungen beider Geräte (FW100/FW120) verglichen in der
> Hoffnung zu finden um welche Unterschiede bei Zeit-Programmen es sich
> handelt, konnte aber nichts finden.
Ja, ich habe da im Nachhinein auch keinen Unterschied mehr in der Doku 
finden können. Hatte irgend etwas mit weniger Umschaltzeiten beim 
Heizprogramm (weniger als 6) im Hinterkopf aber dem ist wohl doch nicht 
so. Also passt auch der FW120.
Auf jeden Fall sind FW100/FW120 die bessere Wahl gegenüber dem CW100 
(falls Du doch einmal an eine Solar-Erweiterung denkst).

> Kann man, oder hat jemand schon versucht einfach die Firmware zu
> aktualisieren,...
Da kann ich Stephan nur Recht geben und aus eigener Erfahrung kann ich 
sagen das dies aussichtslos ist, zumindest ein Update durch Junkers 
selber.
Technisch ist dies natürlich machbar aber 'man' will ja keine 
'Altlasten' betreuen müssen :-(
Vielleicht hat aber doch jemand einen Zugriff auf die interne Software 
der Regler erreicht und kennt sich da besser aus.

Gruß Norbert

[Erwin G. (bastler_erwin)]

Hallo Stephan,
Hallo Norbert,

Vielen Dank für die Infos.

Mit dem Firmwareupdate dachte ich eher an eine Kopie der Firmware von 
einem Gerät und diese dann zu anderen Gerät übertragen. Ist aber jetzt 
nicht mehr das Ziel.
Ich habe mir ein FW120 geholt von Bj-2015.
Das Steuern der Heizung geht jetzt, aber nicht alle Befehle werden 
akzeptiert.
Ich kann den Betriebsmodus wechseln mit "-b" und sonst nichts.
Auf dem Display erscheint auch die Netcom-Anzeige.
Liegt es an FW120?

@Norbert:
>Ja, ich habe da im Nachhinein auch keinen Unterschied mehr in der Doku
>finden können. Hatte irgend etwas mit weniger Umschaltzeiten beim
>Heizprogramm (weniger als 6) im Hinterkopf aber dem ist wohl doch nicht
>so.
Das was du im Hinterkopf hast, ist absolut richtig. Die Menüführung 
wurde in FW120 stark vereinfacht. Viele Menüpunkte sind ganz weggefallen 
und es gibt tatsächlich weniger Programme (bei FW100 A, B, C mit je 6 
Zeiten und bei FW120 nur ein Programm mit je 6 Zeiten). Zusätzlich sind 
die vorbelegte Programme wie "Vormittags, Nachmittags, Frühschicht, 
Spätschicht" etc. weggefallen.

Für mich war das akzeptabel, wenn aber jemand vor ähnlicher Entscheidung 
steht sollte das abwägen.


Gurß
Erwin

[Tim M. (timmmey)]

Hallo zusammen,

nachdem ich einige grundlegende Probleme beseitigt habe, blinken nun 
auch die LEDs (Pi1B+) wild. Leider ist mein ht_logger.log komplett voll 
mit einer Fehlermeldung. Ein Update der pyserial-Lib hat leider auch 
nichts gebracht. Irgendwelche Ideen?



08.10.2016 19:13:11 INFO: ht3_cworker.run(); Start 
----------------------
08.10.2016 19:13:11 INFO: ht3_cworker.run();  Loglevel      :DEBUG
08.10.2016 19:13:11 INFO: ht3_cworker.run();  Datainput-Mode:ASYNC
08.10.2016 19:13:11 INFO: ht3_cworker.run();   Baudrate     :19200
08.10.2016 19:13:11 INFO: ht3_cworker.run();   Configuration:"8N1"
08.10.2016 19:13:11 INFO: ht3_cworker();sqlite-database already 
available
08.10.2016 19:13:12 INFO: 
cdb_rrdtool.createdb_rrdtool();INFO;Database:'./var/databases/HT3_db_rrd 
'  already created
08.10.2016 19:13:17 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:13:26 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:13:38 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:13:40 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:13:57 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:13:59 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:14:08 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:14:40 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:14:55 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:15:09 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:15:12 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:15:35 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:15:45 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:15:45 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:15:53 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:16:00 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:16:09 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:16:15 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:16:16 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:16:17 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:16:18 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:16:19 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:16:20 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:16:24 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:16:24 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:16:31 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:16:39 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:16:39 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:16:44 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:16:49 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>
08.10.2016 19:16:56 CRITICAL: cht3_dispatch.dispatcher();Error;<read 
failed: device reports readiness to read but returned no data (device 
disconnected or multiple access on port?)>


lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 8.0 (jessie)
Release:        8.0
Codename:       jessie


 uname -a
Linux raspberrypi 4.4.23+ #913 Tue Oct 4 13:56:56 BST 2016 armv6l 
GNU/Linux


cat /proc/cmdline
dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 
bcm2708.boardrev=0xd bcm2708.serial=0x4215e460 
smsc95xx.macaddr=B8:27:EB:15:E4:60 bcm2708_fb.fbswap=1 
bcm2708.uart_clock=48000000 vc_mem.mem_base=0x1ec00000 
vc_mem.mem_size=0x20000000  dwc_otg.lpm_enable=0  root=/dev/mmcblk0p2 
rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

stty -F /dev/ttyAMA0
speed 57600 baud; line = 0;
min = 0; time = 0;
ignbrk -brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke


systemctl status [e-mail]
● [e-mail] - Serial Getty on ttyAMA0
   Loaded: loaded (/lib/systemd/system/serial-getty@.service; disabled)
   Active: inactive (dead)
     Docs: man:agetty(8)
           man:systemd-getty-generator(8)
           http://0pointer.de/blog/projects/serial-console.html

[Tim M. (timmmey)]

Tim M. schrieb:
> Hallo zusammen,
>
> nachdem ich einige grundlegende Probleme beseitigt habe, blinken nun
> auch die LEDs (Pi1B+) wild. Leider ist mein ht_logger.log komplett voll
> mit einer Fehlermeldung. Ein Update der pyserial-Lib hat leider auch
> nichts gebracht. Irgendwelche Ideen?
>

Hab den Fehler gefunden. FHEM hat den Port blockiert. Gefunden mittels
>> lsof |grep AMA
falls jemand ein ähnliches Problem haben sollte

[Norbert S. (junky-zs)]

Hallo  Tim,
> FHEM hat den Port blockiert
Hast Du FHEM jetzt komplett deaktiviert oder eine Anpassung im 
Konfigurationsfile: fhem.cfg gemacht?

Gruß Norbert

[Klaus Z. (klaus65)]

Hallo Norbert,

vielen Dank für die neue SW/docu. Bei dem Sch... Wetter werde ich am WE 
alles ausprobieren.

VG
Klaus

[Markus B. (spektrum)]

Hallo Norbert, Hallo Forum,

vielen Dank für das tolle Projekt!

Ich habe den ht_piduino aufgebaut. Die Inbetriebnahme verlief 
problemlos. Das Lesen vom Bus funktioniert mit der HT3 Software. Die 
Diagramme werden wie erwartet dargestellt. Klasse!

Was mir nicht gelingen will, ist die Heizungssteuerung mittels 
ht_netclient. Wenn ich ein netclient Kommando absende, kann ich am TP-TX 
Testpunkt feststellen, dass Daten gesendet werden. Der FW100 reagiert 
jedoch nicht. Die log-Files erscheinen mir unauffällig. (s.u. unten)

Könnt ihr mir zunächst etwas zur Bedeutung der beiden LEDs sagen:

LED D9 (grün) flackert im Takt der ankommenden Daten, bzw. blinkt 
langsam, wenn keine Daten ankommen. Denke das ist ein RX Indikator. 
Okay.

Was ist die Bedeutung der roten D8 LED? TX? Sie flackert jedenfalls auch 
wenn ich keine Daten sende. Soll das so sein?

Wenn ich netclient ausführe, hat man den Eindruck, dass sich die 
Intensität bei beiden LEDs verstärkt.

Mir ist ausserdem aufgefallen, dass der ATmega periodisch Daten sendet. 
So ca. alle 50ms, auch wenn kein netclient cmd ausgeführt wird. Ist das 
korrekt?

Kann ich über RX die gesendeten TX Daten zurücklesen, um zu prüfen, dass 
der TX Teil der Schaltung nach dem Optokoppler korrekt funktioniert?

Danke und Gruss
Markus


./ht_netclient.py -b auto

ht_proxy.log

12.12.2016 20:35:57 INFO: Client-ID:3; ('192.168.6.15', 42898) connected
12.12.2016 20:35:57 INFO: Server   :('0.0.0.0', 8088)
12.12.2016 20:35:57 INFO: Client-ID:3; register(); got devicetype:MODEM
12.12.2016 20:35:57 INFO: csocketsendThread(); socket.send thread start
12.12.2016 20:35:57 INFO: Client-ID:3; added; number of clients:1
12.12.2016 20:35:57 INFO: Client-ID:3; cht_RequestHandler(); 
socket.receive thread start
12.12.2016 20:35:57 DEBUG: Client-ID:3; 
recv:b'#\t!S\x11\x10\xff\x0e\x00e\x04'
12.12.2016 20:36:00 DEBUG: Client-ID:3; 
recv:b'#\t!S\x11\x18\xff\x0e\x00e\x04'
12.12.2016 20:36:03 DEBUG: Client-ID:3; 
recv:b'#\t!S\x11\x10\xff\x04\x00y\x04'
12.12.2016 20:36:07 DEBUG: Client-ID:3; 
recv:b'#\t!S\x11\x18\xff\x04\x00y\x04'
12.12.2016 20:36:10 INFO: Client-ID:3; ('192.168.6.15', 42898) 
disconnected
12.12.2016 20:36:10 INFO: Client-ID:3; removed; number of clients:0

[Markus B. (spektrum)]

Korrektur:

das ht_proxy.log sieht so aus wie unten beigefügt:

Gibt die letzte Zeile des Logs einen Hinweis, warume es nicht 
funktioniert?
"13.12.2016 06:38:07 INFO: Client-ID:11;cportwrite();couldn't read from 
queue"


ht_proxy.log: ( ./ht_netclient.py -b auto )

13.12.2016 06:37:55 INFO: Client-ID:11; ('192.168.6.15', 49104) 
connected
13.12.2016 06:37:55 INFO: Server   :('0.0.0.0', 8088)
13.12.2016 06:37:55 INFO: Client-ID:11; register(); got devicetype:MODEM
13.12.2016 06:37:55 INFO: csocketsendThread(); socket.send thread start
13.12.2016 06:37:55 INFO: Client-ID:11; added; number of clients:2
13.12.2016 06:37:55 INFO: Client-ID:11; cht_RequestHandler(); 
socket.receive thread start
13.12.2016 06:37:55 DEBUG: Client-ID:11; 
recv:b'#\t!S\x11\x10\xff\x0e\x00e\x04'
13.12.2016 06:37:55 INFO: Client-ID:9;cportwrite();couldn't read from 
queue
13.12.2016 06:37:55 DEBUG: Client-ID:11;cportwrite();value:23
13.12.2016 06:37:55 DEBUG: Client-ID:11;cportwrite();value:21
13.12.2016 06:37:55 DEBUG: Client-ID:11;cportwrite();value:53
13.12.2016 06:37:55 DEBUG: Client-ID:11;cportwrite();value:11
13.12.2016 06:37:55 DEBUG: Client-ID:11;cportwrite();value:06
13.12.2016 06:37:55 DEBUG: Client-ID:11;cportwrite();value:10
13.12.2016 06:37:55 DEBUG: Client-ID:11;cportwrite();value:ff
13.12.2016 06:37:55 DEBUG: Client-ID:11;cportwrite();value:0e
13.12.2016 06:37:55 DEBUG: Client-ID:11;cportwrite();value:00
13.12.2016 06:37:55 DEBUG: Client-ID:11;cportwrite();value:65
13.12.2016 06:37:55 DEBUG: Client-ID:11;cportwrite();value:04
13.12.2016 06:37:55 DEBUG: Client-ID:11;cportwrite();value:3a
13.12.2016 06:37:58 DEBUG: Client-ID:11; 
recv:b'#\t!S\x11\x18\xff\x0e\x00e\x04'
13.12.2016 06:37:58 DEBUG: Client-ID:11;cportwrite();value:23
13.12.2016 06:37:58 DEBUG: Client-ID:11;cportwrite();value:21
13.12.2016 06:37:58 DEBUG: Client-ID:11;cportwrite();value:53
13.12.2016 06:37:58 DEBUG: Client-ID:11;cportwrite();value:11
13.12.2016 06:37:58 DEBUG: Client-ID:11;cportwrite();value:06
13.12.2016 06:37:58 DEBUG: Client-ID:11;cportwrite();value:18
13.12.2016 06:37:58 DEBUG: Client-ID:11;cportwrite();value:ff
13.12.2016 06:37:58 DEBUG: Client-ID:11;cportwrite();value:0e
13.12.2016 06:37:58 DEBUG: Client-ID:11;cportwrite();value:00
13.12.2016 06:37:58 DEBUG: Client-ID:11;cportwrite();value:65
13.12.2016 06:37:58 DEBUG: Client-ID:11;cportwrite();value:04
13.12.2016 06:37:58 DEBUG: Client-ID:11;cportwrite();value:23
13.12.2016 06:38:01 DEBUG: Client-ID:11; 
recv:b'#\t!S\x11\x10\xff\x04\x00y\x04'
13.12.2016 06:38:01 DEBUG: Client-ID:11;cportwrite();value:23
13.12.2016 06:38:01 DEBUG: Client-ID:11;cportwrite();value:21
13.12.2016 06:38:01 DEBUG: Client-ID:11;cportwrite();value:53
13.12.2016 06:38:01 DEBUG: Client-ID:11;cportwrite();value:11
13.12.2016 06:38:01 DEBUG: Client-ID:11;cportwrite();value:06
13.12.2016 06:38:01 DEBUG: Client-ID:11;cportwrite();value:10
13.12.2016 06:38:01 DEBUG: Client-ID:11;cportwrite();value:ff
13.12.2016 06:38:01 DEBUG: Client-ID:11;cportwrite();value:04
13.12.2016 06:38:01 DEBUG: Client-ID:11;cportwrite();value:00
13.12.2016 06:38:01 DEBUG: Client-ID:11;cportwrite();value:79
13.12.2016 06:38:01 DEBUG: Client-ID:11;cportwrite();value:04
13.12.2016 06:38:01 DEBUG: Client-ID:11;cportwrite();value:52
13.12.2016 06:38:04 DEBUG: Client-ID:11; 
recv:b'#\t!S\x11\x18\xff\x04\x00y\x04'
13.12.2016 06:38:04 DEBUG: Client-ID:11;cportwrite();value:23
13.12.2016 06:38:04 DEBUG: Client-ID:11;cportwrite();value:21
13.12.2016 06:38:04 DEBUG: Client-ID:11;cportwrite();value:53
13.12.2016 06:38:04 DEBUG: Client-ID:11;cportwrite();value:11
13.12.2016 06:38:04 DEBUG: Client-ID:11;cportwrite();value:06
13.12.2016 06:38:04 DEBUG: Client-ID:11;cportwrite();value:18
13.12.2016 06:38:04 DEBUG: Client-ID:11;cportwrite();value:ff
13.12.2016 06:38:04 DEBUG: Client-ID:11;cportwrite();value:04
13.12.2016 06:38:04 DEBUG: Client-ID:11;cportwrite();value:00
13.12.2016 06:38:04 DEBUG: Client-ID:11;cportwrite();value:79
13.12.2016 06:38:04 DEBUG: Client-ID:11;cportwrite();value:04
13.12.2016 06:38:04 DEBUG: Client-ID:11;cportwrite();value:4b
13.12.2016 06:38:07 INFO: Client-ID:11; ('192.168.6.15', 49104) 
disconnected
13.12.2016 06:38:07 INFO: Client-ID:11; removed; number of clients:1
13.12.2016 06:38:07 CRITICAL: csocketsendThread();Error on socket.send
13.12.2016 06:38:07 INFO: Client-ID:11;cportwrite();couldn't read from 
queue

[Pieter O. (bdp)]

Hello,

I have a Junkers heater (ZBS 14/210 S 3 MA 23 Solar S) with IPM2 (2 
mixed circuits), ISM2 solar module, FB100 and FW200.
I can change values (using Nobert's great software) for mode (auto - 
heizen - sparen - frost) and temperature for circuit 1 (FB 100), but for 
circuit 2 I'm able to change temperature (e.g. ht_netclient.py -t 25.5 
-hc 2), but not the mode.
Does someone has a simular problem?

[Norbert S. (junky-zs)]

Hallo Markus,

Bedeutung der LED's:
> LED D9 (grün) flackert im Takt der ankommenden Daten, bzw. blinkt
>langsam, wenn keine Daten ankommen. Denke das ist ein RX Indikator.
> Okay.
Ja korrekt.

>Was ist die Bedeutung der roten D8 LED? TX? Sie flackert jedenfalls auch
>wenn ich keine Daten sende. Soll das so sein?
Die Heizungssteuerung im Heizgerät (Bus-Master) fragt zyklische einen 
bestimmten Geräteadressbereich ab (Polling) und angeschlossene Module 
(Bus-Clients) antworten direkt dem Master sobald ihre eigene 
Geräteadresse angesprochen wurde. Dann blitzt die ROTE LED auf. Das ist 
also korrekt.

Diese LED wird jedoch per Software von einem Port gesteuert, ob der 
Sendetransistor hinter dem Optokoppler tatsächlich diesen Burst gesendet 
hatte sieht man daran allerdings nicht. Da Du jedoch am Testpunkt HT-TX 
dieses Signal sehen kannst ist der Burst auch vorhanden.

>Kann ich über RX die gesendeten TX Daten zurücklesen, um zu prüfen, dass
>der TX Teil der Schaltung nach dem Optokoppler korrekt funktioniert?
Nein leider nicht, während des Senden ist der Transceiver auf seiner 
RX-Leitung blind.

>Gibt die letzte Zeile des Logs einen Hinweis, warume es nicht
>funktioniert?
Dies ist nur eine INFO und nicht kritisch, jedoch davor steht eine Zeile 
mit 'CRITICAL: csocketsendThread();Error on socket.send'.
Dies sollte so nicht sein, jedoch werden ja die Sequenzen (Bytes) vom 
ht_proxy.server zum Transceiver gesendet (siehe Logfile).

Die Bytes zum Transceiver sind korrekt, jedoch sendest Du 'nur' den 
Betriebsmode:Auto. Daher versuche mal auch die anderen Modi: Frost, 
Sparen und Heizen und setze mal verschiedene Temperaturen.
Kontrolliere alles mit dem HT3_Analyser, dort werden die Änderungen im 
Heizkreis1 angezeigt (siehe Bild).
Du nutzt sicher den aktuellen Softwarestand?

Gruß Norbert

[Markus B. (spektrum)]

Hallo Norbert,

danke für die Erläuterung bzgl. der LEDs. Macht Sinn :-)

Ja, ich verwende die aktuelle SW (git clone)
Andere Modi/Temp funktionieren leider auch nicht.

Der Fehler liegt dann wohl in der HW meines TX Pfades.
Ein Acknowledge vom FW100 scheint es ja nicht zu geben, d.h. die SW kann 
nicht feststellen, ob die Daten am FW100 wirklich angekommen sind.

Muss ich vorab an der Heizung oder dem FW100 irgendetwas konfigurieren?

Wenn ich mir eine zweite RX Schaltung aufbaue, kann ich dann mit dem 
HT3_Analyser und einem 2. Raspi die Kommunikation zwischen ht_piduino 
und FW100 monitoren? Werden alle Busdaten im HT3_Analyser transparent 
dargestellt? Sehe ich ausserdem das Polling und die response ebenfalls 
im hexdump?

Grüße
Markus

[Norbert S. (junky-zs)]

Hallo Markus,

> Muss ich vorab an der Heizung oder dem FW100 irgendetwas konfigurieren?
Nein, vielleicht den Betriebsschalter im FW100 auf 'Auto' stellen aber 
sonst nichts.

Kontrolliere mal das Fertigungsdatum Deines FW100 Reglers. Die steht im 
Gerät auf der Innenseite der geöffneten Geräteklappe. Irgend was mit 
FDxyz.
Vergleiche diese Angabe mit der Tabelle siehe:
  Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"
Details stehen da auch.

>Wenn ich mir eine zweite RX Schaltung aufbaue, kann ich dann mit dem
>HT3_Analyser und einem 2. Raspi die Kommunikation zwischen ht_piduino
>und FW100 monitoren?
Ja das geht, der 2. Adapter muss jedoch eine andere Geräteadresse 
erhalten als der Erste da beide ja am gleichen Heizungsbus hängen. Wie 
das geht steht in der Doku.

>Werden alle Busdaten im HT3_Analyser transparent
>dargestellt? Sehe ich ausserdem das Polling und die response ebenfalls
>im hexdump?
Im aktuellen SW-Release werden alle Bus-Daten angezeigt sofern eine 
gültige CRC gefunden wurde. Die Polling-Daten werden jedoch nicht 
angezeigt.
Um diese zu erhalten ist ein Binäres Logging ('ht_binlogclient.py') und 
anschliessende Auswertung erforderlich

Gruß Norbert

[Markus B. (spektrum)]

Hallo Norbert,

Mein FW100 hat FD 17.12.2007. Hmm, dann bin ich da wohl draussen. 
Schade.
Danke für den Hinweis.

Hat sich schon jemand Gedanken gemacht, ob ht_piduino + raspi anstelle 
des FW100 mit der Heizung kommunizieren können? Geht das technisch und 
liegen die Protokollinformationen irgendwo vor? Wäre für Hinweise 
dankbar.

Danke Norbert!

LG Markus

[Ralf (Gast)]

Hi Norbert und Alle,


Ich wollte mal fragen, ob es jemanden schon einmal unter gekommen ist, 
dass die MicroSD Karte in den Readonly Modus übergeht ? Ich würde jetzt 
vermuten, dass zu viele Lese/Schreibzugriffe zusammengekommen sind. 
Soweit wie ich es jetzt lesen konnte, gibt es dahingehend eine endliche 
Lebenszeit für SD Karten ??


Danke und schonmal guten Rutsch
Ralf

[Stephan (Gast)]

Hallo alle,

über dieses Thema habe ich auch bereits nachgedacht, denn SD-Karten 
vertragen ja nur rund 10k Schreibzugriffe auf eine Zelle. Nun sorgt der 
Kontroller ja dafür dass nicht immer nur dieselbe Zelle beschrieben 
wird, aber da von der Heizung oft im Sekundentakt eine oder mehrere 
Nachrichten kommt/kommen, kann es doch irgendwann mal kritisch werden, 
besonders bei kleineren Karten. Denn da stehen weniger Zellen zum 
Verteilen zur Verfügung.
Bei SSDs gibt es Tools, die die Menge der geschriebenen Daten lesen 
können sowie den Laufwerkszustand, aber bei SD-Karten?

Gruß,
Stephan

[Stefan B. (sbiermann)]

Hallo,
die Problematik mit den Schreibzugriffen sehe ich nicht. Wenn man 10.000 
Schreibzugriffe als Maximum annimmt und am Tag bei einer 1 GB SD Karte 1 
GB Daten schreibt, bleiben 10.000 Tage (etwa 27 Jahre) bis das Teil 
einen Abflug macht siehe 
https://www.usenix.org/legacy/event/fast10/tech/full_papers/boboila.pdf.

Der HT Bus ist zwar sehr gesprächig, aber das der 1 GB Daten am Tag 
produziert glaube ich nicht. Wenn eine SD Karte den Abflug macht, dann 
liegt das in der Regel nicht an zu vielen Schreibzugriffen sondern eher 
an anderen Problemen z.B. schlechte Herstellungsprozesse.

Ich habe eine SD Karte die nun fast 3 Jahre ihren Dienst im Pi tut ohne 
irgend welche Mucken und im Handy hielt eine MicroSD Karte gerade mal 2 
Monate bevor die defekt ging. Die ging aber sicherlich nicht durch 
zuviel Schreibzugriffe kaputt. Ich glaube es ist etwas Glück dabei ob 
man eine gute oder schlechte SD Karte bekommt.

Viele Grüße
Stefan

[Markus (Gast)]

Hallo,

ich habe auch schon 2 Karten (eigentlich eine Karte und ein USB-Stick) 
ruiniert. Ich hoffe es lag nicht daran, das ich vergessen habe SWAP zu 
deaktivieren ... Jedes mal ca. 2-4 Monate.

Die nächste mounte ich read only (/etc/fstab ... root ... ro), und 
mounte eine Ramdisk, oder ein NFS-Laufwerk für die Datenbank.

Im Falle von Ram-Disk braucht man dann einen Backup-Job.

Kann man nicht einfach sqlite gegen mysql/postgres austauschen?

Grüße

[stenny (Gast)]

Hallo


Da ich eine Junkers ZSB 24-4 C23 auslesen und Steuern möchte bin ich 
hier über das fhem Forum gelandet.
Da ich keine Möglichkeit und Erfahrung habe SMD zu löten frage ich 
einfach mal ob ich hier ein fertiges Modul erhalten kann.


stenny

[Stephan (Gast)]

stenny schrieb:
> Da ich eine Junkers ZSB 24-4 C23 auslesen und Steuern möchte bin ich
> hier über das fhem Forum gelandet.

Hallo Stenny,

wieviel Wert legst Du auf das Steuern? Hast Du einen FW- oder CW-Regler? 
Bei letzterem kann man aktuell nur die Temperaturen für die Heizung 
steuern aber weder den Betriebsmodus (sinnvoll) ändern noch irgendetwas 
am WW einstellen.
Es fehlt halt jemand der den CW hat und sich mit dem Aufbau der 
Junkers-Befehle auskennt und wie man etwas durchprobieren könnte.

Wenn Du nur Lesen willst, würde auch die erste Platinen-Version reichen, 
die man noch frei fliegend aufbauen kann.

Gruß,
Stephan

[stenny (Gast)]

Hi

Also, bin jetzt nicht vor Ort....
Aber es ist ein CW Regler

Das regeln wäre schon interessant aber erstmal noch nicht nötig.
Jedoch wäre mir die Hardware die auch schreiben kann lieber....

stenny

[Stephan (Gast)]

Nun, mit einem CW geht tatsächlich wenigstens die 
Betriebsart-Umschaltung, also die Kommen/Gehen-Funktion.
Für die SMD-Platine sehe ich aber schwarz denn sowas macht man kaum 
freiwillig mehrfach denn es geht extrem auf die Augen. Ich könnte Dir 
einen Kontakt weitergeben, von dem ich vor einem halben Jahr meine 
Platine bekommen habe. Vielleicht hat der noch eine.
Ansonsten musst Du den Piduino nehmen, denn der kommt ohne SMD aus und 
lässt sich mit genügend Geduld vielleicht auch fliegend aufbauen.

[stenny (Gast)]

Das das Steuern so eingeschränkt ist hatte ich so nicht verstanden....

Dann werde ich wohl nochmal abwarten

[Stephan (Gast)]

stenny schrieb:
> Das das Steuern so eingeschränkt ist hatte ich so nicht verstanden....

Die Lösung kann ja nur das steuern, was auch das Netcom-Modul von 
Junkers kann. Denn man steuert ja nicht die Therme direkt, sondern den 
Regler. Und der nimmt von anderen Quellen so gut wie nichts entgegen, 
denn eigentlich ist er doch der Boss.

Du kannst also maximal den Betriebsmodus umschalten und die 
Heizungs-Solltemperatur steuern.

Dass mehr gehen müsste, kann man z.B. dem Funktionsumfang der 
Quivicon-Anbindung entnehmen 
(https://www.junkers.com/endkunde/produkte/produktinformation/produktkatalog_62659), 
aber das ist schon locker 1 Jahr verspätet und wer weiss was wirklich 
geht und wenn mit welchen Reglern. Und dann muss sich auch noch jemand 
das Teil holen und dann die Befehle mittracen...

Gruß,
Stephan

[Martin G. (g_martin)]

Ich lese hier schon eine Weile still mit. Ein toller Thread, der mich 
seinerzeit auch davor bewahrt hat, für meine Junkers die 
Netzwerkanbindung zu kaufen. Eine bemerkenswerte Leistung von Norbert 
und der Community.

Nachdem meine  Junkers jetzt eine Weile läuft und ich mittlerweile ein 
paar andere Werte im Haus logge, würde ich gerne der Heizung etwas näher 
auf die Finger sehen. Mit Programmierung komme ich gut zurecht, meine 
Fähigkeiten zum Selbstbau werden aber nicht weiter als bis zum Mini 
reichen.

Gibt es jemandem im Forum, der piduino oder (noch lieber) pitiny baut 
oder überzählige loswerden möchte? Natürlich gegen angemessene 
Entschädigung für den Aufwand insbesondere fürs SMD löten!

Ich würde mich über eine PN freuen.

Sonst starte ich mit dem Mini, aber meine schwache Leistung auf dem 
Gebiet ärgert mich schon, bevor ich angefangen habe ;-)

Viele Grüße
Martin

[Norbert S. (junky-zs)]

Hallo,

es hat sich was bei der Software getan, siehe:
  Beitrag "Re: Heizungs-Datenerfassung (HT3)"

Es werden weiterhin alle Adapter-Typen mit diesem neuen Release: 0.3 
unterstützt.

Hinzugekommen sind die Schnittstellen: MQTT und SPS mit einem neuen 
Daemon:ht_collgate

Gruß Norbert

[Richard P. (richard_p)]

Hallo,

ich bin dabei eine Fhem Smart Home Steuerung aufzubauen. Es ist eine 
Junkers Heizung mit HT3 vorhanden und diese würde ich gerne einbinden.
Leider kann ich überhaupt nicht löten. Gibt es jemanden der eine 
'ht_pitiny' über hat oder eine löten könnte? Ich würde natürlich für die 
Kosten aufkommen.
Bitte melden per PN Mail.

Vielen dank und Grüße
Richard

[URBANsUNITED (Gast)]

Hi!

Löten ist nicht das Problem, nur die Platine ist hier die 
Herausforderung.
Kann mir jemand hier bitte weiterhelfen? Ich brauche nur die ht_pitiny 
Platine ohne Zubehör. Kann die mir jemand bitte anfertigen oder hat 
einer noch eine liegen?

Danke

Andreas

[Norbert S. (junky-zs)]

Hallo,

habe noch einige bestückte ht_pitiny-Adapter zur Verfügung.

Bei Interesse PM an mich.

Gruß Norbert

[Hans (Gast)]

Hallo zusammen,

ich habe eine Frage an die Experten bzw. würde mich über Eure Hilfe sehr 
freuen.
Ich hatte vor geraumer Zeit die Heizungs-Datenerfassung HT3 mit einem 
HT3-Miniadapter erfolgreich im Einsatz. Warum auch immer funktioniert 
die Erfassung nicht mehr.
Der Adapter ist an einem Pi2 Model B angeschlossen, der wiederum über 
einen USB-WLAN-Adpater im Netzwerk hängt. Sobald ich den Adapter mit dem 
HT3-Bus der Heizung verbinde, stirbt der WLAN-Adapter (Indikations-LED 
vom WLAN geht in Dauerlicht) und ein Zugriff übers Netzwerk ist nicht 
mehr möglich.
Nur der Pi mit WLAN-Adapter funktioniert ohne Probleme. Pi mit Adapter 
aber nicht mit HT3-Bus verbunden ist auch alles in Ordnung. Nur sobald 
ich den HT3-Bus anschliesse, stirbt die WLAN-Verbindung. Am Adapter ist 
kein Unterschied festzustellen. Die grüne und rote LED leuchten schön im 
Dauerlicht vor sich hin.
Ich habe keine Idee, warum der Anschluss vom Bus eine Rückwirkung auf 
den WLAN-Dongle hat. Es ist doch alles galvanisch getrennt. Ich habe 
auch schon einen anderen Pi und einen anderen Wlan-Adapter ausprobiert, 
das gleiche Verhalten. Selbst wenn der Optokoppler defekt sein sollte, 
warum sollte das WLAN abgeschossen werden?

Ich bin mit meinem Latein am Ende. Habt ihr einen Tipp für mich ?

Dankeschön für Eure Unterstützung

Hans

[Markus (Gast)]

Hallo Hans,

mir fällt noch folgendes ein, was du prüfen könntest:

- anderen USB-WLAN Dongle ausprobieren
- stärkeres Netzteil
- USB-WLAN Dongle weiter weg vom HT3 positionieren (USB Verlängerung)
- Nebenschluss auf der HT3 Schaltung?

Interessant wäre vor allem die Frage, was du am System geändert hast 
gegenüber dem Zustand, als es das letzte Mal funktioniert hat.

Drücke die Daumen!

Gruss
 Markus

[Hans (Gast)]

Hallo Markus,

Dankeschön für deine schnelle Antwort.
zwischenzeitlich habe ich anstatt des HT3-Buses ein Netzteil 
angeschlossen. Man kann nachvollziehen, dass der Optokoppler den 
Transistor bei Flankenwechseln ansteuert. Von daher gehe ich aus, dass 
die Funktion geben ist. Der WLAN-Adapter funktionierte dabei einwandfrei 
und hält die Netzwerkverbindung. Ich kann mich per SSH aufschalten. Von 
daher gehe ich aus, dass das Netzteil nicht das Problem ist.
Schließe ich jetzt wieder anstatt des Netzteils den HT3-Bus der Heizung 
an (grüne LED leuchtet), bricht der WLAN-Dongle wieder direkt ein. Das 
Verhalten erkennt man direkt an der Signal-LED des Dongles. Diese geht 
von unregelmäßigem Blinken für Datenkommuniktation in Dauerlicht über 
und nach einer gewissen Zeit komplett aus. Ebenfalls kann ich den Pi 
nicht mehr per SSH erreichen bzw. im Router wird er auch nicht mehr 
angezeigt.
Ist für mich nicht nachvollziehbar, dass der HT3-Bus den Dongle 
beeinflußt und das Netzteil keinen Einfluss hatte. Ich habe den Dongle 
auch mit einer Verlängerung weiter weg vom Pi platziert, leider ohne 
Einfluss.

Mein USB-Netzteil hat leider nur 2,4A Ausgangsseitig. Ich werde mir mal 
ein stärkeres besorgen und dann nochmal ausprobieren. Allerdings denke 
ich nicht, dass das Netzteil das Problem darstellt.

VG

Hans

[Norbert S. (junky-zs)]

Hallo Hans,

ich hoffe Du kannst inzwischen wieder Daten erfassen.
Falls nicht, ein paar Tipps von mir:
1. Ich glaube nicht an einen Hardware-Fehler und das Netzteil mit 2.4 A 
ist auch mehr als ausreichend.
2. Ich denke da eher an eine Überlast der CPU wenn Du den Adapter mit 
dem Heizungsbus verbindest und dann Daten reinsprudeln.
Klingt erst mal ein wenig befremdlich was das mit dem WLAN zu tun haben 
soll aber es kann durchaus sein das die CPU mit einem Update (commit) 
der sqlite-Datenbank überfordert ist.
Du verwendest sicher noch die Softwareversion 0.2.x, und bei der ist die 
sqlite-Datebank per DEFAULT AKTIVIERT und wahrscheinlich riesig 
angewachsen, bitte kontrollieren!
Damit kommt das CPU-Lein (1 Kern) dann u.U. nicht mehr zeitgerecht klar.

Wenn Du diese sqlite-DB nicht brauchst kannst Du diese im 
Konfigurationsfile: HT3_db_cfg.xml File deaktivieren mit:
    <!-- sql-database -->
    <dbname_sqlite>./var/databases/HT3_db.sqlite</dbname_sqlite>
    <sql-db>
      <enable>off</enable>
....
    </sql-db>
Danach den PI neu starten.

Falls Du die sqlite-db doch brauchst, so bitte die alte sqlite-db 
löschen oder umbenennen und neu anlegen mit: 
~/HT3/sw/create_databases.py
Hinweis:
die rrdtool-Datenbank wird damit nicht verändert und Deine bisher 
erfassten Daten bleiben erhalten.
Im aktuellen Software-Release 0.3.x wird die sqlite-Datenbank 
automatisch bereinigt (default nach 30 Tagen).

Gruß Norbert

[Hans (Gast)]

Hallo Norbert,

vielen Dank für die Information. Allerdings denke ich, dass die 
Überlastreaktion beim Abschluss des HT3-Buses auszuschließen ist, da ich 
sich das gleiche Verhalten zeigt, wenn nur der Pi mit Jessie-Stretch 
läuft komplett ohne Software zur HT3-Datenerfassung, nur die Hardware 
angeschlossen.

Viele Grüße

Hans

[Kai (Gast)]

Hallo,

mal gemessen, was auf dem HT-Bus für Spannung anliegt?
Auch mal gegen Masse messen, nicht das da was einstreut...
Fremdspannung?

Gruß
Kai

[Norbert S. (junky-zs)]

Hallo Hans,

da stellt sich die Sache allerdings anders dar als vermutet.

>Ich hat hatte vor geraumer Zeit die Heizungs-Datenerfassung HT3 mit
>einem HT3-Miniadapter erfolgreich im Einsatz.
Wege dieser Beschreibung nahm ich an das dies im laufenden Betrieb 
plötzlich aufgetreten ist.
Jetzt bin ich allerdings anderer Ansicht und ich kann Dir nur dringend 
Raten den Adapter von der Heizung zu trennen und sorgfältig 
durchzumessen.

Gruß Norbert