Diskussionsthread EDOMI-Releases/Updates

[gaert]

Es geht mir nicht um rechtliche Aspekte - die sind mir vollkommen wurscht (sonst würde ich EDOMI nicht als Quelltext weltweit zu Verfügung stellen). Vielmehr geht es um die Gemeinschaft der EDOMI-Nutzer, die sicherlich zu einem nicht unerheblichen Teil "nur" Anwender sind oder sein möchten. Daher betrachte ich mich auch als Hauptverantwortlichen dafür, dass EDOMI möglichst harmonisch und gleichartig auf allen (geeigneten) System läuft und weiterhin laufen wird.

Zur Sache: Ich verstehe nicht, was ein "Config-LBS" bewirken soll. Und was ist ein Visu-LBS? (vermutlich meinst Du Visuelemente)

Im Detail ist das alles nicht so trivial wie es vielleicht den Anschein hat. Zur Zeit baue ich z.B. eine vollkommen neue Logikengine (daher werden die genannten Funktionen auch nicht mehr funktionieren) und sehe immer wieder, dass es in vielen Bereichen äußerst komplex wird. Funkt nun irgendein reingebastelter Spezial-"LBS" direkt in der Datenbank herum, kommt es zu für mich nicht mehr reproduzierbaren Ereignissen und zeitlichen Inkonsistenzen (weil ich bzw. EDOMI ja nicht damit rechnen kann).

Also: Bitte habe Verständnis dafür, dass es gute Gründe gibt warum EDOMI ist wie es ist. Was Du hier kostenlos nutzt ist eine Software, die über viele Jahre gereift ist - mit Rückschlägen, schlaflosen Nächten und zeitweise auch einem gewissen Druck der Öffentlichkeit. Entwickelt habe ich das alles primär für meine Zwecke - und doch habe ich mich hingebungsvoll den meisten Anliegen und Wünschen der Nutzer hier angenommen (obwohl ich viele der gewünschten Funktionen nicht benötige).

MQTT kenne ich nicht (im Detail), brauche ich nicht und will ich auch nicht (EDOMI ist KNX!). Daher werde ich das (zumindest aktuell) auch nicht implementieren. Was Dir vorschwebt ist offenbar eine weitere Schnittstelle zur Aussenwelt, mit der man mal fix einen MQTT-Server u.d.G. ankoppeln kann. Aber natürlich universell gehalten für alles was da noch kommen mag. Das ist erheblich mehr Aufwand, als man vielleicht denken könnte - insbesondere das Testen unter Realbedingungen. Klar kann jeder Copy-Paste-Coder sich irgendwelche ergoogelten Codeschnippsel zusammen klicken - läuft! Aber läuft das auch unter allen Bedingungen? "Immer Sonntags um 18 Uhr spinnt die ZSU"...

Abschließend sei noch eine persönliche Anmerkung erlaubt: Komm' mir nicht blöd, mein Freund. Ich werfe Dir nichts an den Kopf und lasse mir schon garnicht vorschreiben, was ich zu recherchieren habe. Also immer locker bleiben und vor dem Absenden nochmal gegenlesen! Der Ton macht die Musik...

[sipiyou]

Ich fasse nochmal das ganze zusammen:

A) Planst du, dass Community-LBS eine eigene Konfigurationsoberfläche unterhalb von Edomi bekommen ? Das hat nichts mit der Konfiguration des Edomi-Basis-Systems zutun, sondern ist nur für die LBS.

[Siehe Verwaltung_Konfig.png im Anhang]

Sprich: Es gibt neben Visu-LBS, Logik-LBS auch "Config-LBS", die von der Community frei programmiert werden können und eine zentrale Verwaltung der Daten,
die für das jeweilige LBS/VSE erforderlich sind zulassen.

B) Was spricht dagegen, die beiden Funktionen für die LBS freizugeben ?

Durch diese Punkte können LBS wesentlich effizienter Funktionen - wie MQTT / AVS und alles, wo ein einfaches Mapping KO <-> externe Transaktion erfordert - implementieren und vorallem ist die Verwaltung dieser Funktionen wesentlich einfacher gestalten, als für jede Transaktion eine LBS-Kopie laufen zu haben.

Da du mir wieder "kein Opensource"-Argumente an den Kopf wirfst, solltest du dich vielleicht über das geltende Recht informieren. Selbst reverse Engineering ist seitens des Gesetzgebers erlaubt und da sprechen wir von ganz anderen Dingen, als 5 Skript-Dateien anschauen und eine Erweiterung für das System programmieren.

https://www.roedl.de/themen/geschgeh...se-engineering

Ich möchte mich weder mit Dir streiten, noch belehren. Aber ich bin auch nicht dein Feind. Ich habe einige Punkte, die mit relativ wenig Aufwand von Dir frei gegeben werden können, (B existiert bereits, A lässt sich mit wenig Aufwand realisieren, wenn das nicht sogar schon existiert).

Hierdurch profitiert letzendlich dein Edomi-Projekt und bietet auch für künftige Projekte ganz neue Möglichkeiten.

Falls du dir das funktionierende Konzept anschauen möchtest, kann ich dir gerne per Teamviewer das ganze inkl. der dynamischen Diagloge, die im Konfigurations-Bereich gut angesiedelt wären zeigen.

[gaert]

Irgendwie verstehe ich das alles nicht… EDOMI wird mittels der Adminseite konfiguriert und das wird auch so bleiben.

Undokumentierte Funktionen stehen einem LBS nicht zu Verfügung! Im LBS sind nur PHP-eigene Funktionen und die dokumentierten LBS-Funktionen erlaubt - alles andere kann sich jederzeit ändern und darf nicht verwendet werden.

Daher nochmal: Die undokumentierten Funktionen sind deshalb undokumentiert, weil diese nicht öffentlich verfügbar sind. Ganz einfach! Wenn jemand meint er müsse im Quelltext nach Funktionen suchen und diese dann verwenden, handelt derjenige bewusst an der Philosophie vorbei - Stichwort: kein Open Source!

[sipiyou]

Es scheint, als wenn Du mich nicht verstanden hast. In deinem Code findet keine Änderung statt, es ist ein eigenständiges Setup und die einzige Schnittstelle, die von Edomi genutzt wird sind die beiden oben genannten Funktion, die als undokumentierte public Funktionen allen LBS zur Verfügung stehen.

Ich denke, es haben mittlerweile alle verstanden, dass Edomi kein Opensource ist, dadrum geht es hier aber auch nicht.

Die Frage hier ist:

A) ob von deiner Seite aus auch eine offizielle Schnittstelle - wie bei den Visuelementen - vorgesehen ist, dass externe Konfigurations-Tools hochgeladen werden können, die sich unter Edomi/Konfigurationen einhaken können.

B) die Funktionen getGADataFromID / writeGA - oder wie diese künftig heissen werden - in die offizielle API freigegeben werden.

C) Die API so erweitert wird, dass man aus einem "Konfigurations-LBS" auf den jetzigen Ausgangsbox-Handler zugreifen kann. Da es logic_callExec gibt, ist das allerdings weitergesponnen und nicht "zwingend" erforderlich.

Allein durch A+B würde sich der Verwaltungs und Konfigurationsaufwand erheblich vereinfachen lassen und es wäre ein großes Plus für Edomi, insbesondere wenn man nicht nur eine Einzimmer-Wohnung mit KNX ausstattet.

Punkt A würde auch eigene Backups vorraussetzen, hier muss sich dann der jeweilige Entwickler dadrum kümmern.

[gaert]

Die genannten Funktionen werden in der nächsten Version ohnehin nicht mehr in dieser Form existieren, daher wird das nicht mehr laufen…

Nochmal: EDOMI ist nicht Open Source! Gefummel am Quelltext sind nicht erwünscht und sorgen i.d.R. für Inkompabilitäten beim nächsten Update. Also Finger weg! Nicht öffentliche Funktionen und Tabellen können sich jederzeit grundlegend ändern.

[sipiyou]

gaert : Planst du in nächster Zeit auch den Zugriff auf den Admin-Bereich als App zu öffnen, sprich die Konfigurations-Sektion in Edomi ?

Ich hab mit Genehmigung von Phillip900 seinen AVS-LBS umgebaut und soweit auch eine Admin aufgebaut, damit die Konfiguration geführt erfolgen kann und Änderungen ohne Edomi-Neustart erfolgen können - es läuft über eine separate DB-Tabelle.

Es wäre schön, wenn das in Edomi "integriert" werden könnte.

Momentan ist es zwar sehr spartanisch, ist aber jetzt schon eine wesentliche Erleichterung und bevor ich hier mehr Zeit reinstecke, ist die Überlegung, ob man es gleich "vernünftig" in Edomi integriert.

Der umgebaute LBS kommuniziert direkt mit der getGADataFromID / writeGA-Funktion von Edomi und in einer künftigen Version könnte man auch die vollständige Integration des Ausgangbausteins anwenden.

[philipp900]

gaert
Wäre es möglich, dass du im "php_errorHandler" in der "main/include/php/config.php" noch eine Überprüfung a la:

if (0 == error_reporting())
{
// Error reporting is currently turned off or suppressed with @
return;
}

einbaust?
Dann könnte man nämlich im LBS mit dem @ Operator bewusst Fehler unterdrücken.

[jonofe]

CentOS.

nur zu Sicherheit: Version 7

[maque]

Hallo,

überlege nicht lange, für den Einstieg gibt es nur eine gute Option: Nimm den Standard.

VG
Matthias

[givemeone]

CentOS.

[marhal]

Hallo alle zusammen,

ich würde gern EDOMI einsetzen, und momentan bin ich bei der Überlegung welches System man nun nutzen soll. Centos ist ja abgekündigt.
Welches System sollte ich nun nutzen. damit ich ein wenig zukunftssicher mit edomi bin nehmen ?

Danke für eure Antwort...

gruß
Marhal

[Glotzkowski]

Okay, danke für den Schubser, Fehler ist gefunden.

Nach dem Upgrade hatte ich den Ordner /usr/local/edomi/www/data/liveproject/cam/archiv

wieder via symbolischen Link auf ein anderes Gerät/Ordner umgelenkt und dabei versehentlich den Ordner /usr/local/edomi/www/data/liveproject/cam/live
gelöscht, sowie wieder neu angelegt aber leider nur mit root-Rechten wodurch edomi scheinbar nicht mehr drauf zugreifen kann.
Nach dem die Rechte des Ordners für alle Benutzer auf rwx geändert wurden, klappt es wieder.

[gaert]

Nein, bei mir funktioniert das problemlos.

[Glotzkowski]

Nach dem Installieren der neusten Version funktioniert bei mir die Live-Ansicht der Kameras (Visuelement Kamera 19 ) nicht mehr.
Anstelle des aktuellen Live-Bildes, wird das letzte Bild des Archivs, dieser Kamera, angezeigt.
Die Vorschau in der Kameraeinstellung und das Visuelement Kameraarchiv 20 funktioniert allerdings einwandfrei.
Kann dies jemand bestätigen?

[gaert]

Die Logikengine wird (vielleicht) bald runderneuert - und dann viel "präziser". Bislang ist das Ergebnis einer Logik manchmal etwas unvorhersehbar, da nicht jeder "Strang" konsequent und strukturiert verfolgt wird, sondern je nach Timing die Ergebnisse variieren können. Das zu beschreiben würde jetzt zu weit führen - es ist kein fehlerhaftes Verhalten, sondern bewußt "ungenau"

Beispiel:
Eine 4-fach Klemme wird mit an E1..4 mit dem gleichen(!) KO befeuert (E1..E4 sind also gleichzeitig auf "refresh"). Dann wird A1 nur einmal auf einen Wert gesetzt, da die Logikengine nur das letzte Setzen eines Ausgangs quasi als Trigger für den nachfolgenden LBS interpretiert.

Verbindet man nun einen Zähler mit A1, wird dieser folglich nur um 1 erhöht. Je nach Interpretation würde man aber eine Erhöhung um 4 erwarten, da schließlich E1..4 jeweils getriggert wurden.

Die neue Logikengine wird nun anders vorgehen (rekursiv), d.h. immer wenn ein Ausgang gesetzt wird, wird der gesamte nachfolgende Logikstrang rekursiv durchlaufen. Der Zähler würde sich also um 4 erhöhen, da A1 4 mal hintereinander getriggert werden würde.

Da sähe dann so aus:

Bildschirmfoto 2021-03-18 um 12.34.26.png

Ich arbeite noch daran, aber ich denke das wird durchaus sinnvoll sein. Die Performance wird übrigens nicht beeinträchtigt. Allerdings könnte es nach einigen 1000 Rekursionsebenen ein PHP-Speicherproblem geben. Das muss ich noch irgendwie abfangen (und dann quasi auf die alte Version umswitchen), was nicht so einfach ist (PHP kann dies nicht catchen). Allerdings ist dieses Szenario wohl recht unwahrscheinlich - in der Defaulteinstellung (Speicherreservierung) schafft man so um die 3000 Ebenen. Das würde bedeuten, dass man eine Verkettung von 3000 LBS hintereinander konstruiert hat (also nicht die gesamte Anzahl an LBS, sondern eine serielle Verknüpfung Ax->Ex mal 3000).