Hallo, meine Hausautomatisierung soll auf einem Raspi laufen und einige Temperaturen, Helligkeitssensor einlesen sowie Jalousien, Aussenlicht und Anwesenheitssimulation mittels FS20 Schaltern steuern. Ich bin mir noch nicht sicher, welchen Ansatz ich bzgl. der Implementierung wählen soll: a) Eventbasiert bspw.: Wenn Helligkeitssensor 20% unterschreitet, Event x senden Event x triggert dann das Einschalten der Aussenbeleuchtung b) zyklisch rechnen es werden also zyklisch ca. alle 5s alle Sensoren eingelesent und davon abhängig werden dann im gleichen Zyklus alle Ausgänge angesteuert. ...so auch Helligkeitssensor->Aussenlicht Welche Vor/Nachteile seht ihr? PS: Ich weiß, dass es FHEM und Konsorten gibt, möchte aber (weils mir grundsätzlich Spaß macht) selbst programmieren ;)
Luke schrieb: > b) zyklisch rechnen > es werden also zyklisch ca. alle 5s alle Sensoren eingelesent und davon > abhängig werden dann im gleichen Zyklus alle Ausgänge angesteuert. > ...so auch Helligkeitssensor->Aussenlicht > > Welche Vor/Nachteile seht ihr? Viel 'Overhead'. Warum sollten die ständig aktualisiert werden? Nur wenn auch mal falsche Betriebszustände auftreten können, sehe ich den Vorteil, dass nach spätestens ein paar Millisekunden wieder ein gültiger Befehl kommt, aber sonst muss das nicht sein, denke ich.
Luke schrieb: > a) Eventbasiert > bspw.: Wenn Helligkeitssensor 20% unterschreitet, Event x senden > Event x triggert dann das Einschalten der Aussenbeleuchtung Wie bekommst Du denn mit, dass der Helligkeitssensor 20% unterschreitet ohne ihn regelmäßig auszulesen?
Dussel schrieb: > Viel 'Overhead'. Warum sollten die ständig aktualisiert werden? Nur wenn > auch mal falsche Betriebszustände auftreten können, sehe ich den > Vorteil, dass nach spätestens ein paar Millisekunden wieder ein gültiger > Befehl kommt, aber sonst muss das nicht sein, denke ich. auf der Basis Funktionen zumindest SPS-Steuerungen. (Zumindest die S7 vor vielen jahren). Das ganze hat den Vorteil das es sich immer gleich verhält. Was ist wenn ein Stromausfall kommt welchen Events müssen da generiert werden? Im schlimmsten fall muss man beiden Implementieren, aber das CPU-Leistung genug vorhanden ist, ist das Polling einfacher.
Dussel schrieb: > Luke schrieb: >> b) zyklisch rechnen > [...] > Viel 'Overhead'. Na ja. Irgendwer muss den Sensor zyklisch auslesen, um festzustellen, ob sich der Wert geändert hat damit er ein Event auslösen kann. Luke schrieb: > Welche Vor/Nachteile seht ihr? Das hängt von deinem System ab. Ist es zentral oder dezentral?
Peter II schrieb: > auf der Basis Funktionen zumindest SPS-Steuerungen. (Zumindest die S7 > vor vielen jahren). Die haben aber auch eine garantierte Zykluszeit. Ich wüsste nicht, wofür man das hier brauchen sollte.
Hi, den Einwand "Overhead" würde ich erstmal ausschließen. Es geht ja nicht darum im ms-Raster zu rechnen sondern alle paar Sekunden. Auf einem Raspi eigentlich kein Problem. Den Helligkeitssensor muss man schon zyklisch auslesen, klar. Die Frage ist nur - wie dann weiter. In jedem Zyklus bei über 20% immer "Aus" senden, bei unter 20% immer "Ein" senden. Oder: Beim unterschreiten von 20% einmal "Ein" senden und beim Überschreiten von 20% einmal "Aus" senden. Mein "System" würde ich als zentral bezeichnen. Alle Sensoren hängen am Raspi und die Aktoren werden ebenfals von selbigem gesteuert. Vorteile für "zyklisch" sind aus meiner Sicht, dass ich mir keine Zustände merken muss. Event-basiert wäre aus meiner Sicht eher State-of-the-Art.
Ich würde das Polling, aus zwei Gründen, bevorzugen. 1. Mir ist, rund um die Hausautomation, kein Ereignis bekannt, das eine extrem schnelle Reaktion erfordert. 2. Eine "normale" CPU wird, bei dem was in einem normalen Haus passiert, trotzdem eine Zykluszeit erreichen, die die meisten Messwerte zu Makulatur machen. Z.B. wen interessieren schon Temperatur-, Windgeschwindigkeits-, Helligkeits- oder Feuchteänderungen im Millisekundenrhythmus?
Amateur schrieb: > Mir ist, rund um die Hausautomation, kein Ereignis bekannt, das eine > extrem schnelle Reaktion erfordert Naja, es gibt Spezis, die alle Schalter sternförmig zusammenführen, einlesen und dann die entspr. Ausgänge schalten. Die Zeit zwischen Schalter betätigen und Licht an muss schon unter 200ms sein. Aber sowas mache ich nicht. Ich tendiere zu zyklischer Bearbeitung...
Luke schrieb: > Den Helligkeitssensor muss man schon zyklisch auslesen, klar. > Die Frage ist nur - wie dann weiter. In jedem Zyklus bei über 20% immer > "Aus" senden, bei unter 20% immer "Ein" senden. > Oder: Beim unterschreiten von 20% einmal "Ein" senden und beim > Überschreiten von 20% einmal "Aus" senden. Den Zahlenwert an die Zentrale senden. Die kann dann z.B. entscheiden, dass an der Nordseite bei 20% das Licht angeht, auf der Suedseite bei 10%. Da dann die Schwellwerte nur in der Zentrale vorliegen, muessen sie auch nur dort geaendert werden. Allerdings wuerde ich das dann gleich mit Luxwerten machen. aswwwer
aswwwer schrieb: > Die kann dann z.B. entscheiden, dass an der Nordseite bei 20% das Licht > angeht, auf der Suedseite bei 10% Die Frage war doch, ob zyklisch oder mit Events. Die Überlegung, welches Licht man bei welcher Schwelle schaltet kommt doch erst im übernächsten Schritt.
Mal rein praktisch gedacht: Wenn ich einen Rolladen/Jalousieschlter zyklisch ansteuere: Vertragen die es, wenn man ständig hoch-hoch-hoch... sendet, wenn sie schon oben sind?
Poli schrieb: > Die Frage war doch, ob zyklisch oder mit Events. Folgende Ueberlegungen draengen sich auf: Wenn man auf Anfrage sendet, dann weiss die Zentrale, dass der Wert aktuell ist. Wenn nur bei Aenderungen, dann muesste das Alter des Wertes in der Zentrale gespeichert werden (und u.U. auf Plausibilitaet geprueft werden), sonst klappt einiges nicht mehr, wenn der Sensor defekt ist. Also in diesem Fall ganz klare Empfehlung: Zentrale fragt, Sensor antwortet. Wie oft, das muss man sich ueberlegen, Aussentemperatur z.B. sicher nicht so haeufig wie die Temperatur einer Zirkulationsleitung. Ausgaenge sicher nur einmal senden fuer Einschalten und einmal fuer Ausschalten oder z.B. wenn sich der Sollwert (z.B. Dimmer) geaendert hat. aswwwer
Amateur schrieb: > wen interessieren schon Temperatur-, > Windgeschwindigkeits-, Helligkeits- oder Feuchteänderungen im > Millisekundenrhythmus? Bei Heizung und Licht kein Problem, bei Glasbruchmelder z.B. wäre zu überlegen ob er das Ereignis lange genug meldet um es zu erfassen. Allerdings sollte man sein Haus nur so automatisieren, daß man es auch STromausfall oder Störung noch benutzen kann. Wenn sich die Tür nicht öffnen lässt und der Herd kalt bleibt wird sich die Freude der Hausfrau in Grenzen halten.
Im Prinzip würde ich ein Event-System bevorzugen, weil die ganzen HA-Systeme auf Hardware mit geringer Bandbreite basieren. Mein EIB arbeitet fast komplett Event-basiert, also ein Lichtschalter sendet dann, wenn er betätigt wird. Damit lässt sich dann leicht ein Event-Handler anhängen. Auch ein Fenster-Kontakt sendet selbst, wenn das Fenster geöffnet oder geschlossen wird. Umwelt-Sensoren senden ihre Daten zB. alle 20-60 Sekunden automatisch (Helligkeit, Temperatur, Luftfeuchte) häufiger macht für mich keinen Sinn, denn diese Werte ändern sich auch nicht beliebig schnell, bzw. ich muß auch nicht schneller reagieren. Wobei, ich habe einen Sensor der nicht alleine senden kann, den frage ich alle 2 Minuten ab. Und dann hängt das auch ein bisschen von deiner Hardware ab: willst du etwas draht-gebundenes oder ein Funk-Netzwerk betreiben. Ein Funksystem ist anfälliger dafür, daß mal ein Event verloren geht. Nach meiner Erfahrung ist das auch ein teil Geschmackssache: wer bereits SPS programmieren kann bevorzugt fast immer deren "Denkweise" und arbeitet eher zyklisch/pollend. Hochsprachler bevorzugen eher den Event-Ansatz (da zähle ich mich dazu) Regelwerke, finde ich, kann man Eventbasiert einfacher formulieren, denn es gibt immer eine Art "Trigger" also in der Art : wenn zwischen 17 und 18 Uhr die Helligkeit unter 35% sinkt, dann Rolläden runter. Der Trigger ist die Helligkeit, die Uhrzeit ist die Nebenbedingung. Sowas verstehen auch die Mitbewohner im Haushalt. Mein Haus-Server unterscheidet auch pollende Nachrichten (Schicht-1) und Ereignisse (Schicht-2). Daten die gepollt werden müssen (weil es anders nicht geht) haben eine konfigurierbare Zyklus/Abfragezeit. Die Daten von beiden trage ich erst mal in eine Proxy-Liste ein. Immer wenn hier ein Ereignis ankommt (entweder weil eine Poll-Response eintrifft, oder ein Event) dann checke ich die Liste ob sich etwas verändert hat und melde die betroffenen Ereignisse weiter nach oben. Auf der nächsten Schicht sitzt dann ein Appl-Server der in o.g. Weise die Ereignisse checkt und schaut ob es was zu tun gibt. Dh. wenn ein Sensor oder Schalter immer denselben Zustand meldet, dann wird der Appl-Server auch nichts machen. Bzgl. deiner Frage Rolladen zyklisch: meine Aktoren vermerken im Datenblatt, daß sie eine Pausenzeit von 300-500 ms möchten, bevor eine Richtungsumkehr gesendet wird.
Mir ist noch nicht klar, auf was Du Event- oder Loopbasiert beziehst. Auf innerhalb das RPi? Oder auf die externe Aktorik (Stromstoß-Schalter?) Also innerhalb beträfe nur die Softwarearchitektur. Aber da gilt beides nicht: Luke schrieb: > Vorteile für "zyklisch" sind aus meiner Sicht, dass ich mir keine > Zustände merken muss. Event-basiert wäre aus meiner Sicht eher > State-of-the-Art. Also meinst Du die Aktoren: Wie schaltest Du denn hier? 230V Relaisklarte? Oder indirekt über Stromstoßschalter? Aber auch hier gibt der Einwand "keine Zustände merken" keinen Sinn. Beschreibe doch mal die Art Deiner Aktorik.
Hi, sorry, ich hatte übersehen, dass du dich bereits für FS20 entschieden hast, würde aber trotzdem an meinem Vorschlag festhalten, einserseits die Werte zu pollen die nicht selbst senden können, aber innerhalb deiner App dann Events zu verarbeiten. In welcher Sprache willst du das denn programmieren ? Ich denke dass mein Ansatz vielleicht nicht ganz einfach in Python umsetzbar ist, weil hier einiges an OO-Programmierung drin steckt (ich habe das in C++ gemacht, ein Bekannter in Java)
eigentlich egal ob zyklisch oder per events. eventbasiert könntest du einen server auf dem pi laufen lassen, und die sensoren melden ihre daten per "http request" auf den im pi entsprechend reagiert wird. beim pollen der werte vom pi an die sensoren hast du den nachteil, das der pi mehr machen muss, aber wahrscheinlich nicht ausgelastet ist. was du aber auf jeden lass wissen willst, ist ob ein sensor keine daten mehr meldet. bei events brauchst du auf dem pi eine "datenbank" die pu zylisch auswertest, und prüfst ob und wann die letzten sensorwerte ankamen. beim pollen kannst du auf einen poll-request der vom sensor nicht beantwortet wird direkt entsprechend reagieren. hat beides vor- und nachteile.
c.m. schrieb: > hast du den nachteil, das der pi mehr machen muss > was du aber auf jeden lass wissen willst > die pu zylisch auswertest, Kannst du mal bitte die Shift Taste benutzen. Das ist ja grausam zu lesen. Außerdem schau dir bitte mal Rechtschreibung und Grammatik an - speziell Kommasetzung und wann man "das" und wann "dass" benutzt. Bis dahin: SCHREIBVERBOT!!!
c.m. schrieb: > eventbasiert könntest du einen server auf dem pi laufen lassen, Nein, viel zu kompliziert. Die Sensoren sind ja per AD-Wandler und 1wire am pi angebunden. Die müssen nix per http melden. Ich will sie zyklisch abfragen und zur weiteren Verwendung in eine mysql Datenbank schreiben. Tendiere momentan zu folgendem: Datenerfassungsmodul -------------------- while 1 1. Sensordaten einlesen 2. Sensordaten bzgl. Status und Grenzen plausibilisieren 3. plausible Sensordaten mit Status und Zeitstempel in mysql Datenbank schreiben 4. sleep 5 Steuerungsmodul --------------- while 1 1. Sensordaten aus mysql Datenbank lesen 2. Fehlererkennung 3. Fehlerbehandlung 4. aus Sensordaten den Zustand der Schalt-Aktoren zyklisch bestimmen 5. Jalousiemotoren zustandsbasiert bedienen 6. Zustand der Aktoren ausgeben und in mysql Datenbank schreiben 7. sleep 5
Luke schrieb: > c.m. schrieb: >> eventbasiert könntest du einen server auf dem pi laufen lassen, > > Nein, viel zu kompliziert. - Korrektur: Das "viel zu kompliziert" bezog sich auf die Anregung, dass die Sensoren ihre Daten per http request melden sollen.
Zumindest was deine Funk-Aktoren (die FS20-Schalter) angeht, denke ich, dass ein zyklisches Versenden verboten ist. Ich will mich da jetzt nicht allzu weit aus dem Fenster lehnen, es ist auch schon eine ganze Weile her dass ich das angeschaut und durchgerechnet habe. Ich meine mich zu erinnern: Das Zugriffsverfahren der Sender ist "Aloha", d.h. die Sender machen kein Carrier-Sense sondern senden einfach drauf los und wiederholen das ein paar mal. Dieses stochastische Zugriffsmodell funktioniert prima, solange der Kanal "fast immer" frei ist. Und genau das ist in der Zulassung auch berücksichtigt. Imho darf dein System den Kanal zu maximal 1% auslasten (gemittelt auf eine gewisse Zeit, die ich jetzt nicht mehr im Kopf habe). Im praktischen Betrieb ist das keine Einschränkung. Wenn du aber alle 5 Sekunden anfängst, deine Schaltaktoren durchzugeben, dann bist du da vermutlich sofort drüber. Die Einhaltung ist nicht nur gesetzliche Anforderung sondern liegt auch in deinem eigenen Interesse, da sonst Sensoren und Handsender unzuverlässiger werden. Den Status der Schaltaktoren musst du dir also ohnehin merken.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.