EDOMI - LBS - Diskussion

[coliflower]

Frage zur Sicherheit …
Wenn der LBS dauernd läuft - kann der eh neue Strings am UDP-Listener empfangen ?

[Robby]

@Wagoklemme

Hast Du den LBS Raumtemperaturregler in Beitrag 22 selber geschrieben oder bin ich nur blind den zu finden? Könntest Du ihn sonst mal online stellen?

[timberland]

Hallo Christian,

experimentiere Gerade mit einem Counter der mir die Position vom Tor anzeigt anhand der Fahrzeit. while ($counter <= 100) {
setLogicLinkAusgang($id,1,$counter);
setLogicElementVar($id,1,$counter);

usleep(1000000*$st);

$counter=$counter+=10;
}


Bei der Liveabfrage zählt er richtig rauf oder runter am Ausgang, aber in der Visu bekomme ich das nicht angezeigt.
Kann es sein, dass das zuweisen am Ausgang an das KO zu langsam dafür ist? Sind in etwa 2sec die Schritte.

[gaert]

Ich hoffe Dein Script liegt im [EXEC]-Abschnitt... Schleifen dieser Art haben im Abschnitt [LBS] nichts zu suchen!! Ich nehme mal an, dass es sich um eine Schleife handelt - wegen dem usleep()...

Die Visu aktualisiert sich je nach Einstellung nur alle paar Sekunden - daher werden natürlich Zwischenwerte "verschluckt" in der Visu.

[fisch3009]

Da du ja anscheinend die Animation eh nur künstlich erzeugst und nicht die aktuelle Torposition wiederspiegeln willst, wäre da nicht eine selbsterstellte Animation dafür das richtige, da könntest du ja die Zeit entsprechend anpassen. Die würde flüssig in der Visu laufen (Christian hat ja schon ein paar vorgefertigte Animationen, da kann man sich was abgucken).

[gaert]

Absolut korrekter Einwand! Genau dafür sind die Animationen u.a. gedacht...

[WagoKlemme]

EDIT 2:
Problem gefunden und gelöst. Das Problem tritt nur dann auf, wenn in der Visu(!) eine bestehende(!) Schaltzeit hinsichtlich einer Datumsangabe geändert wird.

Christian, vielen Dank. Unsere Probleme werden quasi von Dir im "Schlaf" gelöst. Während ich schlafe (Mitternacht) löst Du das Problem, RESPEKT! eine echte Ausnahme deine Leistung.

Ein Kommentar von mir zu deiner neuesten "Kreation" Dämon. Ich bin ehrlich gesagt davon nicht begeistert, obwohl die Idee im Grundsatz gut ist.
Zum Einen werden viele LBS nur dann aufgerufen (Trigger) wenn man sie grad gebraucht werden und andere wiederum jede Stunde. Die wenigsten sind im Dauerdurchlauf.
Im Moment ist es ganz gut, falls was schiefläuft, dass der Prozess nur einmal durchläuft und wenn er das nicht macht greifen timeouts. In Zukunft ists so, wenn was schiefläuft, wird der Prozess immer im Kreis geschickt und wird (weil in der Schleife) nicht abgeschossen. Ich finde das ist genau das wovor Du selber, zu Recht, gewarnt hast. Ich will keine Schleife in meinen LBS, auch wenn es manchmal kein schöner Programmierstil ist.
Und usleep x 100 = schon ein merkbares Problem, die Schleifen belasten das System. Es wird nichts zu Ende gebracht.
Es wird sicher Systeme mit Edomi geben, die 100erte von Logiken und massenhaft Datenpunkte enthalten. Da wirst Du es so sicher nicht vermeiden können, das ein System dann in die Kniee geht. Es wird auch bei Edomi so sein. Irgendwann wird die Zykluszeit zu lang.

[WagoKlemme]

@Wagoklemme

Hast Du den LBS Raumtemperaturregler in Beitrag 22 selber geschrieben oder bin ich nur blind den zu finden? Könntest Du ihn sonst mal online stellen?

Da arbeite ich gerade dran. Ich teste nur, ob sowas sinnvoll ist. Ich will in meine Einzelraumregelungen eine Struktur bringen und brauche es wegen meiner Restwärmenutzung (Kessel), bzw. dessen Verteilung.

[gaert]

WagoKlemme

Nein Das System wird nicht in die Knie gehen - sofern man die LBS korrekt implementiert! Alle meine LBS nutzen kein einziges EXEC-Script. Ich finde es ja toll, dass einige engagierte Leute hier fleissig LBS bauen - allerdings sind die Implementierungen zum Teil "haarsträubend", da der Grundgedanke des LBS-Prinzips in EDOMI (Logik-Engine) vollkommen ignoriert wird. Gut, die Doku ist noch nicht die Beste...

Daher mal @all:

WICHTIG:
Es liegt offenbar ein GRUNDSÄTZLICHES Verständnisproblem bezüglich der Logikbausteine vor. Die Doku erläutert dies eigentlich ganz gut - meiner Meinung nach:

Ein "gewöhnlicher" LBS (z.B. ein Gatter, oder auch ein Timer) benötigt KEIN(!!!!) EXEC-Script! Das EXEC-Script soll eher die absolute Ausnahme darstellen, z.B. für LBS, die aufwändige Berechnungen durchführen, Webabfragen durchführen oder eben als Dämon dauerhaft im Hintergrund laufen sollen.

Beispiel Timer: Ein Timer-LBS braucht KEIN EXEC-Script und KEINE Schleife! Es ist nicht Sinn der Sache, dass jeder beliebige LBS eine eigene PHP-Instanz startet (EXEC-Script). Inzwischen scheint es sich jedoch etabliert zu haben, dass jeder noch so "einfache" LBS von der Möglichkeit des EXEC-Scripts gebrauch macht - dies ist ausdrücklich NICHT sinnvoll! EXEC-Scripte muss man sich wie kleine Programme vorstellen, die nahezu unkontrollierbar im Hintergrund werkeln. Ein LBS hingegen (ohne EXEC-Script) wird von der Logik-Engine kontrolliert und verbraucht sehr wenig Ressourcen.

Bitte lest also die Doku und schaut Euch die Beispiele an. Auch die vorhandenen LBS geben eine Menge Aufschluss, da ich den Quelltext z.T. dokumentiert habe.

Ich weiss - es ist viel einfacher mal eben eine Endlosschleife a la "Timer" in ein EXEC-Script zu packen... Aber so ist die EDOMI-Logik nicht "designed". Man kann und sollte so gut wie alle Aufgaben OHNE EXEC-Scripte lösen!

[WagoKlemme]

Ich glaube es gibt kein Verständnisproblem. Der EXEC Weg ist eigentlich der einzige Weg mit der "Welt" in Kontakt zu treten für UNS. Verbindung zu anderer Hardware, http,...
WIR können an nichts anderem arbeiten.

Mit einem Gatter (verzeih bitte) kann ich kein 1-wire einbinden, keine Wago oder sonstwas. Aber das brauchen wir, diese Hardware ist vorhanden. Wenn das nicht läuft, nehme ich ein anderes System mit dem es geht.

[MatthiasS]

Ich habe gerade ein deja vu.

Wie war das seinerzeit beim HS? Erst die einfache 5012er-Logik, dann kam NilsS mit seinem eval() und es wurde kompliziert(er)

[gaert]

Ok, allerdings verstehe ich dann Deinen Beitrag #37 nicht?!

Für Webabfragen etc. ist der EXEC-Bereich sinnvoll und gedacht, keine Frage. Und wenn man 1000 Webabfragen gleichzeitig durchführt, wird's natürlich eng...

Bei einem "Dämon"-LBS geht's um etwas anderes: Zum Beispiel kann man auf diese Art einen LBS bauen, der ständig(!) im Hintergrund läuft, um z.B. als UDP-Server zu fungieren. Dies wäre dann kein LBS mehr im eigentlichen Sinne, sondern eher ein "PlugIn" für EDOMI. Und um dieses Prozess zumindest ein bisschen kontrollieren zu können, werde ich in 1.14 die erwähnte Funktion einführen - denn nur so kann dieser Prozess "sauber" beendet werden, wenn EDOMI beendet wird. Dies ist in Betriebssystemen nicht anders: Wenn der PC heruntergefahren werden soll, teilt das OS erstmal allen laufenden Prozessen mit, dass gleich was Schlimmes passieren wird...

[gaert]

Klingt plausibel...

Komplizierter wird's eigentlich nicht wirklich - ist ja jedem selbst überlassen, welchen LBS er nutzt und welchen nicht Ich bin ja bekanntermaßen kein Freund dieser Eierlegenden-Wollmilchsau-Visus... Die Wetterprognose, Aktienkurse usw. schaue ich mir lieber im Browser/Apps an - mit der Visu (und Logik) möchte ich meine KNX-Installation beglücken, mehr nicht.

Jeder iPhone-Kalender ist 1000 mal umfangreicher als das beste Visu-Plugin... Was soll das alles?!

[WagoKlemme]

Ich glaube aber der Trend geht dahin, ich war bisher auch deiner Meinung. Ein Ding soll bald alles können. Haus steuern, Musik abspielen, Aufnahmen Fernsehen, Wetter, Müllabfuhr, News oder sonstwas. Schau mal hier die LBS-Beiträge zeigen doch eindeutig die Richtung.

Schau dir mal die Smartvisus an, die hier manche gebastelt haben. Die haben genau das.

[WagoKlemme]

Ok, allerdings verstehe ich dann Deinen Beitrag #37 nicht?!

Der Dämon soll eine Kontrolle bringen ? Kontrollierter Prozessabschluss beim Neustart ? Nicht dein Ernst. Ist das wichtig ?
Beim Neustart können von mir aus alle Prozesse abgeschossen werden.
Und zwischenzeitlich quillt der Fehlerlog über, weil er in der Schleife hängt. z.B. Seite nicht erreichbar