Forum: Haus & Smart Home Eventbasiert oder zyklisch rechnen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Luke (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ;)

von Dussel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von asdfg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Peter II (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von B. S. (bestucki)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Dussel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Luke (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Amateur (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Luke (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von aswwwer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Poli (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Luke (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von aswwwer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Matthias D. (marvin42)


Bewertung
0 lesenswert
nicht lesenswert
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.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Matthias (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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)

von c.m. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Deutschlehrer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!!!

von Luke (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Luke (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Tilo R. (joey5337) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

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

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.