Diskussion zu Logikeditor und MQTT

[Chris M.]

Das Thema ist nun schon ziemlich Off Topic, evtl. mag es ein Admin abtrennen?

Auch ich habe immer noch nicht den Einstieg in die Logiken geschafft. Aktuell habe ich ein WireGate-Plugin das Überarbeitung benötigt, mit dem wollte ich nun aber mal loslegen. Vielleicht spreche ich ja nachher positiver über die Logiken, aber noch ist für mich das JSON-Arrays ineinander schachteln nicht wirklich programmieren. Und es fühlt sich für mich noch zu stark nach Assembler an.

Die in Perl geschriebenen Logiken sind auch nicht Weisheit letzter Schluss (wenn auch sehr universell nutzbar): Event basierte Signalflüsse lassen sich halt nicht so trivial mit Perl handhaben. Und dann ist Perl selbst IMHO keine angenehm zu nutzende Sprache.

Was ich mir für die Logiken gewünscht hätte - und wo ich immer noch davon überzeugt bin, dass das auch für Anfänger gut geeignet ist - ist eine Singnalfluss orientierte, grafische Programmiersprache, also so etwas wie Simulink.
Die im TWS umgesetzten Logik-Blöcke könnten schon in die Nähe kommen. Es müsste halt einen grafischen Custom-Logik-Editor geben, bei dem man die Ein- und Ausgänge mit der Maus verknüpfen kann.

[Robert_Mini]

Abgetrennt vom Heizen/Kühlen Thread.
Hoffe das Logik Unterforum passt.

Robert

[StefanW]

Hallo Chris,

Vielleicht spreche ich ja nachher positiver über die Logiken, aber noch ist für mich das JSON-Arrays ineinander schachteln nicht wirklich programmieren.

Nun, um Programmieren geht es ja nicht, genauso wenig wie das XML für die CometVisu ein Programm ist.

Bei solchen Custom Logiken gibt man eigentlich nur die Signale und die Verbindungsliste für bestehende Logikelemente an - und erschafft damit ein neues Logikelement, dass man dann vielfach weiter nutzen kann. Es ist mithin kein Programmieren, sondern das Anlegen einer Verknüpfungsdefinition bestehender Logikelemente.

Das ist selbst gar nicht so schwierig. Der Aufwand besteht eher darin sich einzulesen, was die jeweiligen Logikelemente können - weil unsere Logikelemente hinsichtlich der möglichen Ein- und Ausgangsklassen sowie der Trigger und Sendefilter sehr viel Funktionalität besitzen. Wenn der Aufwand aber eigentlich darin besteht zu lernen, was die bestehenden Elemente bieten, ändert auch eine andere Sprache zur Definition oder ein umfangreicherer Editor gar nichts daran, dass die große Funktionalität unserer Logikelemente am Ende doch erlernt werden muss, wenn man deren Leistungsumfang nutzen möchte.

Um größere Logiken aufzubauen ist das Anlegen einer Verknüpfungsliste als Custom Logik gar nicht zwangsweise nötig, weil man umfangreiche Logiken auch ganz normal mit dem Logikeditor anlegen kann und mehrere Logiken dabei über den DOS verknüpft. Es niemand selbst eine Custom-Logik (= Verknüpfungsliste bestehender Logikelemente) schreiben, weil man kann sich das auch heute - hier und jetzt - im bestehenden Logikeditor zusammen klicken und das würde ich auch jedem so empfehlen.

Wer mehrere solcher Logikzellen zu einer Logikzelle "zusammendampfen" möchte, kann sich anschließend die Verbindung in einer solchen Verbindungsliste zusammen schreiben. Das Ergebnis wird dann als Custom Logik gekennzeichnet.

Die Verknüpfungsliste für Custom Logiken wird vom Editor selbst zur Definition der Verknüpfungen innerhalb der Logikzelle und von unseren Entwicklern zur Erschaffung neuer Logikmodule genutzt. Wir haben diese Möglichkeiten den Experten unter unseren Kunden freigegeben, die sich damit befassen wollen, weil ein modernes Produkt eben sowohl den Einsteiger als auch den Experten unterstützen soll. Wer das nutzen möchte, muss sich eben einarbeiten, das gilt für jedes komplexere System.


==> Wir schalten in Kürze eine starke Verbesserung der Dokumentation frei, welche von Diego in sehr detailierter und mühevoller Arbeit im neuen Confluence Server geschaffen wurden, es wird nur noch ein wenig am Finishing der Struktur gearbeitet, weil wir dort dann auch die weitere Dokumentation zur Verfügung stellen wollen. Zudem wollte sich Stefan K das noch ansehen. Mit dieser sehr umfangreichen Dokumentation sollte der Einstieg noch sehr viel einfacher werden.

Es müsste halt einen grafischen Custom-Logik-Editor geben, bei dem man die Ein- und Ausgänge mit der Maus verknüpfen kann.

Richtig, Der bestehende Logikeditor schreibt heute die im Editor zusammen geklickten Logken in eine Definitionsdatei (pro Logikzelle). Der Editor wäre dahingehend zu erweitern, mehrere Logikblöcke auf einem Arbeitsblatt zusammenzufassen.

Allerdings ist das vermutlich für nicht mehr als ein oder zwei Prozent aller Logiken nötig, weil die üblichen Standard-Verknüpfungen kann man mit bestehendem Funktionsumfang sehr leicht umsetzen. Zumal wir in die Regeldefinitionen für die Kommunikation zu 1-Wire, ekey und künftig auch Modbus, MQTT, Rest-API viel Funktionen wie Formatwandelung, Bitmusterdekoder, Formelparser, Sendefilter und auch den ein oder anderen Trigger implementieren, so dass der Bedarf für die Nutzung der Logik rapide sinken dürfte.

Eine Erweiterung des Logikeditors steht auf der Liste der Verbesserungen. Zunächst wollen wir die Kommunikationsfähigkeiten des Servers erweitern, weil das für die Nutzer den Einsatzbereich des Servers am umfangreichsten erweitern wird.

lg

Stefan

[Robert_Mini]

Es müsste halt einen grafischen Custom-Logik-Editor geben, bei dem man die Ein- und Ausgänge mit der Maus verknüpfen kann.

Ich muss das auch nochmal aufgreifen, denn diese Aussage steht im Widerspruch zu den Einstiegshürden, die Zugschlus und gurumeditation oben beschreiben.

Egal ob Text oder graphisch - man muss die Module samt Triggerverhalten verstehen. Das gilt beim Gira Hs, Edomi und auch beim TWS.
Ein > ist auch nicht gleich >=, eine steigende Flanke was anderes wie der Pegel.

@markusrohr ist für mich dafür ein Beweis. Ich will jetzt nicht Alter oder dergleichen ausplaudern, aber das sagt alles:

Hallo Marc,
ich hatte auch lange das Gefühl, dass ich zu doof für den Logik-Editor bin. Ich habe mit grosser Wahrscheinlichkeit in den letzten 30 Jahren keine Programmzeile mehr geschrieben und die Einstiegshürde war mir einfach zu hoch (wie so oft beim TWS).

Der Aufwand hat sich letztendlich als doch nicht ganz so hoch herausgestellt, @Robert_Mini hat mich freundlicherweise sehr unterstützt, und ich schreibe inzwischen alle Logiken im Editor selber, vor allem auch wegen der grösseren Übersichtlichkeit. Der Anfangsaufwand hat sich wirklich gelohnt, die Möglichkeiten, die die Architektur des TWS bietet sind nach der Einarbeitung einfach phänomenal und die Fehlersuche (im System, nicht im Logikeditor) hat sich gegenüber den Systemen, die ich bisher benutzt habe, stark vereinfacht.

Und ehrlicherweise war meine Unterstützung praktisch auf 1x Fehlersuche im Beschattungsbaustein aufgrund 0-255 anstelle 0-100% beschränkt.
Lg
Robert

[markusrohr]

Ich kann nur sporadisch an meinem TWS Projekt arbeiten. Eine vernünftige laufende Dokumentation mit wenig Aufwand ist deshalb essentiell. Dies ist einer der Hauptgründe warum ich auf die Custom Logiken umgestiegen bin. Ich kann Ein- und Ausgänge bezeichnen und Kommentare einfügen (Mouse over). Dies erleichtert mir den Wiedereinstieg und die Fehlersuche enorm. Ich habe deshalb begonnen auch einfache Bausteine als Custom Logiken zu generieren (wie von Robert beschrieben). Ich kann mir vorstellen, dass es auch Systemintegratoren ähnlich geht wenn sie sich nach ein paar Monaten für Änderungen wieder in ein Projekt einarbeiten müssen.
Es geht beim Stichwort "graphisch" also nicht immer nur um "Coding".
Vielleicht lässt sich ein solcher Ansatz im Zuge der von Stefan angekündigten Verbesserungen auch in die Standardlogiken integrieren?
Liebe Grüsse
Markus

[Robert_Mini]

Wobei das Vorgehen von Markus durch die „Code kopieren“ Funktion ja praktisch ohne Aufwand möglich ist.

Lg
Robert

[gurumeditation]

Mich hätten mal Beispiele interessiert, wo ihr Probleme habt. Ich war auch ein begeisterter Plugin Skripter am WG, inzwischen aber begeisterter Custom Logic Anwender.

Nur um ein paar Beispiele aus der Erinnerung heraus zu nennen:

• Inhibit ist eine für mich sehr ungewohnte Herangehensweise. Man sieht an anderer Leute Logiken, dass damit viel gemacht werden kann, aber intuitiv ist das für mich nicht.
• Schwellwertfunktion funktioniert nicht mit boolean - um nur bestimmte Werte "durch zu lassen" ist eine (kompliziertere/unintuitivere) Inhibit-Nutzung nötig. Siehe dazu auch die Anleitungen im Forum auf solche Fragen.
• 8 (acht!) Timer-Bausteine sorgen erst mal für Verwirrung, wenn man "einfach nur einen Timer" bauen will.
• Nur ein (1) Logikbaustein gleichzeitig zu bearbeiten. Die schon genannte grafische Verknüpfung (ziehe neue Bausteine auf eine Arbeitsfläche, ziehe einen Ausgang auf einen Eingang, usw. wie man das in Screenshots von Logiken von anderen Anbietern kennt)
• Verteilung der Dokumentation in KB und Forum. Bei einem konkreten Anwendungsfall muss man ordentlich suchen und springen. Wird vielleicht mit Confluence besser...

[stonie2oo4]

• Nur ein (1) Logikbaustein gleichzeitig zu bearbeiten. Die schon genannte grafische Verknüpfung (ziehe neue Bausteine auf eine Arbeitsfläche, ziehe einen Ausgang auf einen Eingang, usw. wie man das in Screenshots von Logiken von anderen Anbietern kennt)

Ich fände es absolut genial, wenn man mehrer Logikbausteine grafisch wie von dir beschrieben verknüpfen könnte und man aber danach auch per Klick aus diesen ganzen Verknüpfungen einen Custom LBS generieren kann.
Nimmt einfach die Einstiegshürde Codezeilen zusammen zu kopieren. Und sorgt wieder für Übersichtlichkeit im Logikeditor.

[gbglace]

Und sorgt wieder für Übersichtlichkeit im Logikeditor.

Aber erst wenn es auf einen Custombaustein zusammengedampft ist. Ansonsten ergibt das teilweise recht umfangreiche Tapeten.

[stonie2oo4]

Das meinte ich ja damit