mikrolinux

Moin! da der Sensor sozusagen gar nix misst.... Auf dem eigentlichenSensorbaustein ist möglicherweise noch ein Schutzaufkleber. Ist der runter?

Hallo Jan, vielen Dank für deine Erklärungen. Ich glaube, ich habe jetzt kapiert worum es geht. Bis jetzt habe ich da echt auf dem Schlauch gestanden. Ich werde versuchen deinen Code in mein Proggi einzubauen. Bis denne Andreas

Hi AuronX, Ich packe einfach mal ein kurzes Stück Code hier hin .... $ipcon = new IPConnection(); // Verbindung aufbauen // -------- try { $ipcon->enumerate(); // Devices auflisten } catch ( Exception $e ) { sleep(10); goto connect; } $did = BrickletLCD20x4::DEVICE_IDENTIFIER ; echo $did; // -------- Danach weiß ich immerhin, dass ich ein Gerät mit der ID 212 angeschlossen habe. Nur brauche ich irgendwie den Weg zur uid. Mein Gerätchen besteht aus einem RasPi, einem Master und einem 20x4 LCD. Das Ganze fragt meinen Solaranlagen-Logger (ein SolarLog) zyklisch ab und schreibt die aktuellen Verbrauchs- und Ertragswerte aufs Display So sieht man bei meiner Eigenverbrauchsanlage auf einen Blick wann es sich lohnt den Geschirrspüler oder die Waschmaschine einzuschalten. Ich will eigentlich dahin, dass jeder sich das Dingelchen nachbauen kann, mein Image auf die SD packt und sich der Nachbau das LCD selbst initialisiert und dann seine Werte aufs Display schreibt. Die ersten 2 Minuten lang schreibt der Raspi seine Ip aufs Display (das ist der link zur Config-Website), danach wechselt das Display auf die Details. Das rennt soweit alles gut, nur das einmalige automatische Ermitteln der Display-UID kriege ich nicht hin. Das muss ja eigentlich nur beim allerersten Einschalten laufen und die ID ins Configfile schreiben, oder vielleicht später mal, wenn das Display ersetzt werden muss. Ansonsten bin ich auch an der Konfigurationswebsite, wo man die IP des Loggers eingibt und ob es einen Verbrauchszähler gibt. Wenn ja, kann ich ein Delta ermitteln und auch aufs Display schreiben ob ich einspeise, beziehe und wieviel. So'n Logger hängt ja gewöhnlich im Keller und da sieht man ein ggfls. vorhandenes Display ja nicht. Meine Bastelei steht irgendwo in der Wohnung rum und man sieht im Vorbeigehen was die Photovoltaik sagt, ohne erst Tablet oder PC anwerfen zu müssen. Nur so zum Hintergrund, auch wenn das nichts mit der Programmierung zu tun hat

Eine ganz blöde Frage, ich weiss.. Also, ich habe einen Master mit LCD-Bricklet dran. Wenn ich die Bricklet-ID in meinem Code angebe kann ich auch ganz einwandfrei meine Ausgaben machen. Was ist aber wenn ich die ID nicht kenne? Wie frage ich in PHP die ID eines angeschlossenen Bricklets ab? Ich würde das gerne so machen, dass ich eine Kleine Schleife in meinem Ini-Prozess machen, die mir die ID ermittelt und ich die dann im Folgecode verwenden kann. Ich habe im Code zur Wetterstation zwar die Enumerate()-Funktion gefunden, aber ich kann das Ganze irgendwie nicht anwenden, will heissen, ich kriege es einfach nicht auf die Kette ... User zu blöd Error

Misst man die Ladung des Akkus nicht eher zw. Regler und Akku und nicht wie Du angegeben hast zw. Panel und Regler ? Moin! Sorry, da war ich nicht präzise ;-) Mit Ladung meinte ich den Ladestrom der vom Panel kommt. Der und die Panelspannung variieren ja je nach Sonneneinstrahlung. Da ist es auch spannend zu Wissen was vom Panel zum Regler fliesst und was anschliessend davon vom Regler wieder in den Akku wandert.

Moin! Ich bastele zwischendrin an einer ähnlichen Geschichte. Ich habe ein Standard-Solarpanel mit 150W und einen Steca PR1515 Laderegler, der eine 80Ah Starterbatterie lädt. Das Bricklet habe ich zwischen Panel und Laderegler gesetzt. Vom Modul kommen Spannungen von ca. 20V bis ca. 35V, der Strom liegt dabei bei so über den Daumen 5A. Das verkraftet das Bricklet ganz gut. Der Laderegler pegelt Strom und Spannung auf akkuverträgliche Werte runter, sprich eben 13,1 - 13,5V. An den Akku habe ich einen AEG Spannungswandler angeschlossen, der wieder 220V für 'normale' Geräte draus macht. Da der Wandler bis zu 500W Geräte versorgen kann (gibt auf weit stärkere) dürfte bei größeren Lasten das Bricklet das Zeitliche segnen, wenn man aber nur einen Switch oder kleineren Rechner etc. versorgen möchte, ist alles ok. Je nach Position des Bricklets (zwischen Panel und Regler oder zwischen Akku und Verbraucher) misst man entweder die Ladung oder die Entladung. Das Integral über die Zeit ist dann die jeweilig geflossene Ladungsmenge. 'Richtig' oder 'falsch' gibt es da m.E. nicht, hängt halt davon ab was man wissen will ;-) Den Ladezustand des Akkus im Betrieb zu messen ist etwas kniffelig, wenn es in Ruhe (also ohne Ladung oder Verbrauch) gemessen wird, bekommt man 2,05V je Zelle, also bei einer Starterbatterie 6 x 2,05V bei voller Ladung, unter ca 11V sollte man nicht gehen, da das irreversible Reaktionen gibt und den Akku schädigt, weil Bleiakkus eben keine Tiefentladungen mögen. Bei einer Abschaltung bei 11,5V ist alles ok - m.M.n.

Moin! Also bei mir ist das eher kunterbunt. Im Job habe ich Win7 auf dem Desktop und administriere damit Linux und HP-UX-Cluster. Zuhause benutze ich fast ausschliesslich MacOS, habe aber meine Web- und Raumsteuerkistchen als Linux-VMs auf einem Mac mini mit Parallels laufen. Nebenher bastele ich noch an einem Raumsteuerserver als Raspi (wheezy). Am WE kommt noch ein Ubuntu dazu, weil ich mir OpenStack mal näher ansehen möchte, allerdings nicht virtualisiert. Ne Sun Netra X1 habe ich auch noch zum spielen (billig ergattert) und jeweils einen G4 und einen G5 (DualCore) Mac habe ich auch noch. Das ist aber eher mein persönliches Rechnermuseum ;-) TF-Komponenten steuere ich ausschliesslich von einer openSUSE-VM aus oder von einem RasPi.

Hi! Ich hätte mich gern mit meiner Haussteuerung beteiligt, aber ich habe jobmässig zu viel dazwischen bekommen. So war der Aufwand leider zu groß und ich bin nicht soweit gekommen, wie ich wollte. So ist es noch nicht vorzeigbar. Die Hintergrund-Jobs funktionieren, die Heizungen werden geregelt, Steckdosen sind schaltbar, auch Jalousien kriege ich rauf und runter. Allerdings fehlen noch Zeitplankontrollen und auch die meisten Konfigurations-Screens. Dafür kann ich Steckdosen abhängig von der Leistung der Photovoltaik schalten lassen. Der Server auf RasPi-Basis ist auch weitgehend fertig und das Konzept für die einzelnen Controller ebenfalls. Allerdings muss ich mir für Hutschienenmodule noch was einfallen lassen. Mühsam nährt sich das Eichhörnchen Als Parallelprojekt werde ich noch eine kleine Photovoltaik-Insel-Steuerung bauen und die - sofern sinnvoll möglich - in die Haussteuerung mit einbauen. Insgesamt muss ich da noch gewaltig Arbeit reinstecken. Aber es macht Spass

Ich fände das absolut klasse! Im klux-Bereich würde das meiner Haussteuerung helfen (Jalousiesteuerung) und nachts könnte ich dann im mlux die Himmelshelligkeit messen. Die Himmelshelligkeit zusammen mit der Bewölkungsmessung wäre dann ein prima Alarmgeber für z.B. die Astrofotografie. Man sieht auf einen Blick ob es sich lohnt das ganze Gerödel auf den Acker zu schaffen

Moin! 'ne Nacht drüber schlafen war gut Ich habe das Ganze jetzt positiv formuliert und schon gings. Der Code ist jetzt total simpel // versuche das Bricklet zu verbinden ... try { $ipcon->connect($host, $port) ; } catch ( Exception $e ) { // Fehlermeldungen vorbereiten etc ... } ; Da ich ein ganzes Rudel Sensoren/Stacks abfrage, mache ich hier keine Schleife und einen neuen Versuch, sondern gebe einfach einen Fehler aus und weiter zum nächsten

Hi! Ich stelle gerade auf das neue Protokoll um. Bisher funzt das auch problemlos, nur beim Abfangen der Fehler tu ich mich iwie schwer. Ich denke die richtige Stelle ist der Connect zum Stack (Master, WLAN, Temperature und Dual Relay). Abfangen will ich den Fall, dass der Server nicht zum Stack verbinden kann. // versuche das Bricklet zu verbinden ... try { if ( !($ipcon->connect($host, $port) ) ) { throw new Exception( ); } } catch ( Exception $e ) { // tu irgendwas ... // Fehlermeldungen vorbereiten z.B. ... } ; Wenn ich das so baue und zu einem Bricklet verbinden will läuft der Code immer durchs catch. Mit dem alten Protokoll lief das prima, da hatte ich es so gebaut: try { if ( !($ipcon = new IPConnection($host, $port) ) ) { throw new Exception(); } } catch ( Exception $e ) { // tu was }; Hat jemand 'ne Idee?

Yepp, schaut gut aus Genauso habe ich es auch gemacht. Am besten testest du einfach mit einer Lampe und schaltest das Ganze vom brickv aus. Wenn das funzt, kannst du mit dem Programmieren loslegen!

Besser nicht Mit dem Relais schaltest du ja 220V Wechselstrom, der Master hätte aber gern 5V Gleichstrom. Wenn du über die Stepdown Power Supply gehst, hätte die auch gern Gleichstrom zwischen 5 und 25V (so etwa)

Hallo allerseits! Ich habe momentan ein etwas lästiges Problem. Nach einem Access-Point Neustart melden sich die Stacks nicht wieder an und sind damit nicht mehr erreichbar ... hmmm Nach einem Reset am Master sind sie dann aber wieder problemlos erreichbar. Die Stacks haben eine feste IP, der Router ist ein Asus RT N56U, Firmware 3.0.0.4.318 vom Dezember '12. Sollten sich die Extensions nicht automatisch wieder zurück melden? Lokal über USB sind die Stacks problemlos weiter abfragbar, sie melden sich also einfach nur nicht wieder im WLAN zurück. Reagieren die WiFi Extension so mimosig auf WLAN-Wackler oder habe ich einfach nur (wäre nicht das erste Mal) eine Einstellung übersehen? Nicht dass ich ständig den AP neu boote, aber als es heute mal sein mußte fiel mir das auf - und es ist wiederholbar Bei einem Apple Airport Express zeigt sich das selbe Phänomen...

Hallo Stefan und ein herzliches Willkommen im Forum! Mit deinen Ideen liegst du schon mal genau richtig. Wenn du nur den Master-Brick und das Dual-Ralay verwenden willst, dann brauchst du einen Rechner (den RasPi z.B.) Der liefert über USB Strom und Kommunikation. Um ihn ansprechen zu können muss natürlich auch der brickd laufen (siehe Dokumentation auf Tinkerforge.com) Alternativ geht natürlich auch Master mit WiFi Extension und das Dual-Relay. Dann läuft auf dem Master/WiFi ein brickd und du brauchst den RasPi nicht. Strom bekommt das Ganze dann aus einem USB-Netzteil. Die Steckdose an das Relais anzuschliessen ist kein Hexenwerk. Solange du nur reinen Experimentalbetrieb machst, brauchst du auch kein Gehäuse. Anders sieht es aus, wenn bei dir Kinder oder Tiere an die Kabel gelangen können. Dann solltest du alle 200V führenden Stellen schützen, es sei denn du möchtest sie rösten Aber zum Anschluss. Nimm dir eine 3-fach Stekdose und entferne an einer Stelle im Kabel die Isolierung. Du wirst auf drei Adern stoßen, meist Blau, Schwarz und gelb/grün. Letzteres ist der Schutzleiter, erste sind die stromführenden Phasen. Davon trennst du eine auf und setzt lüsterklemmen auf die Enden. Die verlängerst du und schliesst sie an A1 und SQ1 des Dual-Relais an. Dann ist default stromlos (Kontakt ist auf B1 geschaltet) und wenn du schaltest geht das Relais auf A1 und schließt den Stromkreis, woraufhin der angeschlossene Verbraucher loslegen kann. Die 10A solltest du aber vielleicht nicht gleich ausnutzen Eine kleine Anmerkung noch, das Dual-Relay verbraucht relativ viel Strom. Wenn du auf den Gedanken kommst und noch das 20x4 Display zu verwenden um den Status anzuzeigen solltest du ein nicht zu schwachbrüstiges USB-Netzteil verwenden. Das gint entweder für den RasPi mit Micro-USB oder für die Kombi Master/WiFi mit USB-Netzteil. Have Fun! Andreas Edith sagt: 'Immer diese Tipperfeller!'

Hi! Ich bastele seit etwa einem 3/4 Jahr mit schwankendem Einsatz an einer solchen Lösung. Dher würde ich aus meiner Warte aktuell sagen: Ja, es macht Sinn bei der Hausautomation mit Tinkerforge Bausteinen zu arbeiten, aber nicht immer und überall. Schau dir auf alle Fälle noch die alternativen System wie 1Wire, KNX, ZigBee etc. an und entscheide dann, was für was das für dich richtige ist. Vielleicht ein paar Beispiele: Heizungsmonitoring Was treiben die Heizkreisvor- und Rückläufe, was macht der Kessel, kommt Wäre von der Solarthermie, was macht die Luftfeuchtigkeit mit den Pellets ... Das habe ich aus verschiedenen Gründen mit 1Wire aufgebaut. Die Sensore sind kleiner (sie müssen unter die Rohrisolierungen gesteckt werden können), billiger (unter 2€ pro Sensor), größere Leitungslängen und eine billige 3-Draht-Verkabelung -> 1Wire Sensoren mit owfs eingebunden (Dallas USB-Dongle) und mit Perl programmiert Kellermonitoring Wir haben ab und an Wasser im Keller und ich fände es doof, wenn mir das die Pellets aufweicht. Ausserdem ist das eine Sauerei, trotz Fliesen. Ich habe also einen Wassermelder via 1Wire angebunden (gibt es vergossen) und die Fühler an die 'Eintrittsstelle gelegt. Dazu gibt es dann noch einen Hutschienen Stromschalter, der auch per 1Wire geschaltet werden kann. Am Stromkreis hängt eine Saugpumpe, die ich fest installiert habe. Im Hintergrund rennt ein kleines Perlproggi, das den Wassermelder alle 15s abfragt und wenn der sagt: 'Iiiih, nasse Füsse!' schaltet der Rechner die Pumpe ein und versucht den Keller leer zu machen. Hat er auch schon mal artig gemacht, als wir nicht zuhause waren. Hat mir 'ne Fuhre Holzpellets gerettet. Raumsteuerung 1Wire hat seine unstrittigen Vorteile, aber was ist mit den Ecken, wo man nicht aufwendig verkablen kann, wo auch mal Sensoren zum Einsatz kommen sollen, die man nicht an jeder Ecke findet (Luftfeuchte, Luftdruck, Relaisschaltungen etc. Hier hat das Bricksystem seine Vorteile. Es gibt die WiFi-Anbindung, es gibt ein sehr breites Spektrum an Sensoren und alles lässt sich homogen abfragen, bei mir so erst mal in PHP. Aktuell habe ich die Raum-Temperatur-Regelung funktional fertig. Ein Raumsensor besteht in Grunde aus einem Master, einer WiFi-Extension, einem Temperatursensor und einem Dual-Relais und einem Gira 112200 (?) Heizkörperthermostaten. Ein PHP proggi rennt alle 5 Minuten durch alle Sensoren und gleicht die Solltemperatur aus dem Raumprofil mit der Ist-Temperatur ab. Zu kalt? Heizkörper auf, zu warm? Heizkörper zu. Insgesamt steuere ich so 5 Räume. Funzt jetzt seit ein paar Wochen ohne Probleme. Ich mache mir über Weihnachten mal Gedanken, in welche Gehäuse ich das packe, meine Frau ist zwar sehr tolerant, meint aber die Bricks seien im Wohnzimmer nicht soooo dekorativ ;-) Ausblick: Rollo-Steuerung (ein passender Antrieb liegt im Kofferraum) und Schaltuhr, schliesslich hat das DualRelais zwei Relais eingebaut, warum nicht nutzen. Wetterstation Temeratur, Luftdruck, Helligkeit bis Bewölkung ist da alles drin. Auch hier ein kleines PHP, dass seine Daten ins RRDTool schreibt und schon gibt es nette Verlaufsgraphen. Anahand der Helligkeit will ich die Rollos steuern ... Ganz weit am Horizont .... Auswertung der PV (wenn e.on denn endlich den Zähler gegen einen Zweiwege-Zähler tauscht ...) und Auswertung der zur Verfügung stehenden selbst erzeugten Strommenge. Mal sehen, was der Wechselrichter so hergibt. Anhand dessen will ich größere Verbraucher (Waschmaschiene, Spülmaschiene ... ) einschalten wenn wir genug produzieren. Hier würde ich wieder die vorgeschlagene Variante der indierekten Schltung bevorzugen. Größere Verbraucher sind da nicht ohne. Die Version mit den Industrials gefällt mir schon ganz gut, aber die schon im Keller verbaute Variante mit 1Wire auf Hutschiene ist auch seit fast einem Jahr zuverlässig dabei. Mal sehen ... Es gibt also immer schön mehrere Wege nach Rom, ein intensiver Vergleich lohnt sich allemal, aber die TF-Bausteine haben sich bisher als zuverlässig und gut programmierbar erwiesen.

@AuronX: Nein, ich dachte eigentlich umgekehrt Mein Proggi läuft zyklisch, gestartet durch cron. Es grast dann seine Liste von Stacks ab und steuert an, was es erreichen kann, was nicht da ist (die besagten abgeschmierten WiFi-Stacks) wird einfach übersprungen. Das Problem ist also mitten im Stack, bzw. Master-WiFi. Es scheint dabei ja so zu sein, dass der komplette IP-Stack darniederliegt und sich nicht mehr melden kann. Interessant wäre ein Watchdog auf dem Stack, der z.B. ein Ping auf eine frei wählbare IP (z.B. den Raumsteuerungs-Server) macht und den Stack resettet, wenn er sie nicht mehr erreicht. Edit: Mir ist gestern noch aufgefallen, dass der Stack, der am häufigsten ausfiel noch mit der Master-FW 1.4.0 lief, alle anderen recht stabil mit 1.4.6. Ich habe ihn dann erst mal 'nach-geflasht'. Jedenfalls ist jetzt alles homogen auf dem selben Stand.

Da müsste ich warten bis wieder einer 'kippt', das kann ein paar Tage dauern... Wenn ich das PHP-Skript manüle starte, zeigt er mir in solchen Fällen einen Fehler im Tinkerforge IP-Connection-Skript, Zeile 281 mit dem Fehler 'No route to host', was mir den Verdacht nahelegt, dass der IP-Stack im BrickD des Stacks platt ist und nicht mehr reagiert, oder?

Hmmh, da schlägt dann gnadenlos zu, dass ich geradeso die ersten ein, zwei Schritte im PHP hinter mich gebracht habe und mich freue, dass es überhaupt geht Ich habe da momentan noch ein ganz einfaches Weltbild: Linux sagt dem brickd was er tun soll. Die Themen Callback und Objektorientierung im PHP kamen da bisher noch nicht vor Der Stack steht ja irgendwo im Haus und wird per WiFi angesteuert. Wenn der sich jetzt irgendwann in die Reaktionslosigkeit verabschiedet, kann ich ihm ja nicht mehr sagen, dass er reset() ausführen soll, also muss ich es irgendwie hinkriegen dass er das selber tut. Nur wie? Da fehlt mir einfach der Background ... Für Ideen (lies mal hier, lies mal da ...) wäre ich echt dankbar!

Äh ja, dann weiss ich zwar, dass der Controller irgendwann weg ist, aber was fange ich damit an? Dass der Stack nicht erreichbar ist bekomme ich mit, da ich alle Stacks zyklisch abfrage und ansteuere. Ich muss ihn ja automatisch wieder ans Laufen kriegen, sonst wird es entweder brühwarm oder eisekalt, oder Licht/Fernsehher, jehen nicht mehr aus oder irgendwann die Rollos nicht rauf oder runter. Die automatisierte Initialisierung bei Fehlern ist mein eigentliches Problem. Edit: Blödsinn geschrieben, ich muss da noch watt mehr lesen

Ein 'Raumsteuer-Controller' ist bei mir modular. Minimum ist es ein Master mit WiFi-Extension mit einem Temperatur-Bricklet für reine Messung. Allerdings habe ich die Räume bisher immer auch mit einem zusätzlichen Dual-Relay-Bricklet zur Steuerung der Heizkörper versehen. Weiterhin kann es noch ein Display oder weitere Dual-Relays geben. Der Durchlauf ist so, dass aus der Device-Tabelle die ID-s und IPs etc gelesen werden. Steht was sinnvolles drin, ist das entsprechende Bricklet angesteuert, bei "000" ist es nicht vorhanden. Damit ist dann die Konfig für den Raum klar und es geht weiter mit der Modus-Ermittlung (Arbeitswoche/Wochenende/Sonderzeitplan/Übersteuert/Lüften). Anhand von Modus und Zeit ergibt sich die Solltemperatur aus dem jeweiligen Profil für den jeweiligen Raum. Mit der Solltemperatur renne ich in die Steuerung und baue die Verbindung auf, lese die Status fer Bricklets aus und daraus ergibt sich wie es weiter geht -> Heizungsventil auf/zu, Steckdose gemäss Schaltwunsch an/aus ... Ich denke ich versuche mal die Geschichte mit try und catch auf die Bricklets auszudehnen. Es kann ja auch sein, dass man sich beim Konfigurieren der Controller vertippert. Dann hätte ich den Fall, dass die IP-Connection aufgebaut werden kann, das Bricklet aber nicht zugefügt werden kann. Dann hätte ich gerne eine Meldung der Art 'xxx-Sensor für den Raum yyy nicht erreichbar. Bitte Konfiguration und Hardware prüfen' oder so ähnlich auf der Website stehen und einen Log-Eintrag. Die Geschichte mit dem Watchdog kann ich schätzungsweise so nicht anwenden, da der brickd auf dem Master/WiFi läuft, der ja nicht mehr erreichbar ist... Da habe ich aktuell echt keine Idee

Hi! Ich habe's am WE dann doch noch raus gekriegt. Ich hatte ja schon den Ansatz mit try und catch, den AuronX ja auch bestätigt hatte.Nach etwas fummeln ( = beseitigen von Verständnisproblemen und Tipperfehlern) läuft es jetzt ... // Wenn die IP-Connection nicht hergestellt werden kann, Fehler ausgeben try { if ( !($ipcon = new IPConnection($host, $port) ) ) // Create IP connection to brickd { throw new Exception( "brickd im Netz nicht erreichbar" ); } } catch ( Exception $e ) { $error = "Controller nicht im Netzwerk erreichbar!"; goto ende; }; Die Fehlerbehandlung habe ich zur Vereinfachung auf das Setzen einer Fehlervariablen und den Sprung zu einer Endemarke gesetzt. In meinem Raumsteuer-PHP kommt da dann entsprechender Ausgabe-Code für die Site, bzw. überspringt es das Ansteuern der nicht erreichbaren Bricklets/Aktoren. Der Ansatz ist das Herstellen einer IP-Connection, wie sie sich in den PHP-Beispiel-Skripten findet. So kann man es hier rauskopieren und in die Samples einfügen. Kann es auch den Fall geben, dass einzelne Bricklets an einem Brick nicht erreichbar sind, während andere funktionieren? Oder ist das einer der ganz unwahrscheinlichen Fehler? Jetzt muss mir nur noch was zum Thema Watchdog einfallen

Moin! Das ist richtig, die Dinger sind digital Das macht aber nix, weil so ein Raum unheimlich träge ist. Eine Einstellmöglichkeit im 1/2-Stunden-Takt ist absolut ausreichend und ich komme so ungefähr auf 5 Ein-/Ausschaltvorgänge am Tag - maximal. Bei einer guten Dämmung verliert ein Raum pro halbe Stunde ungefähr ein halbes Grad und sentsprechend brauchst du auch um wieder nachzuheizen. So gesehen ist diese 'Digitaltiät' absolut nicht kritisch. Die Giras sind übrigens nicht zu hören, das Einzige, was ich mitkriege ist das Klicken der Relais in den Bricklets.

Hi! Ich habe ein ähnliches Projekt, nur anders angefangen Die Heizungsregelung habe ich mittlerweile in PHP zusammengezimmert. Da du die Temperatur ja schon misst, kannst du über das DualRelais die Heizungsventile steuern. Die Gira 112200 funzen gut. Das ist die 220V Version, die kann man direkt steuern. Es gibt noch eine 24V-Version, aber dir lohnt sich m.E. nur, wenn man eh schon auf ein bestehendes System aufsetzt. Was du dann aber auf alle Fälle brauchst, sind Temperaturprofile für jeden Raum (Arbeitswoche, Wochenende, Sonderzeitplan für Urlaub etc.) und die Möglichkeit die zu üb ersteuern, Marke mir ist kalt, ich will warm! Ansosnsten ist ein Checkmark im Webinterface (oder Taste am Display) für Lüften notwendig. Du könntest die Ventile dann entweder für z.B. 20 Minuten zufahren oder auf den nächsten Tastendruck warten. Bei zu viel Lüften Frostschutzsicherung nicht vergessen (z.B. bei Temps unter 5°C wieder auffahren). Da ist jedenfalls derzeit mein Stand Beim Lüften bin ich gerade ;-) Rollos sind das Folgeprojekt. Ich habe in meinem Bewölkungssensor einen Helligkeitssensor verbaut. Wenn die Aussenhelligkeit unter 5Lux geht können die Rollos zu und ab 10lx z.B. wieder hoch. Auch da wieder Profile (z.B. morgen will ich auspennen ...) Rolloantriebe gibt es im Baumarkt und die müssten sich per Taster über IO4 schalten lassen. Edit: So schaut der Anzeigebereich für die Heizung im Webinterface aus: http://www.tinkerunity.org/forum/index.php/topic,972.msg6843.html#msg6843 Die Farbigen Symbole geben den Raumstatus an: grün: +/- 1° Abweichung vom Soll gelb: +/- 2° Abweichung rot: weiter raus Ich lasse die Heizung an bis die Temp ein halbes Grad über dem Soll ist und schalte das Ventil dann ab. Die Temp kann dann fallen bis sie ein halbes Grad unter dem Soll ist und schalte erst dann wieder an. Das vermeidet Hysterese und schont die Ventile und Dual-Relays.

Ich werde das noch mal angehen ... Wenn ich es hingekriegt habe, stelle ich den Code mal ein Danke für die Tips!