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.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten