Diskussionsthread EDOMI-Releases/Updates

[wisoxiko]

Hi, bei mir funktionier das Monitor Log nicht mehr. Ich habe das gefühl, das dies seit v 1.59 der Fall ist. Hat das sonst noch jemand festgestellt? Oder muss ich das Problem bei mir suchen?

Gruess Tom

[benji]

Hi,

ich hab 1.60 auf einem EDOMI installiert wo derzeit noch ein Loxone dabei hängt. Dort gab es richtig Probleme mit Fehlern beim KNX. Läuft bisher jetzt ohne Fehler durch, sieht also klasse aus.

Zuhause gab es nur alle 2 Tage einen Fehler, dort muss ich dann abwarten.

Gruß

[Brick]

1.60... läuft.. endlich wieder der grüne Kreis... (ist mir wirklich abgegangen!)
Rest zeigt sich mit der Zeit !

Vielen Dank

Gruß Martin

[wintermute]

Schonmal vorab der vorläufige Endstand...

[gaert]

Schonmal vorab der vorläufige Endstand...

Funktionen für Logikbausteine mit EXEC-Script Wichtig: Einige der folgenden Funktionen sind ausschließlich für die Verwendung innerhalb eines EXEC-Scripts geeignet.
logic_callExec(LBSID,$id[,$multitasking]) Alias: callLogicFunctionExec	Startet ggf. das EXEC-Script der LBS-Instanz $id. LBSID: Platzhalter für die LBS-ID (nicht verändern!) $multitasking (optional): true: das EXEC-Script darf ggf. mehrfach gestartet werden false: das EXEC-Script wird nur einmal gestartet (alle Aufrufe der Funktion werden ignoriert, solange das EXEC-Script ausgeführt wird) Hinweis: Wird dieser Parameter nicht angegeben, entspricht dies dem Wert "false". Hinweis: Der LBS wartet nicht auf die Ausführung des EXEC-Scripts: Das EXEC-Script wird im Hintergrund gestartet und die Abarbeitung des LBS-Abschnitts wird unmittelbar fortgesetzt.
logic_getStateExec($id)	Liefert den aktuellen Status des EXEC-Scripts der LBS-Instanz $id zurück. Rückgabe: INTEGER (im Fehlerfall wird NULL zurückgegeben) 0=EXEC-Script wird nicht ausgeführt (bzw. wurde beendet) 1=EXEC-Script wird gerade gestartet (i.d.R. nur für wenige Millisekunden) 2=EXEC-Script wird ausgeführt Hinweis: Wird ein EXEC-Script mehrfach gestartet (s.o.), wird stets der Zustand des zuletzt gestarteten (oder beendeten) EXEC-Scripts zurückgegeben. Bei einem fehlerhaften EXEC-Script wird der Status zunächst 1 sein, anschließend 2 und unmittelbar danach 0 (da das Script aufgrund eines Fehlers beendet wurde).
logic_setInputsQueued($id,$E)	Speichert alle aktuellen Eingangsdaten der LBS-Instanz $id in einer Queue, um eine asynchrone Verarbeitung der Eingangsdaten in einem EXEC-Script zu ermöglichen. $E: Array der Eingangsdaten, i.d.R. das zurückgegebene Array der Funktion logic_getInputs() Hinweis: Die Funktion generiert die Eingangsdaten nicht selbst, sondern erwartet das von der Funktion logic_getInputs() zurückgegebene Array als Parameter $E. Achtung: Bei der Verwendung dieser Funktion ist darauf zu achten, dass die Queue regelmäßig abgefragt bzw. geleert wird (s.u.). Wichtig: Diese Funktion sollte ausschließlich im LBS-Abschnitt verwendet werden.
logic_getInputsQueued($id[,$fallback])	Gibt alle Eingangsdaten der LBS-Instanz $id aus der Queue zurück und entfernt diese Eingangsdaten aus der Queue. Es werden stets die "ältesten" Eingangsdaten aus der Queue zurückgegeben. Die aktuellsten verfügbaren Daten werden zuletzt zurückgegeben. $fallback (optional): true: Sind keine Eingangsdaten in der Queue verfügbar, verhält sich die Funktion wie logic_getInputs() - d.h. es werden die aktuellen Eingangsdaten (asynchron) zurückgegeben. false: Sind keine Eingangsdaten in der Queue verfügbar, gibt die Funktion "false" zurück. Hinweis: Wird dieser Parameter nicht angegeben, entspricht dies dem Wert "false". Rückgabe: ARRAY[Eingang]['value';'refresh'] (im Fehlerfall wird FALSE zurückgegeben) Eingang: Nr. des Eingangs (1..∞) 'value': aktueller Wert am Eingang 'refresh': 1=Eingang wurde aktualisiert 0=Eingang wurde nicht aktualisiert Achtung: Nach der Rückgabe der Eingangsdaten aus der Queue werden die entsprechenden Daten aus der Queue entfernt. Ein erneuter Aufruf liefert bereits die nächsten verfügbaren Eingangsdaten aus der Queue zurück. Diese Funktion sollte daher i.d.R. nur einmal pro Schleifenzyklus im EXEC-Script aufgerufen werden. Wichtig: Diese Funktion sollte ausschließlich in einem EXEC-Script verwendet werden.
logic_deleteInputsQueued($id)	Leert die Queue der LBS-Instanz $id, sämtliche Eingangsdaten werden aus der Queue entfernt. Hinweis: Beim Beenden des EXEC-Scripts wird die Queue automatisch geleert.
logic_setOutputQueued($id,$ausgang,$value)	Wie logic_setOutput(), jedoch wird das Setzen des Ausgangswertes in einer Queue zwischengespeichert. Wenn ein Ausgang sehr häufig in kurzer Zeit auf einen Wert gesetzt werden soll, kann diese Funktion in einem EXEC-Script verwendet werden. Der Aufruf dieser Funktion ist zwar weniger performant, jedoch wird jeder Aufruf garantiert wirksam umgesetzt. Hinweis: Diese Funktion verwendet die selbe Queue wie z.B. Telegramme, Visuelemente, etc. - d.h. bei einer sehr "hochfrequenten" Nutzung dieser Funktion, wird die Abarbeitung von Telegrammen etc. entsprechend verzögert erfolgen! Wichtig: Diese Funktion darf ausschließlich in einem EXEC-Script verwendet werden.
logic_dbKeepalive()	Diese Funktion dient ggf. zur Aufrechterhaltung der Datenbank-Verbindung (u.U. wichtig für EXEC-Scripte). Einige der o.g. Funktionen greifen intern auf eine Datenbank zu. Die Datenbank-Engine trennt jedoch die Verbindung, sobald länger als 8 Stunden keinerlei Zugriff erfolgt - der Aufruf der o.g. Funktionen innerhalb eines EXEC-Scripts(!) wird dann u.U. scheitern! Es ist daher ggf. dafür zu sorgen, dass z.B. stündlich ein Datenbank-Zugriff erfolgt, um die Verbindung aufrecht zu erhalten. Die kann z.B. durch einen zyklischen Aufruf (z.B. alle 60 Minuten) dieser Funktion erfolgen. Hinweis: In der Regel ist die Verwendung dieser Funktion nicht erforderlich: Eine (Endlos-)Schleife im EXEC-Script sollte stets in der Form "while (getSysInfo(1)>=1)" implementiert werden (siehe Beispiel "EXEC-Script als Dämon" ⇗), damit der Prozess beim Beenden von EDOMI kontrolliert beendet wird. Die Funktion "getSysInfo(1)" sorgt dabei bereits für eine Aufrechterhaltung der Datenbank-Verbindung. Wichtig: Diese Funktion darf ausschließlich in einem EXEC-Script verwendet werden.

EDIT: $fallback in logic_getInputsQueued() ergänzt.

[wintermute]

Doch, mach ich gerne! Wird mal Zeit, das alles ein wenig aufzuraeumen

[gaert]

Nein, Du musst die Funktionen ja nicht nutzen

Für logic_callExec() wird's noch einen weiteren Parameter geben, der festlegt ob das EXEC-Script mehrfach gestartet werden darf. Per Default ist der Parameter "false", d.h. es ist nur 1 Start erlaubt. Hier muss ggf. der ein oder andere LBS dann angepasst werden...

[wintermute]

Toll, kann ich alle meine LBS endlich mal neu basteln

[gaert]

Gute Nachrichten für EXEC-LBS-Entwickler: Ich bastel gerade eine Funktion zum Prüfen des Status (logic_getStateExec) - dadurch kann man abfragen, ob das EXEC-Script gestartet wurde, läuft oder beendet wurde.

Ausserdem kommt wahrscheinlich noch eine Art Queue dazu für die Eingänge, so dass auch das EXEC-Script keine Eingangswerte mehr verpassen kann (die Logic-Engine arbeitet ja quasi asynchron am EXEC-Script vorbei).

Dies dürfte die LBS-Entwicklung nicht unerheblich eleganter machen

[ggt]

Aufgrund der o.g. Komplexität habe ich jetzt erstmal eine einfache Variante gemacht, die den Trigger des Archivs nimmst und man zusätzlich x,y, Breite, Höhe und eine Vergrößerung in % über LBS Eingänge angibt. Damit lässt sich dann recht einfach der Bildausschnitt generieren.

Andrè jonofe danke für den LBS 19001577, damit passt jetzt die 1.59 wieder zur 1.58

[ibase]

nur so am Rande mal eine Info …
beim Passwort im Backend spielt es bei mir keine Rolle wie ich das Passwort schreibe (nur die Buchstaben) ob klein oder groß.
Bsp.: Passwort oder PASSWORT oder PaSswoRT das funktioniert immer. Nur wenn ich bei den Zahlen mich vertippe, oder durch die hinterlegten Sonderzeichen ersetze
1=! 2=" 3=§ usw. dann wird das Passwort nicht angenommen.

[Brick]

Jaaaa.. is ja gut.. habs verstanden (und die Hilfe nicht bemüht)

[gaert]

Steht sogar in der Hilfe

• KO: Steuerung der Aufnahme
  • mit diesem optionalen KO wird die Aufnahme aktiviert oder deaktiviert
  • der KO-Wert "0" deaktiviert die Aufnahme, ein KO-Wert von "1" aktiviert die Aufnahme
  • Hinweis: Wird dieses KO nicht angegeben, erfolgt eine dauerhafte Aufnahme.
  • Achtung: Bei einer Steuerung der Aufnahme mit Hilfe des KOs kann die entsprechende Reaktion bis zu 1 Sekunde verzögert erfolgen (das KO wird sekündlich abgefragt)!

[Brick]

Ahsooo..

[gaert]

ich fühl mich grad wie der dümmste Mensch auf Erden...

Sag' das mal nicht - was meinst Du, wie oft ich bei der Fehlersuche schon über meine eigenen Implementierungen gestolpert bin