Logikbausteine gegen Programmierung

[StefanW]

Ich dachte, das habt ihr mit eurer aktuellen Architektur verhindert, dass dies auch beim TWS passiert, da kein Zugriff mehr auf root möglich ist?

Nun, im WireGate Server konnte man PERL-Scripte (Plugins) laufen lassen. Das geht im Plugin-Container auf dem Timberwolf auch noch, aber wir haben auch klar gemacht, dass es der Unterstützung einer alten Technologie geht.

Es ist immer nur eine MInderheit der Kunden, die Dinge ausnutzt und mit großer Anspruchhaltung an die Sache geht. Und bei den Plugins gab es dann welche, da liefen die eben "wild" weil schlecht programmiert.

Eine Scriptsprache gibt extreme Freiheiten und zum Teil dann auch Zugriff auf das Betriebssystem. Das hatte damals zu Problemen geführt und Supportaufwand.

Beschweren sich die Kunden auch, wenn etwas an Logikbausteinen falsch eingestellt ist und die Logik dann nicht geht? Ist für mich kein Unterschied zu einem eigenen Script.

Jein. Aber es kommen natürlich schon entsprechende Threads hoch. Und wenn diese nicht bearbeitet werden würden, dann gäbe es auch Kritik. Im Moment sehen wir uns das noch genau an, weil es könnte auch noch einen Bug geben, aber mit zunehmender Reife werden wir das vom Care-Vertragsstatus abhängig machen.

Jetzt ist der Unterschied, dass mit einer Programmier-/Skriptsprache eurer Wahl (etwas C-ähnliches, SCL, PHP etc. die "Standard" Elemente if then else > < mathematische operanden sind ja überall gleich) in dem Baustein programmiert werden kann.

Und genau das lässt sich mit der Logik und den Gattern doch alles abbilden.


lg

Stefan

[MeisterLampe]

Und genau das lässt sich mit der Logik und den Gattern doch alles abbilden.

Dann zeig mir wie ich übersichtlich einen Zustandsautomaten mit 4 Zuständen und 7 Übergängen erstelle. (Schätzung aus dem Beispiel von Marc weiter oben.) Ich brauche dafür in SCL vlt. eine DINA4 Seite mit den Gattern fehlt mir der erste Denkansatz. Brauche dafür vermutlich einige Bausteine und dann habe ich wieder keine Übersichtlichkeit, da die Bausteine nicht auf grafischer Ebene miteinander verknüpft werden können, sondern immer nur der einzelne Baustein zu sehen ist. Ich habe zwar Elektrotechnik studiert und kenne die ganzen Gatter, bin aber so lange in Programmiersprachen unterwegs gewesen dass es mir sehr schwer fällt. Ich habe auch schon mehrere Jarhe in einem Unternehmen für Automatisierungstechnik gearbeitet und mit SPSen gearbeitet. Hier gab es immer die Auswahl zwischen Gattern, AWL und Programmiersprache und jeder der ein wenig komplexere Logiken aufgebaut hat nahm am ende die Programmiersprache...
Anscheinend muss ich mich (wenn das Haus steht und ich Zeit für habe) intensiv mit dem Plugin-Container beschäftigen und muss dann in einem neuen Produkt direkt auf veraltete Technologie zurückgreifen.

[starwarsfan]

Hallo miteinander

... wenn die Programmierer Zeit haben...

YMMD!!!1elf!

[Matze76]

Anscheinend muss ich mich (wenn das Haus steht und ich Zeit für habe) intensiv mit dem Plugin-Container beschäftigen und muss dann in einem neuen Produkt direkt auf veraltete Technologie zurückgreifen.

Das verstehe ich nicht. Wenn du sowieso in beide Themen neu einsteigen müsstest: Warum investierst du die Zeit dann nicht dafür, dich intensiv mit den Logik-Bausteinen und Custom-Logiken zu beschäftigen? Ich habe sogar ohne Elektrotechnik-Studium inzwischen einen ganz ordentlichen Durchblick...

Ja, es ist zunächst ungewohnt, wenn man in dieser Welt nicht zu Hause ist. Man muss anders denken. Aber ich bin weiterhin der Meinung, dass das für diesen Zweck der richtige Ansatz ist.

Mein Geld würde ich jedenfalls lieber in andere Features investiert sehen, als noch eine alternative Script-Sprache auf die Custom-Logiken zu setzen.
Und die Argumente gegen einen zu hohen Freiheitsgrad bei der Programmierung seitens ElabNet kann ich voll und ganz nachvollziehen. Auch das zahle ich als Kunde letztendlich mit, wenn die Möchtegern-Programmierer (allgemein gesagt, nicht auf dich bezogen) sich überschätzen und dann kostenlosen Support verlangen.

... Bis hierher ist es exakt dasselbe wie mit einem Customlogik-Baustein.Jetzt ist der Unterschied, dass mit einer Programmier-/Skriptsprache eurer Wahl (etwas C-ähnliches, SCL, PHP etc. die "Standard" Elemente if then else > < mathematische operanden sind ja überall gleich) in dem Baustein programmiert werden kann.

Gut, das wäre aber dann doch kein Wiregate-Plugin-Ersatz mit all seinen Freiheiten, sondern einfach eine für den Hochsprache-Programmierer bequemere Art eine Custom-Logik zu erstellen. Die Grundsätze des Logik-Editors (keine Sprunganweisungen, keine Schleifen...) würden ja nicht verändert. Ansonsten wäre es nicht "exakt dasselbe".

da die Bausteine nicht auf grafischer Ebene miteinander verknüpft werden können, sondern immer nur der einzelne Baustein zu sehen ist.

Vielleicht kommt ja in der Zukunft mal etwas in der Richtung. Aber wenn du programmierst, hast du auch keine grafische Übersicht.
Wenn du dich mit dem Thema beschäftigst, wirst du komplexe Geschichten sowieso in Custom-Logik abbilden. Dann hast du eine übersichtliche Seite mit Code und Kommentaren, ganz wie gewohnt.

[alexbeer]

Mir geht der Logik-Editor auch noch nicht intuitiv von der Hand. Das Konzept finde ich dennoch super! Vor allem weil er so effizient ist.

Anstatt der Wiregate Plugin Container habe ich mir Node-Red als Docker installiert.
Über den KNX-Ultimate Node klappt die Kommunikation mit dem KNX-Bus super. Einiges was auf dem TWS noch nicht nativ geht, ist so möglich.
Der Entwickler von dem KNX-Ultimate Node ist auch im KNXUF hilfsbereit unterwegs.
Vielleicht wäre das ja auch für euch eine zusätzliche Option neben dem LE.
VG Alex

[Dante]

- Wilde Scripte die den Server lahmgelegt

Ich dachte, das habt ihr mit eurer aktuellen Architektur verhindert, dass dies auch beim TWS passiert, da kein Zugriff mehr auf root möglich ist?

Genau das haben sie, würden sie jetzt aber User-Skripte wieder direkt im TWS laufen lassen bzw. innerhalb der LE des TWS laufen lassen, könnten diese den Server wieder lahmlegen. Wenn da endlose Schleifen, Rekursionen, Speicherfresser oder andere Sachen drinstecken hängt der Server gleich.

Jetzt ist der Unterschied, dass mit einer Programmier-/Skriptsprache eurer Wahl (etwas C-ähnliches, SCL, PHP etc. die "Standard" Elemente if then else > < mathematische operanden sind ja überall gleich) in dem Baustein programmiert werden kann.

Und was sind die Standard-Elemente? Ist ein fopen() in PHP ein Standard-Element mit dem ich auf alle TWS-Dateien zugreifen könnte oder Verbindungen nach extern öffnen kann? Wo fängt man an, wo hört man auf.

Ich verstehe Marc vollkommen, ich bin selbst Programmierer und da finde ich die Gatter-Thematik auch eher schwer bzw. umständlich.

Hier mal ein Vorschlag zur Diskussion:
Im Logik-Editor gäbe es dann neben der Custom-Logik eine Remote-Logik zur Auswahl, zum Initialisieren wird nur eine URL angegeben (ob diese nun auf dem TWS in nem Docker liegt, auf nem Server im eigenen Netz oder sogar irgendwo im Internet). Über diese URL zieht sich der LE alle relevanten Informationen zur Logikzelle (Name, Version, Beschreibung, Anzahl/Variabilität/Typen der Ein-/Ausgänge). Da hier die Besonderheit besteht, dass das Ergebnis nicht "sofort" zur Verfügung steht wie z.B. bei einer einfachen AND-Zelle muss für diese Logikzelle ein Timeout definiert werden.

Ich weiß, das widerspricht etwas @StefanW's hier getätigten Aussagen zur LE. Aber darüber könnte man tausende kleine und größere Funktionen ergänzen die eben keinen Start- oder Endpunkt darstellen sondern in der Verarbeitung benötigt werden - z.B. Texte manipulieren, mathematische Berechnungen durchführen u.ä. Wenn diese Remote-Logik dann in einem Docker-Container auf dem TWS läuft, könnten Antworten fast genauso schnell da sein wie wenn sie nativ im LE laufen.


PS: Zuerst hatte ich an eine Verbindung im Rahmen der IP-Technologie/-Objekte gedacht - aber da seh ich's nicht mehr so wirklich, da es IMHO etwas anders ist.

[supernode]

Meiner Meinung nach sollte auch die Frage geklärt werden wie sich 3rd-Party-Systeme einbinden lassen, die zu selten sind um vom TWS-Team berücksichtigt zu werden. Lass ich in nem Docker dann ein selbst geschriebenes Programm/Script die Umsetzung übernehmen und komme mit wenigen Steuer/Statussignalen hin zur Logik des TWS aus? Gibt es hier Zeitanforderungen? Reicht es über eibd oder ist die Abfragerate zu hoch? Wie sieht das bei MQTT aus? Letzteres wäre langfristig wohl meine Wahl...

Beispiel: Aktuelle Leistung aus einem exotischen PV-Wechselrichter via Web-Schnittstelle auslesen und den Wert loggen oder in der Logik weiterverarbeiten, bspw. um die Waschmaschine anzuwerfen. Die Waschmaschine hängt natürlich auch am LAN ... und beides Lohnt sich für ElabNET (verständlicherweise) nicht zu integrieren.

Das Thema Zustandsautomat finde ich auch sehr wichtig und sehe auch dass ab einer gewissen Größe nur noch die textuelle Eingabe sinnvoll ist. Für moderat große FSMs wäre mir der Weg über Docker zu müßig weshalb ich an einer gut nutzbaren Lösung innerhalb der LE interessiert wäre. Letzten Endes sind das ja nur ein großes switch-case-Konstruct mit verschaltelten if-else-Befehlen und ggf. ein paar lokalen Variablen.

[Sun1453]

Hallo Supernode,

also hier denke ich ist MQTT zu empfehlen um Daten zum TWS und wieder raus zu bekommen. Somit könnte man den DOS und den Dispatcher sowie die Logiken dazu nutzen. Laut einen Betrag hier sind die Entwickler schon an der Implementierung dran. Wenn du auch Beta Tester bist und am Insider Programm teilnimmst, kannst du frühzeitig von den ersten Versionen profitieren und wünsche mit einbringen.

[Zugschlus]

Eine Möglichkeit wäre wie jetzige Customlogiken. Es gibt einen Baustein, bei welchem beliebig viele Ein- und Ausgänge aus dem Dispatcher genutzt werden können. Bei einer Änderung einer der Ein- und Ausgänge wird der Baustein gerechnet oder wenn eine Init-Bedingung "true" ist. Bis hierher ist es exakt dasselbe wie mit einem Customlogik-Baustein. Jetzt ist der Unterschied, dass mit einer Programmier-/Skriptsprache eurer Wahl (etwas C-ähnliches, SCL, PHP etc. die "Standard" Elemente if then else > < mathematische operanden sind ja überall gleich) in dem Baustein programmiert werden kann.

@Zugschlus bin ich hier so weit weg von deinen Vorstellungen?

Das passt ziemlich gut, finde ich.

Grüße
Marc

[Robert_Mini]

Das bringt aber wirklich nichts, eine kastrierte Hochsprache zu implementieren.
Wenn, dann über MQTT die Objekte mit einem Docker verbunden (zum Abkapseln von TWS System) und dann ohne Einschränkungen, dh mit allem was Unix und php/perl etc. hergibt.

Lg
Robert