Fragen zur LBS Erstellung

[gaert]

Im Grunde ist's Deine Entscheidung: Wenn der LBS-Teil beschäftigt ist, wartet die gesamte Logik (alles Auflaufende wird währenddessen natürlich ge-queued). Dabei spielen Nanosekunden allerdings nicht wirklich eine Rolle - so schnell ist die Logikengine nicht wirklich... Es ist halt nur so, dass der LBS-Teil eher für recht einfache (schnelle) Dinge vorgesehen ist - wie z.B. Gatter und Co.

Ich denke msg_queue wird am Ende schneller sein, als die LBS-"Variablen" selbst - denn diese erfordern DB-Zugriffe und sind daher alles andere als Lichtgeschwindigkeit. Ideal wäre sicher shared-memory in Kombination mit einer selbstgebastelten Queue. Dies sollte relativ einfach implementierbar sein, denn shared-memory kann auch mit Arrays umgehen (serialized zumindest).

[jonofe]

Habs mal gemessen:

msg_queue erzeugen: ~ 0,0001 - 0,0002 Sekunden
msg_send: ~0,00001 - 0,00002 Sekunden

zum Vergleich ein getLogicEingangDataAll(): ~0,0005 - 0,00065 Sekunden

Sieht für mich akzeptabel aus. Oder?

[gaert]

Genau Das habe ich schon vermutet - DB-Zugriffe (getLogicEingangDataAll) dauern signifikant länger...

[jonofe]

Auf stackoverflow.com wird es ganz gut beschrieben:

When using shared memory with consideration for possible race-conditions where one process writes to it and another reads from it, something to bear in mind. There is an associated risk of using the former, suppose two processes are using it, one to write to it, the other to read from it, the one that is writing dies due to abnormal condition, the process reading it could hang or crash.
Shared memory can be deemed as faster (low overhead, high volume of data passing) then queues. But queues on the other hand, requires high overhead (the set up for making a queue to be permanent etc) with low volume of data.
The onus with shared memory is that you have to implement synchronization in order to be thread safe. Have a look at the excellent article by Beej on IPC.

When using Queues, they are thread-safe, and not alone that, messages are held in the queue regardless of the outcome, suppose two processes are using the queue, when one process writes to it (in a form of a message) and the other process that is about to read from it gets to die or killed off due to a crash or abnormal condition under a such circumstance, that message is still in place, the other process if restarted can read from the queue, i.e. no data is lost.

Solange die Performance nicht leidet, werde ich wohl bei der message queue bleiben: KISS - Keep It Simple and Stupid

[gaert]

In der Tat: Shared-memory ist "kompliziert" - daher ja meine Warnung... EDOMI nutzt übrigens ne Menge davon - allerdings nur zur Kommunikation zwischen den einzelnen Prozessen, also sehr kontrolliert und statisch. Queues sind natürlich wesentlich sicherer und einfacher in der Handhabung - aber shared-memory ist dafür unschlagbar schnell

[wintermute]

Werde mir aber memcached mal ansehen. Den Vorteil den ich bei shared memory sehen ist die Performance. Da sich aber ein ssh-Befehl anschließt, ist diese Performancesteigerung vermutlich über den eigentlichen Schaltvorgang hinweg kaum messbar.

Ja, damit hast du vermutlich recht. Der groesste memcache Nachteil (zumindest im Edomi Umfeld) ist IMHO die Tatsache, dass man ihn nachinstallieren muss - das find ich eigentlich nicht so prickelnd fuer den Normal-User. Anderer Nachteil ist der mit der benoetigten TCP-Verbindung zum lokalen Daemon erzeugte Overhead, das ist bei "kurz laufenden" Skripten nicht optimal, aber halt prima fuer EXEC-Daemonen geeignet...
Ausgehend von Deinen Benchmarks werd ich mir jedenfalls das mit den Queues mal genauer anschauen, koennte hilfreich sein. Danke dafuer

gruesse :: Michael

[jonofe]

Ja, damit hast du vermutlich recht. Der groesste memcache Nachteil (zumindest im Edomi Umfeld) ist IMHO die Tatsache, dass man ihn nachinstallieren muss.
gruesse :: Michael

Leider muss man das bei der MessageQueue auch.

sudo yum install php-process

Gleiches gilt übrigens auch für die ssh2 extension:

sudo -s
yum install gcc php-devel php-pear libssh2 libssh2-devel
pecl install -f ssh2
touch /etc/php.d/ssh2.ini
echo extension=ssh2.so > /etc/php.d/ssh2.ini
/etc/init.d/httpd restart

Danach edomi restarten.

Vielleicht können diese Module in Zukunft ja in der edomi CentOS Distribution vorinstalliert sein. Ich sehe zumindest auch für weitere Logikbausteine möglichen Bedarf. Und ssh für die Einbindung anderer Geräte könnte auch interessant sein. Ich mach darüber z.B. neben der mPower IP Steckdosen Ansteuerung auch eine Sprachausgabe auf verschiedenen RPIs.

[gaert]

Ungern... EDOMI soll eher schlank bleiben - aber natürlich kann jeder sein EDOMI konfigurieren und ergänzen wie er möchte. Sonst haben am Ende 90% der Nutzer alle möglichen überflüssigen (für diese User) Libs installiert - und genau das möchte ich möglichst vermeiden.

Unabhängig davon jedoch wäre es hilfreich, wenn sich jemand mal mit CentOS 7 und PHP 7 auseinandersetzen möchte. Oder generell mal verschiedene Distros testet (auch in "verrückten" Konfigurationen, also z.B. mit selbst installiertem AMP-Stack usw.). Die "Installation" von EDOMI selbst beschränkt sich ja im Grunde auf das Extrahieren eines TAR-Archivs. Es spricht also prinzipiell nichts dagegen, den tollen Installer ganz zu beerdigen (oder nur für Linux-Laien verfügbar zu halten). Auf diese Weise könnten quasi verschiedene EDOMI-Versionen verteilt werden: Home, Premium, Pro... Und die Premium-Pro-Version enthält dann eben Unterstützung für SSH2 etc.

[Ferengi]

hab vorgestern ohne groß nachzudenken versucht das ganze auf debian jessie zu installieren, zuerst sah alles gut aus, bis ich bemerkt habe das der bcompiler ja nur bis zu php5.3 glaub ich wars funktioniert. Da wurde mir der Aufwand dann zu groß (läuft ja auf centos auch ganz gut ;-). Falls der Bcompiler mal nicht mehr benötigt wird stelle ich mich aber gerne für Tests unter debian zu Verfügung.

[gaert]

bcompiler wird eigentlich garnicht benötigt - der Bursche dient nur dazu, den EDOMI "Kernel" zu verschleiern... (Bis meine Gedankengänge zum Thema Lizensierung etc. vollendet sind)

[SeatSLF]

Ungern... EDOMI soll eher schlank bleiben - aber natürlich kann jeder sein EDOMI konfigurieren und ergänzen wie er möchte. Sonst haben am Ende 90% der Nutzer alle möglichen überflüssigen (für diese User) Libs installiert - und genau das möchte ich möglichst vermeiden.

Unabhängig davon jedoch wäre es hilfreich, wenn sich jemand mal mit CentOS 7 und PHP 7 auseinandersetzen möchte. Oder generell mal verschiedene Distros testet (auch in "verrückten" Konfigurationen, also z.B. mit selbst installiertem AMP-Stack usw.). Die "Installation" von EDOMI selbst beschränkt sich ja im Grunde auf das Extrahieren eines TAR-Archivs. Es spricht also prinzipiell nichts dagegen, den tollen Installer ganz zu beerdigen (oder nur für Linux-Laien verfügbar zu halten). Auf diese Weise könnten quasi verschiedene EDOMI-Versionen verteilt werden: Home, Premium, Pro... Und die Premium-Pro-Version enthält dann eben Unterstützung für SSH2 etc.

Man sollte erstmal eine gemeinsame Hardware Basis oder ebend verschiedene Gundsysteme 1x Raspi, 2-3 "PC" Systeme etc.

Ich habe als OS jetzt 6.7, der Kernel scheint ca 20% Prozent "effizienter" wie es scheint, bei einem gleichen System.
Unter 6.5 hatte ich so ca alle 7-8 Stunden Load Peaks, daher habe ich mit Hilfe von Wintermute da ein wenig rumprobiert.
(Mein System ist ein Asus Board mit Intel N3050, 4Gb RAM und einer SSD)

kernel 3.1 war leider nicht so effektiv auf meinem System wie der 2.6 aus CentOS 6.7, aber die Peaks hatte ich damit noch nicht weg.

Am Ende haben habe ich per GRUB das ACPI ausgeschaltet, nun läuft es völlig geschmeidig.

Ich hoffe du verstehst auf was ich hinaus möchte, wenn man jetzt solche Tests mit anderen unterbauten macht,
sollte man schauen das die Hardware dann immer die selbe ist.

Achja und nebenbei CentOS 6.7 funktioniert bestens mit Edomi,
du scheinst mit deinem Installer die Version des CentOS abzufragen vielleicht kannst du 6.7 ja mit einfügen.

[Winni]

Habe bei der Erstellung von LBS-Bausteinen folgende Probleme und bin auf der Suche nach Lösungen /Vorschlägen:

Ich verwende "interne Variablen", welche wohl auf der Datenbank abgelegt werden, wie z.B. bei Timer-Bausteinen (getLogicElementVar($elementid,$varid)).
Das funktioniert bis zu einem Neustart recht gut, dann aber ist der Inhalt weg..... Kann man solche Daten auch remanent ablegen ohne extern wieder ein KO dranzuhängen, was auch als Eingang zu Verfügung steht? Ich hinterlege hier aktuelle eine Reihe von Daten, wovon aber nur ein Teil an einem Ausgang verfügbar sein soll. Klar kann ich wohl auch eine eigene DB generieren oder ein File schreiben, das wollte ich aber eigentlich nicht.

Timerbaustein: Sollte der Rechner, aus welchen Gründen auch immer einen Neustart hinlegen, läuft der Timerbaustein erstmal nicht mehr. Der vorher gestartete Vorgang (z.B. Gartenbewässerung) wird nicht mehr gestartet. Gibt es hierfür einen Workaround? Ich schließe aktuell bei einem Neutstart alle Ventile, damit ist zwar in diesem Fall das Problem erstmal entschärft, aber evtl. gibt es auch hier irgendeinen Trick, die Timer weiterlaufen zu lassen.....

Winni

[gaert]

Die LBS-Variablen werden in der Tat nicht remanent gespeichert und dies ganz bewusst: Ein Neustart soll die gesamte Logik zurücksetzen (quasi ein Reset).

Du kannst aber mit remanenten KOs arbeiten, siehe z.B. den LBS "Zähler".

Was Deine Bewässerung betrifft: Ich setze diverse Pumpen/Boiler/etc. beim Start grundsätzlich auf "aus" - zur Sicherheit. Alles weitere übernimmt dann die Logik. Ein Neustart soll sich ja gerade wie ein Reset verhalten...

[jonofe]

Noch mal eine grundsätzliche Verständnisfrage:

Situation:

• Ich habe einen LBS mit mehreren Konfigurationsparameter-Eingängen (E2-E13) und einem Trigger-Eingang (E1).
• Ich möchte nun bei einem bestimmten Ereignis (also z.B. in einem Ausgangs-LBS) mehrere Konfigurationsparameter (E2-E13) setzen und dann den Baustein triggern (E1).
• Sind dann beim Ausführen des Bausteins durch den Trigger auf E1 alle Parameter (E2-E13) richtig gesetzt? Oder kann es sein, dass E2-E5 schon geupdatet sind, wenn der Trigger E1 kommt und E6-E13 erst danach geupdated werden?

Wie funktioniert hier der Determinismus? Oder gibt es den nicht und ich muss das mit einer Sequenz machen?

Meine Vermutung/Hoffnung ist, dass der Ausgangs-LBS zunächst komplett ausgeführt wird, bevor der nächste LBS getriggert wird, d.h. es sollten eigentlich alle Eingänge meines LBS die aktuellen Werte haben, wenn er zum nächsten Mal getriggert wird. Aber wie gesagt, hier ist der Wunsch Vater des Gedankens...

Hoffe es ist klar geworden, was ich meine ....

VG
André

[gaert]

Falls ich Dich richtig verstanden habe:

Der LBS wird immer dann getriggert (also aufgerufen), wenn sich an einem seiner Eingänge etwas tut - also z.B. wenn ein KO einen neuen Wert bekommt, oder ein verbundener Ausgang eines anderen LBS gesetzt wird.

Zeitlich betrachtet ist es so, dass z.B. KOs der Reihe nach (Queue) abgearbeitet werden - natürlich in der Reihenfolge in der die KOs gesetzt wurden. Ein "Gleichzeitig" gibt es nicht - EDOMI arbeitet ja event-getriggert!

Mit anderen Worten: Jede einzelne Änderung an einem Eingang führt zu einem Aufruf des LBS. Die Variable $E[id]['refresh'] wird jedoch nur bei dem geänderten Eingang =1 sein - dadurch kann der LBS ermitteln, welcher Eingang zum Aufruf geführt hat.

Was die Ausgänge betrifft verhält es sich im Prinzip genauso, jedoch wird der LBS natürlich zunächst komplett abgearbeitet bevor der nächste LBS getriggert wird. Wenn Du also diverse Ausgänge innerhalb eines "Durchlaufs" (Aufruf) des LBS setzt, passiert zunächst nichts - erst wenn der LBS abgearbeitet ist werden die Ausgänge auch tatsächlich gesetzt. Intern funktioniert das etwas anders als ich jetzt beschrieben habe, denn Ausgänge gibt es eigentlich gar nicht (vielmehr werden direkt die verknüpften Eingänge(!) der anderen LBS gesetzt).

EDIT:
Wenn Du erreichen willst, dass Dein LBS quasi erstmal irgendwelche Parameter "sammelt" und dann eine Aktion ausführt, muss der LBS einen Trigger-Eingang haben - dieser Eingang löst dann die Aktion aus. Denn ansonsten würde es quasi vom Zufall abhängen, ob schon alle Parameter anliegen oder nicht.
Anders verhält es sich allerdings beim Start von EDOMI: Wenn die Parameter als Initialwerte angegeben sind, liegen diese garantiert schon an bevor irgendein KO/LBS diesen LBS triggern wird.