Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi

[Norbert S. (junky-zs)]

Mit diesem Projekt stelle ich einen Heizungs-Bus Adapter fuer den 
Raspberry Pi vor.
Ziel war es die Protokolle des Junkers Heizungs-Bus "Heatronic 3" mit 
dem Raspberry Pi zu erfassen und auszuwerten.
Meine Junkers Heizungs- und Solaranlage verwendet einen 2-Draht Bus, 
ueber den die Versorgungsspannung und die Signalisierung geführt werden.
Es wird ein serielles Protokoll zwischen den Bus-Teilnehmern verwendet, 
welches von UART's ausgewertet werden kann.
Der Heatronic 3-Bus kann jedoch nicht direkt an den Raspberry Pi 
angeschlossen werden, da die Ports nur maximal 3.3 V Eingangssignal 
vertragen.
Das Signal auf dem Bus wechselt zwischen 15 und 10 Volt, welches der 
vorgestellte Adapter fuer den Raspi aufbereitet.

Rahmenbedingungen für den Adapter:
  Galvanische Trennung zwischen Heizungsanlage und Rasberry PI.
  Pegelanpassung an die Raspi-Ports.
  Adapter muss so klein sein, dass er in das Gehäuse des Raspi passt.
  Stromversorgung von
   1. Heizungsanlage mit weniger als 5 mA.
   2. Raspberry PI mit weniger als 4 mA.
  Bauteileaufwand soll möglichst gering, die Funktion zuverlässig 
gewährleistet sein.
  Ein falscher Anschluss (Verpolung) des Heatronic 3 Bus am Adapter darf 
diesen nicht zerstören.

Details bitte dem Schaltplan entnehmen.
Wie der Adapter auf einer Lochraster-Platine aussehen kann und auf den 
Raspi aufgesteckt wird sieht man auf den Bildern.
Eventuell ist ein vorhandenes Gehäuse für die LED's und 
Zuleitung-Durchführung anzupassen.

Falls jemand keinen "Printklemmblock" in der Grabbelkiste hat (ich hatte 
gerade einen) kann dieser natürlich auch weglassen werden. Kurze 
2-Drahtlitze mit Lüsterklemme reicht.

 Auf-/Einbau:
 Noch ein wichtiger Hinweis zur Platzierung der Bauteile.
 Die Platzierung ist nicht beliebig, da sonst der Adapter nicht in den 
Raspi passt.
 Entweder ist dort ein Kondensator oder ein Grafik-Adapteranschluss im 
Weg.
 Damit es keinen Kurzschluss geben kann, habe ich den Kondesator des 
Raspi mit Isolierband abgedeckt (Bild).

 Ebenfalls muss der Transistor Q1 tief genug auf die Platine gesetzt 
werden, da die Anschluss-Pins oben nicht isoliert sind und diese dann 
auf dem darunter liegendem Spannungsregler kommen können.
 Tief genug heisst, die Oberkante Transistor-Gehäuse darf nicht höher 
als die Oberkante Buchsenleiste J1 des Adapters sein.

Stückliste:
 Name     Bezeichnung             Anzahl Bemerkung
  U1       H11L1M Optokoppler      1
     Versionen H11L2M & H11L3M sind nicht geeignet !!
  D1       BAT46 oder 1N4148       1     Conrad 153087-62
  D2       ZPD9.1 oder BZX55/C9V1  1     Zenerdiode, Spannung 9,1 Volt
  D3/D4    LED klein               2
  Q1       BC547                   1     Kann auch anderer NPN-Type 
sein.
  R1/R3/R4 1kOhm 1/8Watt Widerst.  3
  R2       4,7kOhm 1/8 Watt        1
  C1       100nF Keramik Kondens.  1
  HT3 Port Printklemmenblock       1     Conrad 731986-62
  J1       Buchsenleiste RM2,54    2*13  Conrad 733779-62
  -        Lochrasterplatine       1     52 * 33 mm -> 20 * 13 Lötaugen

Beschreibung des Adapters:
  Die galvanische Trennung zwischen HT3-Bus und Raspi wird durch den 
Optokoppler H11L1M von Fairchild gemacht.
  Dieser bietet ein Schmitt-Trigger Ausgangssignal mit Hysterese und ist 
schnell genug für das Signalprotokoll mit: 9600 Baud.
  Die LED am Eingang des Optokopplers schaltet bei Strömen grösser 1.6 
mA den Ausgang auf logisch Null.
  Der Transistor am Ausgang des Optokopplers invertiert das Signal, 
sodass der UART des Raspi dies korrekt empfangen kann.
  Die Diode D1 dient als Verpolungsschutz, Diode D2 passt das Signal an 
den Optokoppler an,
  Diode D3 dient als Signalindikator für den richtigen Anschluss des HT3 
Bus.
  Die Diode D4 ist am TX-UART Ausgang des Raspi-Ports angeschlossen und 
kann als Betriebsindikator genutzt werden.
 Bitte Layout-Bild für den Aufbau nutzen, so passt der Adapter dann auch 
in den Raspi!
 SMD-Bauteile habe ich nicht genutzt, Platz ist ja noch frei auf der 
Platine und der eigene Aufbau vereinfacht sich dann.


Inbetriebnahme:
 Klar, nach Aufbau wird cie ganze Sache durchgemessen (Kurzschluss, 
galvanische Trennung usw.)
 Bitte dies auch machen, ich kann nur für die Funktion geradestehen. Bei 
mir laufen die Adapter schon über ein Jahr in den verschiedensten 
Versionen:
 1. Mit USB / RS232 Wandler und galvanischer Trennung unter Windows und 
Linux.
 2. Mit Brückenschaltung und Komparatoren als Raspberry PI Adapter und 
galvanischer Trennung.
 3. Als Miniadapter als Raspberry PI Adapter so wie hier beschrieben.
 Auch klar, das vor dem Anschluss die Heizung ausgeschaltet wird, damit 
der HT3-Bus stromlos ist.
 (Die Heizleistung des Raspi mit 3.5 Watt reicht nun mal nicht die Füsse 
bei defekter Heizung zu wärmen).

Nach dem Anschluss des Adapters an den HT3-Bus und Einschalten der 
Heizung muss die Diode D3 aufleuchten.
Damit wird der korrekte Anschluss (Polarität) an den HT3-Bus angezeigt.
Ist dies nicht der Fall, müssen die beiden Litzen der 2-Drahtleitung am 
HT3-Adapter getauscht werden.

Software:
 Ohne Software blinken nur die LED's, nicht sehr aufregend.
 Daher hier einige Links zu ähnlichen Projekten mit Schwerpunkt auf das 
Protokoll des HT3 Bus und einer Testsoftware geschrieben in Python.

 Ebenfalls sind für die Inbetriebnahme des Raspi-UARTS die Hinweise von 
kampis-elektroecke.de nützlich. Dort wird gut beschrieben wie der UART 
des Raspi einzustellen ist, damit die Systemausgaben deaktiviert und 
somitHT3-Bus Protokoll reinkommen.

 Meine Software wird wahrscheinlich nie fertig.
 Diese erfasst zur Zeit die Protokolle der Heizung- Heizkreis- 
Warmwasser- und Solar-Informationen.
 Die Daten werden pro Tag in separaten CSV-Dateien gespeichert und 
stehen zur Auswertung zur Verfügung.
 Die Anzeige der Daten als Grafikplot mache ich z.Zeit unter Windows mit 
dem CSV-Viewer.

Weiter ist geplant die Daten unter Linux in eine Datenbank zu speichern 
und grafisch aufzupimpen.
 Dafür wollte ich das Tool 'rrdtool' verwenden welches als Opensource 
verfügbar ist.

URL's:
  Beitrag "Junkers HT-Bus Heatronic 3 Schnittstelle"
    "Junkers HT-Bus Heatronic 3 Schnittstelle"
     Danke für die Vorarbeit!

  Beitrag "Heatronic 3 ür Raspberry Pi"
    "Heatronic 3 ür Raspberry Pi"
  http://kampis-elektroecke.de/?page_id=1648
  http://oss.oetiker.ch/rrdtool/download.en.html
  Beitrag "Visualisierung von geloggten Daten"
    "csv_viewer_130910.zip"

Ich hoffe, dass möglichst viele die paar Bauteile in der Grabbelkiste 
haben und das Ding zum fliegen bringen.
Dieser Adapter kann leicht auch an andere Boards angepasst werden, 
hauptsache es hat einen UART-Eingang und die maximale 
Optokoppler-Betriebsspannung von 16 Volt wird nicht überschritten.

Viel Spass beim Nachbau und
  HYRWC  (Handle Your Raspi With Care)

[Norbert S. (junky-zs)]

Für die Auswertung und Darstellung der Heatronic3 Telegramme habe ich 
die Software beigefuegt.
Läuft unter Python3 in Linux und Windows. Unter Windows ist der 
Port-Name anzupassen.
Bei Linux muss der User in die Gruppe: *dialout' aufgenommen werden mit:
# adduser <username> dialout
Das Bild zeigt die Ausgaben der GUI HT3_CSW_analyser GUI.

Nicht alle Bytes sind dekodiert, hat jemand noch weitere Info's dazu?

(Meine Anlage hat die Module: FW100, ISM, FB10, CSW24)


Ich plane den Adapter für eine Heizungsteuerung (TX-Ausgang) zu 
erweitern.
Kennt jemand die zugehoerigen Protokolle der HT3 ?

[Christian K. (Firma: EDV-Service) (kittekaak)]

Vielen Dank für Hard+Software.
Ich werde über Weihnachten versuchen es auch bei mir zu installieren.
mfg
kitte

[Kai Zöllner (Gast)]

Hallo Norbert,

super Arbeit! Ich suche schon seit langem an einer Möglichkeit, die HT3 
meiner Junkers-Heizung auszulesen. Pegelwandler ebus-TTL gibt es ja nun 
reichlich. Aber auf der Softwareseite ist da meist wenig zu finden, und 
wenn dann (in diesem Forum) auch meist für die Buderus-Steuerung.
Hiermit bin ich nun einen großen Schritt weiter.
Hatte eigentlich an einen Arduino gedacht, aber ein Raspberry ist auch 
ok.
Wichtig ist für mich nicht nur das Auslesen der Daten, sondern die 
Anbindung an meine Heimautomatisierung mit FHEM.
Könnte mir vorstellen, dort ein paar Daten zu visualisieren. Zur Zeit 
hole ich die Daten mit einer handvoll DS1820-Temperatursensoren, aber 
die direkte Anbindung an die HT gibt noch mehr Einblick, vor allem in 
die Solarladung.

Schönen Dank hierfür. Jetzt kann ich endlich mal den Adapter auf den 
HT-Bus bauen und in Betrieb nehmen.

Wenn Du noch eine einfache möglichkeit siehst, z.B. die Daten an einen 
SQL-Server zu schicken (z.B. in Intervallen) oder eine Abfrage über ein 
Webinterface ala http://Ip-raspb/cmd=get_WW_temp (o.ä.) dann wäre der 
Weg sehr einfach, ohne ein neues Modul für Fhem schreiben zu müssen, 
geebnet.

Gruß
Kai

[Norbert S. (junky-zs)]

Hallo Kai,

freut mich, dass auch die SW gut ankommt. Die ist tatsächlich auch aus 
der Not entstanden die spärlichen Informationen in einem Tool zu 
sammeln. Der HT3_CSW_Analyser wird auch weiterhin gepflegt und die neuen 
Erkenntnisse darin versenkt.
Kai schrieb:
> Hatte eigentlich an einen Arduino gedacht, aber ein Raspberry ist auch ok.
Der HT3-Adapter läuft auch am Arduino und jedem anderen uC sofern dieser 
einen UART-Eingang hat. Die J1-Pinbelegung ist entsprechend anzupassen, 
die Bauteile ändern sich nicht. Habe selber keinen Arduino und deshalb 
den Adapter für Raspi gebaut.

Was die SW angeht bin ich dabei die Daten in einer DB (sqlite) zu 
sammeln und von dort intervallbasiert (jede Minute) in die rrdtool-DB zu 
schreiben.
Von dort aus soll die Visualisierung (PNG, html) erfolgen (request |& 
intervallbasiert).
Bild zeigt einen Zoom der System-Temperaturverläufe eines Tages 
dargestellt mit dem CSV-Viewer.
Wenn dies in ähnlicher Art als html verfügbar ist wird dies wohl auch 
ohne grosse Anpassungen im FHEM darstellbar sein.

Gruß Norbert

[Stefan B. (sbiermann)]

Hallo Norbert,
super, genau das ist was ich gesucht habe. Ich hab eine Junkers 
ZWB28-3A23, da diese erst im August 2012 eingebaut wurde, gehe ich davon 
aus das die ebenfalls schon das Heatronic 3 drin hat. Was ich allerdings 
noch bräuchte wäre eine Möglichkeit die Therme zu steuern. Ich nutze 
FHEM um die Temperatur der einzelnen Räume zu regulieren, was auch super 
funktioniert. Allerdings wäre es noch optimaler wenn der Brenner nur 
anspringt wenn auch wirklich die Temperatur in einen der Räume unter den 
eingestellten Wert fällt ansonsten im "Nachtmodus" bleibt.
Bevor ich auf dein Projekt gestoßen bin habe ich mit dem Gedanken des MB 
Lan Moduls von Junkers in Kombination mit der App gespielt. Da hätte ich 
dann mittels Reverse Engineering die App auseinander genommen und 
geschaut welche Kommandos die sendet und hätte die dann einfach selber 
per FHEM an das Modul gesendet. Ist allerdings etwas teuer die ganze 
Geschichte, besonders das MB Lan Modul. Daher ist deine Idee wesentlich 
besser.

Viele Grüße
Stefan

[Norbert S. (junky-zs)]

Hallo Stefan,

den HT3-Adapter habe ich absichtlich noch nicht für eine Steuerung der 
Heizung ausgelegt, obwohl der zusätzliche Hardwareaufwand gering ist.
Gründe sind:
1. Unbekannte Sendeprotokolle und wann diese gesendet werden dürfen.
2. Der HT3-Adapter muss passiv sein (kein TX) wenn der Rasp/uC gebootet 
wird und die Ports noch nicht konfiguriert sind.

Um auch die Sendeprotokolle zu erhalten (Stromsteuerung des HT3-Busses) 
werde ich mir einen Sniffer bauen. Dieser soll zeitgleich die Protokolle 
der Sende- und Empfangsrichtung erfassen. Dazu gibt es einen 
preisgünstigen Adapter: elv JJ-09 18 59 Mini-USB-RS232 Umsetzer, der mir 
so hoffe ich die Protokolle der Fernbedienung FB10 liefern kann.
Damit wäre dann zumindest eine Veränderung der Soll-Temperatur möglich.

Ja der MB Lan Adapter ist zu teuer für das bischen Hardware. Der Preis 
ist geeignet um einen die Tränen in die Augen zu treiben und die 
Vier-Schanzen-Tourne zu finanzieren (na ja, andere Firma).
Es wäre besser diesen Adapter über Tchibo zu vertreiben, mit Qualität zu 
punkten und die Open Source- und Hardware-Gemeinde zu unterstützen.
Aber viele Firmen-Projektmanager denken nur bis zum nächsten 
Rückschlag-Ventil und Ausdehnungsgefäss, jedoch das es dahinter auch 
noch z.B. FHEM gibt ist manchen wohl egal.

Wir arbeiten dran.

Gruß Norbert

[Kai Zöllner (Gast)]

Hallo,

Norbert S. schrieb:
> Gründe sind:
> 1. Unbekannte Sendeprotokolle und wann diese gesendet werden dürfen.
> 2. Der HT3-Adapter muss passiv sein (kein TX) wenn der Rasp/uC gebootet
> wird und die Ports noch nicht konfiguriert sind.

1) ist sicherlich richtig, auch bei ausführlicher Suche und Lektüre im 
I-Net und MC.net kann man die Sendebefehle nicht so einfach ergründen
2) Das mit dem Booten ist zu beachten. Kann man aber bestimmt über die 
Verknüpfung von anderen Ports abfangen, da müsste man mal sehen wie der 
Status der weiteren GPIO's/Pin's beim Booten sich verhalten und dieses 
ggf. mit dem Senden auf dem HT3 hardwaremäßig verknüpfen, so könnte ich 
mir eine Freigabe vorstellen.

Leider habe ich nicht die FB10, könnte mir da aber vorstellen, daß 
verschiedene Sendebefehle durchaus interessant sein könnten. So könnte 
man auch individuell die Zirkulationspumpe einschalten, ohne zusätzliche 
Hardware. Hier wäre eine große Einsparung von Energie denkbar.

Vorerst ist aber das Auslesen der vorhandenen Daten schon ein guter 
Schritt.

Wie sieht das eigentlich mit der aufgelaufenen Summe der Solarerträge 
aus? Wird dieses nur im FW100 aufsummiert, oder kann das auch extern 
ausgelesen werden? Ich sehe nur den Ertrag pro Tag, nicht Gesamt.

Gruß
Kai

[Norbert S. (junky-zs)]

Hallo,

Kai Zöllner schrieb:
> Leider habe ich nicht die FB10,..

Der Sniffer sollte auch an der FW1xy funktionieren, dort ist das 
Datenaufkommen nur höher. Die Teile für den Sniffer sind bestellt, in 
der Zwischenzeit arbeite ich an der Datenbank-Anbindung.

> Wie sieht das eigentlich mit der aufgelaufenen Summe der Solarerträge
> aus? Wird dieses nur im FW100 aufsummiert, oder kann das auch extern
> ausgelesen werden?

Ja, leider werden die Solarerträge nur in der Zentrale FW1xy 
aufsummiert, im Protokoll gibt es nur 2 Byte für den Ertrag der letzten 
Stunde.
Auch hat der Wert für Solarpumpen-Laufzeit nur 2 Byte, sodaß nach einem 
Überlauf dieser wieder bei Null anfängt. Dies ist mir zweimal innerhalb 
der letzen beiden Jahre passiert. Schön für den Ertrag, schlecht für die 
Auswertung :=)

> 2) Das mit dem Booten ist zu beachten. Kann man aber bestimmt über die
> Verknüpfung von anderen Ports abfangen.

Ja, ich werde dafür einen Port vorsehen, der die Sende-Freigabe erlaubt. 
Rest wird mit Pulldown-Widerständen erledigt.

Gruß
Norbert

[Markus v. (markus_va)]

Hi,

ich bin zufällig auf den Beitrag gestoßen und finde ihn sehr 
interessant. Ich würde den Adapter gerne nachbauen. Hab allerdings bis 
dato von Elektrotechnik und Microcontrollern leider nicht viel Ahnung.

Ich bin jetzt erstmal mit nem Arduino Board und ein paar Experimenten/ 
Messungen am Steckbrett gestartet um die Basiscs zu verstehen.

Wollte mir jetzt die Komponenten gemäß der Liste oben bestellen und 
hätte noch ein paar Fragen:

- Bei den Widerständen bin ich nicht 100% fündig geworden was die 1/8 W 
angeht zumindest nicht in verdrahteter Form (ich würde zunächst gerne 
einen Steckbrettaufbau verwenden. Theoretisch kann ich doch auch 1kOhm 
Widerstände mit einer Belastbarkeit von 0,25W nehmen oder?

- Ähnliche Frage zum Kondensator...geht ein 100nF 50VDC? War der 
erstbeste den ich gefunden habe bei Conrad. Nach meinem laienhaften 
Verständnis ist die Nennspannung die max. Spannung die das Bauteil 
verträgt, ist das richtig? Wenn ja dürfte ja bei 10-15Volt Pegeln auf 
dem Bus nichts passieren oder?

- Kann ich mit den oben beschriebenen Komponenten überhaupt ein 
Steckbrett nehmen oder muss ich da noch die Kontaktwiderstände des 
Steckbretts irgendwie reinrechnen?

- Angenommen ich habe die Komponenten soweit zusammengesteckt, gibt es 
eine Möglichkeit zu prüfen ob bei Anschluss an den Bus auch wirklich 
nichts negatives passiert (z.B. bedingt durch einen fehlerhaften 
Zusammenbau des Adapters)? Also sowas wie Spannungsprüfung am 
Printklemmenblock z.B.? Falls ja, worauf muss ich achten?

- Letzte Frage...wo genau in der Heizungsinstallation muss/ kann ich den 
Bus idealerweise abgreifen (falls man das so einfach sagen kann) und 
wenn ich ihn abgreife kann ich dann trotzdem noch die reguläre 
Steuereinheit z.B. eine Junkers FW200 weiterbetreiben?

Danke schon mal für eure Hilfe.


Gruß Markus

[Norbert S. (junky-zs)]

Hallo,
Markus, damit der Nachbau klappt hier die Hinweise;
>... kann ich Widerstände mit einer Belastbarkeit von 0,25W nehmen?
Ja auf jeden Fall, die sind zwar grösser nehmen aber auch nicht viel 
mehr Platz weg.

> ...Kondensator...geht ein 100nF 50VDC?
Ja, da dieser nur Störspitzen auf der Betriebsspannung (3.3 Volt beim 
Raspi) vermeiden soll. Keramik-Kondensator ist ideal, andere gehen aber 
auch, der Wert ist nicht kritisch.

> Kann ich mit den oben beschriebenen Komponenten überhaupt ein Steckbrett nehmen?
Ja, da keine grossen Ströme fliessen (Milliampere-Bereich)

> ...gibt es eine Möglichkeit zu prüfen ob bei Anschluss an den Bus auch
> wirklich nichts negatives passiert
Folgende Aktionen durchführen:
1. Eingangs-Widerstandsmessung am HT3-Anschluss (Printklemmenblock) 
messen.
Es darf kein Kurzschluss vorhanden sein und je nach Mess-Polarität muss 
der Widerstand größer als 1kOhm sein.
2. Galvanische Trennung messen zwischen HT3-Bus und uC Anschluss.
Widerstand zwischen HT3-Bus und Ausgangsseite des Optokopplers (U1) muss 
sehr gross sein. Es darf keine Verbindung vorhanden sein.
3. Funktionsprüfung ohne Heizungs-Anschluss mit Prüfspannung.
Eine externe Spannung von ca. 14-15 Volt (geladene Autobatterie ect.) an 
den HT3-Bus Printklemmenblock anschliessen. Die LED D3 muss aufleuchten, 
wenn die Polarität der Eingangsspannung passt. Stromaufnahme dabei 
grösser als 1.6 mAmpere aber weniger als 5 mAmpere.
Gleicher Test mit reduzierter Eingangsspannung von weniger als 11 Volt.
Die LED D3 darf garnicht oder nur wenig leuchten. Die Stromaufnahme muss 
weniger als 1 mAmpere sein. Falls dies nicht passt bitte den Anschluss 
der Zenerdiode D2 prüfen.
Damit ist der Adapter bereit für den Anschluss an die Heizung ohne dort 
etwas aufzubröseln.

Der HT3-Bus-Anschluss kann an der Steuerplatine in der Heizung 
abgegriffen werden. Bei meiner Heizung CSW xy sind die zwei Klemmen mit 
B bezeichnet.
Einfacher geht es, wenn der Regler FWxyz nicht in der Heizung sondern 
extern an der Wand befestigt ist. Dann kann man den HT3-Bus auch am 
Regler abgreifen. Der Anschluss ist dabei immer parallel zu den 
vorhandenen Bus-Kabeln an den Klemmen B.
Bitte wegen der Leitungsquerschnitte und Leitungsführung immer die 
Hinweise des Herstellers beachten. Stabiles 2-adriges Kabel mit 0,75mm2 
passt gut.

Gruss Norbert

[F.Sigloch (Gast)]

Klasse, jetzt hab ich auch was davon :-)

Gruss F.Sigloch

[Norbert S. (junky-zs)]

Hallo,
es hat sich was auf der Softwareseite getan. Da die aber besser im Forum 
unter Codesammlung aufgehoben ist, habe ich die dort abgelegt unter:
Beitrag "Heizungs-Datenerfassung (HT3)"
Dort ist im Tar-File auch die Dokumentation enthalten, die das ganze 
einfacher machen soll (I'll hope so).

Bitte dort in Zukunft den aktellen SW-Stand holen.
An dieser Stelle werde ich weiterhin die Hardware-Neuigkeiten versenken.
Da es z.Zeit keine spruchreifen gibt, ist hier auch schon Schluss.

Gruss Norbert

[Kai Zöllner (Gast)]

Hallo Norbert,

hatte in den letzten Tagen hier mal wieder reingesehen, ob es was neues 
gibt.
Vielen Dank für Deine Arbeit, super Sache.

Die Portierung auf Arduino habe ich nicht mehr weiter verfolgt, ein 
Raspberry ist dafür auch gut geeignet und liegt hier schon "rum".
Die Hardware muß ich immer noch erstellen, leider hatte Reichelt keinen 
Optokoppler im Angebot, so daß ich nun leider auf einen anderen Anbieter 
wechseln muß. Vielleicht setze ich auch ein PC900 ein.

Das Programm läuft auf meinen Raspberry schon lange sauber durch. Freue 
mich schon "auf die kalten, verschneiten Tage", damit ich die Hardware 
zusammenlöten kann ;-))))

Gruß
Kai

[Norbert S. (junky-zs)]

Hallo,
es hat sich mal wieder was auf der Hardware-Seite getan damit nicht nur 
mit dem RaspberryPi HT3-Telegeramme sondern auch mit jedem anderen 
USB-Host Device kraftvoll Daten empfangen werden kann.

Der HT3 MicroAdapter besteht aus einem Kaufteil (elv 91859) und der 
schon bekannten galvanischen Ankopplung an den HT3-Bus.
Der Preis für die Bauteile liegt bei ca. 10 € sofern man eine alte 
Schachtel (als Gehäuse) zur Verfügung hat.

Die Bilder zeigen wie es sein könnte, den Namen: Micro hat der Adapter 
jedenfalls verdient. Trotz klein aber oho, die HT3 Telegramme kommen 
ohne Abstriche wie gewünscht raus.
Die Software ist weiterhin so verwendbar, der Port muss für diesen 
Adapter aber dann auf /dev/ttyUSB0 oder /dev/ttyUSB1 eingestellt sein.

Viel Spass beim Nachbau.

Gruss Norbert

[Ferdinand (Gast)]

Hallo,

was bedeutet eigentlich T-Steuer Fernbedienung ?

Gruss Ferdinand

[Norbert S. (junky-zs)]

Hallo,

Ferdinand schrieb:
> was bedeutet eigentlich T-Steuer Fernbedienung ?
Damit ist der Messwert der Fernbedienung FB10 gemeint. Diese ist bei mir 
im Wohnzimmer angebracht und der Wert wird als Führungsgröße verwendet.
Da nicht jeder eine Fernbedienung hat, ist dieser Wert dann zu 
ignorieren.
Mein System besteht aus: CSW24, FW100, ISM1 und FB10. Die Software 
(HT3_Analyser) basiert auf den Daten dieses Systems. Nicht jeder hat die 
gleiche Anlage und es währe gut wenn jemand andere Systemkomponenten 
(FW110, FW200, FB100 etc.) hat und die Protokolle erfassen und posten 
kann.

Gruss Norbert

[strauch (Gast)]

Norbert S. schrieb:
> Aber viele Firmen-Projektmanager denken nur bis zum nächsten
> Rückschlag-Ventil und Ausdehnungsgefäss, jedoch das es dahinter auch
> noch z.B. FHEM gibt ist manchen wohl egal.

Hallo Norbert,

ich nutze FHEM und würde gerne meine Gasherme auslesen und über "FHEM" 
visualisieren. Hast du denn schon irgendein Modul um die Therme in FHEM 
einzubinden?
So das man den Raspbi irgendwie per LAN/WLAN einbindet? Kann man über 
den HTBus vielleicht sogar irgendwie den Raspbi mit Stromversorgen?
Man ich würde in dem Bereich gerne mehr können.

Danke und Grüße

strauch

[Norbert S. (junky-zs)]

Hallo,
strauch schrieb:
>ich nutze FHEM und würde gerne meine Gasherme auslesen und über "FHEM"
>visualisieren. Hast du denn schon irgendein Modul um die Therme in FHEM
>einzubinden?
Die aktuelle Software gibt die erfassten Daten (sqlite- und rrdtool-db) 
als PNG-Grafiken aus. Die Visualisierung erfolgt z.Z. mit scripts und 
Browser (siehe Bild).

!!! Hinweis: Die aktuelle Software passend zu dieser Schnittstelle HT3 
gibt es unter : Beitrag "Heizungs-Datenerfassung (HT3)"

strauch schrieb:
>Kann man über den HTBus vielleicht sogar irgendwie den Raspbi mit Stromversorgen.
Nein auf keinen Fall, aus 2 Gründen:
1. die Stromaufnahme des Raspi (Rev.A/B) ist zu hoch und die Spannung 
passt nicht. Ein Schaltnetzteil für 8,-€ ist billiger als eine neue 
Heizungssteuerung.
2. Die galvanische Trennung zwischen Heizung und Erfassung geht dann 
flöten. Die halte ich im übrigen für sehr wichtig.

Gruss Norbert

[strauch (Gast)]

Hallo Norbert,

danke für die schnelle Antwort, ich werde erst mal alles nachbauen und 
mir deine Software anschauen. Bin schon sehr gespannt.

Grüße

strauch

[Ferdinand (Gast)]

Hallo Norbert,

danke für die Antwort.
Für unterwegs wäre ein Webinterface auch was Feines.

Gruss Ferdinand

[strauch (Gast)]

Ich glaube dann sollte man wirklich schauen ob man das nicht in 
vorhandene Systeme einbinden kann (wie FHEM), bevor man sich die Arbeit 
macht und ein Webinterface dafür baut. Ich hab jetzt die Teile bekommen. 
Jetzt brauch ich nur noch Zeit, das alles zusammenzubauen.

[Kai Zöllner (Gast)]

Hallo Zusammen,

ein Modul / Integration in FHEM wäre auch mein Ziel. Wenn das einer 
hinbekommt, das wäre super!!

Bei einem Webinterface wäre vielleicht der Weg auch über das 
HTTPMOD-Modul. Vielleicht reicht dann eine Textdarstellung der Werte und 
FHEM holt sich das manuell mit HTTPMOD ab.

Allerdings, ein vollwertiges Perl-Modul wäre natürlich besser.


Gruß
Kai

[Kai Zöllner (Gast)]

Nochmals ich,

habe die obige Idee mal verwirklicht.
Auf dem RPI wird mittels Cronjob alle 5min ein Script aufgerufen, welche 
die letzten Werte aus der SQLITE-Datenbank in ein Textfile schreibt.
Je Zeile gibt es einen Wertesatz für HG, HK, WW und Solar.

Diese Datei liegt auf dem RPI und kann mit einem Webbrowser 
ausgelesen/angezeigt werden (Stichwort Apache/PHP)

In FHEM habe ich über das Modul HTTPMOD verschiedene Variablen gebildet, 
die über diese Textdatei gefüllt werden. Das Ergebnis ist gar nicht so 
schlecht, nun habe ich alle Daten meiner Heizung in FHEM.

Der Weg ist zwar nicht so schön wie über ein eigenes Modul, aber er 
klappt.

Gruß
Kai

[Frank G. (drego)]

Hi, ich habe mich schon mit Norbert unterhalten und benötige Dringend 
Eure Hilfe. Ich habe eine recht grosse Heizungsanlage und habe das Board 
von Norbert erhalten (vielen Dank noch mal für Deine Hilfe!!!). Leider 
komme ich bei dekodieren der ganzen Codes nicht richtig weiter. Daher 
die Frage an Euch, ob Ihr mir helfen könnt. Ich habe, kurz 
zusammengefasst, ein Junkers Brennwertgerät mit folgenden Teilen: 
Kessel, Warmwasserspeicher, 3 gemischte Heizkreise, FW200, FW100, 2 IPM2 
und 1 ISM2. Ich habe auch mal ein paar Anhänge gemacht zum 
Heizungsscheme sowie noch mal die Zuordnungen zu den verbauten Teilen 
beschrieben, wer kann mir helfen? Entsprechende mitschnitte habe ich 
auch angehängt. Da wir gerade Winterbetrieb haben, ist der Brenner an 
sich nur sehr wenig an. Danke für Eure Hilfe!

drego

[strauch (Gast)]

Ich hoffe das Norbert dir weiterhelfen kann. Ihr seid alle schon 
wesentlich weiter, ich hab die Bauteile zuhause rumfliegen, ich muss 
jetzt nur mal zum löten kommen. Ich hoffe das ich auch irgendwann mal 
die Heizung und ausschalten kann. Das mache ich zur Zeit immernoch per 
Hand. Da die Heizung auch wenn alle Heizkörper zugedreht sind, Gas 
verbraucht.

@Kai schön zu sehen, das du schon etwas für FHEM "gebastelt" hast. Ich 
hoffe ja auch immer das es noch mehr Junkersnutzer bei FHEM gibt. Wenn 
ich mir anschaue wie groß dort der Thread für Viessmann ist.

Vielleicht wenn ich Glück habe, kann ich dieses Wochenende mit Hilfe die 
Platine zusammenlöten und dann auch mal testen und von der Heizung 
lernen.

[bholmer (Gast)]

Nicht ganz das Thema aber kurze Frage an die Heizungsexperten:

Ich habe seit 1 Monat eine Junkers Gasheizung mit MB-LAN, 2 Heizkreisen 
und Warmwasserbereitung.

Ein Heizkreis ist ungemischt an ein Gartenpool angeschlossen. Die 
Heizungsrohre sind direkt im Becken verlegt. Keine weitere Steuerung 
vorhanden.

Ich möchte die Beckentemperatur automatisch regeln. In der jetztigen 
Konfiguration kann ich nur den Heizkreis einschalten über die Junkers 
Home App und hoffen, dass ich nicht vergesse ihn wieder abzuschalten.

Daher habe ich mir folgendes gedacht: Ich nehme eine FB10 (schon 
gekauft) und messe damit die Wassertemperatur als Sollwert für die 
"Raum"-Temperatur. In der Trockensimulation mit 100% Raumeinfluss durch 
die FB10 scheint das auch zu funktionieren.

Einziges Problem: Ich müsste den Sensor, der in der FB10 verbaut ist, 
herausführen, wasserdicht verpacken und mit einem Kabel ins Schwimmbad 
tauchen.

Weiß jemand was das für ein Sensor ist? Ist es ggf. der gleiche, der für 
die Messung der Außentemperatur oder der Vorlauftemperatur von Junkers 
verwendet wird?

Des weiteren würde es mir Bauchschmerzen bereiten, ein Bauteil, das an 
den Heizungsbus angeschlossen ist, so einfach in ein Schwimmbad zu 
tauchen, das von Personen benutzt wird.

Jemand eine Idee dazu?

[Norbert S. (junky-zs)]

Hallo,

bholmer schrieb:
>...kurze Frage an die Heizungsexperten:
Danke für das Kompliment, jedoch sind wir keine Experten (jedenfalls 
nicht für Heizungen) und wir betreiben dies als Sport. Man gönnt sich ja 
sonst nichts.

>Weiß jemand was das für ein Sensor ist? Ist es ggf. der gleiche, der für
>die Messung der Außentemperatur oder der Vorlauftemperatur von Junkers
>verwendet wird?
In der Regel sind dies NTC-Widerstände, die jedoch bei den 
Junkers-Anlagen nicht alle die gleichen Daten haben. Die Fühler für 
Innenbereich haben kleinere Temperaturbereiche als die für den 
Außenfühler oder für den Solar-Kollektor.
Für das Schwimmbecken würde die Auflösung ja reichen.
Ich hätte aber an Deiner Stelle einen Aquarium-Fühler beschafft, mit dem 
kannst Du dann eine Umwälzpumpe ansteuern -> Regelung inklusive.
Das 'Problem' ist bei NTC-Widerständen, das Du die analogen Werte in der 
Regel nicht direkt verwenden kannst sondern noch einen Wandler brauchst 
mit dem Du dann z.B. eine Umwälzpumpe steuerst.
Es gibt glaube ich auch von elv (ohne Werbung zu machen) 
Wassertemperaturfühler, die per Funk die Daten an eine Zentrale senden. 
Den Fühler schmeißt Du direkt in den Pool -> Wenn der groß genug ist, 
stört der Fühler auch nicht.
Übrigens, solltest Du mal einen Beta-Tester für Deine Pool-Regelung 
benötigen, dann stelle ich mich gerne zur Verfügung. Das Wetter soll ja 
jetzt besser werden.

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo,

Frank, danke für Deine Logs. Da tanzt der Bär bei Deiner Anlage und die 
Analyse hat etwas gedauert. Die Ergebnisse habe ich jetzt in einer 
Tabelle versenkt und kann damit das Analyse-Programm verbessern.
Habe Dein log3.log aufgepimpt und lesbar hier angehängt.

Jeder, der weitere Informationen zu den Junkers-Heatronic3 Telegrammen 
hat, kann diese Tabelle erweitern und mir zusenden oder posten.
Auch Junkers-Insider sind hier herzlich willkommen daran teilzuhaben.
(Aber bitte keine falschen Infos reinsetzen, daß wäre dann Viessmann).

Geplant ist die Software konfigurierbar zu machen, um dann den 
unterschiedlichen Anlagen gerecht zu werden. Damit liesse sich aus den 
verschiedenen Telegrammen eine für die Anlage passende Anzeige bauen.

Frank, für Dich werde ich auf Basis dieser bekannten Daten eine 
Testsoftware zusammenzimmern. Du bist mit Deiner üppigen Anlage dann der 
Beta-Tester.

Sitzen drei Heizungsmonteure zusammen und fachsimpeln.
Unsere Junkers Brennwert-Modelle laufen und machen keine Probleme sagt 
der eine.
Der Brötje-Monteur kontert, unsere günstigen Auslauf-Modelle gibts 
überall und wir sind ständig unterwegs.
Leute das ist doch garnichts sagt der Viessmann-Monteur, unsere blonden 
Langlauf-Modelle sind im Rennen und laufen allen davon.

So weit, so gut
Achtet bitte auch auf die Zeitumstellung. Kann ja sein, daß die Software 
dann abkackt. Man kennt das ja.

Gruß Norbert

[bholmer (Gast)]

Danke für die Info. Ich werde die FB10 mal auseinandernehmen.
Vielleicht ist es ja ein gebräuchlicher NTC, den es auch in gekapselten 
Ausführungen gibt.

An die ELV-Steuerung hatte ich auch schon gedacht. Es gibt da einen 
batteriebetriebenen Thermostatsender, der beliebige FS20-Schaltaktoren 
steuern kann. Leider ist deren Sensor auch nicht für Dauerbetrieb unter 
Wasser gedacht und das Problem ist, wenn ich nicht direkt den Heizkreis 
in der FW200 sondern nur die Umwälzpumpe ansteuere, schaltet sich nicht 
die Vorlauftemperatur entsprechend hoch und ich bekomme nicht genug 
Energie in das Becken oder die Vorlauftemperatur bleibt hoch, auch wenn 
das Becken keine Energie braucht. Daher schien mir die FB10 so elegant, 
da diese einfach eine Wärmeanforderung an die Steuerung gibt, die 
wiederum die Pumpe anwirft und den Brenner startet.

[Frank G. (drego)]

@Norbert

Vielen Dank für die Tabelle. Folgendes konnte ich noch erkennen:
Telegramm [90 00 FF xx] hat beim Byte 5 0x72 drin stehen für den dritten 
Heizkreis


Im gleichen Telegramm ist das Byte 8 unnd 9 nicht die Heizkreis 
Solltemperatur sondern die Raumtemperatur Soll. Das Byte 10 und 11 
hingegen ist die Vorlauftemperatur ist für den HK.

Was noch fehlt ist die Vorlauftemperatur Soll für den Heizkreis. Die 
konnte ich leider noch nicht auffinden. Kann es sein, dass diese nicht 
über den Bus geschickt wird oder in Relation zu einer anderen Zahl/Wert 
steht?


Ich würde gern Betatester spielen ...
Gruesse

[Heiko R (Gast)]

Hallo Norbert,

auf Deiner Schaltung mit dem UM2102 sind 3 LEDs. Dazu hätte ich eine 
Frage. Die grüne dürfte die Funktionskontrolle aus der ersten Schaltung 
sein. Wozu sind die rote und die orangene LED? Wie sind die geschaltet 
(dazu gibt es keinen Schaltplan). Was für LEDs sind das? 2mm? 
Low-current?

Grüße,
Heiko

[Norbert S. (junky-zs)]

Hallo Heiko,
hier die Antwort auf 'UM2102'.
> Die grüne dürfte die Funktionskontrolle aus der ersten Schaltung sein.
Ja, dies ist die Kontroll-LED fuer die richtige HT3-Bus Polarität.

> Wozu sind die rote und die orangene LED?
Die anderen LED's sind Test/Kontroll-LED's mit folgenden Funktionen:
Die rote LED ist ueber 1kOhm an ST2 TxD angeschlossen (UART-TX Ausgang).
Leuchtet konstant, wenn kein Signal anliegt.

Die gelbe LED ist an ST1 DSR (Data Set Ready) angeschlossen und der 
Jumper verbindet diesen mit ST1 DTR (Data Terminal Ready). Der 1kOhm 
Widerstand liegt an +3.3Volt und die LED mit Kathode an ST1-DSR.
Hier leuchtet die LED, wenn ST1-DTR aktive (Low) gesetzt ist.

> Was für LEDs sind das? 2mm?
Der Durchmesser der LED's liegt bei gemessenen 2,5 mm. So passen diese 
auch durch die vorhandenen Löcher.

Anschluss:
            Gelbe LED      1kOhm
             | /|        ---------
 ST1-DSR ----|/ |--------|       |--------- 3.3 Volt
         |   |\ |        ---------
 ST1-DTR +   | \|

               1 kOhm          Rote LED
               ---------         |\ |
 ST2-TxD ------|       |---------| \|------ GND
               ---------         | /|
                                 |/ |

Diese LED's sind für die Funktion des HT3-MicroAdapters nicht 
erforderlich, habe diese als Test für eine spätere TX-Steuerung genutzt. 
Diese liegt aber im Moment auf Eis.

Gruß Norbert

[Heiko R (Gast)]

Hallo Norbert,

vielen Dank für die schnelle Antwort.

Die TX-Steuerung planst Du noch? Es klang so, als wolltest Du die aus 
Sicherheitsgründen nicht implementieren.

Geplant ist bei mir die Junkers ZSB14-4 C 21 mit Heatronic 4i. Die 
Schaltung sollte am HT-Bus doch trotzdem funktionieren?

Gruß,
Heiko

[Norbert S. (junky-zs)]

Hallo Heiko,
> Die TX-Steuerung planst Du noch?
Ja, die nötigen zwei 'UM2102' habe ich und die restliche Schaltung ist 
als Draft vorhanden, damit ich dann HT3-RX UND HT3-Stromsteuerung (TX) 
gleichzeitig aufgenommen werden kann. Damit kann ich dann zeitliche und 
protokollabhängige Details erfassen. Dies liegt aber noch in der 
Schublade.

> Geplant ist ... ZSB14-4 C 21 mit Heatronic 4i. Die Schaltung sollte am
> HT-Bus doch trotzdem funktionieren?
Ich nehme an, dass die Hardware (15/10Volt Signalisierung / 
Spannungsversorgung) sich nicht geändert hat, sonst würden alle FW1xy 
/FW2wz Regler von gestern auf heute nicht mehr funktionieren. Sicherlich 
wird die Software und damit die Protokolle neue Inhalte und Funktionen 
haben, z.B. ist neu die 'Selbstanlernfunktion' mit der die 
Systemkonfiguration erfasst werden kann.
Ich selber habe nur HT3, würde mich aber freuen wenn Du Dir mal was 
neues und Gutes gönnst (Heizung mit 4i und HT3-Adapter).
Man (wir) können daraus nur lernen.

Gruß Norbert

[Carsten (Gast)]

Hallo Kai,

die Integration in FHEM ist für mich sehr interessant! Kannst du evtl. 
das Script und die Config vom FHEM zur Verfügung stellen? Vielen Dank, 
Viele Grüße Carsten

[Norbert S. (junky-zs)]

Hallo bholmer,
bist Du schon weitergekommen mit Deiner Schwimmbad-Steuerung?

Falls nicht, kann ich Dir eventuell weiterhelfen.
Ich habe einen Solar-Kollektorfühler zur Verfügung, den man an die Werte 
des FB10 NTC-Fühlers anpassen kann. Anpassung ist erforderlich, da die 
Widerstandswerte bei Raumtemperatur nicht dem im FB10 entsprechen.

>Einziges Problem: Ich müsste den Sensor, der in der FB10 verbaut ist,
>herausführen, wasserdicht verpacken und mit einem Kabel ins Schwimmbad
>tauchen.
Dies könnte wie folgt gelöst werden: Fühlerleitung durch ein Platikrohr 
führen und den Fühlerkopf mit Silikon und Schrumpfschlauch abdichten. 
Die Fühlerleitung ist ca 2Meter lang.
Fühlerkopf ist aus Metall: siehe Bild.

Falls noch Bedarf ist, melde Dich.

Gruß Norbert

[Kai <Zöllner (Gast)]

@Carsten,
Klar, ich stelle das gerne hier rein. Du musst Dich allerdings ein paar 
Tage gedulden, ich muß/möchte das gerne zusammenschreiben und bin am 
Wochenende aufgrund eines beruflichen Termins nicht verfügbar


Gruß
Kai

[Kai Zöllner (Gast)]

@Carsten, ich habe kurz was zusammengeschrieben. Da es hier eindeutig um 
FHEM  geht habe ich die Anleitung auch im FHEM-Forum geschrieben.
siehe: http://forum.fhem.de/index.php/topic,19445.0.html

Gruß
Kai

[Carsten (Gast)]

@Kai: Vielen Dank!

VG Carsten

[Heiko R (Gast)]

Hallo Norbert,

ich bin gerade irritiert. Im Schaltplan mit UM2102 ist ein Kondensator 
eingezeichnet, den ich auf der Platine nicht sehe. Hast Du den 
unterseitig bestückt oder ist das ein Fehler im Schaltplan? Oder 
versteckt der sich hinter der roten LED?

Viele Grüße,
Heiko

[Norbert S. (junky-zs)]

Hallo Heiko,

>...es ist ein Kondensator eingezeichnet, den ich auf der Platine nicht sehe.
Ja, Asche auf mein Haupt, Du hast recht. Im Schaltplan ist er 
eingezeichnet und er hat ja auch seine Funktion -> eventuel vorhandene 
Störspitzen abblocken.
Du kannst diesen Kondensator nicht sehen, weil er noch bei mir in der 
Schublade liegt. Ja nötig wäre er schon, meine Faulheit hat gesiegt. Bei 
99.99 % der Nachbauten funktioniert die Schaltung auch ohne 
Abblockkondensator, bei den restlichen den Kondensator bitte einsetzen.

Gruß Norbert

[fsigloch (Gast)]

Hallo,

ich habe mal mit dem NETCOM 100 Solltemperatur 26 Grad (01 04) und 
einmal
28 Grad (01 18) gesendet. Regler ist FW 100 mit FB 100 (98 00 FF).

Das erste Telegramm wird vom BUS kollidiert das zweite kommt wohl durch.

Das auf den Bus selbst zu jagen, trau ich mich noch nicht :-)

Gruss Ferdinand

Cutecom Protokolle sind angehängt

[Norbert S. (junky-zs)]

Hallo Ferdinand,
danke für die Protokolle.
So gezielt Daten zu erfassen hilft ungemein. Hier der Inhalt der Meldung 
98 00 FF:
Byte  Werte    Bemerkung
0  98    Telegramm: Heizkreis Steuerung FB100
1  00     „
2  FF     „
3  00     „
4  00    Immer 00
5  6F    Heizkreise(1/2/3/4); 6F:=HK1; 70:=HK2; 72:=HK3; 7?:=HK4
6  01/02/03  Betriebsart Heizung:
6       01=Frost
6       02=Sparen
6       03=Heizen
7  02    Immer 02
8  Hi-Byte    Soll-Temperatur (HK1/HK2/HK3/HK4)
9  Lo-Byte
10 Hi-Byte    Ist-Temperatur   (HK1/HK2/HK3/HK4 bzw. Regler/Wand)
11 Lo-Byte
12 00    Immer 00
13 00    Immer 00
14 00    Immer 00
15 xy    CRC
16 00    Ende Marker

Den restlichen Protokoll-Inhalt sehe ich mir noch an. Mal sehen was sich 
dort noch finden lässt.

Gruss Norbert

[fsigloch (Gast)]

Hallo Norbert,
viel interessanter ist :
98 00 FF 00 65 01 00 04 19 28 2D 05 01 00 ...
Ist das meine vermutete Kollision ?
Wahrscheinlich stimmt die Prüfsumme auch nicht.

Netcom 100 habe ich schon lange vom Heizungsbauer, leider kann man damit 
nur die Solltemperatur ändern , blöd wenn man die Kontrolle verliert 
:-).
Das MB LAN2 ist ein ganz grosser Mist, dass die sich nicht schämen!
Ich konnte es mal testen, mit Andriod gings gar nicht nur ein wenig dem 
mit iPhone.
Ich hab es nicht gekauft,Gott sei Dank !
Im letzten Sommer habe ich mir dann, mit den Formeln von Zorro, auf dem 
dem Raspi ein Programm geschrieben,
um wenigstens die Werte zu kontrollieren, ich glaube du hast es in 
deinen
Literaturangaben zitiert. Ich bin nicht der grosse Programmierer, dein
Programm ist viel besser :-)
Ich steuere mit dem Smartphone ein bisschen den Überschuss der 
Solaranlage
in die Fussbodenheizung von unterwegs, dass der Kollektor nicht so oft
in die Stagnation kommt.
Natürlich wär es besser wenn der Raspi das allein tun könnte,aber dafür
müssten wir das Sende-Protokoll kennen :-)

Gruss Ferdinand

[bholmer (Gast)]

Danke für die Tipps.

Ich habe das Schwimmbadproblem jetzt gelöst.

Habe die FB10 Fernbedienung auseinandergenommen und den NTC ausgelötet. 
Es ist ein Standard-NTC mit 10 kOhm bei 25 Grad. Dann habe ich einen 
entsprechenden wasserdichten NTC-Fühler mit 10 m Silikonkabel und IP68 
Zertifizierung bestellt bei sensorshop24.de. Kostenpunkt 18 Euro. Diesen 
Sensor habe ich statt des NTC an die Fernbedienung angelötet.
Kabel genommen und ins Wasser gehängt. Jetzt zeigt er statt der 
Raumtemperatur exakt die Wassertemperatur an und ich kann die gewünschte 
Schwimmbadwassertemperatur direkt als Zielgröße einstellen. Prompt 
springt der Brenner an und die Heizkreispumpe läuft.

Jetzt muss ich das Sensorkabel nur noch vergraben und die FB10 
Fernbedienung im Haus in der Nähe des Schwimmbads anschrauben. Bin mal 
gespannt auf das Regelverhalten. Aber man kann ja vieles einstellen in 
der Heizungssteuerung.

[Norbert S. (junky-zs)]

Hallo,

fsigloch schrieb:
> Das MB LAN2 ist ein ganz grosser Mist, dass die sich nicht schämen!
Danke für die Info, werde mir das Ding dann nicht zulegen, der eine oder 
andere wohl dann auch nicht! -> Junkers-Leute aufgemerkt: Macht das Ding 
besser und billiger. Wir stellen uns auch gerne dann als Testkandidaten 
zur Verfügung.
Häufig sind es Details, aber daran knabbern wir ja auch noch.

Habe jetzt endlich den HT3-Sniffer-Adapter realisiert (siehe Bilder).
Wozu ist das Ding gut? -> Mit dem Sniffer können gleichzeitig die 
emfangenen und die von den Geräten gesendeten HT3-Telegramme erfasst 
werden. Da die HT3-Busgeräte ihre Signale über Stromimpulse senden, ist 
zusätzlich zu dem schon bekannten galvanisch getrennten Empfangs-Zweig 
RX der Sendezweig TX mit Komparator und Optokoppler hinzugekommen. Für 
die Übertragung der Daten zum PC werden zwei UM2102 Module (RS232<->USB) 
der Firma elv verwendet. Kosten des Adapters gefühlte 20,- €. Details 
bitte dem Schaltplan entnehmen.
Testaufbau z.B. für die Fernbedienung FB10/FB100 wie folgt:

HT3-Bus             HT3-Sniffer_Adapter               FB10/FB100
                IN  +---------------+ OUT            +-----+
--------------------|               |----------------|     |
--------------------|               |----------------|     |
                    +---+--------+--+                +-----+
                     RX |     TX |
                        |        |
                        v        v
                        USB1     USB2 PC/Laptop mit z.B. 'hterm'
Natürlich kann statt der Fernbedienung auch ein MB Lan2 drangehängt 
werden, ich habe jedoch keines (für längere Zeit nicht, siehe oben).

Hinweis: Mit dem Open Source Tool 'hterm' lassen sich die RX/TX-Daten 
mit Zeitstempeln unter Linux und Windows recht gut erfassen. Andere 
Terminalprogramme gehen natürlich auch.
Damit habe ich die erforderlichen Telegramme für eine Temperaturänderung 
erfassen können und der zeitliche Ablauf ist jetzt klarer.
Ja, jetzt könnte man daran denken die Steuerung dann selber in die Hand 
(Raspi) zu nehmen.
Aber wie oben schon beschrieben sind die Details deren sehr viele, 
z.Beispiel hat der Raspi (irgendwo gelesen) keinen vollwertigen UART. 
Die Register sind zwar wohl alle da, aber dem tut teilweise nix.
Ein Beispiel ist das 'Break' - Signal, welches ständig beim 
HT3-Protokoll missbraucht wird um das Telegramm-Ende zu signalisieren. 
Statt des 'Break' wird z.Zeit eine 0 erfasst. Dies tut für das Erfassen 
(RX) nicht weh, jedoch ist es für das Senden erforderlich.
Vielleicht hat der eine oder andere eine Idee, ich arbeite auch noch 
daran.

Gruß Norbert

[Psssst ... (Gast)]

Norbert S. schrieb:
> Vielleicht hat der eine oder andere eine Idee ...

Macht es Euch nicht schwerer als nötig ... die Arbeit wurde bereits 
getan:

Beitrag "Faktensammlung Buderus EMS"

[Norbert S. (junky-zs)]

Hallo,

Psssst ... schrieb:
> Macht es Euch nicht schwerer als nötig ... die Arbeit wurde bereits
> getan: ...
Ja, sehr gute Arbeit! Für Buderus und EMS.
Ja, Buderus und Junkers kommen aus dem gleichen Stall, jedoch sind die 
Boxen unterschiedlich und in der Stallgasse laufen andere Telegramme und 
die Telegramm-Inhalte sind bis auf wenige Ausnahmen unterschiedlich.

Wie oben schon erwähnt, die Details machen etwas lauffähig oder nicht.
Eins der Details ist z.B. das Polling-Byte des Bus-Masters: bei Buderus 
ist Bit7:=1; bei Junkers ist Bit7:=0, das Gerät antwortet bei Buderus 
mit Bit7:=0; bei Junkers mit Bit7:=1. (Wie gesagt: gleicher Stall, 
physikal Layer seriell, asynchron, 9600 8N1; klar der Rest soll ja nicht 
passen)

Der EMS-Adapter für Buderus wird wohl nicht 1:1 an Junkers-Anlagen 
laufen. Falls es einen Umschaltmodus auf Junkers-Mode im EMS-Gateway 
geben sollte, so kenne ich diesen noch nicht und ich lasse mich gerne 
eines besseren belehren.

Gruß Norbert

[Psssst ... (Gast)]

Norbert S. schrieb:
> Der EMS-Adapter für Buderus wird wohl nicht 1:1 an Junkers-Anlagen
> laufen.

Es spricht einiges dafür, dass er das tut:

Beitrag "Junkers HT-Bus Heatronic 3 Schnittstelle"
(kennst du vermutlich)

Dass die Telegramme anders geparst werden müssen, ist klar.

Protokoll-Details wie z.B. CRC, TX-Prozedere und Bus-Timing wirst du 1:1 
von EMS übernehmen können.

Wenn du senden willst, wirst du aus Timinggründen um eine 
BREAK-Erkennung nicht drumherum kommen und die bekommt man nur mit einem 
kleinen µC Interface vernünftig hin.

Ich steuere meine Heizung mit einem RasPi der über UART mit einem 
Bus-Interface (ATMega8) kommuniziert. Das Bus-Interface übernimmt 
hierbei autonom die Beantwortung des Pollings und das TX-Prozedere.

Gruß

[strauch (Gast)]

Hallo Norbert,

schön zu sehen das du auch an den Sendenteil gehst. Leider kann ich dich 
Knowhow mäßig nicht unterstützen. Ich versuche mich zur Zeit in FHEM 
Modulprogrammierung einzulesen, leider ist meine Zeit Nachwuchsbedingt 
recht knapp. Ich bin schon froh das du da soviel Arbeit leistest und das 
alles nach vorne bringst. Ich hab es auch nachvor nicht mal geschafft, 
das bisherige nachzubauen, auch wenn ich schon alle Bauteile habe.

Ich bin gespannt wo das noch alles hinführt, mich wundert eigtl. das es 
für viele Thermen schon was gibt nur für Junkers nicht, hier bei uns in 
der Gegend wird sogut wie nur Junkers verkauft, das da nicht mehr Leute 
bei sind.....

Grüße

strauch

[fsigloch (Gast)]

http://www.raspberrypi.org/forums/viewtopic.php?f=44&t=14353

schade der uart kann break aber die pins sind nicht rausgeführt

[Norbert S. (junky-zs)]

Hallo,

strauch schrieb:
>... leider ist meine Zeit Nachwuchsbedingt recht knapp.
Nachwuchs geht vor, daß ist doch klar. Must nur rechtzeitig den in die 
richtigen Bahnen lenken, damit der nicht nur Dir die Pulle(Flasche) aus 
der Hand nimmt sondern alsbald mal den Lötkolben :-)
FHEM ist genau die Sache die ich z.Zeit garnicht bearbeite und deshalb 
ist die bei Dir genau richtig aufgehoben.

fsigloch schrieb:
>schade der uart kann break aber die pins sind nicht rausgeführt
Ja, Schitt can happen. Eigenlich ein geiles Maschinchen, reich an Power 
aber ARM an Anschlüssen.
Muss dann wohl eine andere Lösung her. Wir Arbeiten dran.

Gruß Norbert

[fsigloch (Gast)]

Hallo Norbert,

evtl. kannst du den break so erzeugen :

Kiste says:
December 27, 2012 at 3:01 AM

Some UARTS do not support break signals, or only breaks which are too 
short for DMX specs. If you’re having these troubles (don’t know much 
about the pi’s uart yet) you can always generate the break using a 
seperate GPIO pin, OR’d or ANDed with the TX line. Remember that the 
break will not get queued in the FIFO, so you have to make sure that all 
the buffered data has been sent out before generating the break. This 
probably must be observed even for a uart-generated break.

Gruss Ferdinand

[Norbert S. (junky-zs)]

Hallo Ferdinand,
bitte schau Dir noch mal den Link an, dort habe ich nach der 
Konfiguration des MiniUART und des PL011 gefragt.
Antwort ist:
>If you are running Linux on your Pi then you are already using the PL011,
>not the Mini UART. There are no drivers for the Mini.

http://www.raspberrypi.org/forums/viewtopic.php?f=44&t=14353

An den RX/TX Pins liegt also schon ein vollwertiger UART dran u.A. mit 
RX-BREAK Erkennung und TX-BREAK senden.

Jetzt kommt 'nur noch' die Software ins Spiel. Und diese muss gewisse 
Rahmenbedingungen einhalten:
1. RX-Empfang (klar) und RX-BREAK-Signalerkennung für RX-Message 
Ende-Signal.
2. Auswertung für TX-Antwort
3. Nach ca. 5 bis ca. 20msec TX-Antwort mit TX-BREAK-Signal am Ende der 
Übertragung.
Dieses Timing muss wohl immer eingehalten werden damit keine 
'~Störungen' von der Zentrale erkannt werden. Dies ist schwierig bis 
garnicht zu realisieren, wenn man eventuell noch APACHE und mysql 
nebenher laufen hat.

Fakt ist:
1. Wer 'nur' HT3-Telegramme empfangen und auswerten will, kann dies 
jetzt schon mit dem vorgestellten Adapter und Software kraftvoll tun.

2. Wer auch noch HT3-Telegramme senden und damit die Heizung steuern 
will muss sich noch ein wenig gedulden, eine andere Lösung aus der 
Schublade holen oder die Junkers-Hardware kaufen.

Die Realisierung für den EMS-Bus (siehe oben: Psssst ...) ist sicher 
eine wohl nicht direkt passende aber anpassbare Lösung.

Ich bin offen für Ideen und Vorschläge allgemein und insbesondere für 
den Punkt 2.

Gruß Norbert

[fsigloch (Gast)]

Vielleicht verrät der Psssst ... sein Atmega Programm.

Gruß Ferdinand

[fsigloch (Gast)]

Wirklich so schnell ?

---Nach ca. 5 bis ca. 20msec TX-Antwort mit TX-BREAK-Signal--



In den EMS Unterlagen steht was von 200ms:

Der Busmaster fragt mehrmals in der Sekunde alle Busteilnehmer ab 
(Polling). Wenn ein Busteilnehmer auf den Bus zugreifen möchte hat er 
etwa 200ms Zeit bis er der nächste Teilnehmer seine Zeit bekommt. Wenn 
der Busteilnehmer nichts mehr senden möchte beantwortet er die Abfrage 
sofort.

Gruß Ferdinand

[Norbert S. (junky-zs)]

Hallo,
>Wirklich so schnell,nach ca. 5 bis ca. 20msec TX-Antwort... ?
>In den EMS Unterlagen steht was von 200ms:
Das sind Werte die ich gemessen habe zwischen einer Abfrage des 
Bus-Masters und der Antwort des Gerätes. Wiederholt wurde die Abfrage 
des Busmasters auch schon mal nach ca. 150 msec.
Bei einer grösseren Anlage wird es da wohl etwas enger, der Busmaster 
wird dort dann wohl auch nicht in so kurzen Abständen abfragen.

Das mit den 200msec bei EMS passt ja dann schon fasst.
Werden sicher noch mehr Details ähnlich sein.
Werde dort mal nachsehen.

Gruß Norbert

[fsigloch (Gast)]

Hallo Norbert,

hast du ein Amateurfunkrufzeichen ? Meins ist DB2SG.

Gruß Ferdinand

[Norbert S. (junky-zs)]

Hallo,
>hast du ein Amateurfunkrufzeichen ?
Nein. Falsche Forum.

Gruß Norbert

[Heiko R. (Gast)]

Letzte Woche Donnerstag wurde meine neue Heizung installiert, heute die 
letzten Anschlüsse fertiggestellt. Und der USB-Adapter installiert. Was 
soll ich sagen? Es funktioniert. Auch mit der Heatronic 4i. Vielen Dank, 
Norbert.

[fsigloch (Gast)]

Hallo Norbert,

da hat doch einer von Junkers behauptet Netcom 100 und MB LAN2 dürften
nicht gemeinsam angeschlossen sein. Hab ich ja so gemacht. Es müsste 
dann aber eine Fehlermeldung Störung 14 Kode 117 (unzulässiger 
Busteilnehmer
kommen). Die kam aber nicht... Also MB LAN2 weiterhin verwerfen.

Evtl. bekomme ich vom Heizungsbauer eine CSW14 Leiterplatte und einen 
FR100.
Es dauert aber noch, sobald ich die Teile habe , melde ich mich wieder.
Ich versuche dann der Leiterkarte den Rest der Heizung durch Widerstände
Spannungen etc. vorzugaukeln, dann könnten wir gefahrlos 
experimentieren.



Gruss Ferdinand

[Norbert S. (junky-zs)]

Hallo,
Heiko R. schrieb:
>Es funktioniert. Auch mit der Heatronic 4i
Glückwunsch zur neuen Heizung. Das Wetter ist zwar nicht danach um diese 
zu nutzen, höchsten für den Solarertrag. Gut zu wissen ist aber, daß der 
Adapter und die SW auch mit der Heatronic 4i können.
Der eine oder andere Punkt in den HT4i-Protokollen wird neu sein und 
somit noch nicht ausgewertet werden. Wenn Du Zeit und die Möglichkeit 
hast ein Logfile über einen längeren Zeitraum zu erzeugen würde das 
schon helfen.

Welche Systemanteile sind bei Dir verbaut?
Eventuell ergibt sich dann noch Anpassbedarf an der Software.

Ich selber bin dabei den aktuellen Software-Stand mit den Informationen 
von Frank fertigzustellen. Diese werde ich dann auf github.com 
bereitstellen.

fsigloch schrieb:
>Evt. bekomme ich vom Heizungsbauer eine CSW14 Leiterplatte und einen FR100
Klingt gut. Du hast einen freundlichen Heizungsbauer. Ich arbeite noch 
dran. Interessant wird das ganze, wenn Netcom 100 oder MB LAN2 
dranhängen. Der HT3_Sniffer kann dann an der CSW14 Leiterplatte zentral 
im HT3-Bus gute Dienste leisten. Hast Du die Möglichkeit einen 
HT3-Snifferadapter herzustellen? Falls nicht, stelle ich Dir einen zur 
Verfügung.
Info an PM reicht.

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo,

hier als html-File die bisher bekannten HT3-Telegramme (bitte das 
TAR-File entpacken).
Der aktuelle Software-Stand berücksichtigt die bekannten Werte.
Da alle Anlagen eines gemeinsam haben, sie sind unterschiedlich; kann 
die Systemeingenschaft konfiguriert werden.

Dies alles nur zur Geschmacksbildung, wenn fertig und auf github.com 
kanns weitergehen.

Gruß Norbert

[Heiko R. (Gast)]

Hallo Norbert,

ich habe die Junkers Cerapur ZSB 14-4C, den Warmwasserspeicher ST-120 
und den witterungsgeführten Regler FW-120.

Aufgefallen ist mir, dass bei mir die Warmwasser-Messages sehr selten 
kommen und oft Fehler bei den crc vorkommen. Das werde ich mal näher 
unter die Lupe nehmen.

Gruß,
Heiko

[fsigloch (Gast)]

Hallo Heiko,

evtl. stimmt die Schaltschwelle nicht. Sie muss zwischen ca. 15 Volt 
(High)
und 10 Volt (Low) auf dem Bus liegen, also bei ca. 12,5 Volt.
Das heisst Spannung grösser 12,5 Volt Diode leuchtet , kleiner 12,5 Volt
leuchtet nicht . Sollte symmetrisch funktionieren.

Norbert beschreibt einfachen Test mit Schwelle bei  11 Volt :
(evtl. mal auf Bus mit Oszi messen was High und was Low ist ,Mittelwert 
ist
Schwelle)

Funktionsprüfung ohne Heizungs-Anschluss mit Prüfspannung.
Eine externe Spannung von ca. 14-15 Volt (geladene Autobatterie ect.) an
den HT3-Bus Printklemmenblock anschliessen. Die LED D3 muss aufleuchten,
wenn die Polarität der Eingangsspannung passt. Stromaufnahme dabei
grösser als 1.6 mAmpere aber weniger als 5 mAmpere.
Gleicher Test mit reduzierter Eingangsspannung von weniger als 11 Volt.
Die LED D3 darf garnicht oder nur wenig leuchten. Die Stromaufnahme muss
weniger als 1 mAmpere sein. Falls dies nicht passt bitte den Anschluss
der Zenerdiode D2 prüfen.

Gruss Ferdinand

[Norbert S. (junky-zs)]

Hallo,

Heiko schrieb:
>dass bei mir die Warmwasser-Messages sehr selten kommen und oft Fehler bei
>den crc vorkommen.
Wenn die anderen Telegramme angezeigt werden, glaube ich nicht recht an 
ein Hardware-Problem.
Woran hast Du gesehen, daß häufig crc-Fehler kommen?
Die Telegramme kommen je nach Type im Rythmus von ca. 15, 30 und 60 
Sekunden, bzw. dann wenn eine Änderung in den Daten auftritt.
Bei mir sieht man die WW-Telegramme ca. alle 30 Sekunden.
Auf dem Bus sieht man im RAW-Datenstrom jedoch mehr Telegramme (z.B. von 
der Steuerung (Polling)) die keinen CRC-check haben und dies kann den 
Eindruck verfälschen.
Es kann jedoch auch einen Zusammenhang mit dem HT4i-Bus geben.
Bitte aktualisiere auch die Software. Diese ist jetzt auf dem github.com 
- Server zu finden unter:
URL:  https://github.com/norberts1/hometop_HT3.git

Gruß Norbert

[Heiko R. (Gast)]

Moin moin,

vielleicht habe ich mich da etwas missverständlich ausgedrückt. Nicht 
alle Telegramme haben augenscheinlich bei mir ein Checksummen-Problem, 
nur die der Warmwasserdaten. Auffällig war, dass ich relativ schnell 
alle Werte bekommen habe, nur die Warmwasserdaten kamen sehr spät und 
wurden nur selten aktualisiert. Beim Erstellen eines Moduls für FHEM 
fiel mir auf, dass zwar häufig Warmwasserdaten gesendet wurden, aber 
meistens ein Checksummenfehler auftrat. Ich logge mal gerade mit und 
versuche, die Ursache zu finden. Ich gehe auch nicht von einem 
Hardware-Problem aus, da die restlichen Telegramme (auch die, die nicht 
ausgewertet werden) gut aussehen.

Gruß,
Heiko

[Heiko R. (Gast)]

Update:

Ich habe etwas mitgeloggt und mir die Telegramme für 88 00 34 00 
angesehen. Ich habe 25 Bytes und damit stimmt auch die Checksumme.

Komplettes Telegramm:
88 00 34 00 38 02 1F 02 1F A1 00 00 03 00 00 01 6D 00 00 29 00 80 00 DC 
00

Ich werde mal beobachten, ob er irgendwann mal ein kürzeres Telegramm 
einschiebt, das würde erklären warum ich sehr spät Wasserdaten bekommen 
habe.

Gruß,
Heiko

[Norbert S. (junky-zs)]

Hallo Heiko,
das WW-Telegramm ist mit 25 Byte länger als das was bisher im Decoder 
ausgewertet wurde (Länge 23)und bisher bekannt war.
Die zwei Bytes 80 00 am Ende vor dem CRC:= DC und dem Break:=00 sind 
offensichtlich zusätzlich.
Falls sich das konstant so bestätigt, ist eine Anpassung im Decoder 
erforderlich. Fürchterliches rumgefrickel was die da an Protokollen auf 
den Kunden loslassen, na ja ist ja nur Software und die passt sich halt 
an.
Um dem ganzen dynamisch beizukommen und ich mir ziemlich sicher bin, daß 
die 80 00 am Ende vor dem CRC konstant ist, schlage ich vor den CRC-test 
mit 23 Byte Datenlänge durchzuführen (wie jetzt schon vorhanden) und 
wenn dieser fehlschlägt_ die restlichen 2 Byte nachladen und _erneut 
CRC-check durchführen.
Dies ist zwar nicht schön, aber den Mist haben andere verbockt und weil 
wir z. Zeit keine Break-Erkennung drin haben sind wir auch noch selber 
schuld.
Ich denke Du bekommst das zum fliegen und beobachtest das noch ein 
wenig.

Nichts ist schöner als eine Heizung die man nicht braucht 
(wetterbedingt) :)

Gruß Norbert

[Heiko R. (Gast)]

Hallo Norbert,

ja, die 80 00 ist bisher konstant. Möglicherweise habe ich noch zwei 
andere Telegramme gefunden : 88 00 1C 00 und 88 00 2A 00. Und irgendeine 
andere "Anomalie" schwirrt da auch noch rum, aber da kann ich noch keine 
Regelmäßigkeit finden.

Ich hatte so eine ähnliche Idee, ich probiere erst 25, dann 23, dann 22. 
Die nicht benötigten Bytes bleiben einfach im Puffer.

Gruß,
Heiko

[Heiko R. (Gast)]

Moin moin,

es ist mal wieder ein neues Telegramm aufgetaucht:

9000ff0000d3010000aa00 900009008900

Natürlich stimmt die Checksumme nicht, wohl aber für den Teil bis zum 
Leerzeichen (checksumme aa). Das Telegramm kommt etwa alle 10 Minuten 
und bisher blieb es gleich. Der Teil nach dem Leerzeichen variiert 
manchmal.

Gruß,
Heiko

[Heiko R. (Gast)]

Moin,

Update:
Es gibt noch ein Telegramm 9000ff0000d3020000a600. Dieses kommt bei mir 
auch etwa alle 10 Minuten in der Zeit von 23 Uhr. Ab 5 Uhr kommt wieder 
9000ff0000d3010000aa00.

Gruß,
Heiko

[Norbert S. (junky-zs)]

Hallo Heiko,
ja, das Telegramm habe ich auch bei mir gefunden, ist somit nicht HT4i 
speziell, habe dort jedoch bei gleicher Länge etwas andere Werte:

 90 00 ff 00 00 d3 00 0a 00 ba 00

Es wird auch etwa alle 10 bis 20 Minuten gesendet. Gefunden bei mir in 
einem alten Logfile.
Werde dies gleich in den Dekoder einbauen und länger laufen lassen. Mal 
sehen was dem so soll.

Was macht Deine WW-Auswertung, bist Du da weitergekommen?

Gruß Norbert

[Heiko R. (Gast)]

Hallo Norbert,

das FHEM-Modul läuft soweit. Es sind allerdings wieder zwei Telegramme 
aufgetaucht (wieder 90FF00, aber diesmal wahrscheinlich länger). Diese 
hängen wohl mit einer Tag/Nacht-Umschaltung zusammen, eines kommt 
morgens, das andere abends. Ansonsten kommen keine CRC-Fehler mehr 
durch. Ich werde kurz vor der Umschaltung heute Abend nochmal ein Log 
mitschreiben, um die Länge rauszufinden. Dann muss ich mir nochmal die 
Heizungsmodi ansehen, da habe ich ein paar Umschaltungen gesehen, die 
ich noch nicht ganz verstehe.

Gruß,
Heiko

[Heiko R (Gast)]

Hallo Norbert,

ich habe noch zwei neue Nachrichten gefunden, diesmal mit 9 Bytes Länge
  90 00 ff 00 00 6f 02 c4 00
  90 00 ff 00 00 6f 03 c5 00

Sie werden nur zu den Umschaltzeiten gesendet (bei mir die erste um 22 
Uhr und die zweite um 05 Uhr). Sie geben also den neuen Heizmodus 
(Comfort, Eco, Frost) an.

Gruß,
Heiko

[fsigloch (Gast)]

Hallo Norbert,

ich habe jetzt eine CSW14 Leiterplatte und einen FR120 Regler.

Die Stecker und Buchsen sind ein großes Problem, wahrscheinlich muss

ich mir die original Kabelbäume besorgen, anlöten will ich nicht.

Wenn ich es je zum Laufen kriege, hoffe ich auf starke Software-

Unterstützung von dir. Ich melde mich dann.


Gruß Ferdinand

[fsigloch (Gast)]

Hallo Norbert,

der Heizungssimulator läuft soweit, Widerstände simulieren die Fühler.

Die fehlende Heizungspumpe wird  mit H5 Fehler angezeigt.

Der CRC Check für 90 00 FF (FR200) ist im Moment ausgeschaltet,

irgendwie scheinen die was geändert zu haben. Vorlauf Rücklauf Außen 
Temp

wird normal angezeigt.

Jetzt könnte ich Software Hilfe gebrauchen.


Gruß Ferdinand

[fsigloch (Gast)]

Hallo,

offensichtlich findet der CRC-Check beim FR 200 Regler mit Byte 12 
statt.

Jetzt brauch ich einen Einstieg um die Temperatur über den Bus zu 
stellen.

Die Software soll nicht grafisch sein.


Gruß Ferdinand

[Norbert S. (junky-zs)]

Hallo Ferdinand,

prima das es jetzt läuft.
Um den Protokollen ein wenig auf die Spur zu kommen habe ich das 
TAR-File (ttytest-logger) angehängt welches Dir die Daten binär 
aufzeichnet. Bitte länger laufen lassen und Logfile mir zusenden oder 
hier posten. Kann dann parallel den Inhalt analysieren.
Bitte die Schnittstelle (ttyAMA0 oder ttyUSB0) vor dem Start auf die 
richtige Baudrate (9600) einstellen:
1. stty -F /dev/ttyAMA0 9600
oder
2. stty -F /dev/ttyUSB0 9600
Bin u.A. dabei die Software um die BREAK-Erkennung bei RX-Telegrammen zu 
erweitern. Dies läuft jedoch noch nicht zuverlässig und deshalb vorab 
dieses log-tool.

Du könntest jetzt auch das Netcom 100 bzw. MB LAN2 an den Bus hängen um 
dort die Protokolle mitzuschneiden.

Gruß Norbert

[fsigloch (Gast)]

Hallo Norbert,

MB LAN hab ich nicht mehr.

Mit Netcom 100 hab ich einmal 23 Grad eingestellt und danach

22 Grad. (Hoffe das Loggen hat funktioniert).

Es wurde nicht am Übungsystem gemessen,sondern an der echten Heizung.

Ich kann das Netcom nicht ans Übungsystem hängen, weil ich es

an der echten Heizung brauche.

Das Übungsystem ist ja eigentlich zum Senden gedacht. TX über einen 
Opto-

koppler ist auch schon vorgesehen. Das Netcom sollte später

noch parallel dranbleiben können. Ich hoffe , daß es nicht so ist wie

der Junkers Service behauptet : Entweder MB LAN oder Netcom 100 und wir

auch über die Adresse vom Netcom gehen müssen.


Gruß Ferdinand

[fsigloch (Gast)]

Hallo Norbert,


von deiner Schaltung gibt es da eine Leiterplatte ?
Könntest du mir eine Unbestückte zusenden ?
Bestücken kann ich sie selbst.



Gruß Ferdinand

email:[e-mail]

[Norbert S. (junky-zs)]

Hallo Ferdinand,

der HT3-Sniffer Adapter ist unterwegs, wird wohl heute bei Dir ankommen.

Hinweis:
 Nicht jeder der misst ist eine Messi.

Gruß Norbert

[fsigloch (Gast)]

Hallo Norbert,

was ist damit gemeint ?


Messi : schwerwiegendes Defizit Aufgaben zu organisieren ?

Oder Lionel Messi?

Gruß Ferdinand


Norbert S. schrieb:
> Hallo Ferdinand,
>
> der HT3-Sniffer Adapter ist unterwegs, wird wohl heute bei Dir ankommen.
>
> Hinweis:
>  Nicht jeder der misst ist eine Messi.
>
> Gruß Norbert

[Norbert S. (junky-zs)]

Hallo Ferdinand,

>was ist damit gemeint ?
eigentlich nur ein schwerwiegendes Wissensdefizit bei HT3 zu verkleinern 
und ich hoffe, daß der Adapter Dir und uns dabei hilft :)

Gruß Norbert

[Robert S. (dings)]

Hallo Wissende,

das ist ein sehr schönes Projekt, und es wird scheinbar immer besser. 
Aber wie kann ich mir denn sicher sein, ob ich eine Heatronic 3 vor mir 
habe? Antwort: Hast Du FW100, hast Du Heatronic 3.

(Wer richtig suchen kann, ist klar im Vorteil, und in der 
FW100-Installationsanleitung steht's: "Der FW100 kann nur an ein 
Heizgerät mit BUS-fähiger Heatronic 3 angeschlossen werden.")

Prima also! :-) Das Kunstwerk kann man nach dem Lösen einer Schraube 
(bei mir) nach vorne klappen und hinten gibt es da eine wunderschöne 
freie Schnittstelle (2 blaue Kabel mit Schraubanschluss). Sieht 
einladend aus, aber dort kommen laut Messgerät nur 5V an, das passt also 
irgendwie gar nicht gut zu den bisherigen Erkentnissen und Norberts 
Forschung. Wo genau schnappt man sich nun am besten den Bus für 
Anschluss an den (wenn das Mistwetter beginnt unbedingt zu bauenden) 
Adapter?

Gruß, Robert

[Norbert S. (junky-zs)]

Hallo Robert,
>Aber wie kann ich mir denn sicher sein, ob ich eine Heatronic 3 vor mir
>habe? Antwort: Hast Du FW100, hast Du Heatronic 3.
Ja, die Fxyz Serie kann nichts anderes :), aber das kommt uns sehr 
entgegen!

Der Anschluss muss an den beschrifteten Klemmen 'B' erfolgen. Habe ein 
Bild meiner FW100 Anschluss-Platte beigefügt und den Schaltplan (Bild15) 
aus der FW100 Installationsanweisung.
Ich entnehme aber Deiner Beschreibung, das bei Dir der Regler FW100 
nicht an der Wand sondern direkt in der Heizungsteuerung montiert ist. 
Aber auch dort sind es die Anschlussklemmen 'B' für den Heatronic-Bus.
Ich kenne Deinen Kesseltyp nicht, daher schau bitte in den 
Installations-Unterlagen der Heizung nach.
Wenn nicht vorhanden gibt es die bei junkers.com.
Wenn Deine Heizung nicht so alt ist (ca. > 2010) hat die den HT3-Bus 
drin.
Die gemessene Spannung muss aber grösser als 5 Volt sein, ca 10 bis 16 
Volt.
Die zappelt zwar ein bischen wegen der Signalisierungen, geht aber 
niemals auf 5 Volt.

Gruß Norbert

[Robert S. (dings)]

Hallo Norbert,

danke für die Bilder. Das ist immer super!

> Ja, die Fxyz Serie kann nichts anderes :), aber das kommt uns sehr
> entgegen!

Das fand ich auch extrem nett. ;-)

> Der Anschluss muss an den beschrifteten Klemmen 'B' erfolgen.

Das mit dem "B" hatte ich schon oben gelesen, bei mir auf die Schnelle 
aber keine passende Beschriftung entdeckt, was aber wohl einfach darauf 
zurückzuführen ist, dass bei mir der FW100 direkt eingebaut ist (wie Du 
schon richtig geschlossen hast).

> Aber auch dort sind es die Anschlussklemmen 'B' für den Heatronic-Bus.

OK. Ich hatte mich gestern noch nicht getraut das weiter 
auseinanderzubauen, denn da war an einer Stelle irgend so ein Kleberchen 
drum. Vermutlich, damit nicht jeder dahergelaufene Bastler seinen RPi da 
anschliesst, ohne dass man ihm nachher die Garantiebedingungen um die 
Ohren hauen kann. Aber ich werde wohl am Wochenende noch einmal 
vorsichtig auf die Suche gehen. Kann ja wohl nicht sein, dass man immer 
vor dem Ding stehen und sich durch die Menüs hangeln muss, nur um mal zu 
sehen, ob es ihm gut geht.

> Ich kenne Deinen Kesseltyp nicht, daher schau bitte in den
> Installations-Unterlagen der Heizung nach.

Nennt sich "ZBS 14/210 S-3 MA..." und ist alles in so einem Kombi-Block, 
dazu gibt's Solar auf dem Dach und einen Temp-Fühler draußen. 
(Vermutlich sind also die blauen Kabel für irgend etwas anderes 
Schlaues.) Aber sprechen nicht auch auch die anderen Komponenten, also 
z.B. der Regler für den Solarkreislauf oder der Außenfühler über den 
Bus? Dann könnte man ja vielleicht auch dort irgendwo aufspringen.

Gruß Robert

[Fsigloch (Gast)]

Hallo Robert,

auf Seite 25 ist der Busanschluss deiner Heizung.

Gruss Ferdinand

[Norbert S. (junky-zs)]

Hallo Robert,
in Deiner sehr kompakten Anlage hast Du, Junkers sei Dank 
Standardkomponenten verbaut. Für den Solaranteil ist das Modul ISM1 
zuständig und dies ist links an Deiner Heizung befestigt (Verkleidung 
abnehmen).
Das ISM1 habe ich ebenfalls und viele andere wohl auch, daher habe ich 
ein Bild beigefügt aus dem der Anschluss hervorgeht.
Der Heatronic-Bus liegt auf den rechten zwei Klemmen mit B bezeichnet.

Und Junkers hat sogar noch eine Einführtülle freigehalten damit wir uns 
daran anschliessen können, sehr gut.

Wie gesagt, wir bleiben in Kontakt :)

Gruß Norbert

[Robert S. (dings)]

Hallo Norbert,

danke für's Aufschrauben Deines ISM1 und das Foto!

> Das ISM1 habe ich ebenfalls und viele andere wohl auch, daher habe ich
> ein Bild beigefügt aus dem der Anschluss hervorgeht.
> Der Heatronic-Bus liegt auf den rechten zwei Klemmen mit B bezeichnet.

Da kann ja nix mehr schief gehen (und ich kann bei mir sogar das 
"Siegel" in Ruhe lassen).

Bevor ich jetzt in meinen Kramkisten suche und dann die Bestellung für 
die fehlenden Einzelteile abschicke: Zu welchem Deiner Modelle würdest 
Du heute raten (bzw. würdest Du von einem eher abraten)? Bei mir wird 
auf jeden Fall ein Raspberry Pi das Auslesen übernehmen, denn der wohnt 
da eh schon in der Nachbarschaft der "Kompaktheizzentrale".

Viele Grüße, Robert

P.S. Ferdinand: Besten Dank für's PDF!

[Norbert S. (junky-zs)]

Hallo Robert,
>Zu welchem Deiner Modelle würdest Du heute raten (bzw. würdest Du von einem eher 
abraten)?
Alle Module (HT3_Adapter und HT3_MicroAdapter) sind gleichwertig, 
unterscheiden sich auf der HT3-Busseite garnicht und auf der 
Auswerteseite nur durch den direkten UART- bzw. virtuallen 
UART-USB-Anschluss. Beide Versionen laufen am RaspberryPi.
Beide Versionen sind gleichgut beim Empfang von Bus-Telegrammen.
Für das kontrollierte Senden von Telegrammen auf dem Bus sind beide 
nicht so gut geeignet (siehe weiter oben).
Für das kontrollierte Senden auf dem HT3-Bus ist ein modifizierter 
Adapter in Arbeit jedoch noch nicht fertig.
Wenn Du den HT3_Microadapter nimmst, hast Du die Port-Pins des 
RaspberryPi noch für andere Dinge frei und Du kannst den Adapter bei 
Bedarf auch noch woanders anstöpseln.

Gruß Norbert

[Hartmut D. (Gast)]

Hallo Heiko,
Heiko R. schrieb:
> Ich habe etwas mitgeloggt und mir die Telegramme für 88 00 34 00
> angesehen. Ich habe 25 Bytes und damit stimmt auch die Checksumme.
>
> Komplettes Telegramm:
> 88 00 34 00 38 02 1F 02 1F A1 00 00 03 00 00 01 6D 00 00 29 00 80 00 DC
> 00
>
> Ich werde mal beobachten, ob er irgendwann mal ein kürzeres Telegramm
> einschiebt, das würde erklären warum ich sehr spät Wasserdaten bekommen
> habe.

Konntest du hier schon etwas genaueres herausfinden?
An unserer Heizung kann ich auch nach Stunden noc keine "Warmwasser" 
Telegramme empfangen (neueres Modell von 4/2014).

Wenn ich irgendwie die Suche unterstützen kann, sagt bescheid.

Gruß
Hartmut

[Arne M. (armut)]

Tolles Projekt! noch 2 Ideen:

Du kannst auf deiner Platine noch einen Stepdown für 3,3V 
implementieren. Aus denen kannst du dann den Pi versorgen und den Pi 
eigenen Spannungsregler kannst du dann stilllegen.

Den Tasteranschluss mit Stiftleiste und Rastnase und keine reine 
Stiftleiste nehmen.

[strauch (Gast)]

Arne M. schrieb:
> Du kannst auf deiner Platine noch einen Stepdown für 3,3V
> implementieren. Aus denen kannst du dann den Pi versorgen und den Pi
> eigenen Spannungsregler kannst du dann stilllegen.

Die Idee hatte ich auch schon. Norbet möchte aber die beiden Geräte 
galvanisch getrennt haben, deshalb ist das nicht möglich.

[Norbert S. (junky-zs)]

Hallo,
es hat sich wieder was auf der Hardwareseite getan.
Die Signal Break-Erkennung und das kontrollierte Senden auf dem 
Heizungsbus war bisher ja ein Problem.
Rein durch Software war dies schlecht zu lösen.
Deshalb habe ich den Heizungsbus-Adapter überarbeitet und ihm einen 
Atmel spendiert.
Dieser ist als 'Erfassungs-Frontend' für die Erkennung und das Senden 
von Break-Signalen und Daten auf dem seriellen Bus zuständig. Weiterhin 
wird konsequent die galvanische Trennung im RX-/TX-Zweig verwendet (man 
will ja bei dem Wetter keine kalten Füße bekommen).
In der Dekodierungs-Software (hometop_HT3) ist nur die Baudrate von 9600 
auf 19200 Baud zu ändern, weitere Änderungen sind z.Zeit nicht 
erforderlich (File: ./lib/ht3_worker.py Zeile:63)
Als Interface zum RaspberryPi wird weiterhin die serielle Schnittstelle 
benutzt (19200 8N1) und auf der Heizungs-Busseite natürlich 9600 8N1.

Ebenfalls ist das Senden von Bus-Kommandos mit diesem Adapter möglich. 
Der Adapter ist dabei als 'Modem' mit der zugehörigen Adresse (0d)hex 
eingestellt und sendet die ihm übergebenen Daten gemäß dem 
Bus-Protokoll. Es läßt sich also damit eine Fernsteuerung der eigenen 
Heizung ähnlich Netcom100 realisieren.
Die zugehörige Software ist vorhanden (Python3, Adapter-extern) und 
funktioniert auch, nötige Anpassungen sind jedoch noch nicht fertig.

Das ganze läuft unter dem Titel: 'ht_transceiver' und hat die zwei 
Adaptertypen 'ht_piduino' und 'ht_pitiny'.

Einige Antworten auf Fragen die noch garnicht gestellt wurden:

Wozu zwei Adapter?
Dies ist ein Teil der Entwicklung und ja das Bessere ist des Guten Feind 
(wobei jeder selbst entscheiden muss was nun besser ist).
Beide unterscheiden sich NICHT in ihrer Funktionalität, der ht_pitiny 
ist eine Weiterentwicklung des 'ht_piduino'.

Welchen Adapter würde ich auswählen?
Na wohl den 'ht_pitiny'. Immerhin hat der vier 911 an board. Wer hat das 
sonst schon im Stall!

Welche Gründe für die Weiterentwicklung?
Der 'ht_piduino' ist doch recht stramm bestückt und der Prozessor in 
diesem Gehäuse ist auch nicht der kleinste. Dies kann eng auf dem 
RaspberryPi werden, zumal wenn man dort einen Kühlkörper auf der CPU 
hat. Es könnte zu thermischen Problemen führen wenn man auch noch ein 
Gehäuse drum hat. Allerdings hat der 'ht_piduino' auch mehr Speicher und 
Platz für Erweiterungen.

Wie komme ich an die Software- und Hardware-Informationen?
Diese ist wie gehabt auf github abgelegt unter:
 https://github.com/norberts1/hometop_ht_transceiver.git
Dort sind die Source-/Binär-Files und die Dokumentation abgelegt. Die 
Software ist mit Atmel-Studio 6.2 erstellt.

Ist der Adapter auch für andere Heizungssysteme geeignet?
Ja, nicht nur Junkers- sondern auch Buderus-Heizungen können mit diesem 
Adapter gesteuert werden!.
Bei Junkers-Heizungen ist dies jetzt schon möglich, bei Buderus EMS muss 
die Lower-Level (uart) Software des 'ht_transceiver' angepasst werden. 
Hier auch noch mal heissen Dank an Danny Baumann und seine Vorarbeit 
beim EMS -> Beitrag "EMS > Adapter > NetIO > Raspi"
Sicher können auch noch Heizungen anderer Hersteller mit diesem Adapter 
gesteuert werden, Bedingung ist ein serieller Bus und die Signalisierung 
auf der 2-Drahtleitung. Alles andere ist dann Software-Sache!


Ganz besonders möchte ich mich hier bei Fsigloch für die Unterstützung 
bedanken. Ohne ihn wäre dies nicht so schnell möglich gewesen !

Gruß Norbert

[strauch (Gast)]

Norbert S. schrieb:

> Ganz besonders möchte ich mich hier bei Fsigloch für die Unterstützung
> bedanken. Ohne ihn wäre dies nicht so schnell möglich gewesen !

Hallo Norbert,

ich ähh bin beeindruckt. Also ich möchte mal ein ganz dickes Dankeschön 
an dich für diese tolle Arbeit los werden :-).

Eine Frage stellt sich mir noch, kann man die Platine zur Bestückung 
irgendwo bei dir bekommen? Vielleicht auch schon teilweise vorbestückt? 
(SMD Bauteile?)

Dankeschön

strauch

[Norbert S. (junky-zs)]

strauch schrieb:
>...kann man die Platine zur Bestückung irgendwo bei dir bekommen?
> Vielleicht auch schon teilweise vorbestückt? (SMD Bauteile?)
Habe eine bestückte ht_piduino und zwei bestückte ht_pitiny Platinen zur 
Verfügung. Ansonsten nur noch wenige unbestückte ht_pitiny Platinen.
PM an mich für weitere Informationen.

Gruß Norbert

[Heiko R. (Gast)]

Hallo Norbert,

wenn ich das richtig sehe, werden HT_piduino und HT_pitiny auf den 
GPIO-Port des Raspberry Pi gesteckt (analog zum HT3-MiniAdapter)? Ist 
etwas ähnliches geplant mit dem UM2102 über USB? Ich möchte mir ungern 
die GPIO-Ports dichtmachen, da noch Gas- und Wasserzähler eine 
Auswertung spendiert bekommen sollen.

Gruß,
Heiko

[Norbert S. (junky-zs)]

Hallo Heiko,

genau für diesen Anwendungsfall habe ich mir einen passiven Adapter 
erstellt, der
1. eine 13*2-ploige Stiftleiste (wie beim Raspi) und
2. eine 6*1 und 2 Stück 5*1 Stiftleisten für das UM2102 bereitstellt.

Das UM2102 liefert dabei die 3.3Volt an den ht_transceiver und ist mit 
TXD und RXD entsprechend korrekt verbunden.
Ja und zusätzlich habe ich mir den 2*3 Poligen Sockel für die 
ISP-Programmierung gegönnt damit die Aktualisierung der Software einfach 
geht.
Somit kann man auch über USB die Daten erfassen (naja nicht wirklich 
neu, ausser jetzt mit korrekter Break-Erkennung) und auch bald die 
Heizung steuern.
Falls Schaltplan nötig, kann ich den hier quick and dirty bereitstellen.

PS: Für die FHEM Anbindung/Erweiterung (Senderichtung) kann ich 
Informationen bereitstellen. Einfach PM an mich.

Gruß Norbert

[strauch (Gast)]

Hallo Norbert,

ich muss noch mal eine philosophische Frage stellen ;-). Für was hält 
die Gastherme den Adapter eigtl. später für ein Wandthermostat wie das 
FW120 oder eine Fernbedienung wie das Junkers FB10?

Ich überlege wie man später denn die Steuerung der Therme am 
intelligentesten mit der Heimautomation macht. Sag ich einfach immer 
stumpf, Tag oder Absenktemperatur oder gebe ich der Therme besser eine 
"imaginäre" Raumtempereatur mit. Je nach Bedarf in irgendeinem Raum.

Danke und Grüße

strauch

[Norbert S. (junky-zs)]

Hallo,

strauch schrieb:
>Für was hält die Gastherme den Adapter eigtl. später für ein Wandthermostat wie 
>das FW120 oder eine Fernbedienung wie das Junkers FB10?

Der ht_transceiver ist als MODEM (Adr.: 0d)hex vorkonfiguriert und 
sendet den ihm übergebenen Telgramm-Inhalt auf dem HT-Bus (als 
Bus-Slave).
Mit den Telegrammen, die an den ht_transceiver Adapter gesendet werden, 
kann das Netcom100 nachgebildet werden. Siehe dazu die beigefügten 
Display-Bilder meines FW100.
Steuermöglichkeiten sind somit z.Zeit:
1. Netcom Betriebsart (Auto/Heizen/Sparen/Frost), Abkürzung 'NC' in der 
Anzeige
2. Temperaturniveau-Verstellung für Heizen, Sparen und Frost.

Die Junkers Netcom100 Beschreibung ist unter www.junkers.com vorhanden, 
dort steht leider auch nicht soviel drin.

Funktion des ht_transceiver - Adapters:
Der ht_transceiver fügt zum Telegramm-Inhalt nur seine eigene Adresse: 
(0d)h + (80)h -> (8d)h und die zugehörige CRC hinzu.
Die Junkers Geräte-Adressen sind teilweise identisch mit denen des Bosch 
EMS-Systems, siehe auch URL:
 http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:ems-telegramme
Der Adapter kann durch Software-Befehle auf eine andere Geräte-Adresse 
eingestellt werden und somit könnte er z.B. zu einer FB10/100 werden. 
Dies ist jedoch noch nicht getestet und falls eh schon eine FB10/100 im 
System vorhanden ist scheidet dies auch aus, denn ACHTUNG:
Es darf niemals die gleiche Adresse (Gerät) zweimal in einem Bus-System 
vorhanden sein, auch nicht zwei Modem's (0d)h. (Motto: Viele Geräte 
verderben den Telegramm-Brei!).

Fazit: Der ht_transceiver ist default auf die 'Modem-Adresse' 
eingestellt, lässt sich aber umkonfigurieren. Somit sind auch zwei und 
mehr 'ht_transceiver'-Adapter mit unterschiedlichen Adressen am gleichen 
HT-Bus denkbar.
Somit muss auch die übergeordnete Applikation für die Eigenschaft des 
'ht_transceivers' konfigurierbar sein (Modem/FB10/100 ect, zu sendende 
Telegramme hängen ja auch davon ab).
Ich hoffe einen Teil Deiner Fragen damit beantwortet zu haben!

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo Heiko,
hier der Schaltplan für einen passiven 'ht_transceiver <-> UART/USB' - 
Adapter.
Der Verdrahtungsaufwand ist überschaubar und ich habe dies auf einer 
Lochraster-Platine realisiert.

Mit dem Jumper J1 kann entweder 3.3 oder 5.0 Volt an den ISP-Adapter 
gelegt werden, jenachdem was für eine Betriebsspannung das Board hat.
Die verwendete Adapter-Betriebsspannung habe ich fest verdrahtet J1-1 -> 
3.3Volt und J1-2 5.0Volt (so wie beim RaspberryPi).

Gruß Norbert

[strauch (Gast)]

Hallo Norbert,

danke für die ausführliche und bebilderte Antwort, dass beantwortet 
meine Fragen :-).

Grüße

strauch

[Heiko R. (Gast)]

Hallo Norbert,

vielen Dank für die Erläuterungen und für die Arbeit. Hast Du zufällig 
noch eine pitiny-Platinw über? Ich muss die Neuerungen ja mal wieder ins 
FHEM-System einbringen.

Gruß,
Heiko

[strauch (Gast)]

Man bekommt den ATtiny841 SOIC bei guloshop . Bei mouser scheints eine 
Mindestbestellmenge zu geben. Ich hoffe die Werbung ist erlaubt, ich hab 
ne Weile suchen müssen, das Ding zu bekommen.

[Norbert S. (junky-zs)]

Hallo Heiko,
habe noch eine 99% bestückte da, und die fehlende Bauteile sind heute 
gekommen.
Reserviere die für Dich. Bitte PM an mich.
Kann maximal noch 3 ht_pitiny-Adapter bestücken.
Ansonsten wenn die Nachfrage passt (>10 Stück) werde ich im nächsten 
Jahr noch Platinen bestellen.

Den ATtiny841 bekommt man auch bei: http://www.hbe-shop.de/ (Heinz 
Buechner). Limit sind dort wohl jedoch 30€ Bestellsumme.

Gruß Norbert

[Marcus (Gast)]

Hallo Norbert,

ich bin über das fhem-Forum auf diesen Thread aufmerksam geworden.
Ich würde meine Junkers-Therme mit FW100 auch gerne über fhem steuern 
können.

Da ich zwar programmieren kann, löttechnisch jedoch zwei linke Hände 
habe, würde ich mich riesig freuen gegen eine Aufwandsentschädigung eine 
Platine für den Raspberry erhalten zu können.

Wenn das möglich wäre, wie wäre der weitere Ablauf?

Frohe Festtage wünscht Euch
Marcus

[Norbert S. (junky-zs)]

Hallo,

Marcus schrieb,
>...eine Platine für den Raspberry erhalten. Wenn das möglich wäre, wie wäre der 
>weitere Ablauf?
Bitte eine E-Mail (PM aus dem Forum) an mich, weiteres dann dort.

Euch ebenfalls
Stressfreie Weihnachten (ist selten geworden) und ein Gutes Neues Jahr.

Norbert

[strauch (Gast)]

@Norbert woran erkenne ich die richtige Polung beim neuen Adapter? Egal 
wieherum ich es anschließe die grüne LED blinkt nur. Ich bekomme 
momentan keine Daten auf die serielle Schnittstelle und muss mal ein 
paar Fehler ausschließen :-).

Ansonsten hoffe ich das alle Weihnachten gut überstanden haben, auch 
wenn es noch nicht ganz vorbei ist.

Danke

[Norbert S. (junky-zs)]

Hallo,
strauch schrieb:
>@Norbert woran erkenne ich die richtige Polung beim neuen Adapter?
Es gibt keine falsche Polung beim ht_transceiver (ht_piduino, 
ht_pitiny), da beide Adapter eine Brückenschaltung am Eingang haben.

>...die grüne LED blinkt nur
Die langsam blinkende grüne LED zeigt an, das kein Signal des HT-Bus 
erkannt wurde, Ursachen könnten sein:
1. Der SPI-Bus des Raspberry PI wird auch von anderen Devices verwendet.
2. Ein zugehöriger SPI-Treiber (z.B.: bcm2708_spi) belegt den SPI-Port.
Insbesondere die Blockierung des Pin J1-23 (SPI-CLK) könnte dazu führen, 
daß dieses Signal am Pin:PA4 (SCK) des ATtiny841 auf einem statisch 
festen Pegel liegt. Dieser Pin ist ja gleichzeitig mit 'HT RxD' 
Eingangssignal des HT-Bus verbunden.
Um dies als Fehlerursache auszuschliessen bitte folgendes prüfen:
Kontrolle ob beim Booten ein SPI-Treiber geladen wird, bcm2708_spi oder 
ähnlich.
Falls dieser geladen wird oder ein ähnlicher installiert wurde, bitte 
obiges Script ausführen. Dieses schaltet den SPI-SCK Port (J1-23) auf 
Eingang.


Also folgendes durchführen:
1. Installation des python-treibers (falls noch nicht vorhanden):
  # sudo apt-get install python-setuptools
2. Aufruf des scripts spi_clk_off.py:
  (Das script muss als 'root' ausgeführt werden!)
  # spi_clk_off.py
Danach sollte die grüne LED des ht_pitiny Adapters im Ryhtmus des 
HT-Bussignals flackern!

Bitte Info, falls dies die Ursache war!

Gruß Norbert

[strauch (Gast)]

Das wars danke. Man ich hab ein minimal raspbian auf meinen raspberry a+ 
installiert. Da fehlt echt alles. Ich musste noch das Python Modul für 
die gpio Ports kompilieren. Da kommt ja eine Fehlermeldung nach der 
nächsten.

Das ich das neue Modul nicht mehr verpolen kann hab ich mir schon fast 
gedacht, weil es beide male das gleiche Ergebnis brachte.

Jetzt muss ich mir mal ergoogeln wie ich dein Script autostarte :-) und 
wie ich die serielle Schnittstelle per Socat zu meinem Hauptfhem 
bekomme.

Danke

[Norbert S. (junky-zs)]

Hallo,

habe die erforderlichen SW-Änderungen für die Deaktivierung des SPI-CLK 
Signals (Output wird auf Input geschaltet) in das github-repository 
eingepflegt, Grund siehe:
 Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"
Dort stehen auch die Details, was zu tun ist.

Die github-URL ist wie gehabt:
 https://github.com/norberts1/hometop_HT3.git
Bitte lokales Abbild aktualisieren.

Mit dieser Anpassung wird bei Verwendung des 'HT3_Logger.py' der SPI-CLK 
Port auf Input geschaltet, damit der 'ht_pitiny'-Adapter HT-Signale 
erhält.
Das zugehörige /etc/init.d/ht3_logger - script ist zu ersetzen damit 
nach einem Reboot diese Funktionalität vorhanden ist.

strauch schrieb:
>Jetzt muss ich mir mal ergoogeln wie ich dein Script autostarte :-)
Im Folder ./HT3/sw/etc/sysconfig ist das start-script 'ht3_logger' 
vorhanden. Dies kannst Du z.B. als Vorlage nehmen oder das im Raspian 
vorhandene: /etc/init.d/skeleton

Gruß Norbert

[Stephan (Gast)]

Hallo,

ich möchte gern meiner neuen Heizung mit Heatronic 4i etwas auf die 
Finger gucken, was da so passiert. Also nur gucken, nichts steuern.
Nur Leistungen und Temperaturen loggen.
Ich habe dazu die im allerersten Post genannten Bauteile organisiert und 
werde die Schaltung aufbauen.

Gibt es zu der Raspberry-Software eine neue Version für diesen 
Einsatzzweck?
Die Software von 2013 kennt wahrscheinlich noch nicht alle nachträglich 
gefundenen Telegramme, oder? Und alle spätere Software ist wohl eher für 
andere Hardware/Software.

Danke schon mal...

[Norbert S. (junky-zs)]

Hallo,

Stephan schrieb:
>Ich habe dazu die im allerersten Post genannten Bauteile organisiert und
>werde die Schaltung aufbauen.
Für die reine Erfassung von Heizungstelegrammen ist diese preisguenstige 
Schaltung genau richtig. Dazu brauchst Du nicht einen ht_transceiver mit 
Break-Erkennung etc.
Bisher sind die neuen erkannten Telegramme noch nicht in die 
Dekodierungs-Software eingebracht. Der neue 'ht_transceiver'-Adapter 
erlaubt es jetzt die Telegramme sicherer zu Erfassen (Längenangabe, 
Telegrammheader etc.) und Logfiles sind vorhanden. Diese sind jedoch 
noch auszuwerten und einige neue Telegramme sind ja hier im Thread schon 
beschrieben (Warmwasser-Telegramm
 Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi") .
Mein Schwerpunkt liegt jetzt wieder mehr bei der Software und in einem 
neuen Release werden diese neuen Erkenntnisse enthalten sein.

>Und alle spätere Software ist wohl eher für andere Hardware/Software
Die zugehörige Software halte ich möglichst abwärtskompatibel und die 
wird auch die ältere Hardware unterstützen. Dies ist mir wichtig, da ich 
ja selber die verschiedenen Hardwaretypen im Einsatz habe.

Es dauert noch ein bischen, ist aber in Arbeit.

Gruß Norbert

[Stephan (Gast)]

Hallo Norbert,

vielen Dank für die Info. Habe auch die Komplettinformationen im Github 
gefunden und gehe jetzt danach vor. Der Optokoppler ist allerdings eine 
echte Herausforderung. Conrad hatte den in keiner der 3 Berliner 
Filialen vorrätig und durfte ihn selbst auch nicht bestellen.
Aber wenigstens konnte ich es selbst zur Abholung in der Filiale 
bestellen. Dauert aber 2 Wochen...

Bin gespannt, was nachher dabei rauskommt, wenn die ersten Daten kommen.

Gruß,
Stephan

[strauch (Gast)]

Ich hab meinen Adapter jetzt seit einigen Tagen in Betrieb. Ist wirklich 
sehr gute Arbeit von Norbet und auch sehr interessant zu sehen, wie die 
Heizungsanlage funktioniert und wie sie auf was reagiert.

Und es wirft bei mir schon die Frage auf bei Wieviel % Brennerleistung 
wohl die Gastherme am effizentesten ist. Leider hilft google da nicht 
viel weiter. Weil sich alles nur um die 110% dreht von wegen 
Brennwerttherme.

Grund meiner Überlegung ist, das morgen Warmwasser und Heizung 
gleichzeitig wieder "aktiviert" werden und der Brenner dort auf 100% 
geht, während er sonst am Tag meist so bei 40% rumdümpelt. Lasse ich nun 
heißwasser 15min vor der Heizung starten, kann ich den Peak vermeiden, 
aber bringts das, oder ist es sogar gut wenn der Brenner bei 100% 
Leistung ist.

Vielleicht weiß hier ja jemand genaueres. Der Heizungsbauer weiß es 
nicht. Junkers habe ich angeschrieben, glaube aber kaum das die mir das 
beantworten werden.
Gasverbrauch messen ist vermutlich auch einfach von zu vielen Variablen 
abhängig und damit zu ungenau.

[Stephan (Gast)]

strauch schrieb:
> Und es wirft bei mir schon die Frage auf bei Wieviel % Brennerleistung
> wohl die Gastherme am effizentesten ist.

Also eine Therme ist allgemein dann am effektivsten, wenn sie möglichst 
wenig taktet. Also eine Therme, welche ständig mit kleiner Leistung 
durchgehend läuft und sich an den Bedarf anpassen kann, ist viel 
effektiver als eine, welche ständig an- und ausgeht.

Ich kann das aus Erfahrung sagen, denn meine alte Therme hat mit minimal 
rund 8kW eigentlich eine zu hohe Leistung gehabt für alles über 0 Grad, 
denn sie musste ständig abschalten. Die neue hat jetzt minimal 3,3 kW 
und läuft fast ständig mit 25%. Der Gaszähler dreht sich gaaaanz 
langsam.
Je länger ein Brenner läuft, desto effektiver ist es!

Grundsätzlich ist die Frage hier aber falsch und ich würde Dir das 
heizungsforum.de empfehlen.

[strauch (Gast)]

@Stephan,

danke für den Tipp mit dem Forum, da werde ich mal ein wenig Suchen. 
Junkers hat widererwarten zurückgeschrieben, die Raten dazu, 
Heißwasser/Heizung getrennt starten zu lassen um den Peak zu vermeiden.

Grüße

strauch

[Stephan (Gast)]

strauch schrieb:
> danke für den Tipp mit dem Forum, da werde ich mal ein wenig Suchen.

Vielleicht stellst Du Deine Frage mit Angabe des Heizungstyps in 
Junkers-Forum auf heizungsforum.de. Dann stelle ich meine Antwort dazu 
und wir können im richtigen Forum weiterkommunizieren.

[strauch (Gast)]

@Stephan,

könnte ich tun, aber meine Frage ist in einem anderen Beitrag dort schon 
zu lesen bzw. beantwortet worden. Wäre also doppelt gemoppelt. Ich kann 
das Forum garnicht, sonst wäre ich hier damit garnicht erst aufgetaucht 
:-)

@Norbert, ich hab jetzt alle Teile für die 2. Platine. Ich hab eine 
Frage zum programmieren des Attiny441. Kann ich einfach das Hexfile vom 
git ( 
https://github.com/norberts1/hometop_ht_transceiver/blob/master/sw/pitiny/pitiny/Release/pitiny.hex 
) per avrdude auf den attiny flashen?

wobei ich gerade sehe das avrdude den 441 noch nicht unterstützt, oder 
kann man da einen anderen Typen wählen?

Kommando wäre dann grob:
avrdude -P gpio -c gpio -p attiny441 -U flash:w:/tmp/pitiny.hex -v

Grüße

strauch

[Norbert S. (junky-zs)]

Hallo,

strauch schrieb:
>Ich hab eine Frage zum programmieren des Attiny441. Kann ich ...
Bitte den Attiny841 verwenden, so wie es in der Stückliste angegeben 
ist:
https://github.com/norberts1/hometop_ht_transceiver/blob/master/hw/pitiny/Stueckliste_HT_pitiny_Adapter_distrelec.csv

Der Attiny441 hat zu wenig RAM-Speicher, auch mit Optimierung der SW war 
der nicht zum Fliegen zu bewegen.

Daher unbedingt die Stückliste beachten und den Attiny841 für den 
'ht_pitiny'-Adapter nehmen und NICHT die Angaben aus dem Schaltplan 
verwenden (Der Name 'ATtiny441_841' dort ist nur das verwendete 
Schaltplan-Symbol).

Gruß
Norbert

[strauch (Gast)]

Hallo Norbert,

ich hab auch den Attiny841 bestellt. War wirklich durch den Schaltplan 
irritiert. Was ich sehe soll der auch schon mit avrdude laufen. Dann 
müsste das so wie oben gedacht gehen?

Grüße

strauch

[Norbert S. (junky-zs)]

Hallo,

mit avrdude kann man den 'ht_transceiver' programmieren.
Dafür sind das flash und das eeprom zu beschreiben (und die fuses)
------------------------------------
1. Für das Board: ht_piduino
1.1 Write hexfile to flash
 avrdude -C/<path>/avrdude.conf -v -patmega328p -cgpio 
-Uflash:w:piduino_cpp.hex    (alles in einer Zeile)
1.2 Write eeprom to flash
 avrdude -C/<path>/avrdude.conf -v -patmega328p -cgpio 
-Ueeprom:w:piduino_cpp.eep    (alles in einer Zeile)
------------------------------------
2. Für das Board: ht_pitiny
2.1 Write hexfile to flash
 avrdude -C/<path>/avrdude.conf -v -pattiny841 -cgpio 
-Uflash:w:pitiny.hex    (alles in einer Zeile)

2.2 Write eeprom to flash
 avrdude -C/<path>/avrdude.conf -v -pattiny841 -cgpio 
-Ueeprom:w:pitiny.eep    (alles in einer Zeile)

Bei den wenigsten wird der attiny841 im avrdude.conf-File eingetragen 
sein.
Natürlich bei mir auch nicht. Deshalb funkt dies noch nicht mit avrdude. 
Zur Zeit programmiere ich den attiny841 noch mit dem AVRISP MKII.

Das avrdude.conf-file muss für den attiny841 erweitert werden.
Eventuell hat dies jemand schon gemacht???
Dann bitte posten !!!

Gruß Norbert

[Stefan B. (sbiermann)]

Norbert S. schrieb:
> Das avrdude.conf-file muss für den attiny841 erweitert werden.
> Eventuell hat dies jemand schon gemacht???
> Dann bitte posten !!!
>
> Gruß Norbert

Schau mal hier: 
http://www.avrfreaks.net/forum/need-help-using-attiny841-avrdude da 
wurde das schon gemacht. Angeblich läuft es auch...

[Sebastian (Gast)]

@Stephan:
Ich habe auch grade versucht den Optokoppler über Conrad zu kaufen 
allerdings mit dem gleichen Erfolg wie Du.
Ich habe diesen und alle anderen Bauteile dann bei Segor (www.segor.de) 
in Berlin bekommen.
Und der Adapter und die Software laufen super.
Allerdings habe ich offiziell eine HT3 in meiner Therme aber trotzdem 
das Problem mit dem WW Telegramm.
Ansonsten versuche ich grade das Ganze an meinen OpenHAB Server 
anzubinden...

Grüße und vielen Dank an Norbert für die tolle Arbeit.

Sebastian

[Nils R. (augur)]

Hi.

Ich hänge gerade am rrdtool und Google war da nicht hilfreich. Kennt 
jemand die Fehlermeldung:

Create: rrdtool-database (if request is enabled)
db_rrdtool.createdb_rrdtool();Error;<13>

Hab ein neues Wheezy und alles frisch installiert. rrdtool ist drauf und 
mit der Fehlermeldung finde ich nichts. Die SQLLite DB wird komplett 
installiert.

Viele Grüße,
Nils

[strauch (Gast)]

Ich hab den Optokoppler bei Conrad bestellt:
http://www.conrad.de/ce/de/product/183276/Optokoppler-Isocom-Components-H11L1-DIL-6-Ausfuehrung-Optokoppler-mit-Schmitt-Trigger 
ist lieferbar. Oder hast du das auch vorort versucht?

@Norbert
hier hat einer eine Erweiterung für die conf Datei gepostet:
http://www.avrfreaks.net/comment/1017701#comment-1017701

[Norbert S. (junky-zs)]

Hallo,

Nils schrieb:
>Kennt jemand die Fehlermeldung:
>Create: rrdtool-database (if request is enabled)
>db_rrdtool.createdb_rrdtool();Error;<13>

Die Fehlermeldung bedeutet: Permission denied und diese Exception wird 
im Modul: ./lib/db_rrdtool.py geworfen.
Es wird ja für die Erzeugung der rrdtool-Datenbank ein Perl-Script im 
(Linux) /tmp-Verzeichnis erzeugt (Name:/tmp/rrdtool_dbcreate.pl) und 
dies dann aufgerufen und ausgeführt.
Bitte kontrolliere, ob dieses File vorhanden ist. Falls nicht liegt dort 
schon der Fehler, falls doch wird etwas bei der Ausführung danebengehen. 
Du kannst dieses Script auch von Hand ausführen und eventuell mehr 
Details sehen.

@strauch
Danke für die Info, werde dies testen

Gruß Norbert

[Stefan B. (sbiermann)]

Hi Norbert,
wo hast du denn deine Platine(n) ätzen lassen? Ich würde jetzt langsam 
auch mal an die Sache ran gehen und für meine Junkers das Modul mit 
dedizierten Pi nutzen.

Viele Grüße
Stefan

[Norbert S. (junky-zs)]

Hallo an alle pitiny-Nutzer,

habe das avrdude.conf addon für den ATtiny841 ausgetestet und hier als 
TAR-file beigefügt.
Getestet mit avrdude Version 5.10 auf dem Raspberry.
Installation wie folgt:
1. user 'root'
2. TAR-File entpacken
3. cat avrdude_addon_attiny841.conf >>/etc/avrdude.conf

(Bei mir liegt das conf-file unter /etc)

Flashen und EEProm-Brennen ist dann auch für den ATtiny841 möglich so 
wie oben beschrieben unter:
Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"

Gruß Norbert

[Nils R. (augur)]

Norbert S. schrieb:
> Bitte kontrolliere, ob dieses File vorhanden ist. Falls nicht liegt dort
> schon der Fehler, falls doch wird etwas bei der Ausführung danebengehen.
> Du kannst dieses Script auch von Hand ausführen und eventuell mehr
> Details sehen.

Hi.

Anscheinend ist die Bibliothek nicht korrekt in Perl geladen und er kann 
den Verweis nicht finden:
Can't locate RRDTool/OO.pm in @INC (@INC contains: /etc/perl 
/usr/local/lib/perl
/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 
/usr/lib/pe
rl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at 
./rrdtool_dbcreate.p
l line 5.
BEGIN failed--compilation aborted at ./rrdtool_dbcreate.pl line 5.


Dabei hab ich alles mit APT-GET installiert.  "sudo apt-get install 
rrdtool librrds-perl" müsste ja genügen alle notwendigen Sachen zu 
installieren. Oder benötigt das Skript noch eine andere Komponente?

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo Nils,

es fehlt offensichtlich das Perl objektorientere Interface zum rrdtool.
 'apt-get install librrdtool-oo-perl'.

Installiere dein System bitte anhand der vorhandenen Dokumentation, die 
im Verzeichnis ./HT3/docu/HT3_Adaption.pdf zu finden ist.
Dort im Kapitel 3. Installation sind die erfoderlichen Schritte 
beschrieben.

Gruß Norbert

[Nils R. (augur)]

Hi Nobert,

der Hinweis hat gefehlt. Hab die Anleitung immer bis Kapitel 2 gelesen 
(sorry) und mir gedacht, dass es doch funktionieren soll. Blöder Fehler. 
:-/ jetzt läuft es auch. Danke Dir.

Viele Grüße,
Nils

[strauch (Gast)]

Norbert S. schrieb:
> Getestet mit avrdude Version 5.10 auf dem Raspberry.
> Installation wie folgt:
> 1. user 'root'
> 2. TAR-File entpacken
> 3. cat avrdude_addon_attiny841.conf >>/etc/avrdude.conf

Noch als Ergänzung:
Es muss eine spezielle avrdude Version verwendet werden die gpio 
unterstützt 
(http://project-downloads.drogon.net/files/avrdude_5.10-4_armhf.deb). 
Gibt es z.B. hier:
http://project-downloads.drogon.net/files/

der cat Befehl hat bei mir nicht funktioniert weil das sudo sich 
scheinbar nicht auf das Einfügen bezieht 8vielleicht hat da noch jemand 
ein Tipp?). Ich hab es dann einfach mit dem VI Editor gemacht

sudo vi /etc/avrdude.conf
G # Um ans Ende der Datei zu gelangen
ESC # Aus dem Bearbeitungsmodus raus
:r avrdude_addon_attiny841.conf.txt # Um den Text der Datei einzufügen
:wq # speichern und Beenden

Das flashen hat dann nach der Anleitung oben geklappt. Ich werd die tage 
mal schauen ob ich eine Anleitung schreibe.

[Nils R. (augur)]

Hi.

Kann ich die Grafiken auch in einem anderen Verzeichnis als tmp ablegen? 
Ich hab dies in rrdtool_draw.pl bereits geändert und die Berechtungen 
auf 777 gesetzt vom Zielverzeichnis.

my $ImageHG = "Dateiname mit Pfad"

Leider erstellt er mir diese aber nicht dort?

Viele Grüße,
Nils

[Nils R. (augur)]

Passt.  Hab die Dateien kopiert und berechtigt. Nun werden diese auch 
aktualisiert und ich kann alles über den Apache verteilen. :-) War nur 
beim anlegen der Wurm drinnen wie es aussieht.

Nächster Schritt...Veröffentlichung auf KNX Bus.

vg Nils

PS. Kann ich den PI eigentlich parallel zu einem MB Lan anschließen?

[Norbert S. (junky-zs)]

Hallo Nils,

es geht voran, prima!

>PS. Kann ich den PI eigentlich parallel zu einem MB Lan anschließen?
Ein klares JEIN !
Ohne besondere Vorkehrungen nicht, da ht_transceiver,Netcom100 und 
MB-Lan die gleiche Geräte-Adresse (0d)h haben und jeder wenn er dann vom 
Master abgefragt (gepollt) wird auch als Client antwortet -> HT-Bus 
Telegrammsalat.

Um den ht_transceiver trotzdem am HT-Bus zu verwenden muss man diesen 
passiv bzw. eine andere Geräteadresse verpassen. Dies habe ich mit den 
beiden Testpins realisiert (TP-Out und TP-In). Bisher sind diese Pins 
nicht bestückt, deshalb dort 2-Pin Header einlöten und Brückenstecker 
setzten (kann gesteckt bleiben).

Wenn die Brücke zwischen TP-Out und TP-In beim Booten gesteckt ist, wird 
der Native-Mode eingeschaltet. der ht_transceiver erhält dann 
automatisch die Geräte-Adresse (7f)h und da diese auf dem Bus nicht 
vorkommt leuchtet auch die ROTE-TX LED nicht mehr auf.
Es werden dann weiterhin die RX-Daten (ohne Header nur RAW) an der 
Schnittstelle ausgegeben. Somit kann der ht_transceiver parallel mit 
MB-Lan | Netcom100 betrieben werden.

Gruß Norbert

[fsigloch (Gast)]

---Kann ich den PI eigentlich parallel zu einem MB Lan anschließen?---

Hat bei mir funktioniert mit Netcom100 : Geräteadresse 0d und

piduino Geräteadresse: 0a. Beide dürfen nicht die gleiche Adresse haben.

Gruß Ferdinand

[Norbert S. (junky-zs)]

Hallo,

Ferdinand schrieb:
>Hat bei mir funktioniert mit Netcom100 : Geräteadresse 0d und piduino 
>Geräteadresse: 0a.
Ja, das geht!
Dazu muss man allerdings im EEPROM des ht_transceivers die 
Geräte-Adresse verändern. Und das geht auch per Kommando zum Adapter.

Jedoch ist genau diese externe Software noch nicht reif für 'github' und 
daher erst mal diese Zwischenlösung.

Gruß Norbert

[Nils R. (augur)]

Norbert S. schrieb:
> Es werden dann weiterhin die RX-Daten (ohne Header nur RAW) an der
> Schnittstelle ausgegeben. Somit kann der ht_transceiver parallel mit
> MB-Lan | Netcom100 betrieben werden.


Hi.

die Ausgabe im Raw Format heißt aber auch, dass alles korrekt von den 
Skripten weggeschrieben wird oder sind dort auch noch Anpassungen 
notwendig.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo,
die Software zum Projekt 'hometop_HT3' ist korrigiert und erweitert 
(Rev.: 0.1.6). Bitte lokales Abbild aktualisieren.

!Nicht betroffen davon ist die Software des 'ht_transceivers'!

Details dazu auf:
Beitrag "Re: Heizungs-Datenerfassung (HT3)"

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo Nils,
>die Ausgabe im Raw Format heißt aber auch, dass alles korrekt von den
>Skripten weggeschrieben wird oder sind dort auch noch Anpassungen
>notwendig.
Nein, es sind keine Anpassungen dafür nötig, auch nicht in der gerade 
aktuaisierten homtop_HT3 Version: 0.1.6.
Hinweis: Dies liegt an der Art wie Telegramme geparst werden (Byteweise 
und Suche nach bekannten Bus-Telegramm Headerbytes (in der Payload). 
Daher ist es egal ob diese Payload noch einmal verpackt ist in einem 
zusätzlichen Telegramm (mit eigenem Header und starttag '#') oder ob die 
Paylout im 'RAW'-Format gesendet wird.

Schlag mich wenn es einmal anders sein würde, aber ich wollte und will 
weiterhin alle Hardware-Typen mit der Software bedienen und 
abwärtskompatibel bleiben!

Gruß Norbert

[strauch (Gast)]

Hallo Norbert,

wir haben jetzt den 2 Adapter fertig gelötet, wenn ich da mit einem 
Labornetzteil 15V drauf gebe, leuchtet keine LED. Kann ich den Adapter 
überhaupt genauso prüfen wie den ersten, oder muss ich da etwas anderes 
überprüfen.
Wollte meinen faulerweise nicht abmontieren um es gegen zu prüfen.

Danke für deine Hilfe

Grüße

strauch

[Norbert S. (junky-zs)]

Hallo,

@Strauch
>wenn ich da mit einem Labornetzteil 15V drauf gebe, leuchtet keine LED.

Die LED's werden anders als bei den HT-Mini/Micro-Adaptern nur vom uP 
(ATtiny841/ATmega328) angesteuert (Interrupt/Mainloop) und sind nicht 
mehr direkt mit dem HT-Bus verbunden.

Daher wie folgt vorgehen:
1. Prüfung ob Board soweit keine Kurzschlüsse hat (HT-Bus, 3.3Volt<->GND 
etc.)
2. Board auf Raspberry stecken und mit Software (Flash und EEProm) 
betanken, siehe Beschreibung:
Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"

Nach dem Reset des 'ht_pitiny'-Boards muss die Grüne LED schon blinken, 
da ja der HT-Bus noch nicht angeschlossen ist.

3. Anschluss 'ht_pitiny'-Board an HT-Bus.
Die grüne LED muss im Rythmus der HT-Bussignale flackern, das langsame 
Blinken muss auf jedenfall damit beendet sein.
Die rote LED blitzt zeitweilig auf, sobald der HT-Bus das Polling für 
die Modem-Geräteadresse (0d)h macht.

Gruß Norbert

[Stefano I. (Gast)]

Hi

With the help of Google Translate, I have been able to follow you 
project, witch I find very interesting

I am the owner of a Bosch Europur ZSB 14-3 E heating and hot water gas 
boiler,  according to the manual the BUS is Heatronic 3. The control is 
a FW 120

I am planning to soldering my own HT3_MiniAdapter, but I have some 
questions that I hope you could answer:

1) Where/how do I connect the HT3_MiniAdapter to BUS, parallel with the 
FW 120 control?

2) Can the HT3_MiniAdapter also be use to send control commands (when 
the commands have been discoverer/decoded) to Heatronic 3? - Or would it 
requires a redesign the HT3_MiniAdapter?


Thanks in advance, I relay appreciate the work you are doing

PS: I do not mind if you reply in German

Stefano

[Norbert S. (junky-zs)]

Hi Stefano,
some answer to your questions
>1) Where/how do I connect the HT3_MiniAdapter to BUS, parallel with the
>FW 120 control?
Yes in parallel. If the FW120 controller is mounted outside of the 
heater then you can use the connections signed with 'B' (two of them).
If it is fitted into the heater, then the connections are on the central 
controlboard.
Anyway they are always signed with 'B'.
Keep in mind to use the right signal-polarity for that Type of Adapters 
(HT3_mini- and HT3_micro-adater).

>2) Can the HT3_MiniAdapter/HT3_MicroAdapter also be use to send control 
>commands...
No, they couldn't be used for sending commands regarding lack of 
realtime response to HT-Bustelegrams.
But they are the cheapest solution to receive HT-Bustelegrams.

Use the 'ht_transceiver'-board (ht_piduino or ht_pitiny) instead for 
receiving AND sending HT-Bustelegrams.

Regards Norbert

[Stefano I. (Gast)]

Thanks Nobert, for your quick reply

My FW120 are mounted on the wall, and I can see the two 'B'

The 'ht_transceiver' 
(https://github.com/norberts1/hometop_ht_transceiver) are both on double 
layer circuit board, can they be ordered somewhere? as I am only able to 
created single layer boards

Regards Stefano

[Norbert S. (junky-zs)]

Hi Stefano,

>The 'ht_transceiver' are both on double layer circuit board, can they be ordered 
>somewhere?
Boards (ht_pitiny only) are available again next month in february.
Send me an E-Mail (PM from forum, account required) and I'l send you 
more details.

Regards Norbert

[strauch (Gast)]

Hallo Norbert,

ich muss mal wieder nerven. Ich bekomme keine LED zum Leuchten :-).
Wenn ich an die entsprechende Beine des IC eine Spannung von 3,3Volt 
gebe leuchtet die LED.
Kann ich irgendwie überprüfen ob das flashen des IC funktioniert hat?
Was meinst du mit "Nach dem Reset des 'ht_pitiny'-Boards muss die Grüne 
LED schon blinken". Einmal Stromlos und wieder Strom drauf, oder gibt es 
einen Befehl den man ausführen muss.

Hab gerade keine Idee wo der Fehler liegen könnte.

Danke

strauch

[Norbert S. (junky-zs)]

Hallo,

strauch schrieb:
>...Ich bekomme keine LED zum Leuchten :-). Kann ich irgendwie überprüfen ob das 
>flashen des IC funktioniert hat?
Das Flashen mit avrdude wird ja schon mit anschliessendem Verify 
durchgeführt. Da sollte schon ein Fehler angezeigt werden.
Aufruf:
avrdude -C/<path>/avrdude.conf -v -pattiny841 -cgpio 
-Uflash:w:pitiny.hex    (alles in einer Zeile)
siehe auch nochmal:
Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"

>Was meinst du mit "Nach dem Reset des 'ht_pitiny'-Boards muss die Grüne
>LED schon blinken".
Stromlos und wieder einschalten. Es ist ja eine Reset-Schaltung auf dem 
Board.

Folgende Dinge fallen mir dazu noch ein:
1. Fuses richtig gesetzt?
 EXTENDED: 0xFF
 HIGH    : 0xDF oder 0xD7
 LOW     : 0xEE
Befehle für avrdude dafür must du mal man-pages nutzen.

2. Falls ja, ist der externe Quarz ja schon aktiv und wenn damit das 
Flashen funktioniert ist der uC OK.
 (eventuell geringe Baudrate für SPI-Clock SCK und 1. Flashen nehmen)

3. LED prüfen hast du schon gemacht, ich nehme dafür ein Messgerät und 
Widerstandsmessung, der Strom reicht schon aus das die LED leuchtet.

4. Falls das Flashen bzw. das Setzen der Fuses nicht klappt bitte die 
Einbaulage des uC ATtiny841 kontrollieren. Pin1 ist mit einem kleinen 
Dreieck gekennzeichnet. Wenn nicht vorhanden, dann ist Pin1 unten links 
wenn man die Aufschrift lesen kann.

Ich hoffe dies hilft dir weiter.
 I'l do my very best :-)

Gruß Norbert

[strauch (Gast)]

Hi Norbert,

Fuses setzten klingt nach einer guten Idee, dann werde ich mal schauen 
das ich das mit avrdude hinbekomme:
http://www.mikrocontroller.net/articles/AVRDUDE

Danke. Das hilft mir wie immer weiter :-).

Grüße

strauch

[strauch (Gast)]

Also für andere hier sind die Befehle:
Fuses auslesen
sudo avrdude -n -v -pattiny841 -cgpio

Fuses setzten:
sudo avrdude -cgpio -pattiny841 -U lfuse:w:0xEE:m -U hfuse:w:0xDF:m -U 
efuse:w:0xFF:m

avrdude meint auch ist alles ok mit dem Chip.
LED leuchtet trotzdem nicht mhpf :-(. Hab auch einmal Stromlos gemacht 
das ganze. Meinst du ich soll die Baudrate beim flashen mit avrdude 
festlegen?
Hattest du mit avrdude denn auch schon erfolgreich geflashed das die 
Platine funktionierte?

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

Reading | ################################################## | 100% 
0.00s

avrdude: Device signature = 0x1e9315
avrdude: safemode: lfuse reads as EE
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF

avrdude: safemode: lfuse reads as EE
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

[Norbert S. (junky-zs)]

Hallo,

strauch schrieb:
>avrdude meint auch ist alles ok mit dem Chip. LED leuchtet trotzdem nicht mhpf 
>:-(
sch..., hatte gehofft dies wäre der Grund.

>Hattest du mit avrdude denn auch schon erfolgreich geflashed das die
>Platine funktionierte?
Ja, hatte ich. Dies hatte ich ausprobiert mit dem HEX-Files von github 
bevor ich den Thread geschrieben hatte:
   Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"
Allerdings hatte ich noch nicht damit die fuses setzen müssen. Aber dies 
funktioniert ja bei dir ->avrdude: safemode: Fuses OK

Somit ist uC und SPI-Zugriff OK.
Und du hast sicher die aktuelle HEXFile-Version von Github genommen!!??

Ich gehe davon aus, das du nach dem flash Beschreiben auch noch das 
EEPROM beschreibts? Ich frage deshalb weil die Fuses bei dir so 
eingestellt sind:
 avrdude: safemode: lfuse reads as EE
 avrdude: safemode: hfuse reads as DF
 avrdude: safemode: efuse reads as FF
Dadurch wird jedesmal beim Schreiben des Flashes auch das EEPROM 
gelöscht!.
Um das zu Vermeiden dann besser folgende Einstellung nehmen:
 avrdude: safemode: lfuse reads as EE
 avrdude: safemode: hfuse reads as D7
 avrdude: safemode: efuse reads as FF

Ansonsten bleibt mir nur zu Vermuten, das der ATTiny841 ständig im Reset 
stehen bleibt. Kontrolliere bitte in der Richtung die Bauteile am Pin4 
des ATtiny841.
Deine 1. Platine läuft noch?

Gruß Norbert

[strauch (Gast)]

Hi Norbert,

danke für die Tipps, werde ich nachher mal prüfen bzw. am WE. Die erste 
Platine läuft so gut, das ich sie garnicht abbauen will zum vergleichen 
;-). Ich lade noch mal die aktuellen Datein runter zum flashe, werde auf 
D7 umstekllen, neu flashen, reset und dann mal schauen.

Danke

Grüße

strauch

[strauch (Gast)]

Also Fuse auf D7 geändert. Dann die Dateien noch mal von github geladen 
und erst die hex file und dann noch mal das eeprom geflasht..... und ES 
BLINKT :-)

Vermutlich hatte ich dann nicht die allerletzte Version vom github.

Dankeschön

[Jürgen R. (juergenle)]

Norbert S. schrieb:

> Boards (ht_pitiny only) are available again next month in february.
> Send me an E-Mail (PM from forum, account required) and I'l send you
> more details.
>
Hallo Norbert,
ich hätte auch gerne eine Platine für ht_pitiny. Wäre das möglich ?
Vielen Dank auch für euren Einsatz in diesem Projekt.
Mfg Jürgen

[Norbert S. (junky-zs)]

Hallo,

@Jürgen R.
>...ich hätte auch gerne eine Platine für ht_pitiny. Wäre das möglich ?
Ja, sende mir eine Mail (PM) an den Forum-account. Weiteres dann dort.

Gruß Norbert

[schwiete (Gast)]

Hallo,

ich möchte gern bei meiner Junkers Cerapur Comfort ECO / FW100 das 
Betaetigen der WasserSofort Funktion auswerten. Weiß jemand zufaellig ob 
dieser Befehl ueberhaupt auf dem Bus erscheint oder innerhalb des FW100 
verarbeitet wird?

Zum Hintergrund: Die Warmwassertemperatur fällt bei unserem kleinen 
Speichern so weit ab, dass die Wanne nicht ausreichend gefuellt wird. 
Ich möchte die WasserSofort Taste verwenden um temporaer den NTC im 
Speicher zu manipulieren und so eine sofortige Speicherladung anfordern.

Gruß
schwiete

[strauch (Gast)]

@schwiete

ich hab nicht ganz genau verstanden was du willst. Willst du nur 
mitlesen ob einer die Taste gedrückt hat oder willst du die Taste durch 
das Modul die Wassersofortfunktion auslösen?

Ich nutze FHEM mit dem Adapter und es gibt dort kein Punkt der 
Wassersofort heißt und an geht. Aber der Brenner startet und die 
Umwälzpumpe wenn du den Knopf drückst, daran kann man es erkennen.

[schwiete (Gast)]

Hallo,

eine Wasser-Sofort-Taste hat der FW100 Regler schon selbst. Mit der 
Taste kann man aber nur das Warmwasser anfordern wenn sich die Heizung 
gerade im "Mach mal kein Warmwasser Programm befindet". Da tut sich nix 
wenn das Warmwasser noch 44 Grad hat und der Sollwert bei 50 Grad liegt. 
Nehme ich kurz den NTC aus dem Speicher, so dass der Wert unter 42 Grad 
faellt, legt die Heizung sofort los. Und genau so etwas moechte ich 
haben: Eine Taste die solange den NTC unter 42 Grad drueckt bis die 
Heizung anspringt und SOFORT das Warmwasser auf 50 Grad aufheizt. 
Entweder machte ich mir direkt einen Taster an die Therme oder ich fange 
das Protokoll der "nicht richtig funktionieren" Taste am Regler ab.

Gruß
schwiete

[Kai Z. (kaizo)]

Hallo Schwiete,

kannst Du nicht einfach die WW-Temperatur hochsetzen? Da müßte doch eine 
Änderung von 10-15 Grad ausreichen, so daß die WW-Bereitung sofort 
startet. Wenn du mit dem Zapfen fertig bist kannst du die Temperatur ja 
wieder runter setzen (auf Normaltemperatur)

Gruß
Kai

[Niffko _. (niffko)]

@schwiete

Um zu erreichen was Du möchtest, würde ich wie folgt vorgehen:

1. WW-Soll über ein entsprechendes Datentelegramm auf 60°C hochsetzen.
2. Monitortelegramm überwachen und checken ob WW-Betrieb gestartet
3. WW-Soll über ein entsprechendes Datentelegramm auf 50°C zurücksetzen.

Durch den höheren Sollwert, wird der WW-Betrieb zunächst starten, da die 
Einschalthysterese erreicht wird. Danach wird er weiterhin aktiv 
bleiben, auch wenn Du den Sollwert auf 50°C zurücksetzt.


//Niffko

[schwiete (Gast)]

Hallo,

vielen Dank für Tipps. Das mit dem Sollwert hochsetzen habe ich einmal 
mit dem Drehknopf an der Therme gemacht. Habe den Sollwert langsam 
hochgedreht. Bei 55 Grad ist die Therme dann angesprungen. Dann sofort 
wieder auf 50 Grad runtergedreht. Und was macht das Ding? Das Warmwasser 
war danach 55 Grad! Scheint so als ob der eingestellte Wert ein 
Startwert ist, der bis zum Ende der Aufheizphase stehen bleibt?! Ich 
werde das trotzdem mal mit dem Protokoll testen. Und jetzt nochmal die 
eigentliche Frage die mich hier schreiben lässt: Kann ich den den 
Tastedruck der WasserSofort Taste des FW100 auf dem Bus mitlesen?

Hilfreich wäre das Telegramm zum einstellen des WW Sollwert und das 
Telegram der WasserSofort Taste.

Gruß
schwiete

[Niffko _. (niffko)]

@schwiete

Bin eigentlich von der EMS-Fraktion(Buderus) ... da die Busse verwandt 
sind, wird das bei euch aber ähnlich funktionieren.

Ein spezielles Telegramm der WWSofort-Taste gibt es nicht. Das 
Bedienteil sendet periodisch(wichtig!) eine Art WW-Statustelegramm an 
den Master. Dies beinhaltet den Aktiv-Status von WW und 
Zirkulationspumpe und ist abhängig von den eingestellten Schaltzeiten.

Das Betätigen der WWSofort-Taste veranlasst das Bedienteil dazu, das 
Statustelegramm für eine bestimmte Zeit mit aktiv gesetztem WW zu 
senden. Zusätzlich wird über dieses Telegramm auch kurzzeitig die 
Zirkulation aktiviert.

Die WW-Solltemperatur befindet sich in einem anderen Telegramm.

Beide Telegramme werden sich relativ leicht identifizieren lassen, indem 
du entsprechende Parameteränderungen über das Bedienteil vornimmst und 
dabei auf dem Bus mitloggst.


//Niffko

[schwiete (Gast)]

@Niffko

Allerbesten Dank! Dann werde ich mal ein Interface loeten und schauen 
was das so auf dem Bus abgeht.

Danke und Gruß
schwiete

[Hartmut D. (Gast)]

Hallo Leute,
heute hat es mir mein System irgendwie zerlegt...
Pi Modell B. Speicherung der DB auf einem 32GB USB Stick.

Warum auch immer gab es immer mehr Probleme, die Daten zu speichern.
Die SQLite DB ist ca. 335 MB groß.

Die folgende Abfrage auf der DB
SELECT rrdtool_timestamp FROM rrdtool_infos WHERE rrdtool_timp NOT NULL 
ORDER BY rrdtool_timestamp ASC;
kehrt nicht zurück, was das ganze System blockiert.

Ein export als sql und ein Import als neue DB hat auch nichts gebracht.

Einzig das entfernen der Sqlite DB und das damit zusammenhängende 
neuaufbauen
der DB war hilfreich.

Hat jemand von euch schon mal so ein Problem gehabt und kann mir an 
dieser Stelle helfen die Datenbank zu retten, bzw die Daten zu mergen, 
da ich schon gerne mehr als 3 Monaten in der Datenbank auswerten möchte.

Danke für eure Hilfe und Gruß
Hartmut

[Hartmut D. (Gast)]

Sorry, es ist einfach zu spät, öhm früh ;-)

Die Stelle in dessen weiterem Verlauf der der Fehler Auftritt ist im 
ht3_dispatch.py
Zeile 389 und folgende:
           else:
                # do db_info-tests if enabled
                if  self.__rrdtool_info.isrrdtool_info_active():
                    self.__rrdtool_info.rrdtool_update()


Danke und Gruß
Hartmut

[Norbert S. (junky-zs)]

Hallo,

@Hartmut D.
>Warum auch immer gab es immer mehr Probleme, die Daten zu speichern.
>Die SQLite DB ist ca. 335 MB groß.
Dieses Verhalten von sqlite habe ich auch schon gesehen. Die Zugriffe 
werden langsam bzw. sind nicht mehr möglich. Siehe dazu auch 
Parallel-Thread:
Beitrag "Re: Heizungs-Datenerfassung (HT3)"
Einen Grund dafür habe ich bisher noch nicht gefunden.
Es bleibt in diesen Fällen nur die alte SQLite-DB umzubenennen und mit 
./create_databases.py eine neue anzulegen.

Die SQLite DB war allerdings auch nicht für Langzeitspeicherung 
vorgesehen sondern dient mehr als Kurzspeicher (Analyse) und 
Zwischenwirt für die rrdtool-DB Daten.

Ich empfehle daher die SQLite DB nicht so groß werden zu lassen (<=100 
MB) und die älteren Daten zu löschen. Zur Zeit ist allerdings keine 
automatische Löschroutine oder Backup in den Scripten vorhanden.
Dies muss noch extern mit einem Cron-Job erfolgen siehe:
Beitrag "Re: Heizungs-Datenerfassung (HT3)"

Allerdings willst Du ja die alten Daten noch Auswerten. Dies wird nicht 
einfach wenn Du keinen Zugriff mehr auf die SQLite-DB hast. Ich weiss 
auch nicht wirklich was diesen Zugriff verhindert. Vielleicht hat jemand 
eine Idee wie man diese SQLite-DB retten kann.

Gruß Norbert

[Hartmut D. (Gast)]

Hi Norbert,
danke für die Bestätigung meiner Vermutung.
Die DB ist ok. Ich habe sie auf dem Windows Rechner problemlos öffnen 
können.
Scheinbar ist die Leistung des Pi doch etwas schwach.

Den anderen Thread habe ich übersehen. War gestern wohl doch etwas zu 
spät.

Ich werde mir mal Gedanken um ein Backup bzw. verschieben der Datenbank 
machen. Muss nur sehen, dass ich hierzu kurz exclusiven Zugriff auf das 
System bekomme.

Wie verhält sich eigentlich der Logger, wenn man ihm die DB live unterm 
Hintern wegzieht?

Danke und Gruß
Hartmut

ps. ein echt tolles Projekt! Danke für die Unterstüzung und die Arbeit 
die ihr da schon reingesteckt habt!

[Norbert S. (junky-zs)]

Hallo Hartmut,
>Wie verhält sich eigentlich der Logger, wenn man ihm die DB live unterm
>Hintern wegzieht?
Ohne die Applikation zu stoppen wirst Du dann Probleme bekommen, da die 
DB ja auch nur ein File ist mit dann neuer 'inode'.

Vorschlag: leere SQLite-DB in einem anderen Verzeichnis erstellen, 
Applikation stoppen, die DB's austauschen und Applikation wieder 
starten. Dies per Script geht dann auch schnell, eben Quick and Dirty.
Oder eben ein Backup, Löschen und Vakuum durchführen.
Muss mal sehen, ob es da eine gute Möglichkeit gibt.

Gruß Norbert

[Hartmut D. (Gast)]

Hallo Norbert,
danke für deine Infos.

Habe ich eigentlich eine Chance von außen dem HT3_Logger zu sagen, das 
er sich beenden soll?

Ich hab doch etwas bedenken, das ganze einfach mal eben per
kill <PID von HT3_Logger>
abzuschießen.

Sorry, aber in Python bin ich noch nicht wirklich Sattelfest.

Gruß und Danke
Hartmut

[Hartmut D. (Gast)]

Oh ha,
sorry für meine wirklich überflüssige Frage.
Ich hab ja das Skript im init.d und damit die Chance den Logger
sauber zu beenden.

Gruß
Hartmut

[Jo W. (basteljo)]

Habe eine smb Freigabe der db gemacht und kann so
von jedem Rechner aus zugreifen, bezw.Sicherungskopien
machen.
http://jankarres.de/2013/11/raspberry-pi-samba-server-installieren/

[Nils R. (augur)]

Moin.

Kann ich eigentlich schon auf Störungsmeldungen reagieren wie eine Email 
versenden oder so. Bei uns ist immer mal wieder zu wenig Wasser in der 
Anlage und da wäre das recht praktisch.

Viele Grüße,
Nils

[Nils R. (augur)]

Moin.

Ich bekomme auch beim starten des Service folgende Fehlermeldung:

[....] Restarting This services logs telegrams from  heattronic serial 
communica
tion line: HT3_Logger.pyTraceback (most recent call last):
  File "/usr/HT3/sw//etc/sysconfig/spi_clk_on.py", line 29, in <module>
    import RPi.GPIO as GPIO
ImportError:
Traceback (most recent call last):
  File "/usr/HT3/sw//etc/sysconfig/spi_clk_off.py", line 29, in <module>
    import RPi.GPIO as GPIO
ImportError: No module named RPi.GPIO
./ht3_logger: 55: ./ht3_logger: dphys-swapfile: not found


Wenn ich wie oben kurz beschrieben die Setuptools nachinstalliert habe 
und folgendes Kommando ausführe, sieht es nicht besser aus.

admin@smarthome:/usr/HT3/sw/etc/sysconfig$ sudo ./spi_clk_off.py
Traceback (most recent call last):
  File "./spi_clk_off.py", line 29, in <module>
    import RPi.GPIO as GPIO
ImportError: No module named RPi.GPIO
admin@smarthome:/usr/HT3/sw/etc/sysconfig$


Jemand eine Idee was da fehlt? Sobald das System hochfährt, blinkt die 
Led des Modules auch nur noch langsam. Davor kann man quasi die 
Kommunikation auf dem Bus sehen.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo,

Nils schrieb:
> Jemand eine Idee was da fehlt?
Den Befehl: sudo apt-get install python-setuptools
hast Du ja schon ausgeführt. Wenn dieser erfolgreich war muss das 
zugehörige Python-Modul vorhanden sein.
Dieses Script muss als root ausgeführt werden, dies hast Du ebenfalls 
gemacht mit: sudo ./spi_clk_off.py.
Da dies trotzdem nicht läuft habe ich den Verdacht, das Dein OS nicht 
ganz uptodate ist.
Habe zufällig gerade ein frisch betanktes Raspberian ausprobiert mit 
natürlich aktueller Software und dieses Script aufgerufen.
Das script läuft dort auf Anhieb OHNE vorher die python-setuptools 
installieren zu müssen.
Daher versuch bitte Dein OS auf Stand zu bringen mit:
  apt-get install update
  apt-get install upgrade

>Sobald das System hochfährt, blinkt die Led des Modules auch nur noch langsam.
Dies liegt an dem SPI-Treiber 'bcm2708_spi.o'. Dieser forced den SPI-ClK 
auf einen festen Pegel auch wenn der SPI-Bus nicht benutzt ist. Der 
ATTiny841 hat an diesem Pin beide Signale (SPI-CLK UND HT-Bus RX) 
anliegen) und erhält deshalb nicht das HT-Bus-Signal.
Dies umgeht das Script 'spi_clk_off.py' indem der SPI-CLK Ausgang auf 
Eingang geschaltet wird.
Hinweis:
Leider kann man jetzt nicht sagen: der Treiber 'bcm2708_spi.o' sei 
ungünstig realisiert, der sollte doch besser die Füsse vom SPI-Bus 
lassen wenn der nicht benutzt wird (wenn SEL SS auf inaktiv ist).
Dummerweise hat Motorola damals in grauer Vorzeit genau den SPI-CLK 
nicht auf tristate definiert wenn man den SPI-Bus nicht braucht).

Deshalb muss dieses script 'spi_clk_off.py' funktionieren wenn man ein 
'ht_transceiver'board hat.
Alle anderen mit 'HT3_miniAdapter' und 'Ht3_microAdapter' brauchen 
dieses Script nicht bzw. falls Meldungen auftauchen können diese 
ignoriert werden.

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo,

leider hat sich der Schreibteufel eingeschlichen. Deshalb jetzt korrekt:

> Daher versuch bitte Dein OS auf Stand zu bringen mit:
  apt-get update
  apt-get upgrade

Gruß Norbert

[Nils R. (augur)]

Hat beides nicht geholfen. Hab nun auch wie woanders empfohlen ein 
DIST-UPGRADE gemacht und python-dev installiert. Leider keine Änderung 
vom Verhalten. Das Kommande (hatte ich im Raspberry Forum gefunden) sudo 
apt-get install python-rpi.gpio findet leider das Paket nicht. Daher hab 
ich das nun über PIP nachinstalliert. Leider weiterhin die Meldung. Wenn 
ich die Bibliothek über python manuell importiere klappt es...und im 
Script sehe ich python3...das Probiere ich vielleicht gleich noch aus, 
ist bestimmt dort nicht installiert.

Da ich mit KNX kommunizieren will, hab ich ein Image von smarthome.py 
genommen. Das war von Anfang letzten Jahres. Die neuste Version ist es 
also nicht.

[Nils R. (augur)]

Passt, jetzt bekomme ich nur noch folgende Fehlermeldung beim Starten 
des Services:

admin@smarthome:/etc/init.d$ sudo ./ht3_logger start
./ht3_logger: 55: ./ht3_logger: dphys-swapfile: not found

Ist das schlimm?

[Norbert S. (junky-zs)]

Hallo,

@Nils
Prima das es jetzt läuft. Python und Python3 sind nicht das gleiche. 
Viele Sachen laufen, jedoch Unterschiede gibt es deren viele und 
Abhängigkeiten noch mehr.
Falls dieses Modul fehlen sollte bitte nachinstallieren mit:
   apt-get install python3-setuptools
Bitte die 3 bei 'python3' beachten, steht im script-Kopf noch falsch, 
sorry.

>./ht3_logger: 55: ./ht3_logger: dphys-swapfile: not found Ist das schlimm?
Nein, dieser Aufruf soll das swap-File abschalten da ich nicht swappen 
will und die Applikation (Run-Level3) auch nicht soviel Speicher 
braucht.
Ich wollte damit ein Unnötiges rumnudeln auf der SD-Karte vermeiden.

Du kannst diesen Aufruf im Script deaktivieren.

Gruß Norbert

[Hartmut D. (Gast)]

Hallo zusammen,
nur kurz eine Rückmeldung, wie ich jetzt regelmäßig die DB rotieren 
lasse.

Voraussetzung: Verzeichnis backups unterhalb des database Verzeichnis, 
sowie eine leere Datenbankdatei im Verzeichnis master unterhalb des 
Verzeichnisses database.

Ach ja, das Kill ist ein überbleibsel, falls die DB zu groß geworden 
sein sollte und den Prozess blockiert...

#!/bin/sh
# HT3 Logger stoppen
/etc/init.d/ht3_logger stop
# sollte er haengen, weg mit ihm
if test -f /home/pi/HT3/sw/var/run/ht3_logger.pid
then 
  # Warten, damit er fertig wird
  echo waiting
  sleep 30
  if test -f /home/pi/HT3/sw/var/run/ht3_logger.pid
  then 
     kill $(cat /home/pi/HT3/sw/var/run/ht3_logger.pid)
  fi
fi
# Sicherung anlegen
mv /media/usbstick/Heizung/database/HT3_db.sqlite /media/usbstick/Heizung/database/backups/backup-`date +%Y%m%d`.sqlite
# neue DB bereitstellen
cp /media/usbstick/Heizung/database/master/HT3_db_empty.sqlite /media/usbstick/Heizung/database/HT3_db.sqlite
# weiter gehts
/etc/init.d/ht3_logger start

Gruß
Hartmut

[Nils R. (augur)]

Norbert S. schrieb:
> Ich wollte damit ein Unnötiges rumnudeln auf der SD-Karte vermeiden.
>
> Du kannst diesen Aufruf im Script deaktivieren.

Hi.

Hab mal nachgeschaut, meine Disti hat kein SWAP Bereich definiert. Daher 
läuft der Befehl ins nichts. Hab ihn also raus genommen und nun kann ich 
auch alles normal starten. Nur Leider wird nichts gelogged.

Viele Grüße,
Nils

[Nils R. (augur)]

Die LED flackert nun übrigens auch wie gedacht. Telegramme kommen also 
an.

[Nils R. (augur)]

Wenn ich mich auf den Port schalte kommt auch was im Raspberry an. Nur 
geparst wird die anscheinend nicht. Hätte etwas mehr Klartext über den 
seriellen Port erwartet. :-)   Vielleicht stimmt da noch was nicht.

[Norbert S. (junky-zs)]

Hallo,

@Nils
>Hätte etwas mehr Klartext über den seriellen Port erwartet. :-)
Auf dem HT-Bus wird kein Klartext gesprochen sondern dies sind binäre 
Zeichen. Daher zeigt dir der cat-Befehl auch kryptische Zeichen an.
Klartext wird daraus erst mit der nachgelagerten Decoder- und 
Analyse-Software.

Ich glaube Du betreibst den ht_pitiny noch im Native Mode mit einer 
Brücke zwischen TP-Out und TP-In?
Siehe dazu auch noch Url:
 Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"
Dann sind die Ausgaben des 'ht_transceivers' im RAW-Format so wie diese 
vom HT-Bus kommen.
Dies kann die vorhandene Software: HT3_Analyser.py, HT3_SystemStatus.py 
und HT3_Logger.py verarbeiten. Dein Bild oben zeigt z.B. Nativ-Daten 
(ohne Header) an.

Was man leider nicht sehen kann ist, ob die Baudrate stimmt die Du 
eingestellt hast. Bitte gebe mal folgende Sequenz ein:
  stty -F /dev/ttyAMA0
Damit wird dann die Baudrate ausgegeben und sollte wie folgt sein:

1. 'ht_transceiver' (ht_piduino oder ht_pitiny) -->> 19200 Baud 8N1
2. 'HT3_Micro-/MiniAdapter)                     -->> 9600  Baud 8N1

Falls dies bei Dir nicht passt, bitte das Konfigurationsfile 
diesbezüglich anpassen unter ./HT3/sw/etc/config/HT3_db_cfg.xml.

In Deinem Bild bist Du gerade als 'root' unterwegs. Dir ist klar das die 
Applikation unter 'user' keinen Zugriff auf Datenbank haben kann wenn 
diese mit 'root' angelegt wurden!
Also entweder alles als 'root' unterwegs sein (nicht so gut) oder wie 
üblich das ganze als 'user' anlegen und nutzen und nur in 
Ausnahme-Fällen als root (init-scripte Anlegen etc.).
Details zur Installation stehen ja auch in der Vorhandenen Dokumentation 
Kapitel 3 ff unter ./HT3/docu.


Gruß Norbert

[Nils R. (augur)]

Norbert S. schrieb:
> Ich glaube Du betreibst den ht_pitiny noch im Native Mode mit einer
> Brücke zwischen TP-Out und TP-In?

Noch nicht, habe den Jumper entfernt weil es nicht funktioniert hat und 
vorerst den Raspi alleine angeschlossen.

Baudrate war auf 9600. Hab diese aber nun auf 19200 geändert. Leider 
ohne Besserung.

Aktuell:
[e-mail]:init.d# stty -F /dev/ttyAMA0
speed 19200 baud; line = 0;
min = 1; time = 1;
-brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke


Hatte alles unter Root angelegt um Fehler auszuschließen, weil es nicht 
lief. Wenn es funktioniert, würde ich alles wieder abbauen.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo,

@Nils
>Hab diese aber nun auf 19200 geändert. Leider ohne Besserung.
Nicht OK und schlecht.
Ich habe gesehen das Du folgenden Pfad verwendest:
  /usr/HT3/......
Du bist daher gezwungen ALLE scripte auf diesen Pfad anzupassen. 
Offensichtlich ist dies noch nicht komplett gemacht. Allerdings empfehle 
ich Dir trotz allem und weil es mit weniger Anpassung verbunden ist, das 
ganze unter 'user' einzurichten mit der aktuellen Software von 
github.com.
Wenn Du den Befehl: ps ax | grep HT  eingibst sollte so was rauskommen 
(Als user 'pi'):
  .... /usr/bin/python3 /home/pi/HT3/sw/etc/html/httpd.py
  .... /usr/bin/python3 /home/pi/HT3/sw/HT3_Logger.py

In den Init- und rrdtool_draw_pl Scripten stehen ja default Pfadangaben 
und Username drin (hier Auszug des Startscript vom HT3_Logger.py) :
  NAME_SCRIPT=ht3_logger
  USER="zs"
  DAEMON=/home/$USER/HT3/sw/$NAME
  DAEMON_ARGS=""
  PIDFILE=/home/$USER/HT3/sw/var/run/$NAME_SCRIPT.pid
  APPLICATION_FOLDER=/home/$USER/HT3/sw/

Diese Pfadangaben und User-Namen must Du alle Anpassen wenn Du einen 
anderen Pfad nimmst (wie oben zu sehen).
Deshalb meine dringende Empfehlung um Deine Installation möglichst 
einfach zu halten:
  User       : pi
  Pfad       : /home/pi
  Applikation: /home/pi/HT3/sw/....
Die scripte oben müssen dann nur noch von User:zs auf User:pi geändert 
werden. Dann Konfiguration ändern auf 19200 Baud und dann als user:pi 
die Datenbank anlegen mit
  cd /home/pi/HT3/sw
  ./create_databases.py

Weitere Details auch in der Doku unter: ./HT3/docu

Gruß Norbert

[Nils R. (augur)]

Alles gemacht. Nochmal die aktuelle Doku abgearbeitet und leider 
gleiches Verhalten. Als ich den Systemstatus abgefragt habe kam folgende 
Meldung um Terminal. Ich hab den den HT3-Logger beendet und dann kam die 
Meldung nicht mehr. Aber Daten werden trotzdem nicht angezeigt.

Der Logger läuft auch...wurde beim Neustart korrekt mit gestartet.

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Hallo,

@Nils
>Aber Daten werden trotzdem nicht angezeigt. Der Logger läuft auch...wurde beim 
>Neustart korrekt mit gestartet.
Eine Besserung habe ich schon erwartet, zumindest ein NEUES Bild mit der 
Ausgabe vom Status ps ax |grep HT.
In Deinem Bild sieht man leider nicht den Prozess-Status und ob die 
nötigen Prozesse laufen.
Wenn Du schreibst "Daten werden trotzdem nicht angezeigt" so meinst Du 
sicher die grafische Ausgabe des Browsers. Bitte kontrolliere also ob 
die Datenbanken unter ./HT3/sw/var/databases alle aktualisiert werden (5 
Minuten beobachten). Wenn dem so ist sind die Daten in den Datenbanken.
Dann hast Du 'nur' noch ein "Grafik Erzeugen und Anzeige"-Problem.
Die Grafik wird zyklisch im cron-job durch das script 'rrdtool_draw.pl' 
gemacht.
Dies kannst Du auch manuell aufrufen und die Grafiken werden dann direkt 
aus den vorhandenen rrdtool-Daten erzeugt:
  /home/pi/HT3/sw/etc/rrdtool_draw.pl /home/pi /home/pi 1
Die erzeugten Grafiken (PNG-Files) liegen dann im Verzeichnis:
  /home/pi/HT3/sw/etc/html

Falls Du damit auch nicht weiterkommst kannst Du mir ein Logfile der 
HT-Busdaten erstellen und an meine PM senden:

1. Logger Stoppen
   /etc/init.d/ht3_logger stop
2. Logfile für die Auswertung erzeugen
   cat /dev/ttyAMA0 >> /tmp/htbus_logfile.bin
Bitte einige Zeit laufen lassen und mir zusenden.

Gruß Norbert

[Nils R. (augur)]

Hi Norbert,

hier mal die Ausgabe von PS nach einem Neustart
admin@HT3:/usr/smarthome$ ps ax|grep HT
 1891 ?        S      0:00 avahi-daemon: running [HT3.local]
 1998 ?        Sl     0:03 /usr/bin/python3 
/home/admin/HT3/sw/HT3_Logger.py
 2402 pts/0    S+     0:00 grep HT

Die rrd und sqlite files werden nicht verändert. Sind auch weiterhin 
leer. Hatte schon vorher den Inhalt der SQLite DB geprüft und alle 
Tabellen sind auf 0 Zeilen. Anscheinend schreibt das Programm einfach 
nichts weg.

Ich schick dir mal die Busdaten.

Viele Grüße,
Nils

[Stefano I. (donaldd)]

Hi Norbert

I can see that you have updated the documentation with HT Netclient 
section, when will the client/proxy scripts be available? I am very keen 
to test it

Thanks in advance

Regards

Stefano

[Norbert S. (junky-zs)]

Hallo Stefano,
>when will the client/proxy scripts be available?
That client/proxy- behaviour is already running. Finally I add some 
logging to all library-moduls. So the handling will be easier.
It is finished before end of the week hopefully.
This update on github will come as soon as possible.

Regards Norbert

[Norbert S. (junky-zs)]

Hallo,

es hat sich wieder etwas bei der Software getan.
Die aktuelle Software ist: Rev.: 0.1.7.1 und wie gehabt unter github.com 
zu finden.
Hier an dieser Stelle nur der Hinweis darauf. Details siehe:
  Beitrag "Re: Heizungs-Datenerfassung (HT3), SW-Rev:0.1.7.1"

Gruß Norbert

[Stefano I. (Gast)]

Hi

I am trying to use the new proxy feature, to control my heating system, 
but when I am issuing:

  ./ht_netclient.py -b sparen

Nothing happens, and I get the following errors in my ht_proxy.log:

16.03.2015 18:16:01 INFO: Client-ID:2; ('127.0.0.1', 54056) connected
16.03.2015 18:16:01 INFO: Server   :('0.0.0.0', 8088)
16.03.2015 18:16:01 INFO: Client-ID:2; register(); got devicetype:MODEM
16.03.2015 18:16:01 INFO: Client-ID:2; added; number of clients:2
16.03.2015 18:16:01 INFO: Client-ID:2; cht_RequestHandler(); 
socket.receive thread start
16.03.2015 18:16:01 INFO: csocketsendThread(); socket.send thread start
16.03.2015 18:16:01 INFO: Client-ID:1;cportwrite();couldn't read from 
queue
16.03.2015 18:16:03 INFO: Client-ID:2; ('127.0.0.1', 54056) disconnected
16.03.2015 18:16:03 INFO: Client-ID:2; removed; number of clients:1
16.03.2015 18:16:03 INFO: Client-ID:1;cportwrite();couldn't read from 
queue


Any idea what is wrong?

And what does 'cportwrite();couldn't read from queue' mean?

Thanks in advance

Regards

Stefano

[Norbert S. (junky-zs)]

Hallo,

@Stefano,

>Nothing happens, and I get the following errors in my ht_proxy.log:
These are informations (INFO) and normal message-behaviour of 
ht_netclient.
The ht_netclient will connect only for the required messages and then 
disconnect again.
Your check with ht_netclient is that one with ID:2
  Client-ID:2; ('127.0.0.1', 54056)...
and that logging is OK.

>And what does 'cportwrite();couldn't read from queue' mean?
The Client-ID:1 is used for 'HT3_Logger.py' running parallel as 
proxy-client and the message raised at Client-ID disconnect-time. Anyway 
the HT3_Logger.py will never use any Informations from the queue to send 
messages to the comport.

>Nothing happens..
I'll think you checked all the other parameters like: -b auto, -b tag , 
-b frost and also -t <temperaturvalue> ?
Your indicator for watching:'working' or 'not working' can be the 
FW/FRxyz - display. I'll think you have used it already.

For further checks you can do following:
1. check the informations in logfile: 
./HT3/sw/var/log/ht_client_modem.log
2. Enable debug-output on ht_proxy-server with:
 ht_proxy=ht_proxy_if.cht_proxy_daemon(configfile, 
loglevel=logging.DEBUG)
Please restart that proxy-server than with:
 sudo /etc/init.d/ht_proxy stop
 sudo /etc/init.d/ht_proxy start

In case 2. you will get more debug-messages what is send to the 
ht_transceiver-board.

Please let me know what heater-configuration you are using, like FW1xy 
etc. and how many heater-circuits you have in your system (1 or more).

I'm using one heater-circuit and FW100 and that telegrams setup the 
wanted heater-parameters.

Regards Norbert

[Stefano I. (donaldd)]

Thanks Norbert, for your fast reply

I have one heating circuit and the FW120 control unit

Enabling the debug mode in ht_proxy.py gave some extra information:

16.03.2015 20:22:43 INFO: Client-ID:5; ('127.0.0.1', 33838) connected
16.03.2015 20:22:43 INFO: Server   :('0.0.0.0', 8088)
16.03.2015 20:22:43 INFO: Client-ID:5; register(); got devicetype:MODEM
16.03.2015 20:22:43 INFO: Client-ID:5; added; number of clients:2
16.03.2015 20:22:43 INFO: Client-ID:5; cht_RequestHandler(); 
socket.receive thread start
16.03.2015 20:22:43 INFO: csocketsendThread(); socket.send thread start
16.03.2015 20:22:43 DEBUG: Client-ID:5; 
recv:b'#\t!S\x11\x10\xff\x0e\x00e\x04'
16.03.2015 20:22:43 INFO: Client-ID:1;cportwrite();couldn't read from 
queue
16.03.2015 20:22:43 DEBUG: Client-ID:5;cportwrite();value:23
16.03.2015 20:22:43 DEBUG: Client-ID:5;cportwrite();value:21
16.03.2015 20:22:43 DEBUG: Client-ID:5;cportwrite();value:53
16.03.2015 20:22:43 DEBUG: Client-ID:5;cportwrite();value:11
16.03.2015 20:22:43 DEBUG: Client-ID:5;cportwrite();value:06
16.03.2015 20:22:43 DEBUG: Client-ID:5;cportwrite();value:10
16.03.2015 20:22:43 DEBUG: Client-ID:5;cportwrite();value:ff
16.03.2015 20:22:43 DEBUG: Client-ID:5;cportwrite();value:0e
16.03.2015 20:22:43 DEBUG: Client-ID:5;cportwrite();value:00
16.03.2015 20:22:43 DEBUG: Client-ID:5;cportwrite();value:65
16.03.2015 20:22:43 DEBUG: Client-ID:5;cportwrite();value:04
16.03.2015 20:22:43 DEBUG: Client-ID:5;cportwrite();value:3a
16.03.2015 20:22:44 DEBUG: Client-ID:5; 
recv:b'#\t!S\x11\x10\xff\x04\x00y\x04'
16.03.2015 20:22:44 DEBUG: Client-ID:5;cportwrite();value:23
16.03.2015 20:22:44 DEBUG: Client-ID:5;cportwrite();value:21
16.03.2015 20:22:44 DEBUG: Client-ID:5;cportwrite();value:53
16.03.2015 20:22:44 DEBUG: Client-ID:5;cportwrite();value:11
16.03.2015 20:22:44 DEBUG: Client-ID:5;cportwrite();value:06
16.03.2015 20:22:44 DEBUG: Client-ID:5;cportwrite();value:10
16.03.2015 20:22:44 DEBUG: Client-ID:5;cportwrite();value:ff
16.03.2015 20:22:44 DEBUG: Client-ID:5;cportwrite();value:04
16.03.2015 20:22:44 DEBUG: Client-ID:5;cportwrite();value:00
16.03.2015 20:22:44 DEBUG: Client-ID:5;cportwrite();value:79
16.03.2015 20:22:44 DEBUG: Client-ID:5;cportwrite();value:04
16.03.2015 20:22:44 DEBUG: Client-ID:5;cportwrite();value:52
16.03.2015 20:22:45 INFO: Client-ID:5; ('127.0.0.1', 33838) disconnected
16.03.2015 20:22:45 INFO: Client-ID:5; removed; number of clients:1
16.03.2015 20:22:45 INFO: Client-ID:1;cportwrite();couldn't read from 
queue

the is the response for -b auto, I have also tried change the 
temperature with -t xx

But the mode do not change on the FW120 display

Regards

Stefano

[Norbert S. (junky-zs)]

Hallo,

@Stefano,
this sequenz is exact that I have. It should work in that case. That 
auto-mode is not always shown on the display but after sending any other 
mode like -b sparen then it is.
If you change that temperatur with -t 22.5 then the FW100 shows that 
level as shown above.
Also the HT3_Analyser will display that level (picture above).
The sequence I did was:
 ht_netclient.py -b heizen
 ht_netclient.py -t 22.5

The correspondending sequenz for the temperatur-setting is:
16.03.2015 21:19:15 INFO: csocketsendThread(); socket.send thread start
16.03.2015 21:19:15 DEBUG: Client-ID:8; 
recv:b'#\t!S\x11\x10\xff\x11\x00e-'
16.03.2015 21:19:16 INFO: Client-ID:1;cportwrite();couldn't read from 
queue
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:23
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:21
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:53
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:11
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:06
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:10
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:ff
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:11
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:00
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:65
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:2d
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:eb
16.03.2015 21:19:16 DEBUG: Client-ID:8; 
recv:b'#\t!S\x11\x10\xff\x07\x00y-'
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:23
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:21
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:53
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:11
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:06
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:10
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:ff
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:07
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:00
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:79
16.03.2015 21:19:16 DEBUG: Client-ID:8;cportwrite();value:2d
16.03.2015 21:19:17 DEBUG: Client-ID:8;cportwrite();value:63

I'll think you have the same sequenz for that temperatur-setting.
So then we have some differenz between FW100 and FW120 regarding the 
required sequenzes.
I'll hope to find an answer for that.

Best regards
Norbert

[Stefano I. (donaldd)]

Hi Norbert

When I am comparing your HT3 Analyser with mine, I can see that I do not 
have the Room Temperature (T-Raum), so there must be a difference 
between the  FW100 and FW120

Stefano

[Norbert S. (junky-zs)]

Hallo,

@Stefano,
>I can see that I do not have the Room Temperature (T-Raum)...
So in that case you don't have that remote controller (type FB10 or 
FB100). So the values for that devices in the telegrams are out of order 
(8000)hex and will be surpressed for your system.
Anyway that value must be visible on your controller FW120 as shown with 
the picture above.
Questions:
1. How long (in meters) is the cable between your ht_pitiny-board and 
the connection (Bus-connection fixpoint) to the heater-system (markt 
with 'B')?
2. Which type of cable did you use (thickness)?
3. Do you have any additional resistors in that connection-cable?
Keep in mint that the transmit-direction is current-driven!

So the difference between FW100 and FW120 is not as great as supposed. 
The commands then should work at your system.

Regards Norbert

[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 (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

[Hans (Gast)]

Hallo zusammen,
der Adapter ist bereits von der Heizung getrennt ☺
Das Verhalten kann ich allerdings nicht nachvollziehen. Selbst wenn der 
Optokoppler defekt wäre, warum soll das einen Einfluss auf das 
WLAN-Modul am Pi haben. Da würde ich eher mit einem Komplettausfall des 
Pi rechnen. Nichts desto trotz habe ich die Schaltung durchgemessen und 
mit einer externen Spannungsquelle als Simulator des Ht3-Buses getestet. 
Dabei konnte ich keine Fehler feststellen, alles hochohmig und der 
Optokoppler funktioniert, ohne dass das WLAN abstürtzt.
Die Spannung vom HT3-Bus der Heizung habe ich allerdings noch nicht 
gemessen. Da die Heizung aber gut funktioniert, gehe dort nicht von 
einem Fehler aus. Aber selbst wenn, warum sollte ein Fehler der Heizung 
das WLAN rauskicken. Hmmm, ich habe keinen Reim drauf.

Bin dankbar für alle Anregungen,

Hans

[adam (Gast)]

Hallo Hans,
nach zwei Jahren störungsfreier Arbeit hatte ich die gleichen Symptome.
Neue WLAN-Antenne hat nicht geholfen.
Ich hatte die Backup der SD-Karte (gesichert direkt nach der 
Installation) mehrmals wiederhergestellt (kleine sqlite-DB) , nach paar 
Tage wieder das gleiche.

Da die neue Version 0.3 gibt, habe Jessie und HT3 neu installiert und 
Raspi mit Lan-Kabel verbunden.
Seit einem Monat kein Ausfall.

[Hans (Gast)]

Hallo Adam,

OK, dann werde ich jetzt nochmal anstatt Stretch-Lite ganz normal 
Stretch ausprobieren. Denke aber, dass ich keinen Unterschied 
feststellen werde. Probieren geht über studieren :-)
Ich halte euch auf dem Laufenden.

VG

Hans

[adam (Gast)]

Hans schrieb:
> OK, dann werde ich jetzt nochmal anstatt Stretch-Lite ganz normal
> Stretch ausprobieren.

Hallo Hans,
funktioniert mit Stretch?

Norbert,
funktioniert HT3 problemlos mit Stretch?
Lohnt sich umsteigen?

[Norbert S. (junky-zs)]

Hallo Adam,

>funktioniert HT3 problemlos mit Stretch?
Problemlos nicht, aber die Lösung ist ja da.
Siehe paralleler Projekte & Code - Thread:
Beitrag "Re: Heizungs-Datenerfassung (HT3)"

Es geht dort um die Generierung der Grafiken mit rrdtool.
Details und Lösung sind da beschrieben.
Der Rest läuft wohl. Ich selber setzte Stretch nicht ein und nutzte 
Wheezy bzw. Jessie, kann also keine weiteren Details prüfen.
Aber der python-Code wird wohl auch mit Stretch (ohne Stress) problemlos 
laufen :-)

Gruß

[Hans (Gast)]

Hallo zusammen,

möchte euch eine kleine Rückmeldung zu meinem Problem mit dem 
WLAN-Adpater geben. Habe heute Wheezy aufgespielt und und die 
Datenerfassung läuft perfekt. Das Problem scheint also bei Stretch und 
USB / GPIO-Anbindung zu liegen.
Jetzt stellt sich für mich die Frage welche  Distribution für die 
HT3-Datenerfassung die Richtige ist ? Wheezy oder Jessie ?


Sonnige Grüße aus dm Münsterland

Hans

[Norbert S. (junky-zs)]

Hallo Hans,

> Wheezy oder Jessie ?
"Jessie" := Debian 8 !

Der Support für "Wheezy" := Debian 7 läuft in 2018 aus.
 "Wheezy LTS will supported from 26 April 2016 to 31 May 2018".
Siehe URL:
https://www.debian.org/News/2016/20160425

Gruß Norbert

[Andreas W. (urbansunited)]

Hallo zusammen,

dank Norbert habe ich endlich mein System am Laufen wie es sein soll.
Nachdem ich meine "Testinstallationen" auf einen RPi1b gemacht hatte und 
es da dann endlich lief, bin ich rüber auf einen RPi3 mit Stretch 
gegangen.
Viele neue Probleme, die ich aber alle in den Griff bekommen habe.
Dazu kommt am WE aber noch eine gesonderte Installationsanleitung.

Jetzt will ich das RPi3 Wlan Problem unter Stretch lösen:

Sollte euer Wlan mit Strech nicht klappen, müssen folgende Anpassungen 
gemacht werden.
Ich gehe hier von einer Stretch Fresh-Installation aus!

1. Wi-fi-Country des Raspberry Pi einstellen

sudo raspi-config
Dort unter Internationalisation Options -> Change Wi-fi Country die 
länderspezifischen Einstellungen anpassen. Für Deutschland bitte DE 
Germany auswählen

2. Unter /etc/wpa_supplicant/wpa_supplicant.conf euere Wlan Daten 
eingeben:
sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

network={
    ssid="Name Wlan Netzwerk"
    psk="Passwort zum Wlan"
}

Dann speichern

3. Prüfen, wie das Wlan device heisst. Normal wlan0, kann aber auch 
anders betitelt sein, zB. nxb827ec3f7f60

danach starten wir das Wlan neu:

sudo ifdown wlan0 (oder wie auch immer euer wlan device heisst - evtl. 
anapassen)
sudo ifup wlan0 (oder wie auch immer euer wlan device heisst - evtl. 
anapassen)

4. Die Datei /etc/network/interfaces lassen wir unverändert!!!! Sollten 
da selbstgemachte Einträge enthalten sein, bitte löschen.

5. Config anpassen: sudo nano /etc/dhcpcd.conf
6. Für die statische IP Anbindung bei eth0 die # entfernen und die Daten 
anpassen.
   Für die Wlan config folgendes hinzufügen (ich hatte es unter den eth0 
part gesetzt, kann aber auch ganz nach unten):

inferface wlan0
static ip_address=192.168.0.200/24
static routers=192.168.0.254
static domain_name_servers=8.8.8.8 192.168.0.254

speichern und reboot

Dann sind wir fertig und es sollte wieder mit dem RPi3 eigenem Wlan 
funktionieren.

Gruß

URBANsUNITED

[Jan (Gast)]

Hallo Andreas,

das WE ist noch nicht rum, und ich will nicht ungeduldig sein. Wäre 
trotzdem toll, wenn Du in Deiner Installationsanleitung auch auf die 
spezifischen Einstellungen eingehen könntest, die Raspbian Stretch für 
den GPIO braucht, um mit dem Pitiny zu funktionieren.

Ich habe letzte Woche versucht, vom einen Pi3 mit Jessie auf den anderen 
Pi3 mit Stretch unmzuziehen und habe es ums Verrecken nicht hinbekommen, 
die "richtigen" Einstellungen in der config.txt etc. einzugeben, dass 
mir auch Daten auf dem Pitiny ankommen oder gesendet werden. Nach ein 
paar Stunden basteln habe ich aufgegeben und den Pitiny wieder an den 
"alten" Raspi gesteckt... aber die Herausforderung ist nur aufgeschoben.

Danke!
Jan

[Andreas W. (urbansunited)]

Hallo,
wie schon angekündigt, wollte ich meine Installationsschritte den Usern 
nicht vorenthalten.
Ich habe folgende Hard und Software im Einsatz:
Raspberry Pi 3b
ht_pitiny Adpater
Raspbian Stretch minimal Image stand September

Wer die gleiche Hard und Software nutz, findet anbei meine Anleitung zur 
Installation des Betriebssystems und kleineren Anpassungen.
Ich habe mich dabei der Anleitung von Norbert bedient und habe meine 
Anpassungen entsprechend eingebaut.

Gruß

Andreas

[Andreas W. (urbansunited)]

Wer kann mir bitte weiterhelfen?

Ich möchte an meinen RPi3 jetzt noch einen 433Mhz Sender anschließen.
Wie gehe ich da vor? Wie greife ich die Gpios ab?

Danke

Andreas

[Norbert S. (junky-zs)]

Hallo Andreas,

wenn Du zusätzliche Hardware zusammen mit dem ht_pitiny-Adapter 
anschliessen willst so hängt dies davon ab welche Schnittstelle diese 
Hardware hat.

Auch spielt der Typ des RaspberryPi eine Rolle, der ht_pitiny-Adapter 
benutzt die ersten 26 Pins (2*13) des Raspberry-GPIO.
Wenn Du z.B. einen RaspberryPi mit 40Pin Sockel hast, so kannst Du dort 
die freien Pins nutzen.

Der ht_pitiny-Adapter benutzt nur die RX/TX-Pins des UART und die 
SPI-Pins (Mosi/Miso/Clk) für ein eventuelles Softwareupdate.
Die restlichen Pins sind frei.
Die Pinzuordnung ist festgelegt unter der URL:
 https://pinout.xyz

Gruß Norbert

[Jo (Gast)]

Hallo, ich habe noch zwei wenig benutzte Pitiny Adapter da. Hatte sie 
vor einiger Zeit von Norbert für einen Kollegen und für mich gekauft, 
dann aber aufgegeben weil ich mit dem Thema doch ein wenig überfordert 
war.

Wer Interesse hat bitte melden!

[Patrick (Gast)]

Hallo Jo,

ich hätte Interesse an einem Pitiny Adapter. Wie können wir denn da 
zusammenkommen?

Grüße
Patrick

[Jo (Gast)]

Hallo Patrick
Habe mal eine temporäre Adresse erstellt: [e-mail]
Schreibe die Adresse an und ich werde mich mit meiner echten
Adresse melden. Denke wir werden uns schon einig!

Gruss
Jo

[Ferdinand S. (sir_bacon)]

Hallo Jo,

Dann möchte ich mich gerne melden für der zweite Adapter. Ich wird mir 
dann melden am gleiche Emailadresse, aber erst heute Abend.

Gruß, Ferdinand

[tzem (Gast)]

Hat jemand noch ein piduino oder pitiny adapter über was er nimmer 
braucht

[Ferdinand S. (sir_bacon)]

Gutentag,

Ein kurze Frag zu der Pitiny Adapter. Ich habe eine Nefit Heizung, der 
Niederländische Marke von Bosch, und der spricht EMS. Wenn ich alles gut 
gelesen habe spricht der Pitiny auch EMS. Oder habe ich etwas übersehen 
oder falsch gelesen?

Im Nachbarthread habe ich auch schon ein Frag dazu gestellt, aber noch 
kein Antwort bekommen. 
Beitrag "Re: EMS > Adapter > NetIO > Raspi"

Gruß, Ferdinand

[Holger R. (Gast)]

Hallo Zusammen,

ich versuche zzt. HT3 wieder unter Stretch zum Laufen zu bekommen.

Unter Jessie funktionierte HT3 mit dem HT3-Adapter sauber.
Aufgrund der IP Symcon muss ich auf Stretch aktualisieren.

Upgrade auf Jessie => Stretch durchgeführt und ich bekomme die folgende 
Fehlermeldung in Ccollgate.log

28.12.2017 17:05:47 INFO: Starting 'Ccollgate.run()
28.12.2017 17:05:47 CRITICAL: cht_if_worker();Error;couldn't open 
requested device:/dev/ttyAMA0
28.12.2017 17:05:47 CRITICAL: ccollgate().run();Error;could not start 
'ht-interface' with file:'./etc/config/HT3_db_cfg.xml'
28.12.2017 17:05:47 CRITICAL: ccollgate().run();Error; terminated

Neuinstallation (auf neuer SDCard) nach der Anleitung von URBANsUNITED 
gemacht, leider ohne Erfolg, gleiche Fehlermeldung.

Hat jemand eine Idee wo ich hinfassen muss?
Was übersehe ich?

Danke für Eure Unterstützung im Voraus

Holger

[Norbert S. (junky-zs)]

Hallo Holger,

den Portalias: /dev/ttyAMA0 gibt es so wohl nicht mehr und ist durch 
'serial0' bzw. 'serial1' ersetzt.

Mit: 'ls -l /dev' kannst Du kontrollieren ob /dev/serial0 vorhanden ist.

Ersetze in den Konfigurations-Files diese Werte durch:
  <serialdevice>/dev/serial0</serialdevice>

Betroffene Konfigfiles sind:
 ~/HT3/sw/etc/config/ht_proxy_cfg.xml
(falls der Bus-Adapter direkt vom ht_proxy.server ausgelesen wird.
Dies ist default so.)

 ~/HT3/sw/etc/config/HT3_db_cfg.xml
(Dies nur falls der ht_proxy.server nicht genutzt wird und statt SOCKET 
auf ASYNC konfiguriert wurde: <comm_type>ASYNC</comm_type>)

Nach der Konfigurationsänderung den PI neu booten.

Weitere Details zur Linux Portkonfiguration findest Du u.A. unter URL:
https://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/#Serial_Aliases

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo Ferdinand S,

>Wenn ich alles gut gelesen habe spricht der Pitiny auch EMS?
Die Bezeichnung und Funktion von:'EMS' ist leider zwischen Buderus und 
Junkers unterschiedlich.
Beiden ist allerdings der 2-Draht Bus mit Spannungsversorgung und 
Signalisierung gemeinsam.
Die Protokolle sind jedoch unterschiedlich.

Der ht_pitiny-Adapter setzt das Bus-Signal in ein serielles auswertbares 
Protokoll um. Die Auswertung der Daten muss dann allerdings mit der 
externen Software gemacht werden.
Die Dekodier-Software für die ht-Adapter 
(Mini-/Micro-/ht_piduino-/ht_pitiny-Adapter) ist für das 
Junkers-Bustelegramm geschrieben.
Diese passt nicht zu Buderus EMS bzw. EMS-Plus.

Marke____Bus-Bezeichnung
Buderus: EMS und EMS-Plus
Junkers: EMS2 oder älter Heatronic3, Heatronic4i

So wie ich bisher in den Beschreibungen gefunden habe verwendet 
'nefit'den Buderus EMS bzw. den EMS-Plus Bus.
Der ht_pitiny Adapter passt nicht zu diesem Bus da er aktiv 
Pollingantworten in den Heizungs-Bus sendet.
Du kannst aber eventuell die passiven Mini- oder Micro-Adapter verwenden 
um mit einer eigenen Software die Signale zu dekodieren.
Software dazu gibt es auch unter URL:
https://github.com/bbqkees/Nefit-Buderus-EMS-bus-Arduino-Domoticz

Gruß Norbert

[Ferdinand S. (sir_bacon)]

Hallo Norbert,

Danke für das Antwort, und noch ein gutes Neujahr!

Also, der ht_pitiny würde nicht gehen. Schade, dann kann ich nicht der 
fertige Adapter von Jo benutzen.

Brauch ich also eine micro-adapter. 2 Fragen dazu:
* Gibt es die schon mal fertig zu bewerben?
* Wurde diese dann funktionieren mit der S/W EMS-collector von 
Maniac103: https://github.com/maniac103/ems-collector ?

Gruß, Ferdinand

[Jo (Gast)]

Hallo
Da Ferdinand den Adapter nicht gebrauchen kann, ist er wieder zu haben.

[Mark W. (markidas)]

Ich hätte Interesse am Pitiniy Adapter :-)

[Jo W. (basteljo)]

Zur Info: Beide Pitiny-Adapter sind nun verkauft.
Viele Grüße und viel Bastelspass
Jo

[Martin T. (Gast)]

Hallo Norbert

Erstmal danke für diese fantastische Arbeit.

Nachdem meine Vailant Therme nun langsam aber sicher den Geist aufgibt 
plane ich einen Systemwechsel auf Junkers.
Mir wurde als Therme eine ZSR 18/7 KE angeboten.
Diese hat meines Wissens nach eine HT3 Steuerung.

Da ich im restlichen Haus eine SmartHome Anlage basierend auf Home 
Assistant betreibe suche ich nach einer Möglichkeit auch die Therme zu 
integrieren.

Nun zu meiner Frage.
Derzeit gibt es lt. Junkers Programm für die ZSR 18 3 verschiedene 
Regeleinheiten
C(W/R)100 (1 Heizkreis)
C(W/R)400 (4 Heizkreise, 2 WW Kreise regelbar)
CT100/CT200 (Raumthermostate mit Wlan)

Welche davon kann dein HT-Logger decodieren =?

lg
Martin

[Norbert S. (junky-zs)]

Hallo Martin T.,

>Mir wurde als Therme eine ZSR 18/7 KE angeboten.
>Diese hat meines Wissens nach eine HT3 Steuerung.
Ja, hat sie laut den Junkers-Unterlagen (siehe Bild).

Somit ist dieses Heizgerät auch mit MBLan2 und eben auch mit den 
ht_transceivern (ht_pitiny / ht_piduion) steuerbar.

>Welche (C100/C400/CT100/CT200) davon kann dein HT-Logger decodieren =?
Die wichtigsten Telegramme des CW100 werden dekodiert, eine Steuerung 
mit den ht_transceivern ist auch möglich.
Ich selber hatte einen CW100 an meinem Heizungssystem und konnte die 
Telegramme damit dekodieren (sind im aktuellen Release von 2017 
enthalten).

Die C400 Regler und deren Telegramme sind sehr ähnlich dem C100-Typen, 
haben natürlich zusätzliche Telegramme, aber auch diese werden 
grossteils dekodiert.

Aber nichts ist perfekt und deshalb habe ich mir einen CW400 mit CR10 
und zugehörigem Solarmodul zugelegt. Diese funktionieren ja auch am 
Heatronic3 - Bus.
Nach dem Umbau meiner Heizung (2. Quartal 18) geht das Dekodieren weiter 
:-)

Beim den CT100/CT200 - Reglern weiss ich nicht wirklich ob dort andere 
Telegramme gesendet werden.
Vielleicht hat jemand damit schon Erfahrung gesammelt. Bitte dann hier 
posten.

Gruß Norbert

[Harald G. (hallo_s)]

Weiß jemand oder der neue Junkers Regler CW100 mit dem älteren 
Solarmodul ISB1 in Verbindung mit der älteren Cerapur ZSB 14-3 
funktioniert?
CW100 hat EMS2 BUS Cerapur ZSB14-3 sowie das Solarmodul ISM1 hat 
Heatronic3 neue Thermen Cerapur ZSB 14-4 müssten demnahc Heatronic4i 
haben.

[Nils R. (augur)]

Moin.

Mal ne Frage, ich hab schon länger einen Adapter und einen MB-Lan2 am 
Bus laufen und seit gefühlt letztes Jahr kann ich die Zeitpläne mit der 
Iphone App nicht mehr ändern. Kann das durch die Kombination beider 
Komponenten am Bus kommen oder ist einfach die App defekt (was ich von 
Junkers bzw. Bosch beinahe erwarten würde)?

Vielleicht hat ja noch jemand ein MB-Lan2 am laufen...

Viele Grüße,
Nils

PS. Bei mir stellt sich auch die Sommer/Winterzeit nicht automatisch um. 
Laut Junkers soll sich mein Heizungsbauer das anschauen (toller 
Support...). Sagt das auch jemanden was? In den Einstellungen ist es 
egal, ob ich die Umschaltung aktiviere oder nicht.

[Norbert S. (junky-zs)]

Hallo Nils,
die Bus aktiven ht-Adapter (ht_pitiny, ht_piduino) kann man parallel zum 
MBLAN2 betreiben.
Es muss allerdings die Geräte-Adresse des ht-Adapters von default 13dez. 
auf 10dez. geändert werden. Dann gibt es da auch keine Kollisionen am 
ht-Bus.
Ich glaube aber das Du dies schon gemacht hast und dies als Grund 
ausscheidet.

Welchen Regler (Fxyz oder Cxyz) hast Du in Deinem System und hast Du 
diesen eventuell getausch?
Da habe ich so meine negativen Erfahrungen gemacht, siehe URL:
http://www.heizungsforum.de/board/index.php?thread/11181-mblan2-funktioniert-nicht-mehr-mit-regler-fw100/&postID=116041&highlight=MBLAN2#post116041

Funktionieren die anderen Steuermöglichkeiten (Betriebsmode, 
Temperaturniveau) mit dem MBLAN2 und dem ht-Adapter?

Gruß Norbert

[Nils R. (augur)]

Hi,

die Einbindung mit der Adresse hab ich geändert und es lief bzw. läuft 
auch. Die Umschaltung der Modi oder auch das Auslesen der Parameter 
klappt einwandfrei. Nur die Zeitpläne kann ich nicht mehr mit der Bosch 
App ändern. Hab eine FB120 und hab diese von Anfang an drinnen.

In den App Rezensionen hab ich auch von ähnlichen Problemen bei einem 
anderen Nutzer gelesen. Bosch hab ich mal angeschrieben, aber bisher kam 
da nichts zurück zu dem Zeitplanproblem.

Viele Grüße,
Nils

[Andreas W. (urbansunited)]

Hi!

Wer hat denn eigentlich die Heizungssteuerung mit in seine Home 
Automation eingebunden?
Welche Software nutzt ihr dafür? FHEM, openhab oder?
Ich habe nämlich meine Thermostate für die Fussbodenheizung in den 
Räumen rausgeworfen und steuer aktuell die Anlage über die 
Durchflussmenge und Zeitsteuerung.
Die Thermostate takteten die Heizung einfach zu oft (locker 20x und 
mehr) plus sie waren absolut unzuverlässig, was die angezeigte 
Temperatur anging. 23° eingestellt, 24,5° war der Raum dann, weil das 
Thermostat sich wieder dekalibiriert hatte.
Die aktuelle Umsetzung befriedigt mich aber noch nicht ganz:
0300-0700h Heizung an
0700-0900h Heizung aus
0900-1100h Heizung an
1100h-1400h Heizung aus
1400h-1600h Heizung an
1600h-0300h Heizung aus
Für die angepeilten 23° komme ich damit hin, aber es geht doch bestimmt 
komfortabler? Man könnte ja die Schaltbefehle bequem auch per FHEM 
senden, oder???

Außerdem, wie kriege ich die Pumpenleistung runter? Bei mir ist sie 
immer im 90-100% Bereich. Ist das normal? Hab mal ein Bild dazu 
angehängt.

Danke

URBANsUNITED

[Kaa (Gast)]

Hallo,

ich überlege auch bei mir den BUS mitzuloggen. Ich hatte eine CT100 die 
aktuell jedoch durch ein Tado-Thermostat ersetzt wurde.

Da der Versand aus China für die Bauteile doch eine Weile dauern würde 
und kein Conrad o.ä. in der Nähe ist:
Hat jemand die Teile für einen Bausatz oder einen Bausatz rumliegen?

Wenn ich es richtig verstanden habe wird der Adapter zusätzlich in die 
bestehende Verkabelung mit eingebunden. Ist hierbei etwas im besonderen 
zu beachten?

[whatever_42 (Gast)]

Hallo,

ich besitze in meiner Mietwohnung auch eine Junkers Heizung, welche über 
das Thermostat gesteuert wird von dem ich ein Foto gemacht habe. Kann 
ich die hier besprochene pitiny Lösung dafür auch verwenden? Ich hatte 
bis jetzt den Eindruck als würde diese Lösung eine richtige Verkabelung 
mit der Heizung erfordern und mein Thermostat scheint ja recht 
offensichtlich 868 MHz für die Kommunikation zu verwenden. Falls ich die 
pitiny Lösung dafür verwenden kann, wüsste ich gerne wie und würde dann 
vermutlich auch gerne eines haben, also falls noch jemand so ein Ding.

Vielen Dank schon mal im Voraus.

[Norbert S. (junky-zs)]

Hallo whatever_42,

alle hier beschriebenen Adapter erwarten auf dem Heizungs-Bus das 
Heatronic3, Heatronic4i oder EMS2 Protokoll. Auf diesem Bus werden 
ständig Telegramme zwischen den Modulen ausgetauscht.

Über Funk im 868 MHz Band ist eine ständige Kommunikation nicht erlaubt.
Daher funktioniert die Datenerfassung nicht mit Deinem Funk-Regler TR10.
Eine Verbindung mit mindestens Heatronic3-Bus ist erforderlich.

Gruß Norbert

[Michael (Gast)]

Guten Morgen zusammen,

bin mit diesem Projekt genau das gefunden, was ich gesucht haben. Vielen 
dank für die tolle Vorarbeit und die ausführliche Anleitung. Leider habe 
ich dennoch ein Problem. Beim Hardwaretest (HT3-mini Adapter) will die 
LED (sie ist nicht defekt) nicht leuchten. Eingangswiderstand am HT3 
Anschluss liegt bei 1,3kOhm, galvanische Trennung ist auch gegeben. Das 
sollte also passen. Wenn ich nun am Klemmblock die 14,5V anlege, 
passiert nichts. An der LED messe ich eine Spannung von 7,5V, was 
sicherlich zu hoch ist.

Bauteile wurde alle nach Liste bestellt. In den Abbildungen 3 und 4 der 
Anleitung ist der Transistor unterschiedlich orientiert, gehe davon aus, 
dass er sich entsprechend Abb 2 leichter löten lies. Habe daher den 
Aufbau nach Abbildung 1 und 4 gemacht.

Habe das Ganze auf dem Steckbrett und gelötet versucht. Leider mit 
gleichem Ergebnis.

Die Installetion hat einwandfrei funktioniert, muss diese eigentlich 
noch gestartet werden oder reicht die Installation und der Neustart? 
Habe dazu in der Anleitung nichts gefunden, wie kann eine korrekte 
Installation überprüft werden?

@Norbert, ist es möglich noch einen piduino oder pitiny Adapter zu 
erwerben?

Gruß Michael

[Norbert S. (junky-zs)]

Hallo Michael,

>Beim Hardwaretest (HT3-mini Adapter) will die LED nicht leuchten.
Hast Du mal die Polarität des Bus-Kabels am Klemmenblock getauscht?
Die richtige Polarität ist wichtig, sonst wird die LED auch nicht 
leuchten.

>An der LED messe ich eine Spannung von 7.5V, was sicherlich zu hoch ist.
Wenn Du zwischen der Anode der grünen LED und der analogen Masse (AGND) 
misst so kann dies durchaus so sein. Ca. 15 Volt minus der Zenerspannung 
9.1 Volt kommt in etwa hin.
Wenn Du allerdings direkt über der Diode (zwischen Anode und Kathode) 
diese 7,5 Volt hast, dann ist die Diode defekt oder eben die Polarität 
des Bus-Anschlusses nicht richtig.
Prüfe also noch mal die richtige Polarität an Hand des Schaltplans:
Klemmenblock Pin1 ist an Diode D1 und da muss Plus sein.

Du kannst danach auch mal den Eingang Pin1 des Optokopplers mit der 
analogen Masse AGND (am Optokoppler Pin2) verbinden. Die grüne LED muss 
dann leuchten.

Es muss nichts neu (Heizung etc.) gestartet werden, die Bus-Signale und 
die Modul-Betriebsspannung sind immer da.

Ich habe noch einen ht_pitiny Adapter. Bitte PM an mich. Weiteres dann 
dort.

Gruß Norbert

[Tzem A. (tzema)]

Hat jemand noch ein piduino oder pitiny adapter über was er nimmer
braucht.

oder kann mir einen Löten????

bitte PN wenn jemand noch ein der oben genannten Adapter übrig hat

Danke

[Stefan S. (kami)]

Hallo zusammen,

ich habe auf einem Rpi 3 einen Pitiny mit meiner Junkers Therme im
Einsatz nun möchte ich ein 2,2 TFT LCD über SPI und I2C anschliessen.
Geht das oder blockiert da der Pitiny den Anschluss??

Vielen Dank.

Gruß kami

[Norbert S. (junky-zs)]

Hallo Stefan S.,
>... nun möchte ich ein 2,2 TFT LCD über SPI und I2C anschliessen.
Der I2C Bus wird nicht genutzt und der SPI-Bus 'nur' für einen 
Software-Update des ht_pitiny bzw. des ht_piduino.

Allerdings würden die SPI-Signale für das TFT (insbesondere Clk, MOSI) 
den ht_pitiny- / ht_piduino-Adapter beeinflussen.
Insbesondere beim ht_pitiny Adapter liegt das Signal SPI:CLK und das 
Bus-Signal HT-RX (Heizungsbusdaten) am gleichen CPU-Pin.
Es würden keine gültigen Heizungsbusdaten mehr erkannt werden, da der 
SPI-Clock zum TFT diese dann überschreibt.

Helfen kann da nur das Trennen der SPI-SCK und SPI-MOSI Leiterbahn zum 
Adapter-Sockel. Allerdings ist dann auch nicht mehr das Software-Update 
des Bus-Adapters durch den RaspberryPi möglich.

Besser ist also ein Display mit einem DSI- oder HDMI-Interface. 
Allerdings dann wohl auch teurer.

Andere Möglichkeit ist zwei RPi's zu verwenden:
- RPi(2) mit dem ht_pitiny-Adapter bestücken (ein RPi Typ B reicht 
völlig).
- die Heizungs-Daten mit dem ht_proxy.server auf dem RPi(2) an den 
RPi(1) (mit dem TFT-Display) senden.

Gruß Norbert

[Stefan S. (kami)]

Hallo,

vielen Dank für die Info. Aber inzwischen habe ich selber eine bessere 
Lösung gefunden. der RPi hat einen 2ten SPI und den kann auch mit jedem 
Display nutzen. Aus diesem Grund darüber erledigt.

Danke.

Gruß kami

[Stefan S. (kami)]

Hallo zusammen,

habe einen Raspberry Pi 3 B+ mit dem Pitiny draufgesteckt. Habe die 
Software geupdatet und auch an der Platine gebastelt. Kann ich irgendwie 
sehen, ob auf dem Bus Daten ankommen? Die Hardwareverbindung ist 
aufgebaut aber in die SQLlite Datenbank werden keine Daten geschrieben. 
Wie kann ich mich an das Problem rantesten? Funktion der LEDs?? Danke

Gruß kami

[Norbert S. (junky-zs)]

Hallo Stefan S.,

Hardware-Kontrolle:
H1. zur Prüfung der Hardwarware sollte man mit der elektrischen 
Kontrolle beginnen (kein Kurzschluss am HT-Busanschluss etc.) und dann 
nach Anschluss an den Heizungsbus die LED's kontrollieren.
Eigenschaften der grünen und roten LED-Anzeigen siehe Bild.

H2. Falls man mehr als einen aktiven ht-Adapter (ht_pitiny oder 
ht_piduino) am Heizungsbus hat, muss einer davon eine andere 
Geräte-Adresse erhalten.
Default ist (13)dez. eingestellt. Diese muss dann bei einem Adapter 
auf (10)dez. eingestellt werden. Wie dies geht ist in der Doku 
beschrieben.
Wird dies nicht beachtet so kann es Telegramm-Kollisionen auf dem 
Heizungsbus geben und der Heizungsbetrieb kann beeinträchtigt werden.
Es sind maximal zwei ht-Adapter am gleichen Heizungsbus erlaubt (wenn 
kein MBLan2 vorhanden ist).

Software-Kontrolle:
S1. Letztes Software-Release von github installieren/updaten.
Ältere rrdtool-Datenbanken (erstellt mit Release 0.1x) müssen auf 
Release (0.3) aktualisiert oder besser noch neu erzeugt werden.

S2. Wenn die LED's auf dem Adapter korrekte Funktion zeigen, kann der 
Datenempfang kontrolliert werden. Dabei wird in diesem Beispiel der 
aktive ht_proxy.server vorausgesetzt.
Aktion:
  Mit einem Browser die Heizungsdaten anzeigen lassen:
    http://<IP-Adresse des RPi>:8088/
Es werden die Heizungs RAW-Daten angezeigt. Bei einem ht_pitiny- oder 
ht_piduino-Adapter wird zusätzlich der Header mit ausgegeben (#HR...) 
siehe Bild.

S3. Kontrolle ob perl-scripte im /tmp-Ordner längere Zeit liegen 
bleiben. Dies deutet dann auf eine Fehlfunktion beim Daten-Eintrag in 
die rrdtool-Datenbank hin. Zum Test kann so ein perl-script von Hand 
aufgerufen werden.
Dabei auf zeitliche Reihenfolge achten, älteste Scripte zuerst und nur 
einmal aufrufen. Falls dann Fehler angezeigt werden sind diese 
auszuwerten.

Gruß Norbert

[Stefan S. (kami)]

Hi Norbert,

alles gut inzwischen. Lag an einer losen Verbindung.

Jetzt rennt alles wieder.

Danke.

Gruß Stefan

[Erhard P. (erhard_p)]

Hallo Norbert,

Dir und den anderen Mitwirkenden und Diskutanten hier im Forum zum Thema 
"Heatronic 3 Adapter" zuallererst ein ganz großes Dankeschön für die 
tolle Ausarbeitung und die ausführlichen Beschreibungen und Anregungen 
zu Hard- und Software!

Unsere Junkersheizung ist zwar schon seit ca. 5 Jahren in Betrieb, 
allerdings wurde der Solaranteil zur Unterstützung der 
Brauchwassererzeugung erst vor ziemlich genau einem Jahr hinzugefügt. 
Schon bald nach der Erstinstallation hatte ich immer wieder den Wunsch, 
die ganzen Verläufe mitzuschreiben ("ein Bild sagt mehr als tausend 
Worte bzw. als ein Zahlenfriedhof"). Nach Ergänzung des Solaranteils 
hab' ich die Recherche wieder aufgenommen und intensiviert und bin 
letztendlich hier gelandet.

Die komplette Anlage besteht aus Gas-Brennwertgerät ZBR 28-3 mit 
Heatronic 3 und eingebautem FW200-Regler, einem Heizkreis mit Mischer am 
IPM1, einem Pufferspeicher zur Heizwasserversorgung der 
Frischwasserstation LSS-TF 40 mit integriertem Frischwasserregler sowie 
dem Solarteil mit ISM1.

Für die Aufzeichnungen kommt der HT3-MicroAdapter zum Einsatz an einem 
betagten Laptop, die Anpassung der Software bzgl. Schnittstelle hat im 
zweiten Anlauf auch geklappt. Soviel zur langatmigen Einleitung.

Leider ist der Frischwasserregler autark und nicht mit dem HT3-Bus 
angebunden. Dafür hat er einen Datenlogger, der auf eine SD-Karte 
schreibt, die man dann mit dem TS_Analyser_1 der Fa. Steca (die 
offensichtlich auch der Entwickler/Hersteller des Junkers-Gerätes ist) 
auswerten kann. Ausserdem hat der Regler noch eine RS232 und eine RS485 
Schnittstelle (Zweck?).

Der langen Rede kurzer Sinn: Ist es denkbar, dass die Daten des 
Frischwasserreglers in ein zusätzliches Diagramm der 
Heizungs-Datenerfassung (HT3) mit aufgenommen werden, z.B. mittels eines 
zweiten Adapters?

Es wäre schön, wenn diese Idee von Dir oder einem der Cracks hier im 
Forum wohlwollend kommentiert würde. Schon mal vielen Dank.

Gruß, Erhard

[Norbert S. (junky-zs)]

Hallo Erhard,

sicher können die Daten mit übernommen werden.
Mein Vorschlag wäre die Daten in dem ohnehin vorhandenen 
Warmwasser-Diagramm der rrdtools-db zu schreiben und darzustellen.
Das Problemchen ist jedoch weniger die Darstellung sondern die Erfassung 
und Dekodierung der Schnittstellen-Daten.
Diese Daten von der SD-Karte auszulesen ist nicht sehr handlich (Karte 
raus/rein).
Von der RS232 Schnittstelle zu lesen sollte möglich sein mit einem 
entsprechenden Adapter (siehe URL und Bild)

https://www4.lernplattform.schule.at/gwk/pluginfile.php/18358/mod_folder/content/0/Thema6_Landschaftslabor/Energieversorgung/EN-instruction_manual-PA_CAB_2_Tarcom_data_cable_5000500063.pdf?forcedownload=1

Aber Achtung: die Steca RS232 Schnittstelle hat wohl 'nur' 3.3 Volt und 
daher auf keinen Fall direkt mit einem Seriellen Port eines PC's 
verbinden.
Hinzu kommt leider das die RS232 nicht galvanisch getrennt ist.

Das Protokoll jedoch ist mir nicht bekannt und hat wohl gar nichts mit 
Heatronic3 zu tun.
Steca hat wohl auch wenig mit Junkers/Buderus (Bosch) zu tun und das 
Protokoll wird wohl auch Steca-Eigenbau sein. Jedenfalls habe ich da 
nichts gefunden.
Daher must Du dann wohl selber mal die Daten erfassen und dekodieren. 
Wenn man dann Substanz hat ist der Rest nur noch ein wenig 
Zusatzsoftware, die dann die Daten in die rrdtool-Datenbank (Warmwasser) 
schreibt.

Noch ein paar Fragen zu Deiner Anlage:
1. Der FW200 kann zwei Kreise bedienen, es ist jedoch wohl nur ein 
gemischter Heizkreis angeschlossen?
2.Wie ist denn der Pufferspeicher mit dem Heizgerät verbunden?
Über Warmwasser klar, aber hat der irgenwelche Temperatursensoren?

Gruß Norbert

[Erhard P. (erhard_p)]

Hallo Norbert,

vielen Dank für Deine Stellungnahme und Deine Gedanken zu meiner Anfrage 
bzgl. der Erfassung und Darstellung der Daten der Frischwasserstation.

Gleich vorweg muss ich mich "outen" als absoluter Noob, was Software im 
Allgemeinen und programmieren im Besonderen betrifft (so als gelernter 
Maschinenbauer), dagegen elektronische Schaltungen zusammenlöten, geht 
so leidlich, wenn nicht zu "smd"-lastig.

Jetzt zu Deinen Punkten:

> Mein Vorschlag wäre die Daten in dem ohnehin vorhandenen
> Warmwasser-Diagramm der rrdtools-db zu schreiben und darzustellen.
So etwa hab' ich mir das auch vorgestellt.

> Diese Daten von der SD-Karte auszulesen ist nicht sehr handlich (Karte
> raus/rein).
So hab' ich das in der Not zwei-/dreimal gemacht, dazu muss aber die 
Wärmedämm-Schutzhaube abgenommen und die Datenloggerfunktion deaktiviert 
werden (korrekterweise, ähnlich USB-Stick auswerfen) , bevor die 
SD-Karte entnommen werden kann. Die Datenkorrelation zw. FriWaSt und 
Hzg. ist da natürlich nicht gegeben, deswegen ja mein Ansinnen mit 
zweitem Adapter und parallelem Mitschreiben. Die Dateien werden im 
.CSV-Format Tages-/Monats-/Jahresweise gespeichert, was ich als Anhang 
beifügen könnte (oder fliegt da mein Beitrag raus?).

> Von der RS232 Schnittstelle zu lesen sollte möglich sein mit einem
> entsprechenden Adapter (danke für Deinen Vorschlag).
Geht als Adapter auch die Schaltung mit dem CP2102-Chip (neu: CP2102N), 
wie z.B. im HT3-MicroAdapter verwendet? So einen hätte ich noch.

> Daher musst Du dann wohl selber mal die Daten erfassen und dekodieren.
Das hab' ich ja bereits gemacht und die Kurven mit dem TS_Analyser_1/2 
von Steca angezeigt bekommen, aber halt ohne Zusammenhang.

> 1. Der FW200 kann zwei Kreise bedienen, es ist jedoch wohl nur ein
> gemischter Heizkreis angeschlossen?
--> nur ein gemischter Heizkreis.

> 2.Wie ist denn der Pufferspeicher mit dem Heizgerät verbunden?
> Über Warmwasser klar, aber hat der irgendwelche Temperatursensoren?
--> ein Temperatursensor, bezeichnet mit Speicherfühler-oben.
Der Pufferspeicher wird heizungs-technisch wie ein Brauchwasserspeicher 
behandelt.

Gruß Erhard

[Norbert S. (junky-zs)]

Hallo Erhard,

> Geht als Adapter auch die Schaltung mit dem CP2102-Chip (neu: CP2102N),
Ja, der ist ein 3.3Volt Typ.

> Die Dateien werden im .CSV-Format Tages-/Monats-/Jahresweise gespeichert, was
> ich als Anhang beifügen könnte...
Dies Daten werden ja schon vom TS_Analyser_1/2 dekodiert und angezeigt. 
Da sehe ich keinen Bedarf.
Die Baustellen sind auf der RS232 Schnittstellte zu finden weil dort 
sicher eine etwas andere Reihenfolge / Struktur als auf der SD-Karte 
(*.csv) vorhanden ist.
Auch kann es passieren, dass diese Schnittstelle von sich aus gar nichts 
ausgibt und man als Startsequenz ein 'Zauberwort' auf die Schnittstelle 
geben muss damit eine Antwort ueberhaupt kommt (Viessmann macht dies 
z.B. so).
Ich hoffe nicht das dies so ist und das die Daten wie bei Heatronic von 
selber sprudeln. Wenn dem jedoch nicht so ist wird es ekelig.
Bedarf sehe ich also bei:
1. RS232 Schnittstelle zum fliegen bringen.
2. Daten der RS232 ZUSAMMEN zeitgleich mit Daten der SD-Karte erfassen.
3. Ergebnisse vergleichen und Strukturen finden.
4. Software dazu erstellen und Daten in rrdtool-db schreiben.

Vielleicht hat ja jemand dies schon für den Frischwasser-Regler von 
Steca erstellt. Falls ja bitte melden.

Gruß Norbert

[Erhard P. (erhard_p)]

Hallo Norbert,

vermutlich ist Dir und den potentiellen Mitlesern hier im Thread bereits 
bekannt, um welchen Frischwasser-Regler es geht, trotzdem der 
Vollständigkeit halber hier ein link auf die Steca-Original-Ausführung 
TF A603 MC:

http://www.steca.fr/images/stories/documents/TH/regulateurs-eau/Manuel-TF-A603MC_EN.pdf

Den link hab ich nur über Umwege ergoogelt, auf der Steca-homepage ist 
die Druckschrift auch im Archiv (--> Solarthermie --> Produktarchiv) 
nicht (mehr) zu finden. Das Junkers - Pendant hat die 
Druckschrift-Sachnummer: 6 720 644 711. Die Seite der Junkers / Bosch 
"Technische Dokumentation" mit dem link:

https://www.junkers.com/fachkunde/unterlagen_fachkunde/technische_unterlagen_fachkunde/technische_unterlagen

geht gerade nicht.

Auf der Seite 14 der Druckschriften ist die Schnittstelle hardware-mäßig 
beschrieben.

Eine weitere Gerätebeschreibung findet sich unter diesem link:

http://westech-solar.com/download/steca/st603_mc.pdf

Dort wird unter Schnittstellen ein "Steca TPC 1-Bus" (?) erwähnt.

Vielleicht helfen diese Hinweise irgendwie weiter.

Gruß Erhard

[Max R. (Gast)]

Braucht noch jemand einen ht_pitiny Adapter? Ich habe einen übrig, finde 
keine Zeit ihn zu integrieren. Bitte PN. Gruß

[Hartmut (Gast)]

Hallo zusammen,

ich "durfte" gerade einmal alles von vorne Aufsetzen und bin auf ein 
Problem gestoßen, welches ich nicht ganz erklären kann.

Hardware: Pi 2 Model B V1.1
Raspbian Stretch
HT3-mini Adapter

ASYNC Interface auf /dev/ttyAMA0

Ich erhalte beim start des collgate folgende Fehler:

03.08.2018 23:47:22 CRITICAL: cht_if_worker();Error;couldn't open 
requested device:/dev/ttyAMA0
03.08.2018 23:47:22 CRITICAL: ccollgate().run();Error;could not start 
'ht-interface' with file:'./etc/config/HT3_db_cfg.xml'
03.08.2018 23:47:22 CRITICAL: ccollgate().run();Error; terminated

Auch ein Test mit HT3_Analyser schlug fehl.

Irgendwie bin ich darauf gekommen einmal den Proxy mit dem collgate zu 
vergleichen und auf eine Abweichung gestoßen:

in ht_proxy_if.py ist folgende zeile auskommentiert:
#disabeld, no timeout  self.__port.setInterCharTimeout(0.1) #VTIME; set 
to 0.1*1sec

Kommentiere ich diese Zeile auch im ht3_worker.py aus, so funktioniert 
der HT3_Analyser einwandfrei.

Warum ist die Zeile im ht3_worker noch einkommentiert? Absicht, Feature 
oder Bug?

Danke für Eure Hilfe und Gruß
Hartmut

[Norbert S. (junky-zs)]

Hallo Hartmut,

ja, dieses timeout kann im ht3_worker.py deaktiviert werden.

Allerdings benutzt (per Default) der ht_collgate gar nicht das serielle 
Interface /dev/ttyAMA0 sondern holt sich die Daten vom ht_proxy über das 
SOCKET-IF.
Und nur der ht_proxy.server bemuckelt die serielle Schnittstelle.
Mehrere Instanzen auf einer seriellen Schnittstelle geht nun mal nicht.

Daher der Proxy, der dann die Heizungs-Daten per Socket an N-Clients 
sendet.
Wie gesagt, dies ist die Default-Einstellung in den 
Konfigurations-Files.
Dies ist auch unabhängig davon ob alle Prozesse nur auf einem PI oder 
verteilt auf mehreren laufen.
Einzig die Baudradte muss je nach Adapter-Typ im proxy-Konfigfile 
angepasst werden, ansonsten ist dies auch unabhängig vom Adapter-Typ.

Offensichtlich benutzt Du nicht den ht_proxy.server sondern je nach 
Bedarf den HT3_Analyser ODER ht_collgate. Beides gleichzeitig geht dann 
natürlich nicht, da Du ja das Konfigurations-File 'HT3_db_cfg.xml' wohl 
von SOCKET auf ASYNC umgestellt hast.
Dies hat natürlich die oben geschilderten Nachteile.

Gruß Norbert

[Hartmut (Gast)]

Hallo Norbert,

Danke für deine schnelle Antwort.

Ich nutze schon seit einigen Jahren die erfassung der Heizungsdaten, bin 
aber jetzt auf einen aktuelleren Pi umgestiegen und habe daher mein 2015 
zuletzt aktualisiertes System neu aufgebaut.

Da ich ausschließlich eine Website, welche lokal gehosted wird, als 
Frontend für die Ergebnisse nutze, habe ich darauf verzichtet den Proxy 
einzusetzen.
Den Analyser habe ich nur verwendet, um zu überprüfen, ob die Daten 
korrekt gelesen werden. Sonst setze ich keine weiteren Schnittstellen 
ein.

Wenn ich dich richtig verstehe ist die Zukunft des Projekts aber eher 
der Proxy und due würdest mir eher empfehlen auch für meinen 
Anwendungszweck auf diesen umzusteigen. Richtig?

Auf jeden Fall einmal Danke für dieses Projekt!

Gruß
Hartmut

[Norbert S. (junky-zs)]

Hallo Hartmut,

da Du ja 'nur' Heizungsdaten erfassen willst, kannst Du auch auf den 
proxy.server verzichten.
Allerdings hast Du dann den Nachteil, das bei jedem Aufruf eines anderen 
Tools z.B. HT3_Analyser etc. das gerade laufende Programm stoppen musst 
weil es ja exklusive auf den seriellen Port zugreift.
Genau dies vermeidet der proxy.server und er sendet die Heizungsdaten 
vom seriellen Port an N verbundene Clients.
Dies ist die default-Einstellung in den Konfigurationsfiles.

Wenn man die Heizung steuern will (mit ht_pitiny oder 
ht_piduino-Adapter) dann muss man den proxy.server verwenden, da dieser 
die Steuer-Kommandos für die Adapter aufbereitet und an den seriellen 
Port sendet.

Gruß Norbert

[Hartmut (Gast)]

Hallo zusammen,

das System läuft jetzt nach der Umstellung auf den Proxy schon eine 
ganze Zeit fehlerfrei, bis folgendes aufgefallen ist:

Es liegt neben der eigentlichem SQLite-Datenbank (aktuell über 200MB 
groß) noch ein 110MB großes sqlite-journal File.

Im Log sehe ich regelmäßig die Bereinigung alter Datensätze (Zeit für 
die Bereinigung ist auf 30 Tage gesetzt) aber die Datenbank wächst 
trotzdem.

Ich vermute die SQLite Datenbank hat sich irgendwann an einer 
Transaktion verschluckt und danach alle Löschoperationen 
zwischengespeichert, während die DB weiter wuchs.

Hat das jemand von Euch auch schon einmal erlebt?
Gibt es bekannte Gründe dafür?

Danke für eure Infos.

Gruß
Hartmut

[Markus B. (spektrum)]

Hallo Norbert,

mein System hat nun zwei Jahre erfolgreich funktioniert:
 - Raspberry #1 mit ht_proxy und ht_piduino
 - Raspberry #2 mit FHEM und HEATRONIC
 - FW100

Wegen eines korrupten Filesystems musste ich meinen Raspberry #1 mit 
ht_piduino und ht_proxy im Sommer neu aufsetzen. Die Raspian Version hat 
sich auf stretch geändert. Weitere Änderungen habe ich nicht 
vorgenommen.

Nach der Neuinstallation von Raspberry #1 kann ich nun den hc1_mode 
nicht mehr umschalten. Weder über ht_netclient, noch über HEATRONIC.
Laut Log werden Daten zwar gelesen und geschrieben. Die HEATRONIC zeigt 
auch weiterhin fortlaufend die aktuellen Readings, wie Temperatur, 
Brenner, ... von der Heizung. Die Verbindung funktioniert, nur Schreiben 
kann ich nicht (mehr).

Was kann ich noch prüfen?

Hier das ht_proxy.log

25.09.2018 20:28:30 INFO: ----------------------
25.09.2018 20:28:30 INFO: cht_proxy_daemon init
25.09.2018 20:28:30 INFO: cht_proxy_daemon(); common serveraddress used
25.09.2018 20:28:30 INFO: cht_proxy_daemon start as 
proxy-server:'';port:'8088'
25.09.2018 20:28:30 INFO: logfile:'./var/log/ht_proxy.log'
25.09.2018 20:28:30 INFO: cportwrite();thread start; devicetype:MODEM
25.09.2018 20:28:30 INFO: cportread() ;thread start; devicetype:MODEM
25.09.2018 20:28:36 INFO: Client-ID:1; ('192.168.6.34', 54188) connected
25.09.2018 20:28:36 INFO: Server   :('0.0.0.0', 8088)
25.09.2018 20:28:36 INFO: Client-ID:1; register(); got devicetype:MODEM
25.09.2018 20:28:36 INFO: csocketsendThread(); socket.send thread start
25.09.2018 20:28:36 INFO: Client-ID:1; added; number of clients:1
25.09.2018 20:28:36 INFO: Client-ID:1; cht_RequestHandler(); 
socket.receive thread start
25.09.2018 20:28:36 DEBUG: Client-ID:1; 
recv:b'#\t!S\x11\x10\xff\x0e\x00e\x01'
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:23
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:21
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:53
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:11
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:06
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:10
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:ff
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:0e
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:00
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:65
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:01
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:3f
25.09.2018 20:28:39 DEBUG: Client-ID:1; 
recv:b'#\t!S\x11\x18\xff\x0e\x00e\x01'
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:23
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:21
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:53
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:11
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:06
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:18
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:ff
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:0e
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:00
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:65
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:01
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:26
25.09.2018 20:28:42 DEBUG: Client-ID:1; 
recv:b'#\t!S\x11\x10\xff\x04\x00y\x01'
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:23
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:21
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:53
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:11
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:06
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:10
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:ff
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:04
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:00
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:79
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:01
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:57
25.09.2018 20:28:45 DEBUG: Client-ID:1; 
recv:b'#\t!S\x11\x18\xff\x04\x00y\x01'
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:23
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:21
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:53
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:11
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:06
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:18
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:ff
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:04
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:00
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:79
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:01
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:4e
25.09.2018 20:28:48 INFO: Client-ID:1; ('192.168.6.34', 54188) 
disconnected
25.09.2018 20:28:48 INFO: Client-ID:1; removed; number of clients:0
25.09.2018 20:28:48 INFO: Client-ID:1;cportwrite();couldn't read from 
queue

[Norbert S. (junky-zs)]

Hallo,

@ Markus B.
Die Bytes in den Debug-Ausgaben des ht_proxy sind korrekt.
Somit wird wohl kein Software- sondern ein Hardware-Fehler/Problem 
vorhanden sein. Sicher setzt Du das letztgültige Software-Release ein.

Daher kontrolliere mal die grüne und rote LED. Beide müssen kurz 
aufblitzen, insbesondere die Rote zeigt einen Sendevorgang an.
Dies immer und auch dann wenn keine Kommandos zur Heizung gesendet 
werden.
Hat sich da etwas in Deiner Hardware-Umgebung geändert, längeres Kabel 
zur Heizung etc?

@ Hartmut (Gast)
Das sqlite-Journal ist ja nur temporär und sollte daher nicht so gross 
werden wie bei Dir. Daher kontrolliere noch einmal die 
User-Berechtigungen zur Datenbank und eventuell vorhandene 
Fehlermeldungen.
Du schreibst auch 'das System läuft fehlerfrei...' somit nehme ich an 
das Du die Daten aus der sqlite-Datenbank nicht benötigst sondern 'nur' 
die Grafiken der rrdtool-Datenbank auswertest.
Somit könntest Du auch im Konfiguration-File die sqlite-Datebank 
deaktieren.

Gruß Norbert

[Markus B. (spektrum)]

Hallo Norbert,

nachdem die bisherige Fehlersuche nicht erfolgreich war, habe ich den 
atmega Chip ausgetauscht. Jetzt funktioniert es wieder. Was jedoch nicht 
heissen soll, dass es zwingend am Chip lag.

Danke und Grüße.
Markus

[Norbert S. (junky-zs)]

Hallo Markus,

ich glaube auch nicht das der Atmega Chip defekt ist. Versuche mal den 
alten Chip erneut mit den Programm- und EEPROM-Daten zu füttern.
Er wird wahrscheinlich wieder laufen.

Wenn dem so ist, dann kontrolliere mal die Fuses-Einstellungen. Diese 
sollten so eingestellt sein, das ein Beschreiben von Flash-/EEPROM bei 
Unterspannung vermieden wird.
Kann also durchaus sein das sich die EEPROM-Daten beim Ausschalten des 
RPi verändert hatten und beim erneuten Einschalten die Checksumme nicht 
mehr stimmt.
In diesem Fall läuft der ht_piduino/ht_pitiny-Adapter 'nur' im 
Empfangsmode.
Empfehlung:
Fuses checken. Details stehen in der Doku unter:
 https://github.com/norberts1/hometop_ht_transceiver/docu/fuses.ods

Gruß Norbert

[Markus B. (spektrum)]

Hallo Norbert,

den alten Chip gibt es nun nicht mehr. Er hat bei der Operation seine 28 
Beinchen eingebüßt :-)

Vor dem Austausch hatte ich bereits versucht, den Chip neu zu betanken. 
Es gab beim Schreiben der extended Fuse jedoch eine Fehlermeldung: FF 
<-> 0F (Lesefehler) und es hat danach auch immer noch nicht 
funktioniert.

Daher der Gedanke den Chip zu tauschen.
Es funktioniert mit dem neuen Chip jetzt.
Den Fuse-Fehler gibt es aber auch beim neuen Chip.

Viele Grüße
Markus

[Stefan S. (kami)]

Moin zusammen,

kann man einen Junkers FR 50 Raumregler zusammen am Bus mit dem HT3 und 
einem RPi verwenden?

Vielen Dank.

Gruß kami

[Norbert S. (junky-zs)]

Hallo Stefan S.

der Regler FR50 erlaubt leider nicht die Steuerung der Heizung durch 
MBLan2 oder ht_pitiny/ht_piduino.
Das hat Junkers in diesen Regler-Typ nicht eingebaut.

Allerdings kann man trotzdem die Heizungsdaten mit den hier 
vorgestellten Adaptern und dem RPi dekodieren und sich anzeigen lassen.

Gruß Norbert

[Stefan S. (kami)]

Okay vielen Dank aber ich dachte man kann die Heizung eh nicht ansteuern 
nur auslesen??

Gruß kami

P.s. Ich habe in meiner Heizung einen fr 120 verbaut an den ich den fr 
50 und den ht3 hängen will.

[Norbert S. (junky-zs)]

Hallo Stefan S.,

die Junkers-Heizungen können auch mit den aktiven Adaptern: ht_pitiny 
bzw. ht_piduino gesteuert werden, der Empfang geht mit allen 
Adapter-Typen.

Allerdings sind ein paar Dinge erforderlich.
1. Heatronic3/Heatronic4i oder EMS2 - Bus
2. Fxyz- oder Cxyz-Regler
Das Fertigungs-Datum der Fxyz Regler ist wichtig, siehe:
  Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"
3. FR50 Regler lässt sich nicht steuern

Die Steuerbarkeit der einzelnen Parameter hängt von den Reglern ab. Die 
Basisfunktionen: 'Temperatur', 'Heizungsmode' beherrschen alle.

Ich selber habe verschieden Regler am Heatronic3 - Bus verwendet bzw. 
getestet (auch Steuerfunktion)
FW100 mit FB10 / FB100
CW100
CW400 mit/ohne CR10
Den FR120 habe ich nicht, jedoch Foren-Teilnehmer haben damit schon 
Erfolg gehabt.
Zur Kombination: FR120 mit FR50 kann ich nichts sagen. Mir kommt diese 
Kombination auch eigenartig vor, es sei denn man hat zwei separate 
Heizkreise bei denen beide Raumtemperatur geführt sind.
Gruß Norbert

[Stefan S. (kami)]

Hi Norbert,

vielen Dank jetzt sehe ich es auch. Mir ist wichtig über den Regler FR 
50 mit etwas Hardwaremodifikation die Warmwassersofortfunktion 
auszulösen. Das geht ja sonst nicht, wenn ich das richtig sehe. Dafür 
will ich den Button per µC schaltbar machen.

Sehe ich das so richtig? Der HT3-Adapter soll parallel einfach nur zum 
Loggen der Daten von der Heizungsanlage am Bus hängen bleiben.

Vielen Dank.

Gruß kami

[Norbert S. (junky-zs)]

Hallo Stefan S.,

> Mir ist wichtig über den Regler FR 50 mit etwas Hardwaremodifikation
> die Warmwassersofortfunktion auszulösen.
Dein Regler FR120 hat ja eine eigene Taste dafür.
Wozu also noch separat eine Hardware-Modifikation?

Gruß Norbert

[Henrik (Gast)]

Hallo,

ich versuche gerade meinen ht_pinity in betrieb zu nehmen (Danke 
nochmals Norbert). Ich bekomme allerdings wenn ich die DBs erstellen 
möchte folgende Fehler:
pi@raspi_htpinity:~/HT3/sw $ cd
pi@raspi_htpinity:~ $ cd ./HT3/sw
pi@raspi_htpinity:~/HT3/sw $ ./create_databases.py
------------------------------------------------
Create: sqlite -database
sqlite-database:'./var/databases/HT3_db.sqlite' created and access 
possible
------------------------------------------------
Create: rrdtool-database (if request is enabled)
cdb_rrdtool.createdb_rrdtool();INFO;Database:'./var/databases/HT3_db_rrd 
'  will be created
rrdtool create /home/pi/HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd 
--start 1343999400 --step 60 DS:T_vorlauf_soll:GAUGE:120:U:U 
DS:T_vorlauf_ist:GAUGE:120:U:U DS:T_ruecklauf:GAUGE:120:U:U 
DS:T_mischer:GAUGE:120:U:U DS:V_modus:GAUGE:120:U:U 
DS:V_brenner_motor:GAUGE:120:U:U DS:V_brenner_flamme:GAUGE:120:U:U 
DS:V_leistung:GAUGE:120:U:U DS:V_heizungs_pumpe:GAUGE:120:U:U 
DS:V_zirkula_pumpe:GAUGE:120:U:U DS:V_speicher_pumpe:GAUGE:120:U:U 
DS:T_aussen:GAUGE:120:U:U DS:C_betrieb_gesamt:GAUGE:120:U:U 
DS:C_betrieb_heizung:GAUGE:120:U:U DS:C_brenner_gesamt:GAUGE:120:U:U 
DS:C_brenner_heizung:GAUGE:120:U:U DS:V_displaycode:GAUGE:120:U:U 
DS:V_causecode:GAUGE:120:U:U DS:V_spare_1:GAUGE:120:U:U 
DS:V_spare_2:GAUGE:120:U:U RRA:LAST:0.5:5:1051200 
RRA:AVERAGE:0.5:1:525600 RRA:MAX:0.5:5:105120 RRA:MIN:0.5:5:105120 
failed: cannot allocate memory at /usr/share/perl5/RRDTool/OO.pm line 
444
db_rrdtool.createdb_rrdtool();Error;<db_rrdtool.createdb_rrdtool();Error 
;rrdtool-database:'./var/databases/HT3_db_rrd'  not created>
rrdtool-databases:'./var/databases/HT3_db_rrd' not available

Wo liegt mein Problem?

Gruß

Henrik

[Nils R. (augur)]

Hi.

Sieht für mich so aus als hättest du nicht genug Platz auf der SD Karte 
oder wo das Programm die Daten ablegt. Du brauchst dafür 1GB glaube ich. 
Schau mal mit DF nach.

Vg Nils

[Henrik (Gast)]

Ist eigentlich ne 16Gb Karte....

pi@raspi_htpinity:~/HT3/sw $ df
Dateisystem    1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/root       15242096 4655676   9938332   32% /
devtmpfs           87792       0     87792    0% /dev
tmpfs              92112       0     92112    0% /dev/shm
tmpfs              92112    3776     88336    5% /run
tmpfs               5120       4      5116    1% /run/lock
tmpfs              92112       0     92112    0% /sys/fs/cgroup
/dev/mmcblk0p1     41853   22540     19313   54% /boot
tmpfs              18420       0     18420    0% /run/user/1000

[Henrik (Gast)]

Kann es sein, dass mein Raspi nicht genügend RAM frei hat? Habe die 
Version 1 mit 256Mb?

pi@raspi_htpinity:~/HT3/sw $ free -m -t
              total        used        free      shared  buff/cache 
available
Mem:            227          81          42           9         102 
89
Swap:            99           0          99
Total:          327          81         142
pi@raspi_htpinity:~/HT3/sw $

[Norbert S. (junky-zs)]

Hallo Henrik,

kann durchaus sein das diese 256Mb zumindest für die Erzeugung der 
Datenbanken zu klein ist.
Testehalber kannst Du ja die Grösse der rrdtool-DB Files reduzieren.
Dazu im File: /HT3/sw/lib/rd_rrdtool.py und Zeile: 428 den Wert von 
1051200 auf 105120 reduzieren.
Die rrdtool-DB Files werden dann kleiner.
Die Datenhaltung ist dann halt keine 10 Jahre mehr, aber bis dahin hast 
Du sicher einen neueren RasPi:
 self.__rrdtoolh.write('        archive     => { \n')
 self.__rrdtoolh.write('            rows     => 105120,\n')
 self.__rrdtoolh.write('            cpoints  => 5,\n')
 self.__rrdtoolh.write("            cfunc    => 'LAST',\n")
 self.__rrdtoolh.write('        },\n')
Wenn Du die sqlite-DB nicht brauchts, dann im Konfigurationsfile 
deaktiviert lassen.
Nach der Änderung alte DB-Fragmente loeschen und dann noch mal die 
Datenbanken mit createdatabases erzeugen.
Gruß Norbert

[Henrik (Gast)]

Moin Norbert,

danke für deine Hilfe! Allerdings habe ich es gestern Abend noch 
geschaft, in dem ich eine SWAP angelegt habe. Danach liesen sich die DBs 
erzeugen. Läuft jetzt auch soweit alles, bis auf das ich keine Daten der 
Heizkreise bekomme?

Mein System:
Junker Cerapur ZSB 14-4C (CW400 integriert)
2 gemiste Heizkreise an MM200

[Norbert S. (junky-zs)]

Hallo Henrik,
prima das es jetzt läuft. Daten werden auch in die Grafiken geschrieben.

Allerdings sind tatsächlich zu wenig Daten in den Heizkreis-Diagrammen.
Dies liegt hauptsächlich noch an den neuen Telegrammen der MM200 die 
noch zu dekodieren und mit in die Grafik auszugeben sind.
Ich selber habe zwar eine CW400 jedoch keine MM200.
Deshalb wäre ist gut wenn Du ein binäres Logfile Deiner Anlage über ca. 
1-2 Std. erstellen kannst. Eventuell mit markanten Punkten wo etwas am 
Mischer passiert.
Wie das geht ist beschrieben unter:
Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"
Das Binärfile kannst Du ja hier posten. Dann kann ich die Daten 
analysieren und die Software anpassen.
Gruß Norbert

[Henrik (Gast)]

Hallo Norbert,

anbei mein Logfile. Nochmal zu meinem Setup:

Junker Cerapur ZSB 14-4C (CW400 integriert)
2 gemischte Heizkreise an MM200
1x Temperaturfühler an hydraulischer Weiche an MM200 angeschlossen.

Im Zeitraum des Logs wurden die Msicher kontinuierlich angesteuert, 
mindestens eine Warmwasserbereitung ist inkludiert. Es kann sein, dass 
der Brenner nicht all zu oft gelaufen ist, da meine bessere Hälften den 
Kamin an hat und somit eine Rücklaufanhebung über den Pufferspeicher 
stattgefunden hat.

Hoffe meine Daten helfen.
Gruß
Henrik

[Norbert S. (junky-zs)]

Hallo Henrik,

>Hoffe meine Daten helfen.
Ja sehr!

Habe mit Deinem Logfile die Software anpassen können.
Anpassungen sind im Besonderen bei der Dekodierung der Telegramme und 
bei den Anzeigen für die Heizkreise gemacht worden (siehe HK meiner 
Anlage).

Da du wohl der einzige mit 2 gemischten Heizkreisen und dem MM200-Modul 
bist ist es an Dir die obige Test-Software auf Dein System loszulassen.
Die Software ist jedoch für möglichst alle Junkers-Systeme ausgelegt und 
somit auch für andere Systemkonfigurationen geeignet.

Das obige Tar-File ist das komplette Projekt in einer Testversion.
Nach dem Entpacken liegen alle Files unter ./tmp/HT3/....
Kannst ja Deine alte Installation unter ~/HT3 umbenennen und das neue 
(Testversion) an dessen Stelle setzen. Die Datenbankstruktur hat sich 
nicht geändert. Somit kannst Du die alten Dateninhalte weiter nutzen.

Beim rrdtool-draw der Heizkreise sind die Draw's und Legenden 'T-Soll 
(Vorlauf)', 'T-Mischer' und 'HK-Pumpe' hinzugekommen.
Hinweis: 'T-Mischer' wird immer angezeigt auch wenn kein Mischer im 
System vorhanden ist.
Probier es aus und falls Probleme auftauchen oder Verbesserungen 
sinnvoll sind dann hier posten.

Wenn die Software einen Release-Status erreicht hat wird die natürlich 
wieder unter Github veröffentlicht:
URL
https://github.com/norberts1/hometop_HT3

Gruß Norbert

[Henrik (Gast)]

Moin Norbert!
Danke für die Testversion. Habe diese soeben mal versucht zu 
implemnetieren. Hab meine lauffähige Version umbenannt und die neue 
Version umkopiert.
Danach HT3_db_conf & ht_proxy_conf angepasst und meine alten DBs nach 
/var/databases kopiert.
Danach konnte ich mit FHEM weiterhin daten auslesen, allerdings wurden 
keine .pngs erstellt und über MQTT konnten ebenfalls keine Daten 
abgerufen werden. Daraufhin habe ich die Datenbanken noch einmal 
gelöscht und über das Skript neu generiert. Auch hier nach konnten nur 
via FHEM Daten ausgelesen werden. ht_proxy und ht_collgate laufen....
Hast du einen Tipp für mich wo ich noch Suchen könnte?

Gruß
Henrik

[Norbert S. (junky-zs)]

Hallo Henrik,

es müssen insgesamt drei ht_Daemons laufen: ht_proxy.py, ht_collgate.py 
UND httpd.py (siehe Bild).
httpd.py dient dabei als http.server für den anfragenden Browser. Ohne 
den wirst Du keine Anzeige im Browser erhalten. Die *.png Files müssen 
auch in dem Verzeichnis vorhanden sein wo der httpd.py Daemon läuft.
Dies ist aber schon so in der Default-Konfiguration eingestellt.

Ebenso ist die Startreihenfolge wichtig:
 zuerst: ht_proxy.py
 dann  : ht_collgate.py oder/und FHEM
Dies wird nach einem boot/reboot automatisch durch die Start-scripte 
gewährleistet.

MQTT ist per default NICHT aktiviert. Dazu das Konfig-File 
'collgate_cfg.xml' anpassen und MQTT aktivieren. Danach ht_collgate.py 
neu starten.

Hinweis: Ich habe erst einmal nur die rrdtool-draw Schnittstelle mit der 
*.png-File Ausgabe/Anzeige bearbeitet. Die anderen Schnittstellen muss 
ich noch bearbeiten/ergänzen.
Das FHEM Modul ist ja noch nicht geändert und somit werden dort die 
'neuen' Informationen auch nicht angezeigt.

Gruß Norbert

[Henrik H. (henrik_h271)]

Danke Norbert,
jetzt läuft es. Werde jetzt erst einmal ein bisschen Daten sammeln und 
dann noch einmal Rückmeldung geben. Über MQTT müsste ich die neuen Daten 
doch schon auslesen können korrekt?

Gruß

Henrik

EDIT: Müssen die DBs zwingend neu erstellt werden? In den pngs wird 
nicht die aktuelle Mischerposition angezeigt, ist das korrekt?

[Stefan S. (kami)]

Hallo zusammen,

ich habe gesehen, das auf dem HT-Bus immer ein gewisses Telegramm 
gesendet wird, wenn die Warmwassersofortfunktion aktiviert wird. Das 
möchte ich gerne mit einem kleinen Python-Client erkennen und auswerten. 
Ehrlich gesagt komme ich aber noch nicht so richtig mit dem 
Beispielclient zurecht. Gibt es ein Beispiel von jemanden hier, wie ich 
die einzelnen Telegramme richtig darstellen kann:

Mein Skript sieht zur Zeit so aus:

import sys, time
sys.path.append('lib')
import ht_proxy_if

import time

configfile="./etc/config/ht_proxy_cfg.xml"

print("   -- start socket.client --")
client=ht_proxy_if.cht_socket_client(configfile, 
devicetype=ht_proxy_if.DT_MODEM)
str = ""
while 1:
  ch= client.read(1).decode("latin-1")
  #print (ch)
  if ch != "#":
      str = str + ch
  else:
    if "HR" in str:
      print (str)
    str = ""

damit sehe ich zwar einzelne Zeilen aber ich möchte natürlich mehr 
filtern können.

Kann mir jemand dabei helfen?

Vielen Dank.

Gruß kami

[Stefan S. (kami)]

Hi,

habe es inzwischen durch eine Erweiterung der Ccollgate.py ergänzt und 
klappt super.

Trotzdem Danke.

Gruß kami

[Norbert S. (junky-zs)]

Henrik H. schrieb:
> Über MQTT müsste ich die neuen Daten
> doch schon auslesen können korrekt?
Es fehlen noch die <accessname> Namen für die neuen Parameter im 
Konfigurationsfile und den Heizkreisen. Diese kannst Du bei Dir manuell 
für Deine zwei Heizkreise nachtragen in <systempart name="heizkreis1"> 
und <systempart name="heizkreis2">
        <logitem name="V_spare_1">
            <datatype>INT</datatype>
            <datause>GAUGE</datause>
            <maxvalue>100</maxvalue>
            <default>0</default>
            <unit>Grad</unit>
            <displayname>T-Soll (Vorlauf)</displayname>
            <accessname>hc1_Tflow_measured</accessname>
bzw. für HK2:
            <accessname>hc2_Tflow_measured</accessname>

        </logitem>
        <logitem name="V_spare_2">
            <datatype>INT</datatype>
            <datause>GAUGE</datause>
            <maxvalue>100</maxvalue>
            <default>0</default>
            <unit></unit>
            <displayname>Heizkreispumpe</displayname>
            <accessname>hc1_pump</accessname>
bzw. für HK2:
            <accessname>hc2_pump</accessname>
        </logitem>
Nach der Änderung den ht_collgate ntürlich wieder neu starten damit die 
Änderungen übernommen werden.

Henrik H. schrieb:
> Müssen die DBs zwingend neu erstellt werden? In den pngs wird
> nicht die aktuelle Mischerposition angezeigt, ist das korrekt?
Nein und Ja. Müssen nicht neu erstellt werden und Mischerposition wird 
nicht mit im rrdtool-draw angezeigt weil ja dies wohl weniger 
interessant ist und weil keine freien 'V_spare logitems' mehr im 
Konfigfile vorhanden sind.
Kann man zwar eintragen, aber dann muss die Datenbank wieder neu 
erstellt werden.
Gruß Norbert

[Henrik H. (henrik_h271)]

Das mit den fehlenden Namen hätte mir ja auch auffallen können... 
**grummel**
Alles in Allem sehen die Werte gut aus, bis auf diese Auffälligkeiten:

- "V_spare_1" (Sollvorlauf nach Mischer): dieser Wert hat bei mir in 
beiden Heizkreisen einen offset von +5°C (Bsp.: Sollvorlauf am CW400 ist 
27°C ausgelsen werden 32°C). Kann dies irgendwie mit der Erhöhung des VL 
der Therme zusammen hängen? Dieser steht für beide Heizkreise auf 
+5°C...
- Bekommen wir irgendwo den Temperaturwert der hydraulischen Weiche her?

Mischerstellung, Pumpenstatus und Ist-Vorlauftemperatur passen soweit!
Ein riesen Dankeschön schonmal an dich Norbert!

Gruß

Henrik

[Norbert S. (junky-zs)]

Hallo Henrik,

Henrik H. schrieb:
> - Bekommen wir irgendwo den Temperaturwert der hydraulischen Weiche her?
So wie ich den Junkers-Unterlagen zum ZSB14-4 entnehmen kann, hat dieses 
Geräte keine internen Temperatur-Fühler. Alle Fühler sind extern am 
'Wärmetauscher' (T0) und in den Mischermodulen (TC1 & TC2). Die Werte 
werden vom Lastschalt-Modul MM200 erfasst und dem Regler CW400 bzw. 
System übergeben.
So kann ich dies (als Nichtfachmann) dem Anlagenbeispiel (siehe Bild) 
entnehmen.
Einen Temperaturfühler an der Hydraulischen Weiche sehe ich erst mal 
nicht.
Bitte vergleiche mal Deine Anlage mit dem beigefügten Anlagenbeispiel 
(klar, Solaranlage hast Du nicht, aber der Rest wird wohl so in etwa 
stimmen).

> dieser Wert hat bei mir in
> beiden Heizkreisen einen offset von +5°C (Bsp.: Sollvorlauf am CW400 ist
> 27°C ausgelsen werden 32°C)
Dies ist etwas komisch. Nicht der Offset an sich sondern, das die 
ausgelesenen Werte=32°C um 5°C GRÖSSER sind.
Wenn diese Werte von den Temperaturfühlern TC1 & TC2 in den 
Mischermodulen gemessen werden, so sollte der Wert wohl KLEINER sein, da 
die Temperaturfühler HINTER dem Mischer und der Heizkreispumpe eingebaut 
sind. Der Vorlauf-Istwert (T0 direkt am Heizgerät im 
Wärmetauscher/Trennsystem) muss ja wohl eine höhere Temperatur haben als 
die im/hinter dem Mischer.
Der Offset an sich ist ja wohl nötig, damit die Mischer nicht immer auf 
die 100% Position (voll offen) laufen und die Leitungs-Verluste zu den 
Heizkreisen berücksichtig sind.

Gruß Norbert

[Henrik H. (henrik_h271)]

Hallo Norbert,

Norbert S. schrieb:
> Bitte vergleiche mal Deine Anlage mit dem beigefügten Anlagenbeispiel
> (klar, Solaranlage hast Du nicht, aber der Rest wird wohl so in etwa
> stimmen).

Grundsätzlich passt der Aufbau so, allerdings komplett ohne Solar und 
Pufferspeicher für den Kamin, den hat der Heizungsbauer selbst mit einer 
Rücklaufanhebung an die Junkers angebunden. Diese kennt also den 
Pufferspeicher gar nicht, sonder soll über den Temperaturfühler an der 
Weiche mitbekommen, dass Wasser vom Pufferspeicher gespeist wird. Den 
externen Brauchwasserspeicher können wir wohl vernachlässigen ;-)

Norbert S. schrieb:
> Einen Temperaturfühler an der Hydraulischen Weiche sehe ich erst mal
> nicht.

Im Diagnosemenü vom CW400 habe ich die Vorlauftemperatur vom Kessel und 
einmal von der hydraulischen Weiche (siehe Bild). Der Fühler an der 
Weiche ist am MM200 am Anschluss T0 angeschlossen. Somit muss der Kessel 
ja auch einen internen Fühler haben.

Norbert S. schrieb:
> Dies ist etwas komisch. Nicht der Offset an sich sondern, das die
> ausgelesenen Werte=32°C um 5°C GRÖSSER sind.
> Wenn diese Werte von den Temperaturfühlern TC1 & TC2 in den
> Mischermodulen gemessen werden, so sollte der Wert wohl KLEINER sein, da
> die Temperaturfühler HINTER dem Mischer und der Heizkreispumpe eingebaut
> sind.

Da haben wir glaube ich etwas aneinander vorbei gesprochen. Es geht um 
den Vorlauftemperatur-Sollwert der Heizkreise. Dieser ist laut CW400 für 
meinen HK1 auf dem Bild bei 28°C (Fussbodenheizung), laut Screenshot 
wird aber 33°C ausgelesen (Differenz 5°C). Die Temepratur anhebung von 
5°C gilt ja logischerweise für die Vorlauftemperatur vom Kessel und 
nicht für die vom Heizkreis, somit haben die beiden Temperaturen nichts 
miteinander zu tun.

Vielleicht kannst du ja nocheinmal schauen :-)

Ich wünsche dir und deiner Familie ein schönes Fest und bedanke mich 
schon einmal für deinen tollen Support!

Gruß
Henrik

[Norbert S. (junky-zs)]

Hallo Henrik,

ich habe noch einmal die Telegramme kontrolliert und jetzt wohl die 
richtigen Werte für die T-Soll (Vorlauf) der Heizkreise eingebracht.
Der Wert und das Telegramm hängen stark davon ab, ob ein Lastschaltmodul 
(IPM/MM) im System ist oder eben nicht.
Ebenso ist jetzt die gemessene Temperatur der hydraulischen Weiche mit 
in der rrdtool-Grafik enthalten (siehe Bild).
Wenn keine hydraulische Weiche im System ist, so wird dies in der Grafik 
als 'nicht vorhanden' dargestellt. Bei Deinem System sollte da aber der 
richtige Temperatur-Wert dargestellt werden.

Die Testsoftware liegt als komplettes Paket nach dem Auspacken unter 
~/tmp/.
Die vorhandene Datenbank kannst Du weiterhin verwenden, es wird für die 
hyrdaulische Weichen-Temperatur der Logitem-Name: 'V_spare_2' des 
Heizgerätes verwendet.
Die HT3_Analyser.py / HT3_SystemStatus.py zeigen den Display-Wert 
'T-Hydr.Weiche' an, wenn eine Weiche vorhanden ist.

Bitte vergleiche die Werte mit den Anlage-Daten. Die sollten jetzt mit 
den CW400 Anzeigen übereinstimmen.

Hinweis: Der T-Soll (Vorlauf) Name für die Heizkreise im Konfigfile hat 
sich geändert von:
<accessname>hcx_Tflow_measured</accessname>
auf
<accessname>hcx_Tflow_desired</accessname>

Gruß Norbert

[Michael W. (wemi2019)]

Hallo,
ich bin neu im Forum und würde mich freuen, wenn ich von Euch Hilfe 
bekommen würde. Nachdem im letzten Urlaub meine Junkers Gastherme 
ausgefallen ist, und ich es erst Tage später an der Raumtemperatur, die 
ich über HomeMatic Heizkörper-Thermostate überwache, gemerkt habe, habe 
ich mal im Internet gesucht, wie ich meine Heizung überwachen kann. 
Dabei bin ich auf diesen äußerst interessanten Beitrag gestoßen und habe 
gleich beschlossen, den HT3 MiniAdapter nachzubauen und die Heizung mit 
einem Raspberry Pi 3B zu überwachen. Habe gleich alle notwendigen Teile 
bei Conrad bestellt und alles zusammengebaut und lt. sehr guter 
Anleitung durchgemessen und in Betrieb genommen.
Ich muss dazu sagen, dass ich kein Elektroniker bin und mit Linux bisher 
auch fast keine Erfahrungen habe.

Jetzt habe ich folgendes Problem:
- der HT3 MiniAdapter ist direkt an die FW100 angeschlossen. Die grüne 
LED leuchtet bzw. blinkt sehr schnell, eher ein Flackern
- Die Software und Datenbank SQLite ist auf dem Raspberry 3 lt. 
Anleitung installiert. Es scheinen aber keine Daten anzukommen.
- Ich habe mal testweise das Programm HT3_CSW_analyser.py gestartet, 
aber auch dort kommen keine Daten an.

Ich weiß jetzt nicht, ob ich ein Hardware- oder Software-Problem habe. 
Wie kann ich ermitteln, ob von dem MiniAdapter überhaupt Daten kommen?
Kann mir jemand helfen und sagen, wie ich dem Problem auf die Spur 
kommen kann?

Gruß Michael

[Norbert S. (junky-zs)]

Hallo Michael,
Michael W. schrieb:
> Die grüne LED leuchtet bzw. blinkt sehr schnell, eher ein Flackern
Adapter OK und mit richtiger Polarität am Heizungs-Bus verbunden.
> und lt. sehr guter Anleitung durchgemessen und in Betrieb genommen.
Spricht für den Adapter, wird dann in Ordnung sein.

> Es scheinen aber keine Daten anzukommen.
Da Du einen Raspberry Pi 3B benutzt, solltest Du die Einstellungen der 
seriellen Schnittstelle kontrollieren. Default wird diese von Bluetooth 
benutzt.
Sie dazu Beitrag:
https://wiki.fhem.de/wiki/Raspberry_Pi_3:_GPIO-Port_Module_und_Bluetooth

Bitte auch unbedingt auf die richtige Baudrate von 9600Baud achten (beim 
mini-Adapter).

Empfangs-Kontrolle mit einem Terminalprogramm möglich, z.B. minicom oder 
miniterm.py (Dazu natürlich die HT-Applikation beenden).

Wenn die Software korrekt installiert ist und der ht_proxy.server läuft 
kannst Du den Empfang der Daten auch mit einem Browser überprüfen mit:
 http://<IP des Raspi>:8088

Gruß Norbert

[Michael W. (wemi2019)]

Hallo Norbert,
vielen Dank für die schnelle Unterstützung. Nachdem ich nach Anleitung 
die Einstellung der seriellen Schnittstelle geändert habe und Bluetooth 
deaktiviert habe, bekomme ich jetzt auch mit dem Programm 
HT3_CSW_analyser.py Daten, die auch richtig aussehen. Das ist schon mal 
super.
Leider werden immer noch keine Daten in die Datenbank geschrieben. Die 
Aktivierung des Startscripts ht3_logger mit dem Befehl # insserv 
ht3_logger hat zumindest keine Fehlermeldung gebracht. Doch nach dem 
Neustart müsste doch im Taskmanager ein entsprechender Process zu sehen 
sein, was aber nicht der Fall ist. Da bräuchte ich noch mal Deine Hilfe. 
Wie bereits gesagt, ich arbeite mich in Linux erst so langsam ein.

Gruß Michael

[Norbert S. (junky-zs)]

Hallo Michael,
Michael W. schrieb:
> Leider werden immer noch keine Daten in die Datenbank geschrieben. Die
> Aktivierung des Startscripts ht3_logger mit dem Befehl # insserv
> ht3_logger hat zumindest keine Fehlermeldung gebracht.
Der Daemon: ht3_logger ist veraltet und sollte deaktiviert werden.
Du verwendest offensichtlich ein altes Release.
Das letztgültige ist IMMER zu finden unter:
 https://github.com/norberts1/hometop_HT3
Installation der Applikation wie folgt:
1. Als User Pi einloggen
2. Software-Paket holen mit:
 git clone https://github.com/norberts1/hometop_HT3.git
3. Das von git angelegte Verzeichnis verschieben:
 mv ~/hometop_HT3/HT3 ~/HT3
4. Konfiguration für mini-/micro-Adapter anpassen (Baudrate auf 9600)
 Dies im Konfigurationfile ~/HT3/sw/etc/ht_proxy_cfg.xml machen (siehe 
Doku und Beschreibung im Konfigurationsfile).
5. Start-Scripte installieren (siehe Doku). !Startscript HT3_Logger 
deaktivieren!
6. Datenbanken anlegen mit
 ./create_databases.py
7. Reboot und Daumen drücken :-)
Gruß Norbert

[Michael W. (wemi2019)]

Hallo Norbert,
habe mir die Version von https://github.com/norberts1/hometop_HT3.git 
geholt und nach Anleitung installiert.
Ich hatte ziemliche Probleme, die Datenbanken anzulegen. Das Python 
Script ließ sich bei mir nur aus der Python-Shell starten. Dabei kam es 
zu einer Fehlermeldung, dass die HT3_db.sqlite nicht angelegt werden 
konnte. Da ich in der XML-Datei geshen habe, dass bei vorhandener 
Datenbank, alle Tabellen gelöscht und wieder neu angelegt werden, habe 
ich die Datenbank von meiner ersten Installation einfach in das 
entsprechende Verzeichnis kopiert. Dann lief das Script ohne Probleme 
durch.
Leider existiert das gleiche Problem wie vorher. Die Startscripts 
ht_collgate und ht_proxy werden scheinbar nach dem reboot nicht 
ausgeführt.
Kannst Du mir noch mal helfen?

Gruß Michael

[Michael W. (wemi2019)]

Hallo Norbert,
den ersten Fehler habe ich bereits selbst gefunden. Die Datenbank 
HT3_db.sqlite wurde nicht richtig erzeugt, weil in dem XML-Script 
HT3_db_cfg.xml der Parameter <sql-db><enable> auf "off" gesetzt war. 
Nach der Änderung auf "on" wurden alle Datenbanken korrekt erzeugt.
Der ht_proxy und ht_collgate werden aber beim Startup des Systems 
scheinbar nicht gestartet. Um diesen Fehler zu beheben, fehlen mir im 
Moment noch die Linux Kenntnisse.
Wäre schön, wenn Du mir noch mal helfen könntest.

Gruß Michael

[Norbert S. (junky-zs)]

Hallo Michael,
Michael W. schrieb:
> den ersten Fehler habe ich bereits selbst gefunden. Die Datenbank
> HT3_db.sqlite wurde nicht richtig erzeugt, weil in dem XML-Script
> HT3_db_cfg.xml der Parameter <sql-db><enable> auf "off" gesetzt war.
Dies ist kein Fehler. Nur wenn die sql-Datebank und deren Schnittstelle 
benötigt wird, muss dies aktiviert sein. Default ist die deaktiviert um 
Resourcen zu sparen.
Für die grafischen Anzeigen ist nur die rrdtool-Datenbank nötig.

> Da ich in der XML-Datei geshen habe, dass bei vorhandener
> Datenbank, alle Tabellen gelöscht und wieder neu angelegt werden,...
Es werden keine vorhandenen Datenbanken gelöscht und Tabellen neu 
angelegt.

> ..., habe ich die Datenbank von meiner ersten Installation
> einfach in das entsprechende Verzeichnis kopiert.
Denkbar schlechteste Lösung, weil eine Datenbank aus irgendeinem 
Release-Stand ja nicht zu dem aktuellen Release passen wird.

> Die Startscripts ht_collgate und ht_proxy werden scheinbar nach dem
> reboot nicht ausgeführt.
Bitte die Logfiles unter ~/HT3/sw/log auf Fehlermeldungen kontrollieren.
Die Prozesse lassen sich auch von Hand in einem 'Terminal'-Fenster 
starten.
Dazu in das Verzeichnis ~/HT3/sw wechseln und aufrufen: 'ht_proxy.py' 
bzw. 'ht_collgate.py'. Fehlermeldungen sind dann sichtbar.

Mein Rat an Dich:
- löschen aller Datenbanken unter ~/HT3/sw/var/databases
- Kontrolle der Baudrate im Konfigurationsfile
- Terminalfenster öffnen
- cd ~/HT3/sw
- ./create_databases.py
Dies alles natürlich mit dem aktuellen Release wie oben unter den 
Punkten 1. bis 7. beschrieben.
Gruß Norbert

[Michael W. (wemi2019)]

Hallo Norbert,
ich bins schon wieder. Habe alle Deine Ratschläge befolgt und mir auch 
noch einmal in der Doku die verschiedenen Konfigurationsmöglichkeiten 
angesehen.

Ich benutze den HT3-miniAdapter und habe die Konfiguration für das 
ASYNC-Interface ausgewählt. Wenn ich das richtig sehe, darf ich dann den 
Proxy-Server (ht_proxy) nicht benutzen.

Die HT3_db_cfg.xml sieht dann im Bereich der Definition fürs 
Data_Interface wie folgt aus:
    <data_interface>
      <comm_type>ASYNC</comm_type>
      <proto_type>RAW</proto_type>
      <parameter name="ASYNC">
        <serialdevice>/dev/ttyAMA0</serialdevice>
        <inputtestfilepath></inputtestfilepath>
        <baudrate>9600</baudrate>
        <config>"8N1"</config>  <!-- only 8N1 available -->
      </parameter>
    </data_interface>

Wenn ich nun ht_collgate.py manuel starte bekomme ich im Ccollcate.log 
folgende Fehlermeldung:

23.01.2019 17:57:56 INFO: Starting 'Ccollgate.run()
23.01.2019 17:57:56 CRITICAL: cht_if_worker();Error;could not get 
configuration-values
23.01.2019 17:57:57 CRITICAL: ccollgate().run();Error;could not start 
'ht-interface' with file:'./etc/config/HT3_db_cfg.xml'
23.01.2019 17:57:57 CRITICAL: ccollgate().run();Error; terminated

Was mache ich blos falsch?

Gruß Michael

[Michael W. (wemi2019)]

Hallo Norbert,
ich bin jetzt einen ganzen Schritt weiter gekommen. Die geschilderten 
Probleme sind jetzt behoben.

Ich habe bei der Installation einen großen Fehler gemacht, indem ich das 
ZIP-File von github auf dem PC unter Windows entpackt habe und dann die 
gesamte Verzeichnisstruktur mit WinSCP auf den Raspberry hochgeladen 
habe. Damit sind vermutlich die notwendigen Datei-Attribute verloren 
gegangen.
Ich habe die alte Installation gelöscht, die ZIP-Datei auf dem Raspberry 
entpackt und die gesamte Installation/Konfiguration neu gemacht. Nun 
läuft alles.

Es tut mir Leid, dass ich durch meine Dummheit Dir so viel Mühe gemacht 
habe. Vielen Dank noch einmal für Deine Geduld.

Das einzige was ich bisher nicht hinbekommen habe, ist eine 
Konfiguration ohne den Proxy-Server.
Die HT3_db_cfg.xml sieht dann im Bereich der Definition fürs 
Data_Interface wie folgt aus:
    <data_interface>
      <comm_type>ASYNC</comm_type>
      <proto_type>RAW</proto_type>
      <parameter name="ASYNC">
        <serialdevice>/dev/ttyAMA0</serialdevice>
        <inputtestfilepath></inputtestfilepath>
        <baudrate>9600</baudrate>
        <config>"8N1"</config>  <!-- only 8N1 available -->
      </parameter>
    </data_interface>

Wenn ich nun ht_collgate.py manuell starte bekomme ich im Ccollcate.log
folgende Fehlermeldung:

25.01.2019 15:57:43 INFO: Starting 'Ccollgate.run()
25.01.2019 15:57:43 CRITICAL: cht_if_worker();Error;couldn't open 
requested device:/dev/ttyAMA0
25.01.2019 15:57:43 CRITICAL: ccollgate().run();Error;could not start 
'ht-interface' with file:'./etc/config/HT3_db_cfg.xml'
25.01.2019 15:57:43 CRITICAL: ccollgate().run();Error; terminated

Hast Du da noch einen Tip für mich?

Gruß Michael

[Norbert S. (junky-zs)]

Hallo Michael,

Michael W. schrieb:
> Error;couldn't open requested device:/dev/ttyAMA0
Kann sein, das in Deinem RPi die alternative Schnittstelle: /dev/ttyS0 
zu verwenden ist. Must dann halt den Namen im Konfigfile entsprechend 
anpassen.
Kannst ja mit: ls /dev/ttyAM* bzw.: ls /dev/ttyS* nachsehen ob diese 
Schnittstellen vorhanden sind.

Achte auch darauf, das diese in der Gruppe:dialout sind.

Michael W. schrieb:
> Ich habe bei der Installation einen großen Fehler gemacht, indem ich das
> ZIP-File von github auf dem PC unter Windows entpackt habe...
Norbert S. schrieb:
> 2. Software-Paket holen mit:
>  git clone https://github.com/norberts1/hometop_HT3.git
Dies hätte Dir einiges an Arbeit erspart.

Gruß Norbert

[Chris15 (Gast)]

Hallo zusammen,

hat mittlerweile jemand den Code auf eine Arduino portiert?
Sprich das z.B. bei einem Arduino Mega über Serial1 der HT3-Bus 
ausgelesen wird und über Serial0 im Monitor der Wert für die aktuelle 
Vorlauftemperatur ausgegben wird?

Besten Dank.

Gruß
Chris

[Henrik (Gast)]

Moin Norbert,

habe die neue Software jetzt einige Zeit beobachtet. Soweit scheinen 
alle Werte zu stimmen und decken sich auch mit der Anzeige am CW400. 
Einzig der Temperaturwert für die weiche wird bei dir wesentlich 
schneller übertragen. Junkers schein nur jede Minute den Wert zu 
aktualisieren.
Bis hierher schon einmal ein riesiges DANKE an dich! Echt Top Arbeit.

Wie kann ich eigentlich Befehle über MQTT testen?

Wenn dir noch was einfällt was ich testen kann/soll dann bitte melden!

Gruß

Henrik

[Norbert S. (junky-zs)]

Hallo Henrik,

> Wie kann ich eigentlich Befehle über MQTT testen?
Dies ist in der Doku im Kapitel: 2.3.2 'MQTT-Client' beschrieben.
Beispiel für einen Fxyz-Regler:
2.2 Setzen der Soll-Temperatur auf 21.5 Grad des Niveaus „heizen“ mit:
mosquitto_pub -d -h <host IP-Adr.> -t set/hometop/ht/hc1_Tdesired -m 
"21.5,heizen".

Im Konfigurationsfile: HT3_db_cfg.xml haben alle steuerbaren logitems 
einen zusätlichen Parameter:
 <set_param>Befehle f. Fxyz || Befehle f. Cxyz</set_param>

Wie diese Befehle zu nutzen sind ist im Modulkopf des Konfiguratiosfile: 
HT3_db_cfg.xml beschrieben.

Gruß Norbert

[Henrik (Gast)]

Moin Norbert,
ich habe jetzt längere Zeit versucht mit den Befehlen klar zu kommen. 
Via MQTT scheint nur nach jedem Neustart genau ein Befehl (allerdings 
nur HK1, siehe unten) durch zu kommen.

Mit dem ht_netclient kann ich immerhin den HK1 komplett steuern. Sobald 
ich allerdings den Parameter "-hc 2" anhänge, passiert auf diesem 
nichts, sondern der Befehl wird für den HK 1 ausgeführt.

Noch eine Frage im Rande: Wenn ich den HK 1 in den manuellen Modus mit 0 
°C setzte, geht der Betriebsstatus auf 0 --> also aus, der Mischer fährt 
auf 0% aber die Pumpe geht nicht aus... Müsste sie aber eigentlich oder?

Besteht außerdem die Möglichkeit die gedämpfte Außentemperatur 
auszulesen?

Gruß
Henrik

[Norbert S. (junky-zs)]

Hallo Henrik,
Henrik schrieb:
> habe jetzt längere Zeit versucht mit den Befehlen klar zu kommen.
> Via MQTT scheint nur nach jedem Neustart genau ein Befehl (allerdings
> nur HK1, siehe unten) durch zu kommen.
Ich nehme mal an Du hast für den Heizkreis 2 auch den richtigen Befehl 
gewählt mit 'hc2_...' ?

Zur Kontrolle kannst Du im ht_proxy den Debug-Mode aktivieren:
Zeile im Pyhton-Script: ht_proxy.py aktiveren, darunter die deaktiveren:
 ht_proxy=ht_proxy_if.cht_proxy_daemon(configfile, 
loglevel=logging.DEBUG)
 # ht_proxy=ht_proxy_if.cht_proxy_daemon(configfile)
und den ht_proxy.py und danach ht_collgate.py neu starten mit
sudo /etc/init.d/ht_proxy stop
sudo /etc/init.d/ht_proxy start
sudo /etc/init.d/ht_collgate stop
sudo /etc/init.d/ht_collgate start

Die Debug-Ausgaben werden dann in das Log-Verzeichnis geschrieben unter 
~/HT3/sw/var/log/ht_proxy.log
Die Kommandos zum ht_pitiny sind darin enthalten. Du kannst diese ja zur 
Kontrolle hier posten.

> Mit dem ht_netclient kann ich immerhin den HK1 komplett steuern. Sobald
> ich allerdings den Parameter "-hc 2" anhänge, passiert auf diesem
> nichts, sondern der Befehl wird für den HK 1 ausgeführt.
Beispiel mit ht_netclient für Heizkreis 2:
ht_netclient.py -tc2 21.5 -hc 2
(Einstellung Temperatur-Niveau:Comfort2 auf 21.5 Grad und Heizkreis: 2)

Änderungen dieser Werte werden bei den Cxyz-Reglern leider nicht sofort 
mit einem Telegramm quittiert, es kann durchaus mehr als eine Minuten 
dauern bis ein Wechsel des Parameters mitgeteilt wird (Kontrolle mit 
HT3_Analyser möglich).
Es hängt auch davon ab ob im 'auto'-mode gerade 'Comfort1' oder 'Eco' 
oder ... durch Programm aktiviert ist und dann für 'Comfort2' der Wert 
ändert wird.
Die Änderung wird auch dann nur für 'Comfort2' gemacht und nur dann 
angezeigt wenn 'Comfort2' aktiv ist.
Die Abhängigkeiten sind derer viele und mit den Cxyz-Reglern leider noch 
mehr geworden.

> Wenn ich den HK 1 in den manuellen Modus mit 0
> °C setzte, geht der Betriebsstatus auf 0 --> also aus, der Mischer fährt
> auf 0% aber die Pumpe geht nicht aus... Müsste sie aber eigentlich oder
Die HK-Pumpen haben eine Nachlaufzeit, die im Regler einstellbar ist.

> Besteht außerdem die Möglichkeit die gedämpfte Außentemperatur
> auszulesen?
Habe ich in den Telegrammen bisher nicht gefunden.

Gruß Norbert

[Henrik (Gast)]

Hi Norbert,
ich habe mir mal die Mühe gemacht und das Gesamtsystem neu aufgesetzt 
(also mit aktuellem Stand vom Git). MQTT liefert soweit jetzt alle 
Werte, soweit ist alles wieder wie vorher.

Norbert S. schrieb:
> Ich nehme mal an Du hast für den Heizkreis 2 auch den richtigen Befehl
> gewählt mit 'hc2_...' ?
Den korrekten MQTT-Befehl habe ich gewählt, allerdings funktioniert das 
ja schon nicht mit dem ht_netclient...

Norbert S. schrieb:
> Zur Kontrolle kannst Du im ht_proxy den Debug-Mode aktivieren:
Sobald ich den Debugmode aktiviere, kann ich keine Befehle mehr mit dem 
ht_netclient absetzten.

./ht_netclient.py -tc2 22.0 -hc 2
Is controller-type any of CTxyz/CRxyz/CWxyz y/n ?y
couldn't connect to server
Traceback (most recent call last):
  File "./ht_netclient.py", line 239, in <module>
    main(configfile, ems_bus)
  File "./ht_netclient.py", line 106, in main
    client= ht_proxy_if.cht_socket_client(configfile, devicetype = ht_proxy_if.DT_MODEM)
  File "lib/ht_proxy_if.py", line 857, in __init__
    self._socket.connect((self._ip_address, self._port_number))
ConnectionRefusedError: [Errno 111] Connection refused

Im ht_proxy.log:

26.03.2019 09:04:35 INFO: Client-ID:2; ('127.0.0.1', 39742) connected
26.03.2019 09:04:35 INFO: Server   :('0.0.0.0', 8088)
26.03.2019 09:04:35 INFO: Client-ID:2; register(); got devicetype:MODEM
26.03.2019 09:04:35 INFO: csocketsendThread(); socket.send thread start
26.03.2019 09:04:35 INFO: Client-ID:2; added; number of clients:2
26.03.2019 09:04:35 INFO: Client-ID:2; cht_RequestHandler(); socket.receive thread start
26.03.2019 09:04:35 INFO: Client-ID:1;cportwrite();couldn't read from queue
26.03.2019 09:04:45 INFO: Client-ID:2; ('127.0.0.1', 39742) disconnected
26.03.2019 09:04:45 INFO: Client-ID:2; removed; number of clients:1
26.03.2019 09:04:45 CRITICAL: csocketsendThread();Error on socket.send
26.03.2019 09:04:45 INFO: Client-ID:1;cportwrite();couldn't read from queue

Norbert S. schrieb:
> ht_netclient.py -tc2 21.5 -hc 2

Der Befehl ändert die Temperatur im HK1, egal welchen hc Parameter ich 
übergebe.....


Bin zur Zeit erstmal ratlos......

Gruß
Henrik

[Christoph (Gast)]

Moin Moin,

funktioniert das ganze auch mit Lüftungsanlagen von Junkers/Bosch?
Laut Handbuch haben die ja auch einen Bus.

Hier mal die Installationsanleitung meiner Bosch Vent 5000C:

https://www.bosch-thermotechnology.com/ocsmedia/optimized/full/o222405v52_6720811375.pdf

An den Bus kann Zubehör (z.B. MB-LAN) angeschlossen werden - dann müsste 
das doch klappen, oder?

Grüße,

Christoph

[Grunzrakete (Gast)]

Moin,

bei mir hängt seit einigen Tagen eine Junkers ZWR 18-7 KE 23..blubb mit 
CR100 rum. Hatte mich schon gefreut, die mit eurer tollen bisher 
geleisteten Arbeit leicht anbinden zu können. Zumal in der 
Installationsanleitung

Leider scheint sich bei Junkers etwas getan zu haben: Man scheint sich 
innerhalb von Bosch Thermotechnik auf EMS geeinigt zu haben. In der 
Installationsanleitung des CR100 
(https://www.waerme24.de/media/dokumente/Bosch_Regelungen_Installationsanleitung_CR100_CW100.pdf) 
steht jedenfalls überall EMS 2 drin. Auf dem Gerät steht auch nicht 
Junkers sondern einfach nur Bosch. Eine kurze Google-Suche ergab, dass 
das Ding auch bei Buderus eingesetzt wird. Logisch man will langsam mal 
weg davon alles doppelt zu produzieren.

Mit den Teilen die ich herumliegen hatte hab ich sowas wie den 
HT3-Microadapter gebaut und mit dem Oszi verifiziert, dass ich 
tatsächlich das was auf dem Bus zu sehen ist auch herausbekomme.

Mit dem Zeug was da herauskommt kann jedoch Norberts Software nichts 
anfangen und es sieht mir auch nicht wirklich nach EMS aus (Doku gibt es 
ja in nem Wiki). Hat irgendwer schon mal bei richtig neuen 
Junkers-Anlage Versuche unternommen?

Besten Dank und Gruß,
Grunz

[Norbert S. (junky-zs)]

Hallo,
Grunzrakete schrieb:
> Leider scheint sich bei Junkers etwas getan zu haben: Man scheint sich
> innerhalb von Bosch Thermotechnik auf EMS geeinigt zu haben. In der
> Installationsanleitung des CR100 steht jedenfalls überall EMS 2 drin.
Stimmt, EMS2 ist aber ebenfalls ein 2-Draht-Bus so wie HT3 bzw. HT4i 
(Junkers).
Habe selber den alten FW100-Regler durch zuerst einen CW100- und jetzt 
einen CW400-Regler (beide EMS2) ersetzt. Dieser läuft sehr gut an meinem 
Heizgerät mit dem HT3-Bus.
Auf diesem Regler steht ebenfalls Bosch drauf (ist seit 2017 so) und ist 
als EMS2 Bus gekennzeichnet, jedoch ist Junkers drin.
Wichtig ist die 10stellige Artikelnummer, die muss passen.
Leider kennzeichnet Buderus ebenfalls den Bus als 'EMS-Bus', trotzdem 
laufen die Buderus-Regler nicht mit einem Junkers-Gerät.
Dies liegt dann weniger am Bus (2-Draht sind die beide) sonder an den 
Telegrammen die darüber laufen. Die sind leider zwischen Buderus/Bosch 
und Junkers/Bosch unterschiedlich.
Du hast aber ein Junker-Heizgerät und daher sollten die Telegramme 
Deines CR100 Reglers/ der Heizung dekodiert werden.

Habe Logfiles von z.B. Junkers 9000i Geräten und die Telegramme werden 
ebenfalls dekodiert.

Welche Software-Version setzt Du ein?

Vielleicht kannst Du ein Logfile erstellen und hier ins Forum posten.

Gruß Norbert

[Grunzrakete (Gast)]

Hallo Norbert,
danke für deine rasche Antwort.

Neueste Softwareversion von github.

Im Anhang gibt es eine log-Datei.

Besten Dank

Grunz.

[Norbert S. (junky-zs)]

Grunzrakete schrieb:
> Im Anhang gibt es eine log-Datei
Die Daten im Logfile enthalten keine Junkers Heizungs-Telegramme.

Dies kann zwei Gründe haben:
1. Baudrate in der Konfiguratin des Adapters
2. Hardware des Adapters

Bitte kontrolliere die Baudrate, die in der Konfiguration einzugeben 
ist.
Für den Micro-Adapter ist 9600 Baud erforderlich. Siehe Details in der 
Doku.

Grunzrakete schrieb:
> Mit den Teilen die ich herumliegen hatte hab ich sowas wie den
> HT3-Microadapter gebaut und mit dem Oszi verifiziert.
Bitte die seriellen Signale kontrollieren. Ein serielles Byte fängt mit 
einer fallenden Flanke an und hört mit einer steigenden Flanke auf. Dies 
gemessen direkt am RX-Eingang des UART-USB-Wandlers.

Gruß Norbert

[Grunzrakete (Gast)]

Hallo Norbert,

ich hatte mir die Signale nur mit einem analogen Oszi angesehen. Hab 
jetzt nochmal mit einem digitalen geguckt und siehe da mein 
Ausgangssignal sah nicht so gut aus.. :-) Basiswiderstand in der 
Inverterstufe war um eine Größenordnung zu groß. Da hab ich wohl zu 
später Stunde ins falsche SMD-Kistchen gegriffen.

Nun läuft es und deine Software scheint auch das Meiste zu verstehen. Es 
gibt allerdings eine Menge Telegramme mit ??? davor.

Hab das Ganze übrigens mit Optokoppler 6n139 und einem dahinter in die 
Sättigung getriebenen PNP Transistor gebaut. Zenerdioden zu 9,1V und 
3,3V in Reihe mit Vorwiderstand und Schottkydiode davor und feddich. Was 
halt gerade da war :-)

Besten Dank für die tolle Software Norbert!

Gruß/Grunz

[Frank R. (frenpi)]

Ursachenforschung: Datenaufzeichnung lückenhaft (siehe Bilder).

HT3 läuft seit ein paar Wochen prima (Danke, Norbert). Seit 4 Tagen gibt 
es kuriose Aufzeichnungslücken. In der zwei-Tagesdarstellung wurde 
nichts mehr angezeigt, obwohl die Daten korrekt mit dem HT3_Systemstatus 
angezeigt werden. Die Daten werden auch immer noch korrekt zum ioBroker 
über mqtt gepublished.

Ich habe dann in rrdtool_draw.pl mal my $start_time = time()-20160*60 
gesetzt (20160 sind 14 Tage, 14x60x2).

Siehe da, Vor 4 Tagen war noch alles ok - dann wurden die Daten 
anscheinend "ausgedünnt".

Dazu fällt mir nur ein ein Performance-Problem ein. Warum sollten die 
Daten plötzlich nur noch teilweise aufgezeichnet werden.
Ist ein Raspi 1 Modell A - die SQLilte DB ist ca. 120 MB groß, 
Datenbanken liegen auf USB-Stick. Außer HT3 läuft nix.
Top liefert load average um 5,25, 5,29, 5,13...

Oder gibt es eine andere Idee?

Beste Grüße, Frank

[Stefan B. (sbiermann)]

Hallo Frank,
die Auslastung ist viel zu hoch, der läuft mit 500% Auslastung. Mein Pi 
mit der HT3 Software und noch ein GlusterFS Server als docker Container 
ist bei 60-70% Auslastung. Du solltest mit "top" schauen was da die 
Auslastung verursacht.

Viele Grüße
Stefan

[Frank R. (frenpi)]

Danke für die Rückmeldung - TOP in der Anlage zeigt zwar, dass er schon 
ziemlich beschäftigt ist, aber dass 50% davon von ht_collgate, ht_proxy 
und ubs-storage kommen. Muss ich wohl doch auf den anderen Raspi 
umziehen, den ich hier noch habe.
Die Werte sind aber ziemlich konstant.

Wundert mich allerdings, dass das sich das erst seit 5 Tagen zeigt. Ich 
dachte, das könnte auch an der gewachsenen Sqlite Datenbank liegen, aber 
abschatten in der Config hat nichts genützt.

Ein erneuters Sichten von Ccollgate.log zeigt allerdings, dass seit dem 
Zeitpunkt der teilweisen Aufzeichnung das erste Mal Autoerasing 
Activitities von sqlite eingetragten wurden. Kann das damit 
zusammenhängen? (Anlage)

[Frank R. (frenpi)]

Das Abschalten von Sqlite hat doch geholfen. Auslastung ist jetzt immer 
noch zwischen 1,6-1,9 aber Aufzeichnung geht wieder.

[F. S. (f_s352)]

Hi Leute,

hat noch einer eine Platine für den Raspi übrig oder benötigt diese 
nicht mehr? Für eine PN wäre ich sehr dankbar.  Viele Grüße

[F. S. (f_s352)]

Hallo,

vorab ein Dank an Norbert, dass ich noch einen HT_pitiny bekommen habe!
Ich bin kein Experte und habe lange gekämpft bis ich den Adapter auf 
einem Raspberry 4 zum Laufen gebracht habe.

Ich möchte meinen Notizen aber teilen, vielleicht hilft es ja dem einen 
oder anderen Newbie...

AUSGANGSSITUATION

Adapter: HT_pitiny
Rechner: Raspberry 4
Image: Raspbian Buster Lite
HT Manual: Rev. 0.3

KOMMENTARE ZUR INSTALLATIONSANLEITUNG

Notiz in eigener Sache:
Möchte man den SSH Zugriff auf dem Raspberry aktivieren, so ist mit 
Windows eine Datei mit der Bezeichnung SSH in die Bootpartition zu 
legen.

3.1 Installation Betriebssystem

Debian-Buster ist der Nachfolger von Debian-Jessie
Deaktivieren der default eingeschalteten TTY-Systemausgaben ist bei 
Debian-Buster auch nicht notwendig
Anpassen der /etc/inittab ist bei Debian Buster ebenfalls nicht 
notwendig.
Deaktivieren von Bluetooth ist beim Raspberry 4 nicht notwendig.
Mann muss aber beim Raspberry 4 die serielle Konsole wie folgt 
deaktivieren:
sudo raspi-config -> 5 Interfacing Options > P6 Serial > Login 
accessible over serial > No > serial port enable > Yes

3.2 Applikationen

Der Befehl git muss zuerst noch installiert werden:
$ sudo apt-get install git
Der HT3_logger sollte nicht mehr verwendet werden, der ht_collgate 
ersetzt den HT3_logger.
Zum Aktivieren der Startskripte funktioniert beim Raspberry 4 der Befehl 
insserv nicht mehr.
Folgende Befehle sind statt sudo insserv zu verwenden:
$ sudo chmod +x /etc/init.d/daemonXY
$ sudo systemctl enable daemonXY
Es sollte ht_proxy verwendet werden (SOCKET, kein ASYNC!)
Beim Raspberry 4 liegt der HT_pitiny auf /dev/serial0 (dies ist 2x im 
ht_proxy_cfg.xml zu ändern)

DEBUGGING:

Befehl zur Prüfung der aktiven HT Prozesse:
$ ps ax | grep HT (es sollte httpd, proxy und collgate laufen)

Möchte man die Applikationen HT3_Analyser oder HT3_Systemstatus über SSH 
verwenden, ist folgendes zu tun:
Installation von PUTTY und Xming auf dem Windows Rechner
In Putty unter Connection > SSH > X11 > Enable X11 forwarding aktivieren 
und x display location auf ":0.0" setzen.
Die Session in Putty mit SAVE abspeichern.
Im Terminal prüfen, ob "echo $DISPLAY" den Wert localhost:10.0 ausgibt.
Nun öffnet sich beim Aufruf von $ ./HT3_Systemstatus.py oder $ 
./HT3_Analyser eine schöne Applikation.


Viel Spaß beim "Kämpfen" :-)

[gezuppe (Gast)]

Hi Zusammen,
bei meinem RasPi A hat sich leider die SD Karte verabschiedet und so 
habe ich nun einen RasPi 3 mit Stretch aufgesetzt aber leider bekomme 
ich das Ganze nicht mehr zum Laufen.
Auf dem RasPi habe ich eine HTmini, dass Pinout sollte ja gleich 
geblieben sein.
Beim Start des HT_collgate bekomme ich folgende Meldung:
CRITICAL: cht_if_worker();Error;couldn't open requested 
device:/dev/serial0

- Ich habe auch ttyAMA0 probiert.
- pi user ist in der Dialout Gruppe
- BT ist aus

Hat noch Jemand eine Idee? ICh habe mich dur viele Foren/Bugs gewühlt 
finde aber keine Lösung...

Grüße Sebastian

[Norbert S. (junky-zs)]

Hallo Sebastian,

gezuppe schrieb:
> Auf dem RasPi habe ich eine HTmini, dass Pinout sollte ja gleich
> geblieben sein.
Ist gleich geblieben.

gezuppe schrieb:
> Beim Start des HT_collgate bekomme ich folgende Meldung:
> CRITICAL: cht_if_worker();Error;couldn't open requested
Dies liegt an der nicht mehr unterstützen Funktion:
 self.__port.setInterCharTimeout()
für die serielle Schnittstelle.
Da diese Funktion nicht mehr benötigt wird kann sie deaktiviert oder 
gelöscht werden.
Manuell in folgenden Modulen/Zeilen:
 lib/Ccollgate.py / 487
 lib/ht3_worker.py / 175
 lib/ht_proxy_if.py 281 (war dort schon deaktiviert)

oder komplettes Release: 0.3.2 mit
 git clone https://github.com/norberts1/hometop_HT3.git

Gruß Norbert

[Rene R. (rene3388)]

Anbei noch die Logs und Configfiles!


Sehr geehrte Forenteilnehmer!
Lieber Norbert!

Ich habe den "Raspi_HT3MiniAdapter" nachgebaut, durchgemessen/ 
durchgetestet und nun (via ISM1)am HT3-Bus angebunden.

Therme: Junkers CerapurModul-Solar ZBS14210S3, 1xISM1, 1xFW100;
RPi: Model B+ V1.2, Raspian-Buster

Status:
Am HT3MiniAdapter leuchtet D4 durchgehend, D3 flackert leicht.

Fehler: Es kommen keine Daten am RPi an, bzw. wird nichts in die 
SQL/RRDtool Datenbanken geschrieben.

Ich vermute, dass es an der RPi-Konfiguration liegt, da ich bedingt 
durch Raspian-Buster ein paar Installationspunkte anders machen musste 
(siehe Anhang).
Habt ihr eine Idee woran es liegen könnte?

Vielen Dank und Grüße!
Rene

[Michael W. (wemi2019)]

Hallo Rene,
bei mir läuft der Raspi_HT3MiniAdapter auch unter Raspbian-Buster seit 
einem Jahr problemlos. Ich kann mich dunkel erinnern, dass ich am Anfang 
Probleme hatte, das ganze ohne ht_proxy ans laufen zu bekommen. Bei mir 
läuft seitdem der Proxy-Server. Hat auch den Vorteil, dass man die Tools 
HT3-Analyser und HT3_systemstatus parallel benutzen kann.
Ich würde es mal mit ht_proxy versuchen.
Viel Glück
Michael

[Norbert S. (junky-zs)]

Hallo Rene,

Deine Installation sieht soweit gut aus.
Du benutzt zwar nicht den ht_proxy.server sondern nimmst direkt den 
ht_collgate.py daemon.
Somit wird Dein mini-Adapter direkt mit 9600 Baud vom ht_collgate 
bedient und so kann man das System u.A. auch betreiben.
Zusammen mit dem ht_proxy.server ist es ein wenig komfortabler aber 
nicht zwingend nötig wenn man die anderen Tools (HT3_Analyser usw.) 
nicht benötigt.

Dies ist aber auch wohl nicht die Ursache. Ich habe vielmehr die 
Befürchtung das die serielle Schnittstelle unter /dev/tty.... gar nicht 
mehr vorhanden ist. Schau bitte mal nach ob unter /dev/tty* irgendeine 
serielle Schnittstelle vorhanden ist wie:
 ll /dev/ttyAMA*
oder
 ll /dev/serial*

Wenn diese nicht vorhanden ist, dann war wohl Deine Aktion:
 $ sudo systemctl stop [e-mail]
 $ sudo systemctl disable [e-mail]
zuviel des Guten.
Jedenfalls habe ich dies nicht auf meinem RPiB+ ausgeführt.

Auch sieht mein Eintrag in der /boot/cmdline.txt wie folgt aus:
 console=tty1 root=/dev/mmxytzer rootfstype=ext4 elevator=deadline
 fsck.repair=yes rootwait

Falls /dev/ttyAMA0 vorhanden ist dann bitte folgenden Befehl ausführen 
und Ausgabe kontrollieren:
stty -F /dev/ttyAMA0
 speed 9600 baud; line = 0;
 min = 0; time = 0;
 -brkint -icrnl -imaxbel
 -opost -onlcr
 -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

Gruß Norbert

[Rene R. (rene3388)]

Hallo Michael!

Vielen Dank, für den Input!
Ich hatte diese Konfiguration gewählt, weil sie mir einfacher erschien 
und werde zuerst noch versuchen, den Fehler in dieser zu finden/lösen.

Wenn dies nicht gelingt, werde ich es mit deinem Vorschlag probieren.

lg
Rene

[Rene R. (rene3388)]

Hallo Norbert!


Folgende Informationen hätte ich,


Eingabe:
ls /dev/tty*

Ausgabe:
/dev/tty    /dev/tty12  /dev/tty17  /dev/tty21  /dev/tty26  /dev/tty30 
/dev/tty35  /dev/tty4   /dev/tty44  /dev/tty49  /dev/tty53  /dev/tty58 
/dev/tty62  /dev/ttyAMA0
/dev/tty0   /dev/tty13  /dev/tty18  /dev/tty22  /dev/tty27  /dev/tty31 
/dev/tty36  /dev/tty40  /dev/tty45  /dev/tty5   /dev/tty54  /dev/tty59 
/dev/tty63  /dev/ttyprintk
/dev/tty1   /dev/tty14  /dev/tty19  /dev/tty23  /dev/tty28  /dev/tty32 
/dev/tty37  /dev/tty41  /dev/tty46  /dev/tty50  /dev/tty55  /dev/tty6 
/dev/tty7
/dev/tty10  /dev/tty15  /dev/tty2   /dev/tty24  /dev/tty29  /dev/tty33 
/dev/tty38  /dev/tty42  /dev/tty47  /dev/tty51  /dev/tty56  /dev/tty60 
/dev/tty8
/dev/tty11  /dev/tty16  /dev/tty20  /dev/tty25  /dev/tty3   /dev/tty34 
/dev/tty39  /dev/tty43  /dev/tty48  /dev/tty52  /dev/tty57  /dev/tty61 
/dev/tty9

=====================================

Eingabe:
stty -F /dev/ttyAMA0

Ausgabe:
speed 9600 baud; line = 0;
min = 0; time = 0;
-brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

=====================================

Sieht soweit OK aus oder?

lg
Rene

[Ingo W. (uebrig)]

Hatte in einer ähnlichen Anwendung auch Probleme mit dem RasPi UART.
Hier hat mir 
https://buyzero.de/blogs/news/praktische-kommunikation-per-uart-und-rs485-am-raspberry-pi 
geholfen. Ich zitiere mal:

Standardmäßig ist außerdem eine Linux Console über den "Haupt-UART" des 
Systems vorgesehen. Diese würde uns bei der Kommunikation stören, und 
muss daher abgeschaltet werden.

 Das funktioniert wie folgt:

sudo nano /boot/cdmline.txt

hier muss der Teil mit console=serial0,115200 gelöscht werden (kann 
ähnlich ausschauen).

Da wir den PL011 verwenden wollen, müssen wir bei Pi 3B / 3B+ / 3A+ & 
der Zero Reihe Bluetooth abschalten (optional gäbe es auch die 
Möglichkeit die zwei UARTs zu tauschen, da der miniUART aber u.a. an die 
Taktrate des VideoCores fixiert ist bringt das Nachteile und 
zusätzlichen Konfigurationsaufwand mit sich). Wir gehen wie folgt vor:

sudo nano /boot/config.txt

Hier wird folgende Zeile ganz am Ende eingefügt:

dtoverlay=pi3-disable-bt

Diese Zeile vertauscht in der Softwarekonfiguration die Pins, so dass 
wir jetzt über die uns zugänglichen Pins am Raspberry Pi (siehe Pinout 
oben) den PL011 UART nutzen können.

Außerdem ist es wichtig den Systemservice zu disablen, der mit Bluetooth 
kommuniziert (da er sonst weiter über die Pins kommunizieren versuchen 
würde):

sudo systemctl disable hciuart

Das sollte ausgeben: "Removed 
/etc/systemd/system/multi-user.target.wants/hciuart.service".

Jetzt ist es an der Zeit, den Pi neu zu starten:

sudo reboot

[Rene R. (rene3388)]

Hallo Ingo!

.)In meiner config.txt wurde "console=serial0,115200" bereits entfernt.
.)Bei meinem Raspi handelt es sich wie beschrieben um ein Model B+ V1.2.
(Daher kein integriertes BT)

lg
Philipp

[Daniel H. (Gast)]

Hallo zusammen,

ich würde meine Heizungsanlage auch gerne etwas "smarter" machen. Leider 
fehlt mir eine wenig das Geschick den HT_pitiny selbst zusammenzubauen.
Meine Frage wäre nun, ob jemand von euch noch einen HT_pitiny übrig hat 
und ihn mir verkaufen möchte ?

Vielen Dank und viele Grüße
Daniel

[Remo P. (remo66)]

Hallo allerseits,

ich bin seit kurzem auch Besitzer einer modernen Heizung von Bosch mit 
HT- Bus (Cerapur 9000i).
Als Informatiker habe ich auch schon einige Projekte mit dem Raspberry 
gemacht und auch ein paar im dauerhaften Betrieb.
Jetzt würde ich natürlich auch gern mit meiner Heizung kommunizieren und 
eventuell hier auch etwas beitragen.
Ich weiß es ist schon einige Male gefragt worden, aber auch ich hätte 
gern ein HT_pitiny Board.
Das Repository [[https://github.com/norberts1/hometop_ht_transceiver]] 
ist toll, aber die Herstellung/Bestückung für ein einzelnes Exemplar ist 
für mich doch ein recht großer Aufwand.
Könnt Ihr mir weiterhelfen?

Schöne Grüße!
Remo

[Norbert S. (junky-zs)]

Hallo Remo,
Remo P. schrieb:
> Ich weiß es ist schon einige Male gefragt worden, aber auch ich hätte
> gern ein HT_pitiny Board
Ich habe z.Zeit auch keine Boards.
Sende mir eine PM.
Wenn ausreichend Anfragen kommen kann ich noch ht_pitiny-Boards 
erstellen.
Gruß Norbert

[Rene R. (rene3388)]

Hallo Norbert!

Frage zur Bestückung des USB MicroAdapter's,
Den Mini-USB-UART-Umsetzer UM 2102 (91859) scheint es bei ELV nicht mehr 
zu geben.
Kann man stattdessen einen "CP2102 USB to TTL Serial Converter 5 PIN" 
(zum Beispiel: 
https://www.amazon.co.uk/Yizhet-Converter-Compatible-Arduino-Windows/dp/B07TFSZ3ZP)
verwenden?

Vielen Dank!
Philipp

[Norbert S. (junky-zs)]

Rene R. schrieb:
> Den Mini-USB-UART-Umsetzer UM 2102 (91859) scheint es bei ELV nicht mehr
> zu geben.150952
Es gibt eine neuere Version bei ELV (150952). Die ist wohl auch 
Pin-kompatibel zur Vorgängerversion und billiger als die von Amazon.
Es funktioniert aber jeder USB-UART Wandler wenn dieser eine Spannung 
liefert (3.3 oder 5 Volt) und logischerweise einen RX-Anschluß hat.
Allgemein gilt, die Schaltung ist sehr universell einsetzbar. Die kann 
auch an jedem MC mit UART angeschossen werden.

Gruß Norbert

[Remo P. (remo66)]

Hallo zusammen,

Dank Norbert habe ich nun auch eine funktionierende Anbindung an meine 
Heizung(Cerapur 9000i/CW400/1HK/kein Solar/RPi2/HT_pitiny).
Nach Konfiguration funktioniert jetzt auch alles soweit.
Nur gelingt es mir nicht den HTTP- Server auf dem RasPi anzusprechen.
Alle anderen Sachen (HT3_Analyser/HT3_Systemstatus.py etc.) 
funktionieren remote.
Kann mir vielleicht jemand mal die Konfiguration kurz mitteilen.
Die Doku habe ich eigentlich gelesen. ;-)
Den HTTPD- Daemon habe ich natürlich gestartet und die RRD- DB's werden 
auch gefüllt.
Vielleicht hapert es nur an der richtigen URL im Browser.

Schöne Grüße!
Remo

[Remo P. (remo66)]

Hat sich erledigt.

Durch eine kurzen Blick in "httpd.py" herausbekommen das es Port 8086 
ist.
Sorry für die Anfrage, aber ich habe doch eine ganze Weile gesucht.

Gruß Remo

[Andreas W. (urbansunited)]

Hi!

Ich bin bei meiner Suche nach Einbindung der Junkers Heizung in Home 
Assistant auf das Projekt EMS-ESP
https://github.com/proddy/EMS-ESP
gestoßen.
Meine Fragen:
Kann der ht_pitiny adapter damit irgendwie verbunden werden?
Oder kann sonnstwie die Systeme verbinden und dann per HA die Heizung 
steuern und auslesen?
Auslesen ist nicht das Problem, dafür läuft ja MQTT, aber das direkte 
Steuern?
Oder brauche ich ein neues Board dafür?
Oder hat jemand schon etwas in HA gebaut?

Beim EMS-ESP hab ich schon nachgefragt

https://github.com/proddy/EMS-ESP/issues/456#issuecomment-674030617

Danke und besten Gruß

Andi

[Norbert S. (junky-zs)]

Hallo Andreas,
Andreas W. schrieb:
> Auslesen ist nicht das Problem, dafür läuft ja MQTT, aber das direkte
> Steuern?
> Oder brauche ich ein neues Board dafür?
Nein, Du brauchst nur den ht_pitiny- oder den ht_piduino-Adapter um die 
Heizung auch mit MQTT-Kommonados zu steuern.
Siehe dazu auch meine Doku und obige Test-Beispiele.

Andreas W. schrieb:
> Kann der ht_pitiny adapter damit irgendwie verbunden werden?
ht_pitiny-Adapter (deviceID:0x0D) und EMS-ESP (deviceID:0x0B) können 
parallel am gleichen Heizungsbus (Heatronic oder EMS) angeschlossen 
werden. Da unterschiedliche Device-Adressen verwendet werden kollidieren 
die Telegramme und Kommandos nicht.

Andreas W. schrieb:
> Oder hat jemand schon etwas in HA gebaut?
Ein 'Home Assistant' (HA) Binding habe ich noch nicht im Projekt, aber 
vielleicht hat jemand hier im Forum dies schon für MQTT und RX/TX 
realisiert?

Gruß Norbert

[Bert (Gast)]

Hi Andreas, Norbert,

Ich habe von Norbert einige Jahre züruck auch ein ht_pitiny gekauft.
Aber noch nicht verbunden mit mein Junkers Brenner. Kein Zeit gehat.
Habe seit ein halb Jahr auch den Switch gemacht von FHEM nach Home 
Assistant.

Jetzt wollte ich die ht_pitiny nutzen om den Junkers Brenner ein zu 
binden in HA.
Aber da ist kein directe HA integration von Norbert. Jetzt lese ich das 
es auch geht über MQTT (lesen UND schreiben).

Auf meine HA ist auch ein MQTT Broker installiert. (benutze es für 
Tasmota flashed ESP chips).
Also kan ich die Norbert HT3 software installieren auf ein Pi und ins 
config MQTT localhost ändern nach mein HA MQTT Mosquito broker IP und 
über HA MQTT autodiscovery die topic eintragen für lesen und steueren 
(von Temp setpoint) so ich verstehe.

Habe auch den EMS-ESP Project gefunden welche basiert ist auf ein 
ESP8266 oder ESP32 chip.
Diese software sieht einfacher aus und ist HA ready.
Kein install von Pi mit OS, und HT3 software von Norbert, nur ein 
einfaches flash von ein BIN file auf den ESP8266 und connectieren mit 
ESP-EMS site. (mein entschuldigung Norbert :-) )

Kann ich mit einem ht_pitiny (nur wie interface) auch einem ESP8266 chip 
dirext anschliesen und doch den EMS-ESP software nutzen ?

Auf Seite 17 den Norbert HT3_Adaption.pdf sagt Norbert dan man die 
ht_pitiny auch ohne Raspberry Pi nutzen kann mit zb. ein USB adapter 
(nur 4 signale : RXD/TXD/GND/+3.3V)

Kann ich zb. ein NodeMCU oder Wemos D1 ESP8266 chip direct anschliesen 
an diese 4 signale ?

Also mein ESP8266 nimmt power (5V) über den USB port.

Ich verbinde den ESP 3.3V power pin an pin 1 auf den ST1 ht_pitiny 
header.
Ich verbinde den ESP GND pin an pin 6 auf den ST1 ht_pitiny header.
Ich verbinde den ESP TxD pin (D8 Wemos) an pin 8 (RxD) auf den ST1 
ht_pitiny header.
Ich verbinde den ESP RxD pin (D7 Wemos) an pin 10 (TxD) auf den ST1 
ht_pitiny header.

ESP8266:
Rx GPIO pin - Which pin the Rx is assigned to. On an ESP8266 this has to 
be 3 or 13. The default is 13 (D7 on a Wemos).
Tx GPIO pin - Which pin the Tx is assigned to. On an ESP8266 this has to 
be 1 or 15. The default is 15 (D8 on a Wemos).

Wird das funzen ? :-)

Wofür ist die ATiny441 chip dann eigentlich in den ht_pitiny ?
In die BBQKees EMS Bus HAT for Raspberry Pi siehe ich kein chip.

Vielen Danke im vorraus und ein gutes 2021.

Mfg,

Bert

[Bert (Gast)]

auf https://github.com/proddy/EMS-ESP/issues/456

lese ich:

both hardware can be connected in parallel to the same heater-Bus (EMSx 
or heatronic). They are using different device-ID's, so no 
traffic-collision is on the heater-bus.
EMS-ESP is using fixed device-ID: 0x0B (service-key).
ht_pitiny is using default device-ID: 0x0D (modem) but can be configured 
also to other once's if required.
I have checked this on my heater-system with EMS-ESP rev. 1.9.5 and 
ht_pitiny connected in parallel to the heater-bus.
The communication of them is done with MQTT for receiving decoded data 
and sending commands to the heater-system.
For the HA bindings on EMS-ESP see the wiki.
For that HT3/EMS pi_tiny-Adapter HA bindings are not yet available in 
the project, but I know some forum-members has already created that HA 
binding.
So, if you like you can run them in parallel on the same heater-bus.

und

the EMS-ESP can use a selection of deviceIDs. I'll close this now but 
feel free to re-open and share some feedback and how far you got.

Norbert sagt beide systemen können parallel arbeiten, aber kan den 
pi-tiny nur benutzt werden mit EMS-ESP durch den pi-tiny zu verbinden 
met ein EMS-ESP geflashte ESP8266 ?

von EMS-ESP site:

EMS Bus

    Tx Mode. 1 is default for EMS1.0 systems but also compatible with 
most other protocols. 2 is designed to work better for EMS2.0/EMS+ 
systems and 3 for Heatronics3 used by Junkers and Bosch. Choose the mode 
that works best for your system and watch for Tx errors in the Web 
Dashboard and show ems in the Console. Changing the value has immediate 
effect.
    Bus ID. The EMS-ESP can simulate one of 5 devices. Stick to the 
Service Key (0x0B) unless using multiple EMS gateways or interfaces.
    Rx GPIO pin - Which pin the Rx is assigned to. On an ESP8266 this 
has to be 3 or 13. The default is 13 (D7 on a Wemos). On an ESP32 it can 
be any pin.
    Tx GPIO pin - Which pin the Tx is assigned to. On an ESP8266 this 
has to be 1 or 15. The default is 15 (D8 on a Wemos). On an ESP32 it can 
be any pin.

Also EMS-ESP benutzt default 0x0B (service key) wie bus ID, vielleicht 
muss man diese dan auch änderen nach 0x0D (modem) wenn man ein ESP an 
pi-tiny verbind ?

[Norbert S. (junky-zs)]

Bert schrieb:
> Kann ich mit einem ht_pitiny (nur wie interface) auch einem ESP8266 chip
> dirext anschliesen und doch den EMS-ESP software nutzen ?
Ohne EMS-ESP Software-Anpassung geht dies nicht.

> Auf Seite 17 den Norbert HT3_Adaption.pdf sagt Norbert dan man die
> ht_pitiny auch ohne Raspberry Pi nutzen kann mit zb. ein USB adapter
> (nur 4 signale : RXD/TXD/GND/+3.3V)
> Kann ich zb. ein NodeMCU oder Wemos D1 ESP8266 chip direct anschliesen
> an diese 4 signale ?
> Also mein ESP8266 nimmt power (5V) über den USB port.
Ja, das geht mit jeder CPU die eine serielle Schnittstelle und 3.3V hat.
Allerdings fehlt dann noch die SPI-Schnittstelle, mit der man eine 
Software-Aktualisierung des ht_pitiny-Adapters machen kann. Da aber die 
Transceiver-Software bisher noch nicht geändert werden musste ist die 
nicht zwingend erforderlich.

> Wird das funzen ? :-)
Ja, nach Software-Anpassungen auf dem ESP8266.

> Wofür ist die ATiny441 chip dann eigentlich in den ht_pitiny ?
Auf dem ht_pitiny ist ein ATiny841 und kein ATiny441 (wegen der 
erforerlichen Flash-Groesse).
Die ht_pitiny- bzw. ht_piduino-Adapter machen 'nur' die wichtige 
serielle Telegramm-Anpassung zur korrekten 'Break'-Signal Erkennung bzw. 
Sendung.
Zusätzlich ist die 'galvanische Trennung' zwischen Heizung und RPi durch 
Optokoppler auf dem Adapter vorhanden.
Alle Heatronic-/EMS-Bussignale haben als Telegram-Endesignal das 
'Break'-Signal (>= 10 Bit low). Ohne diese Break-Signal-Generierung und 
-Erkennung kann keine korrekte Kommunikation auf den 
Heatronic-/EMS-Busleitungen erfolgen, da es dort keine Telegramme mit 
festen Längen gibt und auch nicht alle Telegramme ein CRC-Byte enthalten 
(Polling-Bytes z.B.).

> Also EMS-ESP benutzt default 0x0B (service key) wie bus ID, vielleicht
> muss man diese dan auch änderen nach 0x0D (modem) wenn man ein ESP an
> pi-tiny verbind ?
Nein, jede Device-/Bus-ID darf nur EINMAL am gleichen Heizungsbus 
vorhanden sein. Empfang der Heizungs-Daten ist mit jeder Device-ID 
möglich, Senden in den Heizungsbus mit den für diese Aufgabe 
vorgesehenen Device-ID's (0x0B:=service key; 0x0D:=Modem).
Gruß Norbert

[Peter (Gast)]

Hallo Norbert,
ich habe den HT_Pinity schon vor langer Zeit nachgebaut und er 
funktioniert auch gut. Musste jetzt den RPI3 neu installieren und wollte 
dann auch gleich MQTT konfigurieren.
Habe alles laut Anleitung installiert und konfiguriert. Wenn die Konfig 
auf ASYNC konfiguriert ist, werden die Graphiken erstellt. Wenn ich 
hingegen aus SOCKET umstelle (collgate._cfg.xml MQTT aktiviert; 
mqtt_client_cfg.xml broker konfiguriert) werden keine Graphiken erstellt 
und es wurden keine MQTT Daten an mein Homeassistant geschickt. Auf dem 
Homeassistant läuft das MQTT, da mein Shelly EM die aktuellen 
Verbrauchsdaten dort hin sendet.

Die ht3_db_cfg.xml schaut bei mir so aus:

    <data_interface>
      <comm_type>SOCKET</comm_type> <!-- communication-types are:
                                            ASYNC:=tty/comport; SOCKET:= 
socket-interface
                                            If daemon: 'ht_proxy' is 
used then <comm_type>SOCKET is required !
                                    -->
      <proto_type>RAW</proto_type>  <!-- protocoll-types     are:
                                            RAW:=transparent  ; TRX 
:=TBD (transceiver-messages with header) -->
      <parameter name="ASYNC">
        <serialdevice>/dev/serial0</serialdevice>
        <inputtestfilepath></inputtestfilepath>
        <baudrate>19200</baudrate>
        <config>"8N1"</config>  <!-- only 8N1 available -->
      </parameter>
      <parameter name="SOCKET">
        <proxy_config_file>./etc/config/ht_proxy_cfg.xml</proxy_config_file>
      </parameter>
    </data_interface>


Hast du vielleicht einen Tipp wo ich den Fehler suchen kann?

Grüße
Peter

[Norbert S. (junky-zs)]

Peter schrieb:
> Hast du vielleicht einen Tipp wo ich den Fehler suchen kann?
Wahrscheinlich in der Konfiguration.
Damit die SOCKET-Einstellung funktioniert muss der ht_proxy.server 
laufen und 'NUR' dieser bemuckelt die serielle Schnittstelle.
(Einstellungen im Konfigurations-File:./etc/config/ht_proxy_cfg.xml )

Die empfangenen Heizungsdaten werden dann an die verbundenen ht_clients 
verteilt. In diesem Fall ist der ht_collgate.py ein Socket-client des 
ht_proxy.servers (siehe Bilder).
Dies ist übrigens die Default-Konfiguration im Projekt (unter github zu 
finden).
Es muss u.U. nur die Baudrate je nach Type des serielle Adapters und der 
<serialdevice>-name angepasst werden.
File:./etc/config/ht_proxy_cfg.xml:

  <proxy_server>
    <serveraddress></serveraddress>
    <servername></servername>
    <portnumber>8088</portnumber>
    <logfilepath>./var/log/ht_proxy.log</logfilepath>
    <ht_transceiver_if devicename="RX">
      <parameter>
        <serialdevice>/dev/ttyAMA0</serialdevice>
        <baudrate>19200</baudrate>
        <config>"8N1"</config>  <!-- only 8N1 available -->
      </parameter>
      <devicetype>RX</devicetype>
    </ht_transceiver_if>
    <ht_transceiver_if devicename="MODEM">
      <parameter>
        <serialdevice>/dev/ttyAMA0</serialdevice>
        <baudrate>19200</baudrate>
        <config>"8N1"</config>  <!-- only 8N1 available -->
      </parameter>
      <devicetype>MODEM</devicetype>
      <deviceaddress_hex>0D</deviceaddress_hex> <!-- currently unused value -->
    </ht_transceiver_if>
  </proxy_server>

Details dazu sind in meiner Dokumentation ausführlich beschrieben.
PS:
Der ht_proxy.server muss laufen, wenn Du Deine Heizung mit dem 
ht_pitiny-Adapter steuern willst.
Gruß Norbert

[Peter (Gast)]

Hallo Norbert,
jetzt habe ich das Problem gefunden. Die Lösung war auf Seite 56 deiner 
Dokumentation. ;-) Musste bei der Proxy Config von /dev/ttyAMA0 auf 
deviceport="/dev/serial0 umstellen, jetzt funktioniert es einwandfrei. 
Habe alles einige male kontrolliert, aber diese Zeile habe ich nicht 
gesehen.

Hätte noch jetzt noch eine Frage frage zu MQTT, vielleicht kann mir ja 
jemand weiterhelfen.
MQTT läuft auf meinen Homeassistant, habe zwei Shelly's am laufen, die 
wurden automatische erkannt.
Wie kann ich den Pinity im Homeassistant konfigurieren? Muss das gesamte 
Konfigfile manuell erstellt werden? Hate jemand vielleicht ein Beispiel 
sodass ich sehe wie ich starten muss?
Möchte gerne alle Werte vom Pinity auslesen uns steuern.

Vielen Dank!!

Peter

[Norbert S. (junky-zs)]

Peter schrieb:
> Wie kann ich den Pinity im Homeassistant konfigurieren? Muss das gesamte
> Konfigfile manuell erstellt werden?
Hallo Peter, das TAR-File enthält einen MQTT-Konverter um die 
hometop_HT3-messages für den Homeassistant aufzubereiten.
Bitte das Tar-File in das Home-Verzeichnis des Pi-Users ablegen und 
entpacken mit:
 tar -xvf mqtt_ht2hassio.tar
Das Tool und das Konfiguration-File werden dann nach ~/HT3/sw und 
~/HT3/sw/etc/config geschrieben.
Wenn der MQTT-Broker ebenfalls auf dem gleichen RPi liegt, braucht das 
Konfigfile nicht angepasst zu werden.
Andernfalls muss die MQTT Broker-Serveradresse im Konfigfile: 
'mqtt_ht2hassio_cfg.xml' eingetragen werden.
Starten des Tools mit (Hintergrund-Prozess):
 cd ~/HT3/sw
 ./mqtt_ht2hassio.py &

Damit das MQTT-Discovery in Homeassistant gut funktioniert bitte das 
Konfigurationsfile des mqtt-clients anpassen, damit immer alle Log-Werte 
ausgegeben werden:
Konfigfile: ~/HT3/sw/etc/config/mqtt_client_cfg.xml
Anpassung : Publish_OnlyNewValues auf False

<mqtt_client>
 ....
 <Publish_OnlyNewValues>False</Publish_OnlyNewValues>

Nach der Anpassung den daemon 'ht_collgate.py' neu starten.

Die neu erkannten Parameter/Werte werden durch MQTT-Discovery 
automatisch in Homeassistant erkannt und unter 'Sensor' eingetragen.
Die einzelnen Parameter/Werte können dann einzelnen Bereichen in HA 
zugewiesen werden (siehe Beispiel-Bild)

Peter schrieb:
> Möchte gerne alle Werte vom Pinity auslesen uns steuern.
Auslesen der Werte ist mit diesem Tool möglich, steuern nicht.

Gruß Norbert

[Andreas (Gast)]

Danke Norbert!
Danach hatte ich schon gesucht :)

Funktioniert 1a

Falls jemand ein Autostart-Script benötigt, habe ich meins angehängt.
Habe ich mir bei Norbert geklaut und nur angepasst ;) Danke

Bitte nach
/etc/init.d kopieren
sudo chmod +x /etc/init.d/mqtt_ht2hassio
sudo systemctl enable mqtt_ht2hassio

Und schon bleibt es nach nem Neustart erhalten :)

Danke Norbert für deine Skills!

Ich hatte mir, zumindest die Außentemperatur so in HA geholt:

  - platform: mqtt
    state_topic: 'hometop/ht/ch_Toutside'
    name: 'Aussentemperatur'
    unit_of_measurement: '°C'

Andi

[Peter (Gast)]

VIELEN DANK für Eure Hilfe, werde heute Abend gleich probieren!!

[Andreas (Gast)]

Und hier auch noch meine schnell hingeschusterte Config:

  - title: Heizung und Solar
    path: heizung-und-solar
    badges: []
    cards:
      - entities:
          - entity: sensor.ch_tflow_measured
          - entity: sensor.ch_tflow_desired
          - entity: sensor.ch_pump_heating
          - entity: sensor.ch_burner_power
          - entity: sensor.ch_pump_heating_power
          - entity: sensor.ch_mode
          - entity: sensor.ch_burner_fan
          - entity: sensor.ch_burner_operation
          - entity: sensor.ch_thdrylic_switch
          - entity: sensor.ch_treturn
          - entity: sensor.ch_t3waymixer
          - entity: sensor.ch_causecode
          - entity: sensor.ch_errorcode
          - entity: sensor.ch_pump_circulation
          - entity: sensor.ch_pump_cylinder
          - entity: sensor.ch_runtime_ch
          - entity: sensor.ch_runtime_tot
          - entity: sensor.ch_starts_ch
          - entity: sensor.ch_runtime_tot
          - entity: sensor.ch_toutside
        title: Heizgerät
        type: entities
      - type: entities
        entities:
          - entity: sensor.hc1_tmeasured
          - entity: sensor.hc1_tflow_desired
          - entity: sensor.hc1_tdesired
          - entity: sensor.hc1_mixerposition
          - entity: sensor.hc1_tflow_mixer
          - entity: sensor.hc1_tniveau
          - entity: sensor.hc1_pump
          - entity: sensor.hc1_operationstatus
        title: Heizkreis
      - type: entities
        entities:
          - entity: sensor.sol_tcollector
          - entity: sensor.sol_tcylinder_bottom
          - entity: sensor.sol_yield_last_hour
          - entity: sensor.sol_yield_sum
          - entity: sensor.sol_pump
          - entity: sensor.sol_runtime
          - entity: sensor.sol_yield_last_day
          - entity: sensor.sol_buffer_full
          - entity: sensor.sol_collector_deactive
        title: Solar
      - type: entities
        entities:
          - entity: sensor.dhw_tcylinder
          - entity: sensor.dhw_tmeasured
          - entity: sensor.dhw_tok
          - entity: sensor.dhw_tdesired
          - entity: sensor.dhw_runtime_ch
          - entity: sensor.dhw_starts_ch
          - entity: sensor.dhw_charge_once
          - entity: sensor.dhw_thermal_desinfection
          - entity: sensor.dhw_generating
          - entity: sensor.dhw_boost_charge
        title: Warmwasser


Habe ich was vergessen? Bitte info

Danke

[Norbert S. (junky-zs)]

Andreas schrieb:
> Habe ich was vergessen? Bitte info
Sieht OK aus danke für die Arbeit, macht einiges einfacher bei der 
Konfiguration.
Allerdings müssen je nach Heizungssystem einige Werte aus der Liste 
entfernt oder hinzugefügt werden.
Einige Werte gibt es nicht in jedem Heizgerät z.B.: 
'sensor.ch_treturn':= Rücklauftemperatur oder 'sensor.ch_t3waymixer':= 
3Wege-Mischer Temperatur.
Auch gibt es Anlagen mit mehr als einem Heizkreis.
Dann ist Deine Liste halt entsprechend zu erweitern.

Noch eine wichtige Sache zu der 'InfluxDB' Datenbank in Homeassistant.

Diese Datenbank verwendet den Port 8086 als Default-Verbindung (siehe 
Bild).
Dieser Port wird z. Zeit jedoch vom httpd-daemon verwendet zur 
Kommunikation/Darstellung der rrdtool-Grafiken mit einem Browser.
Daher muss das Script 'httpd' auf eine andere Port-Nummer gesetzt 
werden.
Modul: ~/HT3/sw/etc/html/httpd.py
Anpassung: port# auf 48086 setzen

from http.server import HTTPServer, CGIHTTPRequestHandler
serveradresse =("", 48086)
server=HTTPServer(serveradresse, CGIHTTPRequestHandler)
server.serve_forever()

Aktionen:
Daemon stoppen und neu starten und die Browser-Abfragen mit der neuen 
Port-Nummer durchführen.
Gruß Norbert

[Markus L. (markus_l453)]

Guten Morgen,

ich bin über das tolle Projekt hier gestolpert und würde gerne an meine 
Junkers andocken.
Allerdings bin ich nicht so der Elektriker und daher etwas vorsichtig.

Ich bin über das HAT von Waveshare gestolpert.

Waveshare 2-Channel Isolated RS485 Expansion HAT for Raspberry Pi 
SC16IS752+SP3485 Solution with Multi Onboard Protection Circuits

Kann ich das hierfür verwenden?
Ich würde gerne einen Raspery PI Zero 2 verwenden und dann die Daten an
meinen IO Broker übergeben wollen.

Mfg.
Markus

[Josef (Gast)]

Hallo Markus,

ich hatte mich 2015 auch schon mal an dieses Projekt rangehängt.
Die Hardware hat mir dann aber auch zu schaffen gemacht.
Weiss nicht was du machen willst und inwieweit du dich schon mit 
ioBroker auskennst, aber wenn es darum geht Daten zu lesen, hast du mit 
deinem ioBroker nebst MBLAN schon alles was du brauchst.
Schau dir mal den KM200 Adapter an:
https://github.com/frankjoke/ioBroker.km200/blob/master/README.md
Läuft mit meiner Junkers seit Jahren Problemlos.
Gruß

[Norbert S. (junky-zs)]

Markus L. schrieb:
> Ich bin über das HAT von Waveshare gestolpert.
> Waveshare 2-Channel Isolated RS485 Expansion HAT for Raspberry Pi
> SC16IS752+SP3485 Solution with Multi Onboard Protection Circuits
>
> Kann ich das hierfür verwenden?
Nein, leider nicht. Auch nicht den Isolated RS232.
Dies liegt hauptsächlich an der nötigen Pegelanpassung auf der 
Empfangs-Seite und der Strom-Steuerung auf der Sende-Seite (in Richtung 
Heizungs-Bus).

Habe noch einen ht_pitiny-Adapter für den RPi falls Du kein MBlan2 hast.
Sende mir eine PM für weiteren IO.

Gruß Norbert

[Moritz M. (moritz2)]

Hallo zusammen,

ich habe eine Junkers Cerasmart ZSB 3-16 mit dem TA 211 E Steuermodul 
und auf der Suche nach einem Weg, den Gerätestatus zu protokollieren. 
Leider finde ich gar keine Informationen darüber, wo die Bus-Pins bei 
dem Gerät sind.

Hat da ggf. jemand ein Anschlusschema oder eine Info, welches 
Steuermodul dort nachgerüstet werden müsste?

Vielen Dank!

Moritz

[Norbert S. (junky-zs)]

Moritz M. schrieb:
> ich habe eine Junkers Cerasmart ZSB 3-16 mit dem TA 211 E Steuermodul.
> Hat da ggf. jemand ein Anschlusschema oder eine Info, welches
> Steuermodul dort nachgerüstet werden müsste?
Infos habe ich gefunden unter:
 https://manuall.de/junkers-ta-211-e-thermostat/
 https://www.manualslib.de/download/435629/Junkers-Zsb-3-16-A-21.html

Die Bedienungsanleitung ist von 2006 und Dein Gerät wahrscheinlich etwa 
eben so alt. Dort wird zwar von einer 'Heatronic' gesprochen, die jedoch 
wohl keinen Bus-Anschluss hat und eine analoge Steuerung ist.
Erst ab 'Heatronic3' (Ende 2008) sind die hier beschriebenen Soft- und 
Hardware-Schnittstellen nutzbar.
Ich kenne keinen Nachrüst-Set für deine Anlage um eine Bus-Anbindung zu 
erreichen.
Vielleicht hat jemand dazu noch weitere Infos?

Gruß Norbert

[Moritz M. (moritz2)]

Norbert S. schrieb:
> Die Bedienungsanleitung ist von 2006 und Dein Gerät wahrscheinlich etwa
> eben so alt. Dort wird zwar von einer 'Heatronic' gesprochen, die jedoch
> wohl keinen Bus-Anschluss hat und eine analoge Steuerung ist.
> Erst ab 'Heatronic3' (Ende 2008) sind die hier beschriebenen Soft- und
> Hardware-Schnittstellen nutzbar.

Jau, das scheint es zu sein.

Heatronic III: 
https://i.ebayimg.com/images/g/xDIAAOSwYrhhKSBm/s-l1600.jpg, erkennbar 
an SMD

Heatronic II: 
https://i.ebayimg.com/images/g/eD4AAOSwuMNd~Rh2/s-l1600.jpg, erkennbar 
an LED digit display.

Scheinbar gibt es für die Heatronic II einen CAN-BUS kompatiblen Regler 
(siehe 
https://wiki.volkszaehler.org/hardware/channels/heating_control/gastherme_junkers_can_bus, 
Beitrag "Junkers CAN-Bus Protokoll"), bedeutet dann aber wohl, 
dass auch nur die Reglerinformationen abgefragt werden können, und nicht 
der Brennerstatus oder ähnliches, und benötigt wohl ein extra Modul.

Ich schaue sonst mal mit nem einfachen Temperatursensor am Vorlauf und 
nem Strommessstecker ob ich einen ungefähren Status bekomme..

[Andreas (Gast)]

Hallo zusammen,
hat jemand von Euch noch eine Platine für den Raspi?

Ich habe den Thread durchgelesen verstehe es so, dass ich die Platine 
dann entsprechend der Pläne von Norbert auf GitHub bestücke und dann 
auch die Software von GitHub auf dem Raspi einrichte. Ist das richtig 
so?

Das ist echt ein tolles Projekt, vielen Dank! Bin mal gespannt, ob ich 
das hinbekomme. 😉

Viele Grüße!
Andreas

[Andreas L. (homeberg)]

Eine Zusatzfrage habe ich noch: Was ist einfacher umzusetzen? pitiny 
oder piduino?

[Peter (Gast)]

Hallo Moritz,

hier liegen deine Möglichkeiten -->
Beitrag "Junkers CAN-Bus Protokoll".

Aber Du benötigst mindestens noch den CAN-Bus Adapter BM1 bzw. evtl. das 
komplett Paket TA250 oder höher von Junkers. Die Schnittstelle HTII ist 
wesentlich einfacher zu handeln als III.

Über TA211 bekommst Du nur die Austemperatur bzw. die eigenen 
Einstellungen über eine sequentiellen Spannungs/Frequenzaustastung [VCO] 
über die beiden i2C-Anschlüsse.

Peter

[Michael G. (katzenschreck)]

Andreas schrieb:
> Hallo zusammen,
> hat jemand von Euch noch eine Platine für den Raspi?
>
>....
> Viele Grüße!
> Andreas

Hallo zusammen,
ich hätte noch eine unbestückte Platine für den piduino übrig.
Wer Interesse hat, einfach per Mail melden.

Ich würde sie für 3 Euro abgeben incl. Versand als Brief.

Frohe Ostern,
katzenschreck

[Markus B. (spektrum)]

Hallo,

da ich demnächst umziehe, habe ich einen bestückten und funktionsfähigen 
"ht_piduino" abzugeben, auf Wunsch auch mit einem Raspi incl. Netzteil 
und Gehäuse. Es handelt sich um einen Raspi Model B Rev 1, der lediglich 
als Proxy eingesetzt wurde. Dafür war er völlig ausreichend und hat 
bereits über Jahre einen treuen Dienst an einer Junkers Therme 
verrichtet. Lediglich die Fuses mussten einmal nachprogrammiert werden - 
warum auch immer.

Bei Interesse Nachricht per PN.

Grüße
Markus

[Tobias S. (herrgesangsverein)]

Hallo,
ich bin neu hier und stehe vor einem geradezu enzyklopädischen Thread.
Soweit ich verstanden habe, gibt es HW-Adapter, um den 2-Draht-Bus an 
einen Raspi anzuschließen. Dabei wird auch ein RS232-USB-Umsetzer 
verwendet.

Ich habe schon einen Nano-PI Neo im Einsatz, der noch einen freien UART 
und 5V hat, den ich gerne verwenden würde. Geht das? Wenn ja, welchen 
Adapter muss ich nehmen und wo muss ich abgreifen?
Ich gehe davon aus, dass die Python Software vom norberts1/hometop den 
Unterschied nicht merken würde?!

[Norbert S. (junky-zs)]

Tobias S. schrieb:
> Dabei wird auch ein RS232-USB-Umsetzer
> verwendet.
Ist nicht erforderlich.

> Geht das? Wenn ja, welchen Adapter muss ich nehmen und wo
> muss ich abgreifen?
Ja, geht wie folgt:
Nötige Verbindung zwischen ht_adapter und Nano-PI Neo

Funktion  Pin (ht_adpater)  Pin (Nano-PI Neo)
3.3 Volt    1               1 (SYS_3.3V)
UART TX    10 (TXD0)       10 (UART1_RX/GPIOG7)
UART RX     8 (RXD0)        8 (UART1_TX/GPIOG6)

Es sind für den Betrieb keine weiteren Verbindungen nötig.
Nur für einen Sw-Update der ht_pitiny-/ht_piduino-Adapter sind weitere 
Verbindungen erforderlich.
Ein Software-Update ist z.Zeit jedoch nicht vorgesehen.

Es können alle vorgestellten (passive-/aktive Adapter) mit dem Nano-PI 
Neo oder auch anderen Boards betrieben werden.
Erforderlich ist nur:
  Betriebsspannung 3.3 Volt
  UART-Anschlüsse müssen 3.3Volt tolerant sein.

Offensichtlich ist der GPIO des Nano-PI Neo pinkompatibel zum RaspPI.
Somit wird man wohl auch die hier vorgestellten ht_adapter direkt 
(gesteckt) an einem Nano-PI Neo betreiben können.
Allerdings habe ich keinen Nano-PI Neo und kann es somit nicht testen.

Die Projekt-Software von github/norberts1 wird auch funktionieren, da 
auf dem 'Nano-PI Neo' Board ubuntu-Linux eingesetzt wird und
ich das Projekt unter ubuntu auf meinem Laptop getestet habe.

Gruß Norbert

[Tobias S. (herrgesangsverein)]

Danke Norbert,
ich habe mich jetzt an die Schaltung anbei gehalten.
Ich muss eine eigene Leiterkarte machen, weil ich Sie zu einem NanoPI 
Gerät hinzufügen muss.

Dabei ist mir aufgefallen, dass diese ein AGND auf der Busseite und ein 
BGND auf der UART Seite hat. Wo schliesst man denn AGND an?

[Norbert S. (junky-zs)]

Tobias S. schrieb:
> Dabei ist mir aufgefallen, dass diese ein AGND auf der Busseite und ein
> BGND auf der UART Seite hat. Wo schliesst man denn AGND an?
AGND ist ja Teil des 2 Draht Heizungsbusses. AGND und BGND dürfen auf 
keinen Fall verbunden werden! Sonst ist die galvanische Trennung 
zwischen Heizungsbus und Datenerfassungseinheit (Adapter - CPU etc.) 
nicht mehr vorhanden.
2-Draht Heizungsbus-Anschluss wie folgt (für die ausgewählte Schaltung):
1. Pluspol des 2-Draht Busses an Pin1 Klemmenblock bzw Anode der Diode 
D1.
2. Minuspol des 2-Draht Busses an Pin2 bzw. AGND.
Polarität des 2-Draht Busses vorher ausmessen.

Wie gesagt, BGND wird nicht mit dem Heizungsbus verbunden, sondern ist 
ja die Betriebs-Masse Deines 'Nano-PI Neo' und bleibt durch den 
Optokoppler auch vom Heizungsbus galvanisch getrennt.

Gruß Norbert

[Markus B. (spektrum)]

Markus B. schrieb:
> Hallo,
>
> da ich demnächst umziehe, habe ich einen bestückten und funktionsfähigen
> "ht_piduino" abzugeben, auf Wunsch auch mit einem Raspi incl. Netzteil
> und Gehäuse. Es handelt sich um einen Raspi Model B Rev 1, der lediglich
> als Proxy eingesetzt wurde. Dafür war er völlig ausreichend und hat
> bereits über Jahre einen treuen Dienst an einer Junkers Therme
> verrichtet. Lediglich die Fuses mussten einmal nachprogrammiert werden -
> warum auch immer.
>
> Bei Interesse Nachricht per PN.
>
> Grüße
> Markus

Das Teil st nicht mehr da. Kann Beitrag leider nicht löschen. 
(Exception)

[Tobias S. (herrgesangsverein)]

Hallo Norbert,

ich kämpe noch. Ich habe jetzt die Schaltung umgesetzt und möchte sie 
testen. Ich verstehe Sie so: Unterhalb einer Schwellspannung sperren die 
Dioden und es fließt kein Strom. Der Optokoppler bleibt auf 0V, der 
Transistor sperrt, am "Ausgang" TX liegt HI an.
Wenn die Schwelle überschritten wird, fließt Strom durch die Diode am 
Optokoppler. Der Transistor schaltet durch und zieht den Ausgang auf Low

Nur: bei mir passiert das alles nicht. Schon auf der Eingangsseite: Ich 
habe ein Netzteil angeschlossen und die Spannung schrittweise erhöht. 
Ich erwarte, dass an irgendeinem Bauteil die Spannung abfällt, aber 
nicht am Optokoppler.
Ich messe überall nur mV.
Ich habe dann die Spannung bis auf 18V erhöht, das gleiche Bild.
An den äußersten Bauteilen (Kathode von BAT46 und vom H11L1) messe ich 
die Netzteilspannung.

Meine Fragen:
Wie prüfe ich die Schaltung?
Welche Schwellspannung ist vorgesehen (ich zähle ca. 
0,4V+9,1V+2V+0,7V=12,2V) ?
Was macht die Schottky-Diode da?

[Norbert S. (junky-zs)]

Tobias S. schrieb:
> Nur: bei mir passiert das alles nicht.
Nette kleine Platine.
Diode D1 ist offensichtlich falsch rum montiert. Kathode und Anode 
vertauscht.

> Meine Fragen:
> Wie prüfe ich die Schaltung?
Dazu bitte den zugehörigen Schaltplan posten.

Gruß Norbert

[Tobias S. (herrgesangsverein)]

Oh Mann, wie dumm! Wie kann man das übersehen. In der Tat habe ich im 
Schaltplan schon die Schottky-Diode falsch rum eingesetzt und nicht mehr 
verglichen. Ich bin nicht so der Analog-Elektroniker. Daher ist mir auch 
nicht klar, was die Schottky-Diode dort soll.

[Norbert S. (junky-zs)]

Tobias S. schrieb:
> Daher ist mir auch nicht klar, was die Schottky-Diode dort soll.
Die soll die Zenerdiode D2 und die LED D3 schützen falls man den 
Heizungsbus mit falscher Polarität anschließt. Eine Zenerdiode verhält 
sich ja wie eine Diode (0.6Volt Spannungsabfall,kein Zenereffekt) sobald 
man Plus an die Anode und Minus an die Kathode anschließt.
PS:
Widerstand R4 und LED D4 können entfallen bzw. brauchen nicht bestückt 
zu werden. Sind mal in der Entwicklungsphase als Indikatoren für die 
TX-Richtung  gedacht gewesen, sind aber überflüssig für die RX-Richtung.

Frage: Welches CAD-Programm hast Du für die PCB-Erstellung verwendet?

Gruß Norbert

[Tobias S. (herrgesangsverein)]

Ich benutze KiCAD 6.0. Passt für mich optimal.

Gegenfrage: Warum reicht denn nicht die LED gegen Verpolung. Die sperrt 
doch auch, oder?

[Norbert S. (junky-zs)]

Tobias S. schrieb:
> Gegenfrage: Warum reicht denn nicht die LED gegen Verpolung. Die sperrt
> doch auch, oder?
Die sperrt auch ja, aber nur bis zu einer Reverse-Spannung von ca. 5-6 
Volt.
Da jedoch auf dem Heizungsbus (Junkers/Bosch) bis zu 15Volt 
Gleichspannung liegen, wäre dies nicht gesund für die LED.
Gleiches gilt auch für den Optokoppler.

Gruß Norbert

[Renee (renee)]

Lieber Norbert S.,

ganz herzlichen Dank für Deine wunderbare Arbeit und den ausdauernden 
Support, den Du uns noch dazu gibst.

Ich habe eine Frage zum ht_transceiver-master: Kann ich den Empfangsweg 
betreiben ohne den Sender zu nutzen? Ich habe den HT_pitiny in Auszügen 
auf Lötpunktrasterkarte nachgebaut. Aber nur den Empfangsweg. Die 
Verriegelung mit HT Bus enable habe ich weggelassen. Programm und Fuses 
mit meinem alten JTAGICEmkII programmiert. Jetzt liefert der µC schön 
Daten mit 19200 ab, wie mein Terminalprogramm zeigt.

Bevor ich einen Computer bestimme, auf dem Deine Auswertung laufen soll, 
möchte ich fragen, ob es für das reine Mitlesen Nachteile hat, wenn der 
Sendeweg fehlt. Bekommt das HT_pityni Programm wichtige 
Initialisierungen vom
HT3 System?

Vielen Dank im voraus und nochmals großen Dank für die Arbeit!

Grüße, Renee

[Norbert S. (junky-zs)]

Renee schrieb:
> ...möchte ich fragen, ob es für das reine Mitlesen Nachteile hat, wenn der
> Sendeweg fehlt. Bekommt das HT_pityni Programm wichtige Initialisierungen
> vom HT3 System?
Nein, hat keine Nachteile. Die aktiven Adapter (ht_pitiny/ht_piduino) 
detektieren (RX) und generieren (TX) das Break-Signal und setzen die 
Kommunikation auf 19200Baud um, mehr nicht.
Es werden keine Daten von diesen aktiven Adaptern vom Heizungsbus 
angefordert. Der Heizungsbus selber generiert ohne Aufforderung die 
Telegramme, die nachgelagert ausgewertet werden.
Man kann zwar aktiv Daten vom Heizungsbus abfragen, dies habe ich jedoch 
vermieden damit der Betrieb auch mit den passiven Adaptern möglich ist.
Die Auswertung des Heizungsbus RX-Datenstroms erfolgt nur in der 
nachgelagerten Python-Software.
Dadurch sind auch mit der gleichen Software die passiven Adapter nutzbar 
(mit etwas eingeschränkter Break-Signal Detektionssicherheit).

Gruß Norbert

[Renee (renee)]

Danke Norbert. Alles klar!

Grüße, Renee

[Renee (renee)]

Hallo Norbert, hallo allerseits!

Nochmals ganz herzlichen Dank und weiter unten kommt noch eine Frage.

Seit gestern Abend läuft das System bei mir.

Hier arbeitet ein Junkers Cerapur Brennwertkessel mit einem eingebauten 
FW100. Es gibt einen Heizkreis und einen frei stehenden 
Warmwasserspeicher. Die Warmwasserbereitung wird im Sommer durch sechs 
Velux Flachkollektoren unterstützt. Die Solarthermie hat einen eigenen 
Regler und steht nicht unter Junkers Kontrolle.

Meine bisherige Hausdatenerfassung umfasst die Vor- und 
Rücklauftemperaturen von Heizung und Solar sowie die Temperaturen im 
Wasserkessel oben und unten. An den Wasser-, Gas- und 
Elektrizitätszählern habe ich Sensoren, die mir Impulse pro 
Verbrauchseinheit liefern. Ich zeichne mit ein paar Shellscripten auf 
einem kleinen Linux-Rechner auf. Die Temperatur- und Verbrauchskurven 
visualisiere ich mit gnuplot. Eine Webseite zeigt mir die Livewerte und 
ermöglicht die Anwahl der Grafiken.

Und jetzt kann ich dank Norbert besser nachvollziehen, was die 
Heizungssteuerung sich so "denkt". Gerade jetzt, wo wir Gas sparen 
möchten und unsere Heizkurven optimieren, empfinde ich das als sehr 
wertvoll. Wie schon geschrieben, habe ich den HT_pitiny abgewandelt 
(siehe Schaltplan) und betreibe ihn im Schaltschrank meiner Messtechnik. 
Die Auswertung läuft auf einem Raspberry Pi 3B, der schon da war und 
mein DNS-Filter (Pi-hole) hostet.

Das HT3 System ist jetzt die erste Nacht durchgelaufen und die Grafiken 
füllen sich langsam (siehe Bilder).

Und nun zu meiner Frage: Wie starte/nutze ich den HT3_Analyser oder 
HT3_Systemstatus?

Beste Grüße, Renee

[Norbert S. (junky-zs)]

Renee schrieb:
> Und nun zu meiner Frage: Wie starte/nutze ich den HT3_Analyser oder
> HT3_Systemstatus?
Startbeispiele:
1. auf RPi ins Verzeichnis ./HT3/sw und module: HT3_Analyser.py oder/und 
HT3_Systemstatus.py aufrufen/ausführen.
Können beide (wenn gewünscht) gleichzeitig laufen. Default-Konfiguration 
mit ht_proxy.py vorausgesetzt.
2. auf einem separaten Linux-Rechner mit der kompletten hometop_HT3 
Projektinstallation und der Anpassung des Moduls auf die RPi IP-Adresse: 
./HT3/sw/etc/config/ht_proxy_cfg.xml
  <proxy_client devicename="RX">
    <serveraddress>RPi IP-Adresse</serveraddress>
    <servername></servername>
    <portnumber>48088</portnumber>
    <logfilepath>./var/log/ht_client_rx.log</logfilepath>
    <devicetype>RX</devicetype>
  </proxy_client>

  <proxy_client devicename="MODEM">
    <serveraddress>RPi IP-Adresse</serveraddress>
    <servername></servername>
    <portnumber>48088</portnumber>
    <logfilepath>./var/log/ht_client_modem.log</logfilepath>
    <devicetype>MODEM</devicetype>
  </proxy_client>
</ht_proxy_cfg>
Die Heizungs RAW-Daten werden dann vom RPi über den dort laufenden 
ht_proxy.py an den/die verbundenen externen Linux-Rechner gesendet.
3. unter Windows und putty können auch alle python-Module (ohne GUI) 
ausgeführt werden.
z.B. Module:
  ht_binlogclient.py <<-- binäre Heizungsdaten-Aufzeichnung
  ht_netclient.py <<-- Steuerung der Heizung mit einem aktiven Adapter 
(ht_pitiny oder ht_piduino)

Nutzung:
Kontrolle und Anzeige der Heizungsdaten in Echtzeit.

> Wie schon geschrieben, habe ich den HT_pitiny abgewandelt (siehe Schaltplan)
Wozu hast Du den Spannungswandler LP2950-3.3 verwendet?
Der RaspberryPi hat ja schon 3.3Volt auf der Steckerleiste und der 
Optokoppler kann bis zu 3.0 Volt runter betrieben werden.

Gruß Norbert

[Renee (renee)]

Norbert S. schrieb:
> Wozu hast Du den Spannungswandler LP2950-3.3 verwendet?
> Der RaspberryPi hat ja schon 3.3Volt auf der Steckerleiste und der
> Optokoppler kann bis zu 3.0 Volt runter betrieben werden.

Ich wollte die 3.3 V vom Raspi nicht weiter belasten und 5 V habe ich da 
reichlich. Und meine pitiny Variante hängt an knapp 10 m Leitung. Da 
habe ich gerne einen Spannungsregler auf dem Board.

Ich bin übrigens über einen FTDI USB/Serial Wandler mit 3,3 V Logikpegel 
an den Raspi gegangen. Und der gibt mir auch gleich die +5V und GND 
raus.

Beim H11L1 werden mir die Kennlinien bei 3 V zu krumm. 5 V sind mir 
lieber. Vielleicht Geschmackssache :)

Danke für die Anleitung!

Grüße, Renee

[Max (Gast)]

Hallo.
Auf der Suche nach dem MB Lan2, der scheinbar ausgelaufen ist, bin ich 
auf diesen Beitrag gestoßen.
Leider bin ich nicht sehr bewandert im löten nach Schaltplan (und 
Linux).
Nach Anleitung arbeiten sollte ich aber irgendwie hinbekommen.
Wenn ich es richtig verstanden habe ist ht_pitiny der aktuellste 
Hardwarestand. Aber woher bekomme ich eine (vorbestückte?) Platine?
Ich bin entweder blind oder zu blöd die Quelle zu finden :)
Vielen Dank im voraus für Tipps oder Lösungen

[Philippe (Gast)]

Bitte nicht hauen... Bin auch nicht so der Harry Hirsch mit Platinen, 
aber weiß welches Ende vom Lötkolben heiß wird...

Hab jetzt die Heizung damit unter Kontrolle:

https://bbqkees-electronics.nl/?lang=de

Er hat auch noch ein kleines Modul wo man seriell ran gehen kann

[Philippe (Gast)]

Das hier meinte ich...

https://bbqkees-
electronics.nl/product/ems-schnittstelle-board-v3/?lang=de

[Michael W. (wemi2019)]

Hallo,
ich habe noch einen HT3-MiniAdapter kostenlos abzugeben. Der Adapter 
lief bei mir 4 Jahre problemlos an einer Junkers Gastherme. Da ich auf 
Wärmepumpe umgestellt habe, benötige ich den Adapter nicht mehr.
Bei Interesse bitte melden.
Gruß Michael

[Stefan B. (sbiermann)]

Hallo zusammen,
ich habe seit letzten Montag das Problem das ich nicht mehr über den 
Adapter (ht_pitiny) senden kann. Vorausgegangen war ein Stromausfall am 
Pi durch Stecker ziehen. Seit dem empfängt der Adapter alle Pakete und 
dekodiert die auch korrekt. Sprich das MQTT kommt mit validen Daten an, 
aber so bald ich ein Kommando senden will passiert nichts. Die grüne LED 
auf dem Adapter flackert im Tackt des HT Bus aber vor dem Stromausfall 
war immer mal wieder ein flackern von einer roten LED zu sehen. Was 
jetzt auch fehlt. Sprich die rote LED leuchtet nur noch wenn man den Pi 
aus schaltet und wieder einschaltet kurz auf.
An der Heizung selber habe ich den MB Lan Modus abgebrochen und auf das 
Automatik Programm geschaltet, damit die Heizung wieder funktioniert. 
Ich hätte erwartet das wenn ich neue Kommandos sende wie Heizung auf 
Frost oder so müsste sich die Anzeige wieder ändern und anzeigen das der 
MB Lan Modus aktiv ist. Das passiert aber leider nicht.
Weiß jemand woran das liegen kann?

Viele Grüße
Stefan

[Horst S. (h3aau)]

moin,
ich habe eine KSBR3-16 A leider ohne BM1.
hat schon wer einen ESp32 oder so als ersatz für die BM1 zusammen 
gezaubert?
ich würde meine anlage gern in hausnetz sehen können. steuern ist nicht 
nötig.

[Norbert S. (junky-zs)]

Stefan B. schrieb:
> Hallo zusammen,
> ich habe seit letzten Montag das Problem das ich nicht mehr über den
> Adapter (ht_pitiny) senden kann. Vorausgegangen war ein Stromausfall am
> Pi durch Stecker ziehen.
Die Fuses im ATtiny841 müssen korrekt eingestellt sein damit bei 
Unterschreiten/Ausfall der Betriebs-Spannung das EEPROM und das Flash 
nicht mehr beschrieben werden. Eventuell war dies der Grund bei dem 
ht_pitiny.

Die ht_transceiver-Software (Flash, EEPROM und Fuses) kann inzwischen 
per Script in die Boards geschrieben werden.
Dazu muss das Board auf dem RPi installiert sein, weitere Details sind 
im Projekt-Verzeichnis im Readme unter 'Sofware Installation' 
beschrieben.
URL:
https://github.com/norberts1/hometop_ht_transceiver

Gruß Norbert

[Andreas W. (urbansunited)]

Hallo,

ich möchte meinen ht_pitiny verkaufen.
Er wird bei mir nicht mehr benötigt und funktionierte bis zum Abbau 
einwandfrei.
Wenn jemand Interesse hat, ich schicke gerne Bilder von der voll 
bestückten Platine vorab zu.
Gerne höre ich auch Preisvorschläge, weil ich keine Idee habe, was man 
dafür verlangen kann.

Vielen Dank

Andi

[Bernhard D. (boots)]

Hallo, hier bin ich noch auf ein interressantes Board gestoßen, das 
Daten über MQTT an den IOBroker schicken kann. Ich werde es mir mal 
bestellen und berichten.
VG Bernhard

https://emsesp.github.io/docs/
https://www.ebay.de/itm/276135335043?itmmeta=01HR2F3YJ1M1VCVKPF7J9TH1Y1&hash=item404af2d483:g:MEsAAOSwCHNlyNEv&itmprp=enc%3AAQAIAAAAwERhqJvri5SGyJVr7T%2FnbTN4iwikTfU9%2FRiXSW1%2FfOYJBuFkrFjFhEhfjweOM80PZNNcMDomE5iaj9d2T7h6Vq%2B4gDMSJn5ukotWrzKS8keC5K8y%2FGgVyJRCeONE9GJkQKHF7PjtoUd2mpDHYGiqufNG1zYZNaxFqJ6uyT9MkAkjpWyIsLWY6%2BB9jdhDyByAX04U89pnxKv8m3nPgjciKR%2BllT5sgM%2FFieV2jNnROEsVcVp6UN8%2BPp7U%2FXKdrk0jMQ%3D%3D%7Ctkp%3ABk9SR4zpj8_AYw

[Matthias M. (tubercel)]

Teurer aber fix und fertig inkl. der o.g. Software.

https://bbqkees-electronics.nl/

hat ich hier mir mit einer Buderus GB172 / RC35 an fhem in Betrieb.
Funktioniert problemlos. HT3 wird auch unterstützt.

Direktes steuern des Kessels GB172 funktioniert auch prinzipiell,
man arbeitet dann aber gegen das RC35 Steuergerät.

Das RC35 kann man auch beschreiben, z.B. Heizkurve ...
Aber nicht vollständig (Zeitpläne).

Das wird bei allen Kessel / Steurgerät Kombis ähnlich sein.

[Bernhard D. (boots)]

Hi
bei bbqkees liege ich mit Versand auch bei 42€, also nicht so weit weg. 
Aber ja, teurer.
Hiermit sollte ich aber auch mein CW100 überschreiben können. Ich muß 
die Heizung meines WW-Kreislauf darüber abschalten, wenn meine 
Röhrenkollektoren liefern und das WW die gewünschte Temperatur noch 
nicht erreicht hat.
Das Teil soll morgen kommen, dann werde ich es mal anschließen :-)

[Martin S. (matz666)]

Hallo an die Community.

Ich hatte am Donnerstag Abend einen direkten Blitzschlag.

Teile meiner Anlage und ich schätze auch mein Adapter für den Raspberry 
hat der Tot ereilt. Die Anlage läuft teilweise wieder und auch die 
Raspberry Dienst, nur leider kein Output.

Hat jemand einen Adapter übrig (natürlich gegen Entgelt) mit dem ich 
meinen HT3 Busgeräte auch steuern kann. Wenn ja bitte ein PM.

Bitte um Rückmeldung.

Und Danke schonmal.

LG

Matz.

[Stefan S. (kami)]

Hi,

sehe ich das richtig, dass dieses Board eine Alternative zum Heatronic 3 
Adapter für Junkers Thermen sein kann? Ist der Funktionsumfang der 
gleich oder mehr oder weniger?

Wie sieht das mit dem HT3 Bus aus, kann man auch irgendwie den 
HT3-Adapter mit einem ESP32 und der EMS-ESP32 Software nutzen?

Danke.

Gruß kami

[Bernhard D. (boots)]

Hallo zusammen,

das Board läuft problemlos an dem Bus. Es gibt auch einen Menüpunkt am 
CW100, Heizungkreislauf ausschalten. Muß nochmal nachschauen, wie der 
genau heisst.
Das kann das Board überschreiben, leider gibts mit dem Verkäufer keine 
weiteren Infos. Aber die Werte werden über MQTT ausgelsen und an eine DB 
verschickt.
durch einen Unfall bin ich aber da nicht weiter gekommen.

VG Bernhard

[Stefan S. (kami)]

Hi Bernhard,

vielen Dank.Kann man denn damit mehr machen als mit dem HT3 Adapter von 
hier?

Gruß kami

[Norbert S. (junky-zs)]

Martin S. schrieb:
> Teile meiner Anlage und ich schätze auch mein Adapter für den Raspberry
> hat der Tot ereilt.
Ich glaube nicht das der Adapter defekt ist, ist ja auch galvanisch von 
der Heizung getrennt und deine Heizung läuft ja wohl auch noch.
Es ist wahrscheinlich der Inhalt des Adapter-EEPROM's beeinflusst bzw. 
gelöscht worden.
Dies lässt sich aber wieder durch eine Neuinstallation der 
Adapter-Software korrigieren.
Dazu bitte die Hinweise und das Script auf der Projektseite ausführen:
URL:
https://github.com/norberts1/hometop_ht_transceiver?tab=readme-ov-file#softwareinstallation
Script(e):
prepare_pitiny_board.sh für den ht_pitiny - Adapter
prepare_piduino_board.sh für den ht_piduino - Adapter

Gruß Norbert

[Stefan S. (kami)]

Hey Norbert,

kann man deine Adapter denn auch mit dem EMS-ESP32 Modulen nutzen?

Würde mich nur mal interessieren, wie das mit der Software im Vergleich 
aussieht? Also ist die Hardware kompatibel?

Danke.

Gruß kami

[Norbert S. (junky-zs)]

Stefan S. schrieb:
> kann man deine Adapter denn auch mit dem EMS-ESP32 Modulen nutzen?

Ja, kann man.
Einzige Bedingung: Die Adapter müssen unterschiedliche Bus-Adressen 
haben wenn sie am gleichen Heizungsbus werkeln.
Per default ist dies auch so eingestellt:
Adapter  | Bus-Adresse (dez.)
------------------------------
ht_pitiny | 13 (Modem)
ht_piduino| 13 (Modem)
EMS-ESP32 | 11 (service-key)
(siehe Bild)
Kommandos an den Heizungsbus sind parallel auch möglich, beeinflussen 
sich aber natürlich gegenseitig.
Da der EMS-ESP recht geschwätzig am Heizungsbus ist und die 
ht_transceiver von Haus aus nur zuhören, kannst Du dir ja denken wer 
gewinnt -> Szenen einer Ehe :-)

> Würde mich nur mal interessieren, wie das mit der Software im Vergleich
> aussieht? Also ist die Hardware kompatibel?
Die Software des EMS-ESP ist weiterentwickelt und unterstützt auch 
Wärmepumpen soweit diese am EMSx-Bus hängen. Es werden neben Junkers 
auch Buderus-Geräte untersützt.
Die Hardware ist aus Sicht des Heizungsbus natürlich identisch.
Die ht_transceiver sind jedoch galvanisch vom Heizungsbus getrennt und 
die Dekodierung und Steuerung erfolgt auf dem Host (RPi, PC...) unter 
Python.
Die Darstellung der Daten (Historie) erfolgt direkt mit der 
Projekt-Software, Schnittstellen zu MQTT, sqlite, SPS und rrdtool sind 
vorhanden.
Gruß Norbert

[Martin S. (matz666)]

Norbert S. schrieb:
> Ich glaube nicht das der Adapter defekt ist, ist ja auch galvanisch von
> der Heizung getrennt und deine Heizung läuft ja wohl auch noch.

Hallo Norbert.
Ja nach Austausch der Platine am Heizgerät, den beiden IPM1 Modulen dem 
ISM2 und dem FB100 läuft die Heizung wieder. (einzig das FW200 hat 
überlebt)

Daher habe ich die Vermutung das auch die galvanische Trennung nur den 
Raspberry gerettet hat und nicht den ht_piduino.

Werde heute am Abend den Bus trennen und versuchen den EEPROM neu zu 
beschreiben.

lg

Martin

[Stefan S. (kami)]

Hey Norbert,

danke für die schnelle Antwort. Zu deiner Antwort auf Frage 1 das habe 
ich wohl etwas missverständlich ausgedrückt, kann man deine Hardware 
auch mit dem EMS-ESP32 nutzen, also nicht beide Geräte an dem Bus 
sondern den EMS-Bus mit deiner Hardware an einen ESP32 anschliessen und 
dann EMS-ESP32 nutzen?

Oder muss man sich das EMS-ESP32 Module kaufen.

Würde halt gerne relativ günstig mal umstellen und testen was mir besser 
gefällt.

Kann man per EMS-ESP32 an einer Junkers Therme mit Warmwasserspeicher 
mehr an Statusmeldungen sehen oder mehr steuern?

Danke.

Gruß Stefan

[Norbert S. (junky-zs)]

Stefan S. schrieb:
> ..., also nicht beide Geräte an dem Bus
> sondern den EMS-Bus mit deiner Hardware an einen ESP32 anschliessen und
> dann EMS-ESP32 nutzen?
Willst Du einen ht_transceiver als Hardware-Schnittstelle zum 
Heizungs-Bus nutzen und durch ein ESP32-Modul mit der EMS-ESP32 Software 
darauf steuern?

Ohne Hardware- und Software-Anpassungen geht dies erst mal nicht.
1. Die Schnittstelle zum/vom ht_transceiver ist seriell und es werden 
die Daten mit einem eigenen Protokoll übertragen.
2. Das EMS-ESP32 Modul will eine Hardware-Verbindung zum seriellen 
Heizungs-Bus haben, da ein Handshake auf dem Heizungs-Bus bedient werden 
muss.

> Kann man per EMS-ESP32 an einer Junkers Therme mit Warmwasserspeicher
> mehr an Statusmeldungen sehen oder mehr steuern?
Ja

> Oder muss man sich das EMS-ESP32 Module kaufen.
Ja, wenn mehr dann mehr.

Gruß Norbert

[Martin S. (matz666)]

Norbert S. schrieb:
> Martin S. schrieb:
>> Teile meiner Anlage und ich schätze auch mein Adapter für den Raspberry
>> hat der Tot ereilt.
> Ich glaube nicht das der Adapter defekt ist, ist ja auch galvanisch von
> der Heizung getrennt und deine Heizung läuft ja wohl auch noch.
> Es ist wahrscheinlich der Inhalt des Adapter-EEPROM's beeinflusst bzw.
> gelöscht worden.
> Dies lässt sich aber wieder durch eine Neuinstallation der
> Adapter-Software korrigieren.
> Dazu bitte die Hinweise und das Script auf der Projektseite ausführen:
> URL:
> 
https://github.com/norberts1/hometop_ht_transceiver?tab=readme-ov-file#softwareinstallation
> Script(e):
> prepare_pitiny_board.sh für den ht_pitiny - Adapter
> prepare_piduino_board.sh für den ht_piduino - Adapter
>
> Gruß Norbert

Hallo Norbert.

Leider sieht es doch nach Tot des Adapters aus.

Hier der Output des Script.
3. Write programm to flash

avrdude: Version 7.3-20240615 (41781bdd)
         Copyright the AVRDUDE authors;
         see https://github.com/avrdudes/avrdude/blob/main/AUTHORS

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

         Using port            : /dev/parport0
         Using programmer      : linuxgpio
avrdude linuxgpio_sysfs_open() OS error: cannot export GPIO 8, already 
exported/busy?: Invalid argument
avrdude main() error: unable to open port /dev/parport0 for programmer 
linuxgpio

avrdude done.  Thank you.

  ------------------------------------------------------------------------ 
----------
  4. Write data to eeprom

avrdude: Version 7.3-20240615 (41781bdd)
         Copyright the AVRDUDE authors;
         see https://github.com/avrdudes/avrdude/blob/main/AUTHORS

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

         Using port            : /dev/parport0
         Using programmer      : linuxgpio
avrdude linuxgpio_sysfs_open() OS error: cannot export GPIO 8, already 
exported/busy?: Invalid argument
avrdude main() error: unable to open port /dev/parport0 for programmer 
linuxgpio

avrdude done.  Thank you.

preparing of 'ht_pitiny-board' done

[Stefan S. (kami)]

Hey Norbert,

danke für die Antwort, dann werde ich mal im Vergleich den EMS-ESP32 
probieren.

Danke und schönen Abend noch.

Gruß Stefan

[Norbert S. (junky-zs)]

Martin S. schrieb:
> avrdude main() error: unable to open port /dev/parport0 for programmer
> linuxgpio
Der Aufruf von linuxgpio und Nutzung des Ports zur Programmierung 
funktioniert nicht mehr. Deshalb kann auch der ht_transceiver nicht neu 
programmiert werden.
Es gibt wohl Änderungen/Probleme bei der Nutzung der RaspberryPI-GPIO's, 
siehe auch Meldungen: https://github.com/avrdudes/avrdude/issues/1708.
Muss ich mit meinem RPi4 und Adapter überprüfen.

Welche RPi-Version nutzt Du?

> Leider sieht es doch nach Tot des Adapters aus.
Dies glaube ich weiterhin nicht, aber dies hilft Dir auch wenig.
Schicke Dir eine PM, werden da eine Lösung finden.

Gruß Norbert

[Norbert S. (junky-zs)]

Martin S. schrieb:
> Leider sieht es doch nach Tot des Adapters aus.
Die Programmierung war nicht korrekt. Siehe folgenden Kommentar.
>
> Hier der Output des Script.
> 3. Write programm to flash
>
> avrdude: Version 7.3-20240615 (41781bdd)
>          Copyright the AVRDUDE authors;
>          see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
>
>          System wide configuration file is /usr/local/etc/avrdude.conf
>          User configuration file is root.avrduderc
>          User configuration file does not exist or is not a regular
> file, skipping
>          additional configuration file is RPi_gpio.conf
>
>          Using port            : /dev/parport0
>          Using programmer      : linuxgpio
> avrdude linuxgpio_sysfs_open() OS error: cannot export GPIO 8, already
> exported/busy?: Invalid argument
> avrdude main() error: unable to open port /dev/parport0 for programmer
> linuxgpio
>
> avrdude done.  Thank you.
> ....

Für die Programmierung der ht_transceiver mit dem RPi ist es zwingend 
erforderlich das SPI-Interface auf dem RPi zu deaktivieren.
Dies wird auch so im Installations-Script gefordert.
Die obige Meldung zeigt, das das SPI-Interface noch aktiv ist und 
deshalb der ht_transceiver nicht programiert werden konnte.
Siehe Bilder für die erforderlichen Aktionen.

Gruß Norbert

[Luca (olivluca)]

Hello Norbert, I like your interface more than the one of the ems-esp 
project because of the optocouplers.

I have no doubt that it works because there are many people using it, 
but I'd like to understand how it works, so I tried to simulate it with 
ltspice.

The receiving part is easy to understand (the output is 3,3V with 15V on 
the bus and 0V with 10V) what I cannot wrap my head around is the 
transmitter (probably because of my limited understanding of the bus).
I suppose that the bus, when idle, supplies 15V and the transmitter 
should pull it down to 10V, however by simulating the transmitter part 
in ltspice, I see that it only pulls it down to 14,2V.

I the simulation I omitted the optocoupler but I used a square wave of 
4,7V (the voltage of the zener used to supply the optocoupler in your 
circuit).

What am I doing wrong?

[Luca (olivluca)]

Luca schrieb:
> however by simulating the transmitter part
> in ltspice, I see that it only pulls it down to 14,2V.


Actually the swing is only 1,5mV...

[Norbert S. (junky-zs)]

Luca schrieb:
> What am I doing wrong?
Keep in mind: in transmit-direction the current-flow is important and 
not the voltage.
The internal resistance of "V2" is to low in your bus-simulation.

At least the heater-bus works for connected moduls as:
 - receiving with 15V...10V signalisation.
 - transmitting with 0... 15V/220 Ohm current.

The heater-bus control-logic translates the transmit-current to 
internaly voltage-signalling.
So "V2" in your simulation must have an additional serial resistor for 
the bus-simulation.

Regards Norbert

[Luca (olivluca)]

Norbert S. schrieb:

> So "V2" in your simulation must have an additional serial resistor for
> the bus-simulation.


Thank you for your fast reply!

I tried various values for the series resistance of V2 but I cannot find 
a suitable one:

 - with 10 Ohm its effect it's negligible both in voltage and current
 - with 100 Ohm the voltage goes from 11,6 to 9,9V, the current flowing 
into V2 from 28 to 42 mA
 - with 200 Ohm I get 7,8 to 10,8V and 32 to 19mA
 - with 500 Ohm I get 6,2 to 10,4V and 8 to 16mA

I don't know if any of those values sounds right.

I'd like to get the simulation working correctly so I can swap the 
optocouplers with different ones I have available and see if the 
waveform is still acceptable.

[Norbert S. (junky-zs)]

Luca schrieb:
> I'd like to get the simulation working correctly so I can swap the
> optocouplers with different ones I have available and see if the
> waveform is still acceptable.
I'm not sure you'll find that used optokopplers in LTspice.

It's better to compare the datasheets of that selected optokopplers I'll 
think.
Most important is the rise- and fall-time to get the best serial 
signalisation.

Regards Norbert

[Luca (olivluca)]

Oh, I found a model online for the H11L1, the optocoupler I have 
available has no schmitt trigger and even if it is slower it gave an 
apparently good enough result in the receiver, but I'd like to simulate 
the transmitter.

[Luca (olivluca)]

I came up with this circuit (I have some 4N25 around), do you think it 
could work?

[Luca (olivluca)]

Mmh, I put V1 on the bus side so I was losing the isolation provided by 
the opto.
This is a revised version with the transmitter and receiver.
What do you think?

[Norbert S. (junky-zs)]

Luca schrieb:
> This is a revised version with the transmitter and receiver.
> What do you think?
Your simulated 4N25 seems to be fast enough to do the job.
But there are some problems with that design:
1. Q1 is closed (default current-flow) if V2 is low or disconnected.
-->> No 'failsave' available and blocking the heater-bus on failures.
2. D6 not required, but use the resistor-value with higher value.
3. UART-signals from MCU have high-levels in idle-mode, so your design 
is wrong.
Please look at my design, strip it down and simulate this with the 4n25.

Regards Norbert

[Luca (olivluca)]

Hello,

thank you for your feedback, really appreciated.

Regarding 1., I didn't think of that, but since my bus is currently 
unused and I will only connect this interface, in turn permanently 
connected to an esp32 (so that V2, aka tx, will be idle high, 
phototransistor of U2 closed, Q1 open, bus high), I'm not sure it is a 
problem.

Regarding 2., good, I'll remove the zener and adjust the resistor.

Regarding 3., maybe the ltspice model I found of the H11L1 is wrong, but 
when I simulated your transmitter it gave me the same result as my 
circuit: tx high, (idle) green trace) -> bus high (blue trace), tx low 
(transmitting) -> bus low.
Same for the receive side: bus high -> rx high, bus low -> rx low.
Should they be inverted?

[Luca (olivluca)]

Latest iteration with the zener removed and changes in the simulation 
(V2 simulates the transmission for a short while and after that V4 
simulates the reception).

Edit: in the real circuit the GND in the middle won't be connected, but 
AFAIK in ltspice it's needed otherwise it cannot simulate the circuit.

[Luca (olivluca)]

This is my attempt to simulate your circuit.
As I said in my first message, the voltage swing is very low, but the 
current in the bus seems ok (70mA, not really sure it's actually ok).
But I see that it follows the input (input high -> optocoupler high -> 
bus high, input low -> optocopler low -> bus low).

[Richard (richard_p)]

Hallo,

verkaufe einen original ht_pitiny. Bei Interesse per Mail melden.

[Norbert S. (junky-zs)]

Luca schrieb:
> This is my attempt to simulate your circuit.
> As I said in my first message, the voltage swing is very low, but the
> current in the bus seems ok
Thanks for your simulations-attempts.
Keep in mind that this heater-bus has NOT a full-duplex communication.
You have to simulate that RX-direction and the TX-direction separately 
and not in one turn.

Regards Norbert

[Luca (olivluca)]

Norbert S. schrieb:
> Luca schrieb:
>> This is my attempt to simulate your circuit.
>> As I said in my first message, the voltage swing is very low, but the
>> current in the bus seems ok
> Thanks for your simulations-attempts.
> Keep in mind that this heater-bus has NOT a full-duplex communication.
> You have to simulate that RX-direction and the TX-direction separately
> and not in one turn.

Yes, that's what I did in htbus-transmitter-4n25.asc (*) (I first 
simulate a couple of pulses in the tx side, then, after a delay, a 
couple of pulses on the bus (to test the rx side).
In case of ht-transmitter-norbert.asc I only simulated the transmitter.

(*) It turns out that what I have available are 4n27 but the simulation 
doesn't change.

[Nils R. (augur)]

Hi,

mein FW200 ignoriert irgendwie die (automatische?) 
Sommer-/Winterzeitumstellung und verliert auf Dauer recht viel Zeit auch 
wenn der Heizungsbauer mal dran. Leider ist sind hat es mit 2 Stunden 
Verschiebung dann doch Auswirkung auf die Schaltprogramme...ist es 
theoretisch möglich die Zeit auszulesen (Monitoring) und von außen zu 
setzen (mit der öffentlichen Zeit über NTP) oder bietet der Bus das gar 
nicht?

Viele Grüße,
Nils

[Norbert S. (junky-zs)]

Nils R. schrieb:
> mein FW200 ignoriert irgendwie die (automatische?)
> Sommer-/Winterzeitumstellung und verliert auf Dauer recht viel Zeit auch
> wenn der Heizungsbauer mal dran. Leider ist sind hat es mit 2 Stunden
> Verschiebung dann doch Auswirkung auf die Schaltprogramme...
Hallo Niels,
die Zeit und Umschaltung lässt sich am FW200 einstellen, siehe Bild und 
Bedienungsanleitung.
Auch der Korrekturfaktor ist einstellbar.

> ist es theoretisch möglich die Zeit auszulesen (Monitoring)
Die Zeit wird ohnehin jede Minute vom Regler gesendet, dies sieht man im 
HT3_Analyser.
Allerdings wird diese nicht per MQTT-Meldung ausgegeben, habe bisher 
keine Notwendigkeit gesehen.

> und Zeit von außen zu
> setzen (mit der öffentlichen Zeit über NTP) oder bietet der Bus das gar
> nicht?
Muss ich klären.

Gruß Norbert

[Nils R. (augur)]

Das wäre toll, danke.

Die automatische Umschaltung ist aktiv macht aber nichts. Dort hatte 
mein Heizungsbauer schon bei Junkers nachgefragt, das Gerät war aber 
bereits aus der Garantie.

Bei dem Zeitverlust kommt es m.E. eher daher, wenn mein Heizungsbauer 
die Anlage stromlos macht. Aktuell habe ich 2 Stunden Zeitunterschied 
und mein Mieter hat sich beschwert. Ich habe dort die Herausforderung 
mit Hamburg das Mietobjekt und Rosenheim wohnhaft. Als ich selber noch 
oben gewohnt habe war das einfach, jetzt ist es ein wenig nervig. Wenn 
wäre eine sehr große Zeitkorrektur notwendig, ist aber schwierig zu 
analysieren.

[Norbert S. (junky-zs)]

Norbert S. schrieb:
>> und Zeit von außen zu
>> setzen (mit der öffentlichen Zeit über NTP) oder bietet der Bus das gar
>> nicht?
> Muss ich klären.
Hallo Nils,
habe einiges probiert um die Zeit des Reglers über Telegramme von Aussen 
zu verändern. Dies ist mir bisher nicht gelungen, habe zwar einen CW400 
in meinem Heizungssystem aber offensichtlich gibt es dieses Problem auch 
bei Fxyz Reglern von Junkers.
siehe dazu auch URL's:
https://github.com/emsesp/EMS-ESP32/issues/536
https://github.com/emsesp/EMS-ESP32/issues/666
https://github.com/emsesp/EMS-ESP32/issues/386

Habe mal Deine alten Log-Files mit dem Analyser auf die Uhrzeit 
kontrolliert (siehe Bild).
Bei dem markiertem Telegram Msg:6_0 (Systemzeit) ist:
 der Status(Byte11) = 0 und
 der RTC-Owner(Byte12) = 70hex.
Dies bedeutet: Uhrzeit nicht gültig und die Zeit kommt vom Heizgerät 
statt vom Regler.
Allerdings ist mir nicht bekannt wie man dieses ändern könnte, habe 
keine Infos darüber in den Installations-Anweisungen gefunden.
Systemuhrzeit kann man eigentlich nur am Regler Fxyz/Cxyz 
einstellen/konfigurieren.
Bei meinem System steht bei den Bytes:
 der Status(Byte11) = 1 und
 der RTC-Owner(Byte12) = 10hex <<-- Geräteadresse des Reglers.

Nils R. schrieb:
> Bei dem Zeitverlust kommt es m.E. eher daher, wenn mein Heizungsbauer
> die Anlage stromlos macht.
Die Regler haben keine Batterie aber eine Super-CAP. Die speichert die 
Daten und betreibt die Uhr für eine begrenzte Zeit.
Daher nehme ich an das diese Super-CAP defekt ist. Ein Tausch könnte das 
Problem vielleicht ja beseitigen.

Frage: Du hast ja noch ein MBLAN2 im Heizungssystem. Läßt sich damit die 
Systemzeit einstellen?

Gruß Norbert