Cooperating radiator monitoring 114

Version vom 15. November 2012, 14:16 Uhr von Xoquox (Diskussion | Beiträge) (Nutzerverweis geändert)
Crystal Clear app error.png
C.R.M. 114

Status: unstable

HR20 Debugging.jpeg
Beschreibung Steuerung und Überwachung von HR20 Thermostaten per 1-Wire
Autor: xoQUox, schinken
Version 1
PayPal Spenden für Cooperating radiator monitoring 114

Beschreibung

Idee

Um die Heizkosten im Backspace zu minimieren, möchten wir unsere Heizungen zentral über einen einfachen Bus steuern. Zusätzlich sollen über diesen Bus noch weitere Temperaturfühler und Erweiterungen ausgelesen und gesteuert werden können.

Planung

Für die Realisierung versuchen wir die Heizungsthermostate per 1-Wire Bus steuerbar zu machen. Zusätzlich sollen an diesen Bus auch DS18S20 Temperaturfühler angebracht werden. (vgl. DS1820TOUSB)

Die Daten soll von einem 1-Wire Master gesteuert werden, der auch die Regelung der Thermostate, die Raumtemperaturüberwachung und ein Webinterface bereit stellt.

Arbeitsverteilung

Die integration der Busfunktionalität auf Softwareebene übernimmt xoQUox. Für die Entwicklung der Bedienebene und Steuerung ist schinken verantwortlich, dies wird auf Basis eines Raspberry Pi realisiert.

Honeywell HR20

Hardware

Das Honeywell HR20 ist ein gängiges µC gesteuertes Heizungsthermostat. Seine große Verbreitung und die Tatsache das es bereits einige Projekte für alternative Betriebssoftware gibt, bietet die ideale Grundlage.

  • 3 Tasten
  • 1 Stellrad mit Drehgeber.
  • LC-Display
  • Stellmotor für Heizungsventil
  • Prozessor: AVR ATmega169P
  • 10 Zugängliche Pins: JTAG, RX(PE0)/TX(PE1), 1 GPIO (PE2), VCC, GND

Es gibt von diesem Thermostat auch eine ältere Version die mit einem NEC µC arbeitet. Wir beziehen uns jedoch nur auf die aktuelle Variante mit dem AVR.

Open HR20

Die Software Open HR20 wurde von Dario Carluccio, Jiri Dobry und Thomas Vosshagen entwickelt. Diese Software ist ein funktioneller Nachbau der Original-Software und ist als GPL-2 lizensiert.

1-Wire

Software Vorlage

Als Vorlage für die 1-Wire implementierung verwenden wir "1-Wire Device mit AVR-Mikrocontroller" von Tobias Müller, veröffentlicht unter der GPL-3 Lizenz. Mit dieser Software ist es möglich, einen 1-Wire Slave rein in Software zu implementieren.


Umsetzung

Original Arbeit der 1-Wire Slave Quellcode mit dem INT0 des AVRs, dieser ist jedoch bei unserem ATMega169P schon als Line für das Display des HR20 in Verwendung. Als Alternative verwenden wir den PCINT2 der glücklicherweise an die externe Pinleiste geführt wurde. Die Pin Change Interrupts der ATMegas sind jedoch viel simpler aufgebaut als der externe Interrupt INTx . Es können nur Logikänderungen am Pin, nicht aber welche Flanke, erkannt werden. Außerdem teilen sich 8 Pins je einen PC Interrupt. Beim Aufruf des Interrupts muss also noch eine abfrage auf den richtigen Pin und seinem Zustandswechsel erfolgen um die Flankenfunktionalität nachzubilden.

Proof of concept

Wie oben beschrieben haben wir beim HR20 nicht den für die 1-Wire integration benötigten INT0 frei. Des weiteren wird auch der 8-Bit Timer (Timer0) bereits in der Open HR20 Software verwendet. Da wir diese so gut wie Unverändert lassen wollen, ist es nötig den externen Interrupt auf den bereits beschriebenen PCINT2 zu legen und auch der Timer Overflow muss von Timer0 auf den 16-Bit Timer1 umziehen. Um dies zu Testen wurde das Projekt OW_Simple gestartet. Dabei handelt es sich um die 1-Wire Slave Vorlage mit allen Änderungen für den ATmega169P des HR20 sowie den Anpassungen der Interrupts. Ziel ist es die 1-Wire Funktionalität als Standalone Software auf dem HR20 zum laufen zu bekommen.

Probleme

Flankenerkennung schlägt fehl

Um eine Flankenerkennung für einen Pin Change Interrupt am ATMega zu realisieren, muss man sich den letzten Pin-Zustand merken und beim erneuten Aufruf der Interrupt-Funktion mit dem aktuellen Zustand vergleichen. Nun hat man jedoch das Problem, das alle Interrupts des AVRs gleich priorisiert sind und sich nicht gegenseitig unterbrechen dürfen. Fällt ein Interrupt während der Laufzeit eines anderen an, so wird erst nach Beendigung des aktuellen der neue ausgeführt. Dabei stellt sich jedoch das Problem, das sich in dieser Zeit der Zustand des Pins schon geändert haben kann.

Wir haben keine Möglichkeit bei diesem Typ den Zustand zum Zeitpunkt des Logikwechsels am Pin festzustellen. Dadurch kann es dazu kommen, das wir zwar einen Pinchange-Interrupt bekommen, aber bei der Ausführung die händische Detektion der Flanke fehlschlägt. Wir bekommen nicht alle Bits vom Master mit und kommen aus den Takt.

Änderung des Timings

Erste Versuche die "Wartezeiten" des Timerinterrupts gezielt zu verkürzen zeigten erste Postive Ergebnisse. Die Anzahl der verschluckten Pinchange-Interrupts wurden weniger. Die genauere Analyse ergab jedoch auch, wie gut auf dem Bild rechts zu sehen, das unser Slave die Leitung zu spät auf Low zieht um eine Logische 1 auf den Bus zu schreiben. Und zwar erst wenn die Flanke wieder am steigen ist. Dies kann man gut auf dem Bild rechts an den kurzen Spitzen beim 10 und 13 Bit des unteren Graphen erkennen.

Die Zeiten des Timers sind fest in der 1-Wire Software vorgegeben. Per Defines können diese zwar verändert werden, sind aber zur Laufzeit fest im Programm. Es könnte also sein das die Software nicht immer mit jedem 1-Wire Master vom Timing her zusammenarbeiten kann und erst die passente Werte Messtechnisch oder durch Versuche ermittelt werden müssten.

Interrupts werden Ignoriert

Beim weiterführenden Debuggen stellten wir einige Unstimmigkeiten in der Software Vorlage fest. Die Bits wurden nach erster Analyse invertiert auf den Bus geschrieben, was zu einer Unstimmigkeit mit dem Master führte. Auch an einer anderen Stelle war eine Abfrage auf den Logischen Zustand des Pins falsch. Nach einer Korrektur war das Ergebnis wie im linken Bild zu sehen. Unsere Bits (x) und Komplement-Bits (Cx) werden korrekt gesendet und vom Master bestätigt (Ax). Dies geht hier für genau 4 Bits (12 Flanken am Bus) richtig. Dann verpassen wir eine Flanke (X) und kommen mit unseren Interrupt erst zum darauf folgenden. Dies verschiebt die Kommunikation, der Master stellt einen Fehler (E) fest und löst einen Reset aus.

Dies kommt vermutlich von einer unsauberen erkennung am PCint. Dieser Löst wohl im Logikübergang ab und zu falsch aus, wenn der Pin noch keinen festen zustand hat. Bei Tests war hier innerhalb weniger Takte ein Zustandswechsel zu beobachten.

Lösungsansätze

Da wir gern unabhängig von der Geschwindigkeit des Masters sein möchten und vor allem Sicherstellen wollen, das die Slave Software auch Fehlerfrei mit anderen 1-Wire Mastern zusammen arbeiten kann, ist eine dynamische Anpassung der Zeitintervalle zur Laufzeit nötig.

Raspberry Pi

Software

1-Wire

Als 1-Wire Master wird das OWFS 1-Wire File System verwendet.

Weblinks