Diskussion zu Logikeditor und MQTT

[gurumeditation]

Mit den Tapeten kann man aber besser arbeiten als mit x separaten LBS, die nicht optisch miteinander verknüpft sind. Stell dir mal eine "Straßenkarte" vor, bei der du statt der normalen Karte eine Tabelle hast, welche Straße mit welcher verbunden ist. Für einen Computer ist das zur Routenfindung völlig ausreichen, für einen Menschen eher nicht. Ich denke das Bild der "Straßenkarte vs. Tabelle" passt für den Logikeditor ganz gut.

[stonie2oo4]

Mit dem Beispiel hat @gurumeditation den Nagel perfekt auf den Kopf getroffen, finde ich. Das Arbeiten würde so einfacher und vor allem schneller gehen.
Momentan ist es halt recht aufwendig LBS zu verknüpfen, da man in Tabellen die richtigen Ausgänge und Eingänge suchen muss.

Aber der TW braucht ja auch noch bisschen Luft nach oben

[StefanW]

Guten Morgen,

wir verstehend den Wunsch nach mehr Funktionen und auch mehrere Logikelemente auf einer Seite unterzubringen und das ist auch ein wichtiges Entwicklungsziel.

Aber vor drei Jahren waren Ressourcen knapp und wir mussten eine Entscheidung treffen, welche Leistungsmerkmale umgesetzt werden. Klar hätten wir einen größeren Editor bauen können mit freier Anordnung mehrerer Logikelemente auf einer Seite. Aber dann wären - rein zeitlich - die anderen tollen Merkmale wie "Instant-Einzelupdate einer Logikzelle ohne Neustart der ganzen Logikengine", "Flexible Zahl an Eingangsports", "Persistenz der Logikzelle" und der "Doktormodus mit den tollen Diagnosemöglichkeiten" auf der Strecke geblieben.

Manches davon hätte sich auch nicht mehr später nachrüsten lassen, weil es den inneren Aufbau einer Logikengine betrifft - und das ändert man später im laufenden Produkt nicht mehr, das wäre jedem Produktmanager eine viel zu umfassende Änderung eines Kernmodules. Solche tollen Leistungsmerkmale kann man nur von Anfang an eindesignen. Aber es ist uns auch nicht zugeflattert sondern musste mühsam erforscht und erarbeitet werden und damit waren eben auch Ressourcen gebunden.

Wir mussten uns damals entscheiden. Deshalb hat der Logikeditor zunächst das "fixere Design einer Logikzelle" bekommt, allerdings mit sehr viel Eigenschaften für Triggerkontrolle, Eingangsmodifzierern, beliebigen separaten Triggern, zumeist beliebiger Anzahl von Eingängen ("100 fach Oder"), beliebig viele Inhibit ("Sperrobjekte") sowie Ausgangsmodifizierer, Timer und sehr granular einstellbare Sendefilter.

Wer sich unsere Logikzellen im Detail ansieht und diese auf einem anderen Server nachbildet, der wird feststellen, dass er dort eine A3 Seite mit 15 Modulen bauen muss um das gleiche zu erzielen (wenn man alle Möglichkeiten einer Logikzelle ausnutzt). Nur ohne Doktormodus, ohne Persistenz der Logikzelle und vor allem ohne Instant-Update zur Laufzeit. Ganz abgesehen davon, dass der Nutzer eine solche Logikzelle auch am Handy einrichten kann.

Ich verstehe, dass man gerne mehr möchte und bei komplexeren Verschaltungen mag eine größere Zeichnung auch sinnhaft sein. Der Vorteil des Entwicklungsweges, den wir gegangen sind, ist, dass wir einen größeren Logikeditor rein technisch nachrüsten können, denn dieser muss ja nur eine Customlogik erzeugen. An der Engine müssen wir da gar nichts ändern. Umgekehrt hätten man die vielen anderen Features die wir nun schon haben, später nicht mehr nachrüsten können. Beides zugleich ging von den Ressourcen nicht, weil die Kunden wollten dann auch die Server haben. Es nützt auch nichts, den schönsten Server zehn Jahre lang zu entwickeln, den kein Kunden auf den Tisch bekommt, weil die Entwickler alles immer noch besser und besser und besser machen. Deshalb haben wir den Weg gewählt, der viele neue und tolle Leistungsmerkmale beinhaltet und im Punkt des Editors eine spätere Upgradebarkeit ermöglicht.

Ich bin überzeugt, dass die anderen Komfortmerkmale wie Instant-Update, Doktormodus, Simulationsfähigkeiten, Persistenz unter dem Strich mehr Zeit für die Kunden einsparen als eine freie Anordnung mehrerer Logikelemente ohne alle diese Leistungsmerkmale.

Wir haben für den Timberwolf Server genug Ideen für eine Menge an Verbesserungen für die nächsten fünf bis acht Jahre. Jetzt entwickeln wir die Konnektivität weiter und danach machen wir uns an alles was mit Logiken, KI und Automatisierungen zu tun hat.

lg

Stefan

[Eraser]

Jetzt entwickeln wir die Konnektivität weiter und danach machen wir uns an alles was mit Logiken, KI und Automatisierungen zu tun hat.

[Zugschlus]

Ich war schon wieder eine Weile nicht mehr hier, aber ich versuche trotzdem mal konstruktiv weiterzugehen. Ich muss mich regelmäßig in neue Dinge hineinfuchsen und habe die Erfahrung gemacht, dass mir oftmals der Sprung von "10" zu "30" fehlt. Das braucht es dann einen Schubs, der bei mir dazu führt, dass ein Knoten platzt und ich plötzlich die Zusammenhänge verstehe. Ist dieser Punkt nicht erreicht, stehe ich hilflos wie der Ochs vorm Berge, manchmal braucht es nur einen einzigen Satz der Erklärung.

Hier drei Beispiele.

(1)
Ich habe bis heute aus der KB nicht verstanden, was ein Inhibitor ist, wofür und wie man ihn einsetzt.

(2)
Ich habe im Haus oftmals den Wunsch, dass manche Lichter mit aus gehen, wenn ich z.B. das Hauptlicht eines Zimmers ausschalte. Ich möchte aber nicht, dass diese Lichter mit _an_ gehen, wenn ich das Hauptlicht einschalte. Ich brauche hier also eine Logik, die ein "Aus" Telegramm emittiert, wenn sie an ihrem Eingang ein "Aus" gesehen hat; ein "An" Telegramm am Eingang aber kommentarlos verschluckt.

(3)
Meine komplizierteste aktuelle Logik, die ich mangels KNX-Fähigkeit der Wärmepumpe noch gar nicht umstellen kann, wäre zum Beispiel, dass der Timberwolf die angeforderte Vorlauftemperatur der Wärmepumpe um 2K erhöht, wenn die im Haus verbauten Heizungsaktoren zurückmelden, dass ein Ventil für länger als vier stunden zu 100 % offen ist. Die Heizung soll also quasi mitbekommen, dass das Haus mehr Wärme anfordert als sie gerade liefert und mehr liefert. Im Gegenteil soll die Vorlauftemperatur zurückgenommen werden, wenn es im Haus kein Ventil gibt, das zu mehr als 25 % geöffnet ist: Dann ist die Wärmelieferung der Heizung offensichtlich zu hoch für den Bedarf des Hauses. Sowas programmier ich in perl in fünf Minuten, ist vermutlich nur ein Zehnzeiler bis zum ersten Prototypen, aber bei der Timberwolf-Logik wüsste ich aktuell nicht einmal wo ich anfangen soll.

Ich hangle mich unglaublich gerne von einfachen Lösungen zu den komplizierteren, aber beim Logikeditor fehlt mir schon der Schritt zum ersten Ergebnis. Das führt bei mir dazu, dass ich einfach etwas anderes mache. Habe im Haus ja schließlich noch genug andere Baustellen. Aber den Frustlevel bezüglich Timberwolf reduziert das freilich nicht.

Grüße
Marc

[Eraser]

Ein Inhibit-Eingang setzr einfach die Logik auf inaktiv, einfach das Gegenteil von einem Enable-Signal.

Das mit dem nur 0-Signal durchlassen geht mit einem einfachen AND mit nur einem Eingang, bei dem dieser mit dem Fixwert False verbunden wird. Das Eingangs-Signal, dass das False-Signal am Ausgang schalten soll wird an dem Inhibit angeschlossen. Bedeutet, wenn das Eingangssignal 1 ist, dann wird die Logik gesperrt (Inhibit). Bei einer 0 wird dann die Logik getriggered, welche aber dann in einer 0 am Ausgang resultiert, da der Eingang des AND fix auf False steht.

[James_T_Kirk]

Danke für die Erklärung, da wär ich nicht drauf gekommen... Aber einfach und logisch ist anders.
Ich habe immer noch auf den passenden Filter am Ausgang gewartet.

[Robert_Mini]

Hallo zusammen!

Kleine Ergänzung: Den Filter am Ausgang gibt es in custom Logiken seit kurzem mit “Send Explicit”.
Da kann man frei entscheiden, wann gesendet wird.

Lg
Robert

[Eraser]

Ich habe immer noch auf den passenden Filter am Ausgang gewartet.

Was ich im Kopf habe steht der auf der Agenda wenn ich mich nicht irre

[StefanW]

Was ich im Kopf habe steht der auf der Agenda wenn ich mich nicht irre

Der Ausgangsfilter ist bereits in der Logikengine implementiert und kann in Custom Logiken genutzt werden. Bei der nächsten Überarbeitung des LogikEditors kann man diesen dann auch in der GUI einstellen, so dass die Nutzung noch einfacher ist.

lg

Stefan