Diskussionsthread EDOMI-Releases/Updates

[givemeone]

CentOS.

[maque]

Hallo,

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

VG
Matthias

[jonofe]

CentOS.

nur zu Sicherheit: Version 7

[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.

[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.

[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]

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]

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]

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]

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 habe Dir gesagt, dass ich nicht dein Feind bin, das macht mich aber auch nicht zu deinem Freund. Meinst du, dass dieser Rundumschlag wirklich passend ist ?
Auch dieser "Copy/Paste-Coder" Nebensatz ist ein unnötiger Schlag in die Gesichter der Leute, die irgendwas für Edomi auf die Beine gestellt haben, womit du übrigens auch wirbst.

Ich erachte es als Respektlos an, wenn ein konstruktiver Wunsch, immer wieder mit den Kommentaren "kein opensource" abgestempelt wird.
Die Musik folgt bekanntlich dem Takt. Auch jetzt werde ich nicht weiter auf deinen Takt eingehen und bitte dich erneut, sachlich zu bleiben. Das ist nicht zuviel verlangt.

Ich sage nicht, dass du MQTT implementieren sollst, das wird schon die Community machen (bzw. hat es). Dass Edomi nicht nur für KNX genutzt wird, siehst du bereits an den vielen Bausteinen, die sonstwas anbinden.

Deine Bedenken bzgl. der Stabilität verstehe ich nicht. Ein Entwickler, der ein LBS/VSE für Edomi programmiert ist für die Gesamtstabilität verantwortlich. Das hat doch nichts mit Dir zutun. Wenn ein Baustein jetzt Mist baut, kann Edomi jetzt auch schon instabil werden. So gesehen dürfte es garkeine externen Bausteine geben.

Das jetzt verfügbare sql_call Kommando kann übrigens wesentlich mehr Schaden anrichten als die beiden Funktionen, die nur definierten Zugriff auf Edomi erlauben, wie z.B. eben die beiden Funktionen um auf die KO's zugreifen zu können.

Dass du diese geändert hast / ändern wirst ist hier doch auch kein Weltuntergang, aber was spricht dagegen, diese für die API freizugeben ? Was ändert es an der Gesamt-Stabilität, dass ein LBS direkt den KO-Wert über die ID auslesen kann oder diesem einen Wert zuweisen kann ?

Ein "Config-LBS" wäre ein Baustein, der sich wie in meiner Grafik unter der Verwaltungs-Oberfläche eingebunden wird. Was dort konfiguriert werden kann ist dem jeweiligen Baustein überlassen.

Nochmal: Lass uns bitte das Thema konstruktiv angehen und wenn du etwas nicht verstehst, erkläre ich es Dir auch gerne detailierter. Wenn du prinzipiell offen hierfür bist, mache ich mir sogar die Arbeit und zeichne Dir paar Diagramme für das bessere Verständnis.

PS:
Das System läuft übrigens schon unter "Realbedingungen" und verbraucht wesentlich weniger Resourcen wie die x-LBS Lösungen, wie es momentan üblich ist.

[gaert]

Rundumschlag? Schlag in die Gesichter? Respektlos?

Merkst Du eigentlich was?!

Sorry mein Nicht-Freund - Du bist raus.

[gaert]

Für die, die meine ehrenamtliche Arbeit zu schätzen wissen - in Bezugnahme auf Post 2096:

sql_call() ist nicht öffentlich, zumindest finde ich nirgends einen Hinweis darauf LBSe, die mit EDOMI-Datenbanken hantieren sind natürlich technisch möglich, aber by design nicht vorgesehen. Da aber die meisten LBS-Entwickler sehr genau wissen, was sie tun dürfte das i.d.R. ohne Nebenwirkungen bleiben. Zumindest bis zum nächsten Update, wenn sich Datenbankstrukturen (mal wieder) ändern

LBSe und VSEe sind bekanntlich spezielle Scripte in "EDOMI-Sprache" und erwarten daher eine bestimmte Struktur. Natürlich kann man dies unterlaufen, aber man sollte nicht. In der Realität ist der Reiz natürlich groß die Grenzen schrittweise zu überschreiten, das ist verständlich und in einem gesunden Rahmen vielleicht sogar förderlich für die weitere Entwicklung des "EDOMI-Kernels". Dennoch stellen derartige Bausteine immer auch eine Gefahr für das Gesamtsystem dar - die Dinger heissen nicht umsonst "Logikbausteine", d.h. ursprünglich sollten diese Scripte logische Operationen ausführen. So wurde z.B. der "EXEC-Teil" erst später eingeführt, um zeitintensive Berechnungen etc. zu ermöglichen - mit allen Nachteilen wie asynchrones Verhalten usw. (gar nicht so trivial dies in den Gesamtkontext der Logik-Engine unterzubringen).

Da nun offensichtlich einige wenige Schlauberger meinen, sie müssten in undokumentierten Datenbanken und Funktionen herumstochern (weil sie ja den EDOMI-Code vollumfänglich verstanden haben) bekomme ich ernste Zweifel... Solange dies auf dem jeweiligen Rechner bleibt - so what. Aber bitte nicht weitergeben oder veröffentlichen - losgelöst von rechtlichen Umständen empfinde ich dies als respektlos unserer Community (und mir) gegenüber.

[sipiyou]

Warum wirst du schon wieder persönlich und woher nimmst du dir das Recht, mich mich nun als Schlauberger zu bezeichnen ?
Davor war ich noch ein Copy/Paste-Coder.

>sql_call() ist nicht öffentlich, zumindest finde ich nirgends einen Hinweis darauf

- Edomi-Admin,
- auf Logik-Editor klicken.
- das Fragezeichen in der oberen Ecke des Browser-Fensters anklicken
- In der Eingabemaske "sql_call" eingeben
- Entwicklung von Visuelementen / Funktionsreferenz (3-3.htm) auswählen
- Runterscrollen bis "Datenbank (sql)".

Da sind übrigens noch paar mehr Funktionen, um auf die Datenbank zuzugreifen.

> "Da aber die meisten LBS-Entwickler sehr genau wissen,"

Ahja, gut. Jetzt wissen die Entwickler doch, was zutun ist. 2 Beiträge weiter oben klang das anders.

> "Solange dies auf dem jeweiligen Rechner bleibt"
Jeder, der Edomi installiert hat, hat eine Kopie der Quellcodes, was ist das schon wieder für ein Vorwurf ? Glaubst du allen ernstes, dass sich die Welt um Edomi dreht ?!


Also, willst du dich auf das eigentliche Thema einlassen oder nicht ? Es ist immer noch ein Vorschlag, wovon EDOMI profitiert und die Entwicklung künftiger Bausteiner sich besser an die Bedürfnisse anpasst.

Ich muss dir nicht sagen, dass ein "Smarthome" mit der Zeit neue Anforderungen aufweist und die Möglichkeit haben muss, sich diesen anzupassen.

[beauty]

So nun will ich als "CopyPaste-Coder" was dazu sagen..... ich finde es toll was alle hier leisten und und vorallem gaert auf die Beine gestellt hat....ich bin einer derjenigen der auf "Schlaumeiers wie sipiyou" und "Edomi-Papa gaert " angewiesen ist da meine Kenntnisse nicht über Basic der 80er/90er Jahre und learning by doing hinausgeht. Ich möchte nicht wissen wieviel "Eigengewächse" schon auf diversen Edomi-Server laufen was eigentlich auch ein normaler Prozess ist, da jeder das Beste für seine Bedürfnisse haben will. Edomi wächst und wird irgendwann erwachsen sein..... Wäre es hier nicht möglich einen gemeinsamen Konsenz zu finden, z.b. den "Schlaumeiers" eine Schnittstelle anzubieten so das die Stabilität von Edomi nicht darunter leidet, oder das Grundsystem nicht beeinträchtigt wird?
Und ja wir sind alles Freunde... Freunde von Edomi...... sipiyou gaert reicht euch die Corona-Getho Faust..... und vielleicht ist es ja möglich das gaert über seinen Schatten springt und sich das mal so wie von sipiyou angeboten live in Action anschaut......