EDOMI - LBS - Diskussion

[vento66]

Das wird notwendig sein, da alle Bausteine in der SQL liegen, die Eingangswerte sind ja auch dort gespeichert.

[wintermute]

Sind sql_connect(); und sql_disconnect(); zwingend notwendig? Wenn ja warum?

Ja, weil zum Beispiel die Abfrage des aktuellen Zustandes eines Einganges schlussendlich eine Datenbankabfrage ist. Weglassen kannst Du das nur wenn Du garantiert ueberhaupt nicht mit Edomi interagieren moechtest, aber dann macht ein Baustein ja auch eher weniger Sinn

[nno]

Ok, macht Sinn. D.h. wenn im ###[LBS]### Block die Eingangswerte mit $E=logic_getInputs($id) bereits abgeholt wurden, muss/kann/soll (?) das im ###[EXEC]### Block nicht nochmal passieren?

[jonofe]

Ok, macht Sinn. D.h. wenn im ###[LBS]### Block die Eingangswerte mit $E=logic_getInputs($id) bereits abgeholt wurden, muss/kann/soll (?) das im ###[EXEC]### Block nicht nochmal passieren?

doch es muss nochmal passieren, da es ein komplett eigenständiger PHP Prozess ist.
Das EXEC Skript weiß erstmal gar nichts und mit dem "require" und dem "sql_connect()" wird es dann an EDOMI "angebunden".

[Winni]

Kann mir jemand weiterhelfen:
Ich möchte eine Funktion sowohl im EXEC, als auch im LBS Teil eines Bausteins verwenden. Es scheint aber nicht zu klappen ?!?
Keine Fehlermeldung und kein Aufruf.
Muss man da was beachten (bin php Anfänger)

[gaert]

LBS und EXEC sind zwar in einer Datei (Logikbaustein) untergebracht, haben haben im echten Betrieb rein garnichts miteinander zu tun: Das EXEC-Script wird vollkommen unabhängig als eigenständiger PHP-Prozess ausgeführt. Am Einfachsten ist es also die entsprechende Funktion zu kopieren - einmal im LBS-Teil und einmal im EXEC-Teil.

Und aufgepasst: Funktionen im LBS-Teil müssen einem bestimmten Namensschema folgen (siehe Hilfe)!

[Winni]

LBS und EXEC sind zwar in einer Datei (Logikbaustein) untergebracht, haben haben im echten Betrieb rein garnichts miteinander zu tun: Das EXEC-Script wird vollkommen unabhängig als eigenständiger PHP-Prozess ausgeführt. Am Einfachsten ist es also die entsprechende Funktion zu kopieren - einmal im LBS-Teil und einmal im EXEC-Teil.

Ist leider ne ziemlich große Routine, muss ich mir was anderes einfallen lassen und werde alles im EXEC-Teil machen.

Und aufgepasst: Funktionen im LBS-Teil müssen einem bestimmten Namensschema folgen (siehe Hilfe)!

Daran hab' ich gedacht.

[jonofe]

große und komplexe Routinen gehören ohnehin in den EXEC Bereich, da sie sonst die EDOMI Logikschleife verzögern. Hängt natürlich vom Inhalt ab. Worum gehts denn konkret?

[Winni]

große und komplexe Routinen gehören ohnehin in den EXEC Bereich, da sie sonst die EDOMI Logikschleife verzögern. Hängt natürlich vom Inhalt ab. Worum gehts denn konkret?

tja, ist so ein Ding, sitze gerade über einer eigenen Anrufliste der Fritzbox. Komplex ist die Routine eigentlich immer, Laufzeitintensiv aber nur bei Abarbeitung von z.B. 400 Einträgen.
Muss abhängig vom Status des aktuellen Anrufs ja in eine Poll-Schleife bis es entweder aufhört zu klingeln, oder der Anruf beendet wird. Deshalb wollte ich die Funktion zum SOAP-Aufruf für die komplette Liste einersaeits im EXEC-Teil haben und für den einzelnen Datensatz im LBS-Teil, auch wegen dem Wiederaufruf... Hab mir aber was anderes ausgedacht....
Wird wohl noch ne Zeit dauern, bis ich da was öffentlich mache...

[Winni]

Fritzbox Anrufliste

Ich habe bei meiner Anrufliste nun einige Fortschritte gemacht, leider musst ich beim Testen feststellen, dass abgehende Anrufe, die nicht angenommen wurden nicht in der Anrufliste von AVM enthalten sind. Ich möchte diese aber unbedingt haben, das hat mit vor einigen Monaten mehrere tausend EUR gespart.
Ich hätte nun vor die KOs von gaert mitzuverwenden um diese Versuche auch in die Liste (die ich in einer eigenen Datgenbank ablegen will) zu berücksichtigen.
Leider fehlt mir ein Event, wenn das Telefonat oder der Versuch beendet wird. Ich bräuchte hier entweder ein weiteres KO, oder evtl. ein Rücksetzen der vorhandenen KOs auf 0.
Hat jemand eine Idee wie ich sonst überprüfen kann, ob der Anrufversuch abgebrochen wurde?

Ergänzung gaert : könntest du in einem KO einfach die Info aus dem Callmonitor zur Verfügung stellen, da sollte alles relevante enhalten sein und ich muss das Rad nicht nochmal erfinden....

Hat sicher erstmal erledigt, hab' rausgefunden, wie ich selber an den Callmonitor komme.

Winni

[Winni]

gaert Ich würde beim mitloggen im LBS gerne die id der LBS-Instanz auf der Logikseite und Evtl die id der Logikseite selber zur Verfügung haben. Geht das irgendwie?

[jonofe]

gaert Ich würde beim mitloggen im LBS gerne die id der LBS-Instanz auf der Logikseite und Evtl die id der Logikseite selber zur Verfügung haben. Geht das irgendwie?

Ich vermute es ist die Variable $id. Die müsstest du dann vermutlich in der debug/logging Routine mit ausgeben.
Vermutlich spielt die ID der Logikseite nur im Editor eine Rolle, somit würde mich wundern, wenn die im LBS Coder verfügbar wäre.

To be confirmed by Christian...

[gaert]

Dem ist nichts hinzuzufügen

[Winni]

Dem ist nichts hinzuzufügen

Wäre dann diese ID im Logfile (als Standardspalte) nicht interessanter als die PID?

[gulp2k]

Hi,

ich bin gerade dabei meinen ersten LBS zu bauen und stolpere über Probleme mit einer externe phplib...
Konkret geht es um Modbus mit phpModbus.

Wenn ich das EXEC script laufen lasse bekomme ich eine Menge Fehler/Warnungen nach dem gleichen Schema:
/usr/local/edomi/main/include/php/ModbusMaster.php | Error: 2048 | Line: 477 | Non-static method IecType::iecBYTE() should not be called statically, assuming $this from incompatible context

Script scheint aber zu laufen und ich bekomme auch ein Ergebnis an A1 angeliefert das plausibel ist.

Ich denke ich muss die Lib anders einbinden aber als PHP Anfänger ist mir nicht ganz klar wie...

Gibt es eigentlich einen besser weg zu entwickeln als:
1. Code im Editor erstellen
2. Copy & Past in Edomi/Logikbaustein und speichern
3. Projekt aktivieren
4. Logikeditor aufrufen und Live werte anschauen.
5. goto 1

?

Danke!