Oszillatorbaustein

[gaert]

By the way: Falls Du noch mit einer älteren Version arbeiten solltest - die aktuelle 1.19 ist offenbar deutlich performanter in dieser Hinsicht!

[WagoKlemme]

Verstehe ich alles (ich bin nicht so doof wie ich aussehe ) , ABER ein Oszillator treibt hier die Stromaufnahme des >Hosts< dauerhaft um 4 Watt hoch. Da war man in den 1950er noch stromsparender.
Natürlich sehe ich das nicht linear ansteigen, aber ich stehe immer noch am Anfang von Edomi und gehe davon aus vielleicht in der Größenordnung 50-100 Timer, Oszillatoren... dazukommen. Und dann bin ich vielleicht bei 50% ?!?
In meiner Wago habe ich ein komplexes Konstrukt aus ZSU, Timern und Oszillatoren selbst programmiert, eine gewaltige Anzahl. Die werden in 100ms alle abgearbeitet, Echtzeit eben. Da juckts die CPU wirklich nicht, die ist mit der Haussteuerung im 20ms Bereich beschäftigt. Hier habe ich aber eine 4-Kern-CPU, die um Faktoren mehr Rechenleistung hat und die beschäftigt schon 1 einziger Oszillator.

Edit: 1.19

[WagoKlemme]

edomi_Last.png

War gar nicht so einfach mal einen Peak zu erwischen.
Man beachte LBS RUN.

[WagoKlemme]

Edomi_Last2.png
Jetzt ohne den Oszillator.

[gaert]

Ja, aber Deine Wago muss auch keine Visu versorgen und einen grafischen Logikeditor bereitstellen - einschließlich Community-LBS und und und Äppel und Birnen... Ich kann Dir auch einen Oszi programmieren - nein, sogar mit einem NE555 zusammenlöten. Aber darum geht's nicht

Meine Hardware braucht 10 Watt unter VOLLLAST. Ich weiß ja nicht, was Du da für einen "Bräter" hast

Hier mal 64 Oszis in einer VM - 1 CPU/Core(!) auf meinem iMac 2007(!). Mit anderen Worten: Schneckenlahme Hardware... Bildschirmfoto 2016-02-26 um 20.31.39.png




Und mal noch ein ganz anderes Argument:
KNX und Oszillator passen eigentlich nicht wirklich zusammen... Ich wüßte kaum einen Anwendung von 100 Oszis?!
EDOMI (und KNX) sind Ereignis-getriggert ausgerichtet...!

Eigentlich ist dieses Thema auch schon längst abgehakt - wohin soll diese Diskussion führen?! Aktuell ist EDOMI was es ist - und die Performance sollte für ein gewöhnliches Projekt mehr als genügen. Ich denke nicht, dass EDOMI mit einer Echtzeit-Hardware mithalten kann, aber das soll's ja auch nicht (umgekehrt gilt schließlich das selbe...). Natürlich gibt's deutlich schnellere und effizientere Möglichkeiten einen scheiss-Oszi zu implementieren (T'schuldigung) Aber es macht doch keinen Sinn, EINE Komponente herauszupicken und losgelöst vom Gesamtkontext "EDOMI" zu betrachten. Der Oszi könnte ja glatt eine Aufgabe haben und 1000 weitere LBS antriggern etc..

Edit:
Übrigens: Wenn Du Deine Logik geschickt aufbaust, genügt m.E. 1 Oszi - quasi als Taktgeber für alles mögliche. Oder kein Oszi, sofern Sekundentakt genügt (System-KO Uhrzeit). Oder Du baust Dir einen EXEC-LBS, der als eigener Prozess vor sich hin läuft und relativ unkontrolliert aber dafür performant seine Ausgänge "taktet". Dieses Taktsignal verwendest Du dann gemeinsam(!) für alles mögliche...

[WagoKlemme]

Ja, aber Deine Wago muss auch keine Visu versorgen und einen grafischen Logikeditor bereitstellen - einschließlich Community-LBS und und und Äppel und Birnen...
[ATTACH=CONFIG]n918810[/ATTACH]

Christian, verzeih, ich schätze deine Arbeit sehr. Ich wollte dich auch nicht kritisieren oder reizen, aber das ist keine Diskussion.

Wago:
Tja, so ist das wenn man sich nur in einer Sache auskennt.
Kein weiterer Kommentar.
Um es mit deinen Worten zu sagen nach #33
"Also ich bin jetzt raus hier"

[gaert]

?! Ich habe Deine Argumente nicht als Kritik verstanden! Was gefällt Dir an meinem Argument nicht?

Ich weiß wirklich nicht, wie ich meinen Standpunkt noch besser formulieren könnte... Die Logik ist eben nicht alles in EDOMI, sondern "nur" eine Facette eines komplexen Gesamtsystems. Also absolut nicht vergleichbar mit einer dedizierten Hardware (z.B. ein Aktor mit Timerfunktion).

Natürlich könnte ich EDOMI auch von Grund auf vollkommen anders designen: Statt über DBs zu kommunizieren, wäre eine gewöhnliche Verwaltung im RAM natürlich wesentlich fixer. Nur geht dieses Konzept in seiner Gesamtheit nicht auf - wir reden hier von einer Client/Server-Anwendung in PHP/JS/etc.! Würde die Logik also konventionell im RAM verarbeitet werden, wäre das um Faktor 10000 schneller - klar. Nur wie erfährt die Visu davon? In PHP ist es nicht (oder nur sehr rudimentär) möglich, prozessübergreifend zu "kommunizieren".

Mit anderen Worten: EDOMI ist kein Echtzeitsystem. Und EDOMI braucht tatsächlich Ressourcen Und ein Oszi/Timer/etc. ist eben NICHT nur eine dumme Schleife, sondern muss sich wie jeder andere LBS auch an die Gesamtumstände anpassen.

Du machst m.E. den Fehler Deine Aufgabenstellungen zu sehr in den Vordergrund zu stellen: Du wünscht Dir quasi einen Ersatz für Deine Wago-Einheit - alles andere ist nicht so wichtig für Dich. Aber andere Nutzer von EDOMI sehen es möglicherweise genau umgekehrt: Die wollen nur die Visu nutzen und haben mit Logik/Oszis/etc. kaum etwas am Hut. Und ich versuche ganz einfach EDOMI für alle Szenarien verwendbar zu halten - natürlich gibt es dadurch hier und da gewissen Einschränkungen in Sachen Performance. Dies liegt in der Natur der Sache! Oder anders formuliert: Die Logik ist EINE Komponente von EDOMI - nicht DIE Hauptkomponente.

[gaert]

Tja, so ist das wenn man sich nur in einer Sache auskennt.
Kein weiterer Kommentar.

Was meinst Du damit?! Verstehe ich nicht...

Ich kenne dieses "Wago"-Ding nicht, das ist richtig. Aber ich bezweifle einfach mal sehr stark, dass falls das Teil eine Visu bereitstellt, diese auch nur 1% der Funktionalität und Freiheit der EDOMI-Visu bieten kann

Falls Du mich provozieren wolltest: Ich kenne mich mit Dingen aus, an die Du nicht im Traum denken würdest in diesem Zusammenhang Ich bin kein nerdiger Programmierer, der im Keller PHP coded

[coliflower]

Hey Leute macht euch doch nicht unnötig gegenseitig fertig

[gaert]

Habe ich auch nicht vor Ich verstehe nicht, warum Wagoklemme sich plötzlich so merkwürdig geäußert hat - m.E. habe ich durchaus sachlich mit einer Portion Humor argumentiert...

[saegefisch]

Eine allgemeine Frage zum Verständnis bei der Nutzung von Oszillatoren. Idee ist noch ein Regelmäßiger Trigger für einen oder beliebig viele Zwecke. Für meine bisherigen Tests habe ich entweder die System-Trigger (Uhrzeit = jede Sekunde) oder viertelstündlich verwendet ohne eigenen Trigger. Für andere Zwecke brauchte ich minütlich und 5-minütlich. Da die systemseitig nicht verfügbar sind, habe ich mir die über zwei Oszillatoren in zentrale KO gelegt. Damit stehen sie mir systemweit zur Verfügung. Diese Trigger habe ich dann in mehreren/beliebig vielen Logiken in der Eingangsbox als Auslöser eingebunden. Damit habe ich alle meine Bedarfe erfüllt. Habe mich nur gefragt, warum minütlich und 5minütlich ( und von mir aus auch 10-minütlich) nicht auch systemeigen sind - dann wären wohl die meisten Trigger-Anforderungen abgedeckt. Ok, bei Verwendung in vielen Logiken könnte es dann kleine CPU-Peaks geben, keine Lastverteilung auf der Zeitachse. Aber: sowhat?

Aber wofür könnte man noch mehr Trigger im Haushalt brauchen? Sicher gibt es bestimmte Logiken, die hier und da vielleicht noch eine spezielle Lösung mit einem Timer brauchen. Alles was flackern oder blinken soll, geht über Animationen. Ich lasse mich gerne inspirieren. Oder ich habe den Zweck eine Oszillators - im Kontext der Haussteuerung (!) - noch nicht verstanden?

[wintermute]

Oder ich habe den Zweck eine Oszillators - im Kontext der Haussteuerung (!) - noch nicht verstanden?

Uhmnoe, ich gebe Dir da nen FullACK.
Urspruenglich aufgefallen ist mir das, weil auch mir der minuetliche Takt fehlte. Aber zum Testen eigener LBS arbeite ich auch gern mit hoeheren Frequenzen (1-2s oder so) um bestimmte Ereignisse zu triggern. Es bleibt aber beim FullACK, weil letzteres nix mit Gebaeudesteuerung sondern mit Entwicklung und/oder Simulation zu tun hat

gruesse :: Michael

[gaert]

FullACK auch von mir

Aaaaaaaaber: Es gibt Neuigkeiten! Ich habe die Logikengine überarbeitet - das Ergebnis mit den üblichen 64 Oszis auf meiner alten Hardware (VM, iMac 2007) sieht so aus:

Bildschirmfoto 2016-02-27 um 21.26.36.png


Der Haken an der Sache: Ich muss alle LBS, die "laufen" können (also Oszillator, Timer, Trigger, etc.) etwas überarbeiten - hält sich aber in Grenzen.

Das Prinzip ist folgendes:
Bislang wurde ein "laufender" LBS stur in festen Abständen aufgerufen, damit der LBS z.B. prüfen kann, ob eine Ziel-Zeit erreicht ist (Timer). Dies geschah unabhängig davon, welche Zielzeit überhaupt erwartet wird - d.h. ein Timer der z.B. 10 Sekunden wartet wurde hunderte Male aufgerufen, damit der LBS prüfen kann ob das Ziel erreicht worden ist.

Neu implementiert ist nun die Funktion setLogicElementStatus() - bislang konnte man den Status des LBS nur auf 0 (läuft nicht) oder 1 (läuft) setzen. Jetzt kann man bei Bedarf noch einen 3. Parameter übergeben: Die Verzögerung in Millisekunden bis zum nächsten (automatischen) Aufruf des LBS. Klingt zunächst wenig spektakulär, hat aber einen enormen Effekt!

Beispiel exemplarisch für einen Timer:
Der LBS wird von einem KO getriggert, setzt gewisse Werte und soll dann starten (laufen). Dazu setzte man bislang den Status=1 (dies geht natürlich nach wie vor) - jetzt übergibt man zusätzlich quasi noch die Zeitspanne, in der der LBS garantiert nichts zu tun hat: Hier also die Timer-Dauer.

Sollte aus irgendwelchen Gründen diese Verzögerung zu kurz gewählt sein, gibt's ein automatisches Fallback auf das bisherige Vorgehen - d.h. der LBS wird wie gehabt zyklisch abgefragt, bis das Ziel erreicht ist. Es ändert sich also rein garnichts an bestehenden LBS, man hat jedoch die Möglichkeit die Performance auf diese Weise zu optimieren.

Übrigens: Dies alles ist natürlich vollkommen unabhängig von Änderungen an den Eingängen während der Laufzeit etc.! Wenn also der LBS z.B. erst nach 10.000 ms automatisch(!) abgefragt wird, werden "Telegramme", die während dieser "Totzeit" eintreffen selbstverständlich berücksichtigt.

So, das war nur ein kurzer Abriss - ich muss noch weiter testen und implementieren

PS: Der Performance-Gewinn korreliert natürlich mit der Frequenz (beim Oszi), d.h. wenn der Oszi mit 1ms-Intervall "schwingt" (was er eh nicht schaffen würde) hätte man logischer Weise nichts gewonnen. Aber bei z.B. 1000ms sieht dies schon ganz anders aus

[wintermute]

Ich habe die Logikengine überarbeitet...

[gaert]

saegefisch
Weitere Trigger gibt es aus einem ganz einfachen Grund (noch) nicht: Ich hatte noch keine Lust diese zu Implementieren Weil ich noch keinen Bedarf hatte... Steht aber natürlich auf meiner Liste (irgendwo)