Ein weiteres Projekt, welches ich mit der Homematic Haussteuerung realisiert habe, ist der Aufbau einer intelligenten Warmwasser Zirkulationspumpen-Steuerung.

Ich habe im Haus eine Vaillant Gas-Brennwerttherme verbaut. Da diese an eine Solaranlage mit Warmwasseraufbereitung und Heizungsunterstützung gekoppelt ist, kommt der Solarsystemregler auroMATIC 620/2 zum Einsatz. Nun ist mir beim studieren der Anleitung aufgefallen, dass diese bereits rudimentär eine intelligente Steuerung der Warmwasser Zirkulationspumpe auf Zeitbasis unterstützt, und somit die entsprechende Verkabelung vorhanden ist.

Man sieht deutlich die Verknüpfung des Schaltaktors mit dem auroMATIC Regler

Der weitere Schritt liegt nun eigentlich sehr nahe. Ich habe die Zirkulationspumpe von der Steuerung abgeklemmt und an einen Unterputz Schaltaktor des Homematic Systems angeschlossen. Desweiteren habe ich im Haus in jedem Zimmer, wo Warmwasser “gezogen” werden kann, den Innen-Bewegungsmelder von Homematic installiert. Sobald eine Bewegung erkannt wird, sendet der Bewegungsmelder eine Nachricht an die Homematic Zentrale, die wiederum die Warmwasser Zirkulationspumpe bei einschaltet. Damit ist schon ein wichtiger Meilenstein erreicht. Die Zirkulationspumpe läuft nur noch, wenn sich wirklich jemand in einem Raum mit Warmwasseranschluß befindet.

Das ganze kann jedoch noch optimiert werden. Nachdem die Zirkulationspumpe eine Zeit lange gelaufen ist, befindet sich ausreichend Warmwasser in der Z-Leitung und eigentlich müsste die Pumpe mehrere Minuten nicht mehr laufen. Im obigen Aufbau wird diese jedoch bei jeder Bewegung eingeschaltet. Hier kommt nun eine entsprechende Logik zum Einsatz.

Die Meldung eines Bewegungsmelders wird mit einem Programm auf der Zentrale gekoppelt welches:

• die Pumpe für 5 Minuten einschaltet (und danach wieder deaktiviert)
• eine Sperre für 45 Minuten definiert, in der die Pumpe nicht laufen soll

Das kann ganz einfach mit den Verzögerungsfunktionen der Homematic-Steuerung im Programmablauf realisiert werden. Es wird lediglich eine Systemvariable benötigt, die die Sperre global anzeigt.

Die Verknüpfung ist im Ablauf dann ganz einfach: Sobald die Variable Sperre WWZP auf TRUE steht, wird die Pumpe nicht eingeschaltet. Nach 45 Minuten wird die Variable automatisch vom System durch eine Verzögerungsfunktion auf FALSE gesetzt, und die Pumpe wird bei der nächsten BEWEGUNG ERKANNT Meldung eingeschaltet.

Die Werte von 5 Minuten Laufzeit und 45 Minuten Sperre sollten pro Haushalt überprüft werden, da man nicht pauschal sagen kann, wie lange das Warmwasser benötigt, um die Z-Leitung zu füllen (je nach Leitungslänge). Auch kann nicht pauschal definiert werden wie lange das Warmwasser wirklich “warm” in der Z-Leitung verbleibt. Das hängt von der Isolierung und der Gebäudedämmung ab. Mit den obigen Werten fahre ich in unserem KFW60 Haus sehr gut.

In meinem Fall habe ich 3 Bewegungsmelder über ein Programm mit dem Aktor verknüpft

Fazit:
Mit dieser Realisierung über das Homematic-System lässt sich über ein oder mehrer Jahre wirklich viel Geld sparen. Zirkulationspumpen und Z-Leitungen sind eine feine Sache. Jedoch sollte die Steuerung dahinter ein wenig intelligent sein um nicht sinnlose Laufzeiten zu haben und Energie zu verschwenden.

Siehe dazu auch: http://de.wikipedia.org/wiki/Zirkulationspumpe

Es hat ein weiterer sinnvoller Sensor der Homematic Haussteuerung Einzug gehalten. Der Tür- und Fensterkontakt Funk-Sensor ist vielseitig einsetzbar. Sei es zur Einbruchsüberwachung, für die Statusmeldung über offene Fenster/Türen oder als Sicherheit, daß der automatische Rolladenverschluß keine Person versehentlich ausschließt.

Herleitung:
Ich habe einen Programmablauf erstellt, der alle Rolläden zur Uhrzeit des Sonnenuntergangs automatisch herunterfährt. Nun kann es jedoch vorkommen, daß die Terrassentür offen steht, und eine Person sich außerhalb des Gebäudes befindet. Ein automatischer Verschluß des Rolladens wäre in diesem Fall nicht gewünscht. Nun habe ich den genannten Tür- und Fensterkontakt mit der Rolladensteuerung so kombiniert, daß vor dem Runterfahren der Jalousie der Status des Kontaktes überprüft wird. Sollte dieser “offen” melden, dann wird das Herunterfahren in diesem Moment für dieses Fenster verhindert. Das versehentliche “ausschließen” wird somit verhindert.

Der Tür- und Fensterkontakt wird am festen Rahmen und am beweglichen Teil des Fensters angebracht

Der Status einer Tür bzw. eines Fenster ist im Webinterface der Homematic CCU leicht erkennbar

Das erste Großprojekt mit der Homematic Funkbus-Lösung war die Einbindung der Rolladensteuerung. Gut, daß wir in der Hausbauphase tiefe Unterputzdosen verbaut haben. Somit war der nachträgliche Einbau der Funkaktoren ein Kinderspiel.

Die am Aktor angeschlossenen Taster schalten autark von der Homematic Basisstation. Daher ist eine manuelle und automatische Steuerung der Rolläden kein Problem.

Zu sehen ist die Unterputzdose mit dem hinzugefügten Aktor und dem herausgenommenen Taster

Die Steuerungs- und Statusoptionen der Rolläden werden im Webinterface sehr übersichtlich angezeigt

Schon sehr lange Zeit spiele ich mit dem Gedanken, viele Prozesse im Haus zu automatisieren. Daher habe ich mir ans Herz gefasst und das Projekt “Hausautomation” ins Leben gerufen.

Von Moeller, Merten und Co über EnOcean bis hin zur Homematic stehen viele Lösungen zum Thema Automatisierung parat.

Ich hatte ein paar Anforderungen, die vom System schon von Grund auf erfüllt werden sollten:

• Die Lösung sollte eine Basisstation mitbringen, damit ich auf den einsatz eines zusätzlichen Servers verzichten kann.
• Das System muß auf einem Funkbus basieren. Optional sollte auch eine Verdrahtung möglich sein.
• Verschlüsselt und ausfallsicher sollte die Protokollschicht des Busses in jedem Fall sein.
• Die Aktoren und Sensoren müssen sich in einem bezahlbaren Bereich bewegen.
• Eine bestehende Elektroinstallation muß durch die Komponenten des Systems einfach und schnell erweitert werden können.

Nach vielen Überlegungen und reichlichem hin und her ist die Entscheidung auf die Homematic von ELV gefallen. Alle oben genannten Anforderungen werden erfüllt, und auch das Bauchgefühl, welches zusätzlich sehr wichtig ist, stimmt.

Nach dem öffnen des Kartons begrüßte mich, in diesem Fall, eine weiße Homematic CCU Basisstation.

Natürlich konnte ich es kaum erwarten meine Finger an die Software der Station zu bekommen. Daher war es auch kein Wunder, daß die Basis im Handumdrehen in Betrieb genommen wurde. Alle Einstellungen können wirklich sehr komfortabel im Webinterface vorgenommen werden.

Homematic CCU – Systemsteuerung

Nachdem meine Grundkonfiguration stand, habe ich sicherheitshalber noch letzte Blicke in die Anleitung geworfen, ob nicht eventuell sicherheitsrelevante Einstellungen vergessen wurden. Das war nicht der Fall, und somit kann nun die Installation von Aktoren und Sensoren im Haus beginnen.

Bereits heute ist der Öffentlichkeit die lange Liste an potenziellen Toptiteln bekannt, die 2009 ausschließlich auf PS3 erscheinen sollen.
Um diese Toptitel einmal aufzuzeigen, hat eine niederländische PS3 Community aus dem bekannten Videomaterial dieser Games einen fast filmreifen Teaser erstellt.

  
Januar 2009

• 50 Cent: Blood on the Sand (23. Januar 2009)
• Skate 2 (23. Januar 2009)

Februar 2009

• Bolt (06. Februar 2009)
• Destroy all Humans (06. Februar 2009)
• X-Blades (06. Februar 2009)
• Bionic Commando Rearmed (13. Februar 2009)
• Eternal Sonata (13. Februar 2009)
• F.E.A.R. 2 (13. Februar 2009)
• SOCOM: Confrontation (13. Februar 2009)
• Street Fighter IV (20 Februar 2009)
• Wheelman (20. Februar 2009)
• Killzone 2 (27. Februar 2009)
• Silent Hill: Homecoming (27. Februar 2009)

Ich habe mich gestern intensiver mit unserer SAT-Anlage und einer folgenden Kanalsuche beschäftigt. Dabei bin ich auf ein Problem gestossen, welches ich im ersten Moment nicht erklären konnte.

Als Receiver stehen mir aktuell eine Dreambox 600 PVR und die Windows TV-Software DVBViewer zur Verfügung. Zuerst habe ich in der DVBViewer Software die DiSEqC-Einstellungen vorgenommen um 4 angepeilte Satelliten korrekt erreichen zu können. Durch rumprobieren und manuelle Kanalsuchen habe ich dann die entsprechend korrekten Einstellungen gefunden und eine Kanalsuche mit Erfolg durchlaufen lassen.

Da ich davon ausgegangen bin, dass die Optionen in der Dreambox identisch sein müssen, wurden diese folglich übernommen und eine Kanalsuche gestartet. Insgesamt wurden in dem Lauf ca. 30 Sender gefunden. Anscheinend gab es Probleme mit den Satelliten-Einstellungen der Dreambox.

Durch eine stundenlange Fehleranalyse hat sich dann ganz einfach herausgestellt, dass die
Zugriffe der beiden Receiver via DiSEqC unterschiedlich sind.

DVBViewer DiSEqC Einstellung

Dreambox DiSEqC Einstellungen

In der TV-Software DVBViewer ist z.B. die Benennung DiSEqC Position A / Option B anders zu verstehen als in der Dreambox. Genau genommen ist diese einfach komplett verdreht. DiSEqC Position A / Option B auf der Dreambox ist zum Beispiel DiSEqC Position B / Option A bei DVBViewer.

Jetzt stellt sich natürlich die Frage, wer von den beiden Receivern richtig liegt. Entweder liegt das Logikproblem bei der Dreambox oder bei der TV-Software DVBViewer. Zum Vergleich werde ich wohl noch einen anderen Receiver heranziehen müssen. Danach sollte der Übeltäter lokalisiert sein.

Auf ein Feature, was ich bisher nur von meinem alten Draytek-Router kannte, hat mich heute ein Kollege aufmerksam gemacht. Und zwar ist es das manuelle Einstellen von DSL-Modem Parametern der AVM Fritzbox.

Damit lässt sich entweder noch das ein oder andere Megabit an Leitungsreserve rauskitzeln oder man kann selbst bestehende Leitungsprobleme beheben.

Letzteres könnte beispielsweise angewendet werden, wenn oft Resync-Probleme auftreten oder sich das Modem mit dem DSLAM auf einen zu hohen Datenraten-Wert geeinigt hat und wiederholte Verbindungsabbrüche daraus resultieren.

Wenn man jetzt die Sync-Werte ein bißchen niedriger schraubt, werden damit schon die meisten Fehler behoben. Auch umgeht man natürlich das konsequente runterstufen der Leitungskapazitäten der Internetprovider bei nur “winzigen Problemchen“.

Aufgerufen werden die Einstellungen über folgende versteckte URL.

Dieses Feature wird bisher von folgenden AVM Fritzboxen angeboten: Fritzbox 7141, 7170 und 7270. Vielleicht bzw. eher hoffentlich wird es dieses auch noch für die 7050 geben, die ja bekanntlich einige DSL-Probleme mit sich bringt.

Ich war sehr überrascht zur Erfahren, dass aus meinen Recherchen ein Community-Projekt entstanden ist. Meine Empfehlungen wurden anscheinend erhört! :-)

Da nun auch die Fritzbox-Community einen Focus auf der internen Firewall hat, werden hoffentlich
in nächster Zeit viele neue Meilensteine erreicht werden. Mein Interesse an der professionellen Nutzung
der Fritzbox ist beispielsweise sehr groß, und ich denke, dass in der Box noch viel mehr drin steckt
als bisher herausgefunden wurde. Die Box ist mit entsprechenden Modifikationen selbstverständlich auch
im Businessumfeld (Officebetrieb) nutzbar.

Ich bin gespannt, was dieses erste Projekt, basierend auf der internen Firewall, zu Tage bringt. Auch soll die Dokumentation der Firewallregeln und Features weiter ergänzt werden.

Ich habe viel über Firewall-Projekte auf der Fritzbox gelesen. Im DS-MOD gibt es die Möglichkeit, iptables auf die Fritzbox zu bringen. Meiner Meinung nach macht das aber wenig sinn. Auf der Fritzbox befindet sich bereits eine, der Hardware entsprechend, leistungsfähige Firewall. Konfiguriert und administriert wird diese wie gewohnt über die ar7.cfg.

Vor der Konfiguration muss man sich klar machen, in welchem Modus die Fritzbox läuft. Es müssen nämlich unterschiedliche Bereiche in der ar7.cfg verändert werden. In der Sektion accesslist werden die entsprechenden Regeln definiert. Es gibt jeweils eine Sektion accesslist in den Kategorien pppoefw, dslifaces und dsldpconfig.

• pppoefw – Router läuft im PPPOE Mode (nur als Modem)
• dslifaces – Router läuft im Router-Mode (NAT-Funktionalität)
• dsldpconfig – Kann ich leider nicht sagen. Wer weiß mehr?

In meinem Beispielfall werde ich die Regeln im Bereich dslifaces betrachten und verändern. Für den Fall, dass die Firewall nicht nur als Modem sondern als Router fungiert, ist die Nutzung von diesem virtuellen Interfaceabschnitt zwingend notwendig.

Der Firewall-Regel-Syntax ist in allen Bereichen identisch. Als Beispiel könnte man folgendes Beispiel nehmen:

accesslist =
            /*####################
              ### Own FW-Rules         ###
              ####################*/

            /* Erlaube eingehend eine statische IP auf den SSH-Port des Routers */
            "permit tcp host 194.94.10.10 host 194.10.65.181 eq 22",

            /* Erlaube eingehend eine statische IP ins lokale Netz */
            "permit ip host 194.94.10.10 195.10.183.192 255.255.255.240",

            /* Erlaube eingehend Port 80 auf den Webserver im lokalen Netz */
            "permit tcp any host 195.10.183.206 eq 80",

            /* Stateful-Regel für die 2. WAN-IP */
            "permit ip host 194.10.65.181 any",
            "permit ip any host 194.10.65.181 connection outgoing-related",
            "reject ip any host 194.10.65.181",
            /* Stateful-Regeln für das lokale Netzwerk */
            "permit ip 195.10.183.192 255.255.255.240 any",
            "permit ip any 195.10.183.192 255.255.255.240 connection outgoing-related",
            "reject ip any 195.10.183.192 255.255.255.240",

            /*###################################
              ### Standard FRITZ!Box FW-Rules                  ###
              ###################################*/
            "deny ip any 242.0.0.0 255.0.0.0",
            "deny ip any host 255.255.255.255",
            "deny udp any any eq 135",
            "deny tcp any any eq 135",
            "deny udp any any range 137 139",
            "deny tcp any any range 137 139",
            "deny udp any any range 161 162",
            "deny udp any any eq 520",
            "deny udp any any eq 111",
            "deny udp any any eq 22289",
            "deny udp any any eq 1710",
            "deny udp any any eq 1048",
            "deny udp any any eq 158",
            "deny udp any any eq 515";

Der Aufbau der Regeln ist ganz einfach:

#Aktion# #Protokoll# #Quelle# #Ziel# #Zusätzliche parameter#

#Aktion#

• Permit – Erlaube eine Verbindung mit folgenden Parametern
• Deny – Lehne eine Verbindung mit folgenden Parametern ab
• Reject – Weise eine Verbindung mit folgenden Parametern zurück

#Protokoll#

• tcp – Diese Parameter definieren eine TCP-Verbindung
• udp – Diese Parameter definieren eine UDP-Verbindung
• icmp – Diese Parameter definieren eine ICMP-Verbindung
• ip – Diese Parameter definieren eine Verbindung mit allen Protokollen

#Quelle# oder #Ziel#

• any – Ist gleichzusetzen mit *. Definiert alle Hosts und Netze
• host [ip] – Nur diese IP / nur dieser Host
• [net] [subnetmask] – Definiert ein Netz mit der größe des angegebenen Subnetzes

#Parameter#

• eq [Port] – Regel zieht nur bei diesem port
• range [Startport] [Endport] – Es wird eine Portspanne definiert. Alle Ports innerhalb dieser Spanne sind von der Regel betroffen
• connection outgoing-related – Wirkt nur, wenn sich die Regel auf eine ausgehende Verbindung bezieht (Stateful)
• connection incoming-related – Wirkt nur, wenn sich die Regel auf eine eingehende Verbindung bezieht (Stateful)

Die Accessliste muss in den virtuellen Interface-Definitionen sowohl im lowinput als auch im highoutput Bereich eingetragen bzw. verändert werden.

Um die erstellen Regeln in den aktuellen Betrieb zu übernehmen, muß das Kommando ar7cfgchanged ausgeführt werden.

Hinweis: Jeder Tippfehler mit dem folgenden Kommando ar7cfgchanged wird mit einem vollständigen Konfigurations-Reset geahndet!

Ich habe schon lange Zeit den Wunsch, über die Fritzbox eine zusätzliche IP bzw. ein zusätzliches Netz neben der schon zugewiesenen dynamischen IP zu nutzen. Da ich bis dato keinen Erfolg bei Google und einschlägigen Foren hatte, habe ich mich also dran gesetzt und selbst nach einer Möglichkeit gesucht. Und siehe da, ich kann Euch heute mein Ergebnis vorstellen :-)

Um überhaupt eine Möglichkeit zu haben auf der Fritzbox modifikationen vernünftig durchführen zu können, muss die bereits vorhandene Firmware gegen eine sog. gemoddete ausgetauscht werden. Dazu eignet sich sehr gut das DS-MOD.
Nachdem dann das Image, wie in der obigen URL beschrieben, vorbereitet und installiert wurde, können wir mit meiner folgenden Lösung fortfahren.

Beschreibung eines Beispielszenarios

Ich werde in meinem Howto ein Szenario beschreiben, welches natürlich von Fall zu Fall verändert werden muss.
In meinem Beispiel gelten folgende Randparameter:

• Eine zusätzliche IP auf dem WAN-Interface welche als zusätzliche NAT-IP bereitgestellt wird
• Die zusätzliche IP soll nur zu fest definierten Hosts/Netzen für einen Client genattet werden
• Ein zusätzliches /28 Netz, welches auf dem WAN-Interface liegt, soll von entsprechenden Clients nativ genutzt werden

Technische Informationen

• LAN-IP der Fritzbox: 192.168.2.1
• WAN-IP: 194.10.65.181
• WAN-Netz: 195.10.183.192/28

Realisierung auf der Fritzbox

Zunächst loggen wir uns auf der Fritzbox via telnet oder ssh ein. Mit nvi editieren wir die Datei: /var/flash/ar7.cfg. In muss dann nach folgendem Eintrag gesucht werden: brinterfaces.
In den darunter liegenden Zeilen befindet sich der Eintrag: lan:0.

Unter diesen konfigurieren wir dann diese Einträge (Auf die geschweiften Klammern achten!):

  {
      name = "lan:1";
      dhcp = no;
      ipaddr = 192.168.178.1;
      netmask = 255.255.255.0;
      dstipaddr = 0.0.0.0;
      dhcpenabled = no;
      dhcpstart = 0.0.0.0;
      dhcpend = 0.0.0.0;
} {
      name = "lan:2";
      dhcp = no;
      ipaddr = 195.10.183.193;
      netmask = 255.255.255.240;
      dstipaddr = 0.0.0.0;
      dhcpenabled = no;
      dhcpstart = 0.0.0.0;
      dhcpend = 0.0.0.0;
}

Ich habe ein zusätzliches Interface mit einer 192.168.178.1 IP gewählt, da wir im späteren Verlauf Host/Netz abhängige Routen für das entsprechende NAT setzen wollen.

Nun suchen wir in der Datei den Kategoriepunkt dsldpconfig.
Hier gibt es dann eine weitere Sektion mit Namen: forwardrules. Entsprechend unserem Beispiel werden wir hier nun die zusätzliche NAT-IP und 2 IPS aus dem zusätzlichen Netz konfigurieren.

Das Resultat könnte dann wie folgt aussehen:

forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
                    "ip 194.10.65.181 192.168.178.2 0 # Zusätzliche NAT-WAN-IP",
                    "ip 195.10.183.195 195.10.183.195 0 # WAN Netz - 1. Host",
                    "ip 195.10.183.196 195.10.183.196 0 # WAN Netz - 2. Host";

Nach den Änderungen muss die Datei natürlich noch gespeichert werden. Anschliessend wird dann folgendes Kommando auf der Konsole abgesetzt: ar7cfgchanged. Es werden alle Änderungen neu geladen und aktiviert.

Client-Konfiguration mit zusätzlicher NAT-IP mit Host abhängiger Route

Auf diesem Client müssen 2 lokale IPs konfiguriert sein (z.B. 192.168.2.2 und 192.168.178.2). Das Default-Gateway wurde in der Netzwerkkonfiguration auf die 192.168.2.1 gesetzt. Die ganz normale Kommunikation geschieht im lokalen 192.168.2.0/24 Netz.
Nun möchten wir aber zu einem bestimmten Host mit der zusätzlichen NAT-IP (feste IP) connecten. Dazu muss lediglich eine Host-Route auf dem Client-System gesetzt werden.

Unter Windows würde das beispielsweise wie folgt aussehen:

route -p add 193.99.144.85 mask 255.255.255.255 192.168.178.1

• Das -p bewirkt einen Permanenteintrag.
• 193.99.144.85 ist in diesem Beispiel die IP von www.heise.de

Sobald der Client sich mit www.heise.de in Verbindung setzt, wird die Kommunikation nun im 192.168.178.0/24 Netz geführt, und somit die ausgehende Verbindung anders genattet.

Konfiguration von 2 Clients mit IPs aus dem zusätzlichen Netz

Diese Konfiguration ist am einfachsten. Es müssen lediglich die öffentlichen IPs auf der Netzwerkkarte konfiguriert werden, mit der entsprechenden öffentlichen IP auf der Fritzbox als Gateway.

Hinweis

Die obige Konfiguration basiert auf einem Beispiel und muss natürlich an die lokalen Gegebenheiten angepasst werden.