mikrolinux

Hi! Hmmmh, in der crontab steht bei mir die Ausführung des PHP-Skripts. Ich könnte eine Schleife voranschicken die einen Ping oder so macht und wenn nichts kommt wird die jeweilige IP in eine Defects-Liste eingetragen. Das ist in etwa, was ich in PHP machen will, nur weiß ich nicht recht, wie ich das implementieren soll. Ich habe mal versucht den Verbindungsaufbau in try und catch abzubilden, bin aber kläglich gescheitert - mangels Erfahrung und Kenne. Ich möchte es nur möglichst einfach konfigurierbar halten. Mein Ziel ist es einen RasPi-Host zu haben (das läuft schon) der über ein Web-Interface konfiguriert werden kann. Ich würde bspw. meinem Vater einen Raspi in die Hand drücken, der kauft sich die TF-Bausteinchen für n Räume und kann loslegen. Vielleicht kann man auch ein Raumsteuer-Set draus machen oder was auch immer. Jedenfalls will ich es letztlich DAU-freundlich haben und da finde ich eine Schleife, die eine Tabelle abarbeitet am besten. Aktuell lese ich die Geräte-Konfigs (IP, Baustein-IDs etc) aus einer MySQL-Tabelle in ein Array und arbeite das in einer Schleife ab. Beim Verbindungsaufbau muss es in PHP doch irgendwie die Möglichkeit geben, das Zustandekommen der IP-Verbindung zu checken und Fehler abzufangen .... ? Das löst aber noch nicht das zweite Problem. Otto Normaluser findet es ws. ziemlich ätzend, wenn er alle paar Tagen einen der 'Raum-Controller' resetten muss. daher der Watchdog. Mir ist bei der Gelegenheit auch aufgefallen, dass Bausteine die mit dem weissen TF-Netzteil ausgestattet sind häufiger ausfallen, als solche, die mit einem 'dickeren' Netzteil (Tablet-Ladegerät) versehen sind. Scheint mit dem Strombedarf zusammen zu hängen. Vor dem Hintergrund wäre jedenfalls ein Watchdog nicht schlecht, der das Ganze (Master und WiFi) ins Leben zurück holt ....

Hi! Ich hätte da mal gerne ein Problem ... Aktuell bastele ich ja an einer Raumsteuerung. Das Standard-Setup für einen Raum besteht aus einem Master mit WiFi-Extension, einem Thermo-Sensor und einem DualRelay-Bricklet. Das DR ist an 220V angeschlossen und schaltet (erst mal) ein Gira 112200 Heizungsventil. Das ist erst mal das Basis-Setup Software-Seitig habe ich ein kleines PHP-Skriptchen geschrieben, dass jede Minute seine Liste mit Bricks durchgeht und eine WiFi-Verbindung zum Thermo-Bricklet aufmacht, die Temperatur ausliest und dann entscheidet ob es das DualRelay schaltet oder nicht. Die Funktionalität ist da und es rennt auch soweit gut, aber ..... Nun kommen meine beiden Probleme: 1. Ab und an hängt sich so ein Stapel mal weg und ist nicht mehr erreichbar. Natürlich passiert das gerne, wenn man nicht da ist (dann bleibt die Hütte kalt oder wird brühwarm) oder bei Stapeln, die nur schwer zu erreichen sind (Wetterstation draussen). 2. Hier muss ich voranschicken, dass ich noch ziemlich am Anfang meiner PHP-Lernkurve bin. Ich lasse mein Skript durch seine Liste mit Stapeln rennen und grase so Raum für Raum ab. Solange alles ok ist, rennt das auch gut durch; wenn nun z.B. der dritte Stapel nicht erreicht werden kann, bricht das Skript mit einem Fatal Error in den TF-PHP-Dateien ab. Das hat zur Folge, dass die ersten beiden Räume zwar noch geregelt werden, der Dritte und alle folgenden aber nicht mehr. Die beiden Probleme hängen somit direkt bei mir zusammen. Einerseits muss ich den Fehler abfangen, dass ich z.B. ein nicht erreichbares Modul einfach übergehe und den nächsten Raum aber wieder regeln kann .... -> Wie mache ich das am dümmsten in PHP? Andererseits wäre es toll, wenn es einen Watchdog im Modul gäbe, der es automatisch resettet, wenn es 'hängt'. -> Gibt es so etwas? Das wäre z.B. für den Urlaub toll, denn der Stapel muss ja auch den Heizkörper aufdrehen, wenn z.B. die Raumtemperatur unter 5°C sinkt (Frostschutz) Vielen Dank für eure Tips!

4 davon laufen mit 1.4.6, der Wolkensensor mit einer 1.3 und der ist am stabilsten. Ich habe da eher eine Wechselwirkung mit den DualRelays im Verdacht. Möglicherweise tritt bei Schaltvorgängen eine Spannungsschwankung auf, die der Stack dann manchmal nicht wegsteckt. Ein Grundmodul bei meiner Raumsteuerung besteht aus Master/WiFi-Brick, Temperatur- und DualRelay-Bricklet. Über das DualRelay schalte ich die Heizungsventile und der zweite Kanal soll Steckdosen schalten (Lampe, Weihnachtbeleuchtung, whatever). An zwei dieser Stcks ist dann noch ein 20x4 LCD-Bricklet angeschlossen, das Raumdaten (akt. Temperatur, Ventilstaus, ...) anzeigt. Die Kombi neigt am ehesten zum Aussteigen. Wenn es das ist, dann hilft mir allerdings auch der Reset nicht. Aber ich glaube, ich verlasse gerade das Thema ganz weit

Eine reine "Sicherheitsmassnahme" Ich habe bisher 5 Master/WiFi Kombis im Einsatz. Eine für mein Astrowetter und 4 weitere für meine Raumsteuerung. Alle paar Wochen schmiert mal eine ab und reagiert nicht mehr. Ich habe jetzt einfach ein kleines Scriptchen geschrieben, das meine Liste an Master-Bricks durchgeht und täglich einen Reset macht. Ob das was bringt kann ich noch nicht sagen, da muss ich wieder ein paar Wochen warten und sehen wie es läuft Direkt am USB rennen die Dinger monatelang ohne irgendwelche Fehlfunktionen.

Hi! Ich kann Einsteins Beobachtungen bestätigen. Bei mir läuft die "Wetterstation" seit über einem halben Jahr stabil und ohne HW-Ausfälle. Das sind ein Temp-IR, ein AmbientLight und ein Master mit WiFi in einem IP54-Gehäuse auf der Fensterbank draußen in etwa 8m Höhe. Von direkter Sonneneinstrahlung am Abend bis (bisher) leichtem Frost, Hagel und Regen war alles dabei. Gepollt wird das Ganze alle 5min von einem PHP-Script mit einem SW-Reset morgens um kurz nach zwei. Rennt alles absolut klaglos

Perfekt, danke! Jetzt kann ich bei meiner Raumsteuerung auch den aktuellen Ventilstatus abfragen Heute abend packe ich das noch in das Steuerproggi, dann steht das auch im LCD

Hi! Ich habe ein völlig banales Problem, stehe mir aber wohl gerade selber auf den Füßen ... Habt ihr einen Tipp für mich? Ich möchte von PHP aus den Sachltzustand eines Relais ermitteln. Das sollte eigentlich ganz einfach mit getState() gehen, aber ich kriegs nicht hin. Der Code schaut eingedampft so aus: <?php require_once('Tinkerforge/IPConnection.php'); require_once('Tinkerforge/BrickletDualRelay.php'); use Tinkerforge\IPConnection; use Tinkerforge\BrickletDualRelay; $host = "IP-Nr"; $port = 4223; $drid = ID des Dual-Relay; // DualRelais-Bricklet $ipcon = new IPConnection($host, $port);// IP connection zum brickd $dr = new BrickletDualRelay($drid); // Device-Object fuer DualRelais $ipcon->addDevice($dr); // Dual Relay-Device zur IP-Connection zufuegen $dr->setState( TRUE, FALSE ); // schaltet das erste Relais $relais = $dr->getState(); // hier komme ich ins Schleudern if ( $relais[0] == true ) { $status = "Relais 1 ist geschaltet"; echo "$status \n"; } ?> Das Schalten des Relais funktioniert ganz prima, nur andersrum halt nicht. Ich hätte in der Variablen $relais ein Array mit 2 Werten erwartet, so dass mir $relais[0] den Status des ersten Relais liefern sollte - dachte ich. Wie muss ich die getState()-Abfrage formulieren, damit ich den Schaltstatus zurück bekomme ... ? Vielen Dank für eure Hilfe!

Hi! Die latest ist immer gleich der mit dem neuesten Datum, da bist du mit dem Link genau richtig. PS: Sakra, zu viel umgemodelt . Der Link ist: http://download.tinkerforge.com/firmwares/ Ist auf der von dir verlinkten Seite ganz unten der letzte Link

... tja, meinen Raspberry werde ich wohl erst im November bekommen. RS hat 6-8 Wochen Verzögerung angekündigt. Dafür ist es dann vielleicht aber ein in England gefertigter V2. Aber nix genaues weiß man nicht. So ist der WiFi-Baustein schon ein enormer Fortschritt

Tolle Geschichte und total gut umgesetzt! Ich werde meine Mini-Wetterstation jetzt auf WiFi umrüsten; die Extensions habe ich eben bestellt. Damit kann ich meine Station besser ansteuern und kann einen Rechner (auch wenn es nur ein Atom D525 ist) einsparen und die Station von der zentralen VM aus abfragen. Was mir bei deiner Gradeinteilung aufgefallen ist, ist dass deine Deltas wesentlich weiter auseinander gehen als meine. Das scheint wirklich nur daran zu liegen, dass dein Sensor nicht so tief im Gehäuse verbaut ist wie meiner. Womit hat du deinen Sensor abgedeckt/geschützt?

so, -2, damit bleiben euch noch 9998 Stück Das macht die Geschichte mit der Wetterstation leichter und auch meine angedachte Teleskopsteuerung rückt etwas näher

@AuronX Nein, da ist es nicht drin. Das Ganze Projekt ist meine Version PHP und Perl zu lernen. Also die Programmierung hat da heftig Luft nach oben. Andererseits ist das System zu so 95% als 1-Wire aufgebaut. TF-Bausteine haben da ein Problem, nämlich das sie per USB angebunden sind und die Kabel zu den Bricklets max. 2m lang sind. Wenn ich mir allein die Heizungsüberwachung ansehe, sind da so an die 30m Kabel verlegt. Dazu kommt noch, dass ein 1-Wire Thermosensor keine 2€ kostet (verbaut sind 12Stück). Der Wassersensor ist nichts weiter als ein Relais, dessen Schaltzustand überwacht wird. Wenn Wasser im Keller ist, werden die Sensorfühler kurzgeschlossen und das Relais schaltet. Den 1Wire-Schalter für 220V gibt es als Hutschienenmodul, so dass ich das Zeugs einfach in einen kleinen passenden Elektro-Schaltschrank aus dem Baumarkt packen konnte. Was ich mir hingegen gut vorstellen kann ist die Heizungsventile mit TF zu schalten. Das setzt dann aber einen Stapel WiFi-Module voraus. Auf meinem Webserver läuft ein BrickD mit, der könnte die 'Heizungsschalter' zyklisch abgrasen und schalten. WiFi- und Master-Brick, dazu Dual Relais und Thermo Bricklet und los geht es. Das ganze braucht man dann für jeden Raum. Ein nettes Gehäse drum und evtl. noch das LCD-Bricklet rein, dann sieht man auch gleich was geht. Über die Taster kann man dann auch gleich die Automatik (o.g. Zeitpläne) übersteuern und es wärmer oder kühler machen. Den zweiten Port des Dual Relais nimmt man dann für eine ggfls. vorhandene zweite Heizung im Raum. So als erste Idee. Als Zentrale schwebt mir ja noch ein altes iPad 1 an der Wand vor, das die Steuerzentrale bildet, kann aber auch gerne ein Galaxy-Tab 1 sein. Deswegen setze ich ja auf eine Website zu Steuerung, das spart die ganze Client-Programmierung, die auf Dauer ws. eh auseinander läuft. So synchron kann man die Entwicklung gar nicht halten.

Hi! Schon gemacht, bzw. dabei Wir haben Anfang des Jahres eine neue Heizung bekommen und da das einigen Wiggel bedeutete (Pelletheizungen sind in unserer Gegend nicht wirklich verbreitet und so hatte auch der Heizungsbauer bei den Einstellungen etwas Schwierigkeiten), habe ich mich daran gemacht, die Aktivitäten der Heizung zu überwachen. TF kannte ich zu dem Zeitpunkt noch nicht, so habe ich 1-Wire verwendet. Heizungen und Home-Automation ist ein übles Terrain. Einerseits macht das bisher kaum jemand, zum Anderen sprechen Heizungen und HA-Systeme ganz verspiedene, 99,9% proprietäre Protokolle. Dazu kommt noch, dass viele Sensoren über lange Strecken angebunden werden müssen. Sternförmige Verkabelungen sind da höchst blöde, allein schon was Materialmengen und Kabelführungen angeht. Meist liegen die Kabel noch zusammen mit weiß Gott welchen anderen, da gibt es dann massig Störungen. Da ich aus o.g. Gründen nicht direkt in die Kesselsteuerung eingreifen wollte habe ich letztlich eine parallele Sensorik aufgebaut. 1-Wire hat den Vorteil einfaches Ethernet-Kabel verwenden zu können. Da gibt es das Kabel als 100m-Rollen und es gibt Stecker und Verteiler vorkonfektioniert, bzw im Elektrohandel. Langer Rede kurzer Sinn: ich habe zuerst die Heizungsüberwachung aufgebaut, wo ich dann dabei war habe ich eine Kellerüberwachung dazu gebastelt, so dass mir der Steuerrechner jetzt artig die Tauchpumpe schaltet, wenn der Wassermelder ihm sagt, dass wieder mal der Abfluss das Regenwasser nicht schluckt. Im Kellerraum hängt dann noch ein kleines Display (ähnlich 20x4 LCD Bricklet) mit ein paar Knöpfchen, so dass ich die Stromkreise auch manuell schalten kann. Da angekommen hatte ich dann die Idee, dass ich, wenn ich schon alles verkabele auch Heizkörper oder Beleuchtung auf die gleiche Art schalten könnte. Das wird aber meine Herbstbastelei, momentan gibt es nichts zu regeln. Die ersten TF-Bausteine rutschen jetzt über die Wetterstation, bzw den Wolkensensor mit rein. Heizkörper weiss ich noch nicht, da ich viele/mehrere dezentral schalten muss. Man braucht also in jedem Raum einen Thermosensor und die Möglichkeit 220V oder 24V zu schalten, dann dafür gibt es Ventile. Ziel ist letzlich schön vom iPad aus die Räume steuern zu können. Heisst: manuelles oder zeitplangesteuertes Schalten von Steckdosenleisten/Beleuchtung/Geräten. Dito natürlich für die Temperaturen. Wie im Keller, soll das Haus dann auch auf Ereignisse reagieren können. Z.B. Wenn ein Fenster auf ist und der Regensensor sagt Regen, dann soll er die Rolläden runterlassen uvm. Das Ganze verwendet zur Darstellung aktuell eine Website mit php, da lssen sich die TF-Geschichten dann wieder gut einbinden. Aktuell läuft der 1-Wire über OWFS, die Programmierung besteht aus Shell-Skripten, Perl und PHP. Ich habe ein paar Screenshots angehängt. 1 ist der Einstieg mit der Überblicksseite. Die Farbkodierung habe ich wie eine Ampel gemacht. Grün heisst alles im Soll, Orange bedeutet eine tolerable Abweichung und Rot verlangt ggfls. einen manuellen Eingriff. Die Kellersteuerung verwendet ein paar eigene Sysmbole Grau ist aus, die Schaltersymbole werden grün wenn manuell geschaltet wurde und die Blitze gelb wenn Strom geschaltet ist. Blauer Tropfen ist Wasser im Keller. 2 ist ein Überblick über die Heizungswerte und 3 die Folgeseite mit den Verlaufgrafiken. Die geht noch nach unten weiter mit Raumtemperaturen, Luftfeuchtigkeiten usw. Das gibt es noch für die Klimawerte (da mit TF Bausteinen) und die Raumsteuerung ist in Arbeit. Das waren so meine Spielereien in dem Bereich. Wenn noch jemand Ideen hat: immer her damit! 1_HomeAutomation.tiff 2_HomeAutomation.tiff 3_HomeAutomation.tiff

Hi! Nö, man misst die Temperatur des Wassers in der Atmosphäre. Je mehr Wasser da ist, desto höher geht die Temperatur der IR Messung. Ohne Wasser misst man sozusagen die Temperatur des Weltraums plus Atmospäreneinfluss plus Sensoreinflüsse. Wolken nehmen die Sonnenenergie auf und die Temperatur geht hoch. Wolken sind ja unregelmässige Objekte und die erkennt man dann an den riesigen Ausschlägen, während bei wolkenlosem Himmel die IR-Temp nahezu konstant bleibt. Letztlich misst man die Temperatur des Wassers am Himmel. Je mehr Wasser da ist, desto mehr weicht das natürlich vom Idealwert ab. Die rel. Luftfeuchte ist aber abhängig von der Temperatur der Luft (nicht unbed. des Wassers) am Boden. Die Luft kann ja abhängig von der Temperatur und Luftdruck eine gewisse Menge an Wasser aufnehmen, das misst z.B. das Humidity Bricklet. Es sind also völlig verschiedene Messungen

Moin! Besten Dank! Ich werde dann mal sehen, ob ich ein altes Okular schlachten kann. Einen (anders verplanten) Servo-Brick habe ich hier, ein Servo auch. Mal sehen was ich daraus basteln kann. So was gibt es zwar schon (http://www.unihedron.com) als SQM, aber selber bauen macht deutlich mehr Spaß :-) Außerdem ist es zusammen mit der Bewölkungsmessung viel flexibler.

Hi! Hat jemand eine Idee wie ich sehr schwache Lichtstärken messen kann? Ich möchte die nächtliche Himmelshelligleit messen, bzw. damit auch die Lichtverschmutzung ...

Hi! Die Bilder des Sensorgehäuses finden sich im Anhang. Es ist aber noch sozusagen 'Beta'. ... wobei, Provisorien lebn eingentlich immer am längsten ;-) Im Deckel habe ich die Sensoren und den Brick verschraubt, vor den Sensoren habe ich dann jeweils ein Loch gebohrt, damit der jeweilige Sensor auch was 'sieht'. Auf der Aussenseite habe ich vor dem Ambient Light Bricklet einfach ein Deckglas aus dem Mikrosopiebedarf aufgeklebt und wie vorher schon beschrieben vor dem IR-Bricklet etwas PE-Folie. Geklebt und abgedichtet habe ich einfach mit Pattex, die Schrauben habe ich auch damit überzogen - so rosten sie nicht Ist nicht schön, für den Testbetrieb reicht es aber erst mal. Im Gehäuse selbst ist auch noch ein kleines Beutelchen mit Silicagel (Trockenmittel), das Kondenswasser aufsaugt. Wie auf dem Bild zu sehen ist, habe ich das Gehäuse dann auf einen Aluwinkel geschraubt, damit die Hauswand aus dem Sichtfeld des Sensors verschwindet und die Messwerte nicht verfäschen kann. Der Sensor zeigt jetzt im 45°-Winkel direkt nach Norden. Das Anwinkeln, hate nur leider den Haken, dass Wetteränderungen erst erfasst werden, wenn sie im Norden angekommen sind. Ideal wäre ein direkter Blick des Sensors nach oben. Nun zur Grafikerstellung. (Skripts im angehängten Text-File) Als Datenbank verwende ich das RRDTool. Das ist eine Raound-Robin-Datenbank, die Ihre Werte zyklisch wieder überschreibt. Der Vorteil ist, dass sie klein und schnell ist - und nicht wächst. Das ist ideal für embedded-Systeme, bzw später für den RPi. Für meine Messungen habe ich eine RRDB mit 5 Minuten -Aggregation angelegt (--step 300) Ich kann die DB also mit Werten füttern, die aggregiert sie und legt alle 5 Minuten einen Werte in die DB. Als FElder neghme ich t_sky, t_ambient, t_delta, light und humidity. t_ steht einfach für Temperaturen. 650 bedeutet, dass wenn 650s lange keine Messwerte kamen, der Messpunkt auf Unknown gesetzt wird, die beiden anderen Werte sind der Messbereich (Min und Max). RRA:AVERAGE.... gibt dann noch die DB-Größe an. 5-Minuten Intervalle und 130000 Messwerte. Das reicht für etwas über ein Jahr rückwärts. Das PHP-Skript füttert die DB dann mit Messwerten. Ich starte astrowetter.php alle 5 Minuten über den cron. Der Anfang des Skriptes dürfte zziemlich bekannt sein, es ist nichts weiter als das Zusammenkopieren der Beispiele aus der Doku. Interessanter wird es dann im Abschnitt 'Beginn der Auswertung'. Die Variable $deltat normalisiert die Messungen. Der Part danach ist nur für Textausgaben interessant, wenn man die Messwerte auf dem Bildschirm ausgeben will. Ich mache das Update der RRDB über einen Update-String als Shell-Befehl und baue mir den $RRDString aus den Messwerten auf. Nur das Humidity-Bricklet ist noch nich angeschlossen, deher setzte ich den letzten Messwert fix auf U (unknown). Danach kommt der Update auf die DB, gefolgt vom Generieren der Grafik. Die erste Zeile definiert die Grafik als solche (Filename, Abmessungene etc) und jede der Folgezeilen fügt einen GRaphen zu. Wenn ich einen der Graphen nicht mehr möchte, kommentiere ich die Zeile einfach und beim nächsten Durchlauf ist die Kurve dann raus. Natürlich kann man das auch über mehrere RRDBs mischen. So könnte ich mit einer Zeile mit Verweis auf meine Heizungs-DB auch die Vorlauftemperatur des Kessels anzeigen. Ok, sinnlos, aber geht ;-) Mit den letzten - hier auskommentierten - Zeilen kann mann die Messwerteauch in ein Textfile schreiben und ie Auswertung z.B. in Excel machen. So waren die ersten Kurven entstanden. Das generierte PNG schiebe ich danach in einem zweiten Schritt per ncftpput auf den Webserver, wo es verlinkt ist. Am Ende der Text-Datei ist dann noch ein Beispiel wie man die RRDB von der Kommandozeile aus auserten kann. Die -nan-Werte (not a number) in der Mitte wasrten einfach die Werte, die auf Unknown gesetzt wurden als ich den Masterbrich mit der aktuellen FW geflasht habe, danach ging es nahtlos weiter. In den Kurven sieht man das als kurze Unterbrechung der Linien. Dann noch ein paar Worte zum Messverfahren. Über die letzten Tage konnte ich ganz gut die Bewölkung verfolgen, lediglich die Interpretation der Werte muss ich noch verfeinern, speziell an den Übergängen. Je nach Höhe der angemessenen Bewölkung kommt es da zu Ungenauigkeiten. Bodennaher dünner Dunst hat eine ähnliche Wirkung wie hohe etwas dickere Bewölkung. Da muss ich noch etwas nachdenken. Was man gut unterscheiden kann sind durchgehende Bewölkung und durchziehende Wolkenfelder. Wenn man eine hin und her zachende Linie sieht, sind es Wolkenfelder. Richtig klarer Himmel zeigt sich als fast gerade Linie bei unter -12° DeltaT astrowetter.txt

Klar, Bild poste ich morgen, ist aber nix dolles. Ich habe meine Werteermittlung jetzt automatisiert und rrdtool baut mir nun Graphen auf die HP. Auch die Skalierung der Messwerte wird so langsam. Wenn es von Interesse ist, kann ich den ganzen Prozess mal vorstellen. Aktuelle Werte finden sich auf www.elverdissen.de Der Sensor sitzt an einer Nordwand, allerdings kommt die Sonne am späten Nachmittag weit rum und erwärmt das Gehäuse, so dass ich zwischen kurz vor 18:00 ud kurz nach 20:00 eine fette Beule in der Messkurve sehe. Ich nehme das einfach mal als Schönheitsfehler ;-)

Banal - wie erwartet Ich brauchte nur das paket php5-sockets zu installieren, dann lief alles wie geölt. SuSE installiert das Paket bei frischen Installationen anscheinend nicht mit. Ich werde in der nächsten Woche mal meine Dokus mit einer Installation from Scratch zu ergänzen. So kann ich meine TF und 1Wire-Projekte mergen. Dann habe ich Heizungsüberwachung und Raumsteuerung als 1Wire in Perl und die neueren Spielereien mit TF in PHP

Hi! Es ist peinlich, ich weiss. Bisher habe ich meine Bricks an einer Linux-VM unter SuSE 12.1 betrieben, der VM-Host ist ein Mac mini mit Parallels. Ok, bei dem funzt der Zugriff mit PHP auf den BrickD prima. Heute Nachmittag habe ich mir dann einen Nettop mit SuSE 12.1 installiert, alles benötigte drauf, brickd, PHP mit bcmath etc. pp. Also eigentlich ganz genauso wie bei der VM. Nur steigen die Skripte wortlos aus, wenn ich die IP-Connection aufbauen will. Es kommt kein Fehler nichts, nur die Verarbeitung bricht ab und ich bin wieder auf dem Prompt. Zugriff (auch von einem anderen Rechner aus) mit BrickV klappt einwandfrei, auch die Skripte von der VM aus gestartet auf den 'neuen' Rechner fluppen. Es liegt also wohl einfach an meiner PHP-Installation, ws. nur eine völlig doofe Kleinigkeit, aber ich finde sie nicht. :'( Hat vielleicht jemand eine Idee für mich?

Hi! Nee, das ist peinlich einfach Ich habe einfach das Beispiel fürs Bricklet aus der Doku genommen und eine neue Variable deltat als $deltat = $obj - $amb; eingeführt. mehr ist es wirklich nicht! Den Rest, also eigentlich die Schwellwerte hängen vom Gehäuse des Sensors ab. Mein Gehäuse war für die Wärmestrahlung zu dicht, Ambient und Object waren zu nah aneinander und so konnte ich eigentlich immer nur die Temp des Gehäusedeckels messen. Also musste ich ein Guckloch für den Sensor ins Gehäuse bohren, mit verschiedenen Lochgrößen und Abdeckmaterialien spielen und mir dann was passendes aussuchen. Der Sensor hat laut Doku einen Blickwinkel von 70°, bzw. 35° von der Achse mit dem Schwerkunkt der Messung auf derselben. Für mich ist dabei rausgekommen, dass ich ein Loch gebohrt habe, das zwischen den Bohrungen des Bricklets liegt und gerade noch etwas Futter stehen lässt, dass ich den Sensor festschrauben konnte. Dann kamen erst mal ein paar messungen ohne Abdeckung als Referenz und ein paar zeitgleiche mit verschiedenen Materialien. Glas ging gar nicht, als praktikabel hat sich für mich PE-Folie herausgestellt (aka Müllbeutel). Die dämpft die Messung nur um ca. 2,5°C und lässt die Differenz zwischen Umgebung und Himmel groß ausfallen. Idealerweise zeigt der IR-Sensor senkrecht nach oben und hat im besagten 35°-Winkel keine Hindernisse. Da das alles vom Gehäuse und vom Standort abhängt. kommt man leider nicht um eine eigene Eichkurve herum. Vielleicht noch etwas zur Grundlage. Bei klarem trockenem Himmel hat man ja wenig Wasser in der Sichtlinie des Sensors, so dass man die Temperatur des Welraumes misst (-270°, weil -273° abs. Null plus 3K Reliktstrahlung) Nun kommt die Atmosphäre mit ihrem Wasser dazu so dass ich komplett ohne Gehäuse mit dem Bricklet auf -20° gekommen bin. Das mag aber vom Sommer zum Winter noch variieren. Im Gehäuse eingebaut kommen natürluich noch spezifische Störungen dazu. Die kriege ich aber gar gut normalisiert, indem ich die Differenz beider Werte bilde. Das fängt die Drift über den Tag / die Nacht leidlich ab und ich komme zu den oben genannten Werten. Letzlich könnte man natürlich auch direkt auf die IR-Werte gehen, das macht jeder anders. Ich habe mal zwei Messreihen aus den letzten Tagen angehängt. eine richtig gute Nacht habe ich weggelassen, die war langweilig, weil die Delta T-Linie konstant bei ca. -13 blieb In der Grafik der 'guten Nacht' sieht man vor Mitternacht durchziehende Wolkenfelder, das sind die Zacken, nach Mitternacht blieb es dann klar und das Delta unten. In der Regennacht schrumpft das Delta zusammen, im Bereich von 0:40 - 0:55 kamen Sterne durch den Dunst, um 3:55 und 5:40 müsste es jeweils kurz klar gewesen sein, aber nicht doll. Ganz am Anfang des Graphen, es ist der 27./28.7. sieht man ein großes Delta von so -13°, das war ein schöner sonniger Tag, bei dem dann innerhalb einer Stunde die Regenfront heranzog. Grundsätzlich scheint das Messverfahren also ganz ordentlich zu funktionieren ;-)

Hi! Mir einem IR-bricklet könntest du noch einen Bewölkungsmesser realisieren. Damit misst du ja letzlich den Wassergehalt der Luft (Emissivität 0,98 eingestellt) Das Delta von Ambient und Object ist dann spezifisch für den Bewölkungsgrad. Funzt bei mir prima. Man wuss nur etwas mit den Sensorgehäusen experimentieren. Ich habe vor dem Sensor ein Loch ins Gehäuse gebohrt und es mit PE-Folie bedeckt. So weiss ich nun abends immer: Delta T > -8 bedeckter Himmel Delta T -8 bis -10: die ersten Sterne kommen raus Delta T -10 bis -12: es lohnt sich das Teleskop raus zu holen Delta T < -12: eine wirklich gute Nacht zum Sterne gucken unter -14 ist es dann sozusagen phänomenal :-) Das funzt auch tagsüber, nur ist der Wert da für mich nicht von Belang und das PHP skript läuft nicht ;-) Ich lasse es als cron-Job alle 5 Minuten laufen und schreibe die Werte in eine Round Robin DB (RRDTool). Da lassen sich dann auch einfach die Graphen für die Nacht erstellen. Für deine Wetterstation ( super durchgezogenes Projekt!) wäre die Bewölkungsmessumg vielleicht noch eine schöne Ergänzung.

Genau so Leider habe ich bisher keine Möglichkleit gefunden isoliert 'freizugeben', so bleibt erst mal, wenn man eine oder mehrere nicht Apple-Cert-signierte Anwenden verwenden möchte, nur die Variante alles freizugeben. Das schlägt übrigens auch bei schon installierten Anwendungen zu. Der brickd war ja schon unter Lion installiert und lief einwandfrei. Nach dem Update war er geblockt und nach dem Umstellen des Gatekeepers war alles gut. Ich habe es auf zwei Macs verifiziert

Hi allerseits Ich glaube, ich hab's. Es liegt scheinends tatsächlich am Gatekeeper. Wenn man in den Systemeinstellungen unter Sicherheit bei 'Progamme aus folgenden Quellen erlauben' auf 'keine Einschränkungen' umstellt laufen die Installation und auch der Daemon einwandfrei. Das funkt auch bei schon erfolgten Downloads mit einem Browser. D.h. wenn der Daemon mit einem Entwickler-Zertifikat von Apple kompiliert würde, sollte es auch mit den Default-Einstellungen bei der Sicherheit durchlaufen.

Hi! Tja, da war ich wohl zu voreilig ... Auf meinem Mac mini lief alles perfekt - bis gestern! Da habe ich das Update auf ML (OS X 10.8 ) gemacht und: nix mehr. Auch die Neu-Installation des Brickd geht nicht, da ML das Programm als defkt deklariert. Ich habe auch versucht das Shell.Skript aus dem Data-Verzeichnis zu starten. Das lieft einwandfrei durch, nur funkt es genauso wenig wie vorher :'( Wie kriege ich nun den brickd wieder ans Laufen? brickv rennt hingegen prima, der Connect zum Linux-Server und alle Auswertefunktionen laufen einwandfrei.