UMFRAGE: Logikfunktionen vs. Konnektivität (ab Version 4)

[Sun1453]

Glückwunsch an euch beide.

[Dragonos2000]

Glückwunsch zum Nachwuchs

[pbm]

Alles Gute zum Nachwuchs, euch beiden!

[maggyver]

Auch noch von mir alles Gute zum Nachwuchs.

Grüße
René

[StefanW]

Verehrte Foristen,

die beiden frisch gebackenen Väter bedanken sich bei Euch allen für die Glückwünsche.

Ich denke, wir sollten nun wieder zum Thema zurückkehren, also Euren Wünschen ab V 4.0

lg

Stefan

[CHD]

Moment noch, da ich zurzeit auch von den Kindern etwas vom Forum abgelenkt werde muss ich noch verspätet dazwischen grätschen. Herzlichen Glückwunsch an euch beide! Hatte die letzten Tage des öfteren an dich gedacht, Stefan, habe aber einfach nicht die Zeit zum fragen gefunden. Super, ich freue mich.

Zum Thema: Über HomeKit habe ich die Hoffnung, schnell eine einfache Visu zu erstellen. Für die wichtigsten Sachen.
Als zweites und drittes die Logikpakete Beschattung und Licht.
Mehr durfte man ja nicht auswählen Ein bisschen wie am Buffet hier bei euch

VG, Christian

[cheater]

Hallo Stefan,
habe jetzt auch mal abgestimmt:
Clouds Personal Assistants (z.B. Alexa, Homekit, Google)
Logikpaket Beschattung (Rolladen & Jalousien)

Vielen Dank für deine Erläuterung in Beitrag #5

[ThomasD]

Hallo,

ich habe für die Sprachsteuerung gestimmt. Bei mir steht demnächst ein Neubau an, und da ist ganz klar die Ausrichtung auf Sprachsteuerung mit HomeKit bzw. Amazon Alexa (Echo).

Gruß
Thomas

[StefanW]

Hallo Bernd,

Die aktuelle Logikengine vom Timberwolf finde ich ausgesprochen sperrig.

Nun, Du meinst nicht die Logikengine, sondern den Logik Manager (also den Editor).

Wir hatten 2015, als wir grundsätzliche Leistungsmerkmale für den Timberwolf Server designed haben, eine Reihe von Festlegungen getroffen:

1. Betriebssystemunabhängige Oberfläche die auch auf kleinen Tabletts / großen Smartphones läuft
2. Instant-Update, also kein Neustarten von irgendwas, nur weil man eine Einstellung geändert hat
3. Möglichst einfaches Debugging und Analyse, damit der Nutzer mögliche Fehler in der Konfig leicht findet
4. Alles leicht auffindbar und fast beliebig verknüpfbar

Das sind in der Summe eine Menge Herausforderungen die zu bewältigen waren und diese führten dann auch zum Design des Logik Managers.

Die Anforderung, dass man die Oberfläche und auch den Logik Manager mit einem großen Smartphone bedienen kann, hat die Größe der Zellen limitiert. Alles kann man nicht haben.

In 2015 war eine Zeit, da haben manche Menschen keine Notebooks und PCs mehr gekauft, sondern stattdessen Tablets und man sah damals den normalen PC dem Untergang geweiht. Unsere Vorstellung war, dass ein Kunde oder dessen Integrator eine Umstellung auch mal schnell mit einem kleinen tragbaren Device machen kann, zumal Loxone eben auch Ihre App am Start hatte.

Die Anforderung für Instant Update (dass man nicht, wie z.B. beim Homeserver die gesamte Kiste neu starten muss, weil man ein Bit an der Einstellung verändert hat) hat eine Menge Aufwand in der Entwicklung verursacht. Der Doktormodus war ebenfalls sehr aufwändig.

Ich verstehe, dass es den Wunsch der Kunden gibt, dass man möglichst große Blätter mit vielen Logikelementen darauf malen möchte. Vielleicht hätten wir uns auch dafür entscheiden sollen. Aber es wäre ein Verstoß gegen das Versprechen gewesen, den Server auch mit einem kleinen Device nutzen zu können und für die anderen Leistungsmerkmale wie Instand Update und Debugging wäre womöglich kein Budget mehr gewesen.


==> Wir haben aber durchaus eine Idee in der Pipeline, wie man einen "Erweiterten Editiermodus" integrieren könne, mit dem man dann mehrere Logikelemente beliebig anordnen kann. Weil wir wollen, dass unsere Kunden glücklich sind damit. Daher wird es irgendwann auch einen Logik Manager V 2.0 geben, der auch diesen Wunsch umsetzt

Einfache Logiken sind zwar ganz gut machbar, aber sobald es etwas komplexer wird, muss ich eine Custom Logik bauen, die alles andere als übersichtlich und wartbar ist.

Bei Logiken kommt es irgendwann immer zu einem Punkt, an dem Anforderungen sich mit einem gegebenen Design einfach und andere schwerer umsetzen lassen. Die Grundausstattung von Logikbausteinen bei HomeServer oder Edomi ist auch begrenzt und wenn man spezielleres will, hat man entweder sehr monströse Logiken und / oder benötigt spezielle Bausteile, die von Hand programmiert werden müssen. Da braucht man Programmierkenntnisse und das ist dann auch irgendwo sperrig.

Unsere Custom Logiken waren auch eigentlich gar nicht für die Nutzung von Kunden gedacht, sondern für uns, um damit komplexere Logiken auf Basis von einfacheren Logiken zu entwickeln. Darum sind diese nicht so nutzerfreundlich vom Aufbau her, wie man sich das wünschen würde.

Weil eigentlich ist es so, dass wir den Timberwolf Server so konzipieren, dass die Logikengine so wenig wie nur irgend möglich genutzt werden muss vom Kunden. Daher ist die Logik auch nicht der Mittelpunkt des Systems, wo jedes Signal drüber muss, sondern auch nur ein Subsystem wie alle anderen, die am Objekt-Verteiler (aka "Dispatcher") andocken.

Insofern arbeiten wir bei allen anderen Subsystemen daran, dass eine Reihe von Aufgaben bereits dort mit wenigen Klicks einstellbar ist. Das sieht man gut an Modbus mit den Formeln, Objekttyp-Wandlungen, bitweisen Dekodierungen, Mappings, Triggereinstellungen.

Wir haben auch mittlerweile die Funktion der "Auto-Konvertierung" implementiert, man kann nun verschiedene Objekt-Typen (das Extremste ist z.B. Float auf Bool oder umgekehrt) über den Objekt-Verteiler miteinander verknüpfen und es erfolgt eine automatische Umrechnung im Hintergrund, ohne dass man hierfür eine Logik bemühen muss. Werden manche womöglich gar nicht bemerken, weil es geht einfach auf magische Weise. (Erkennen kann man das Feature daran, dass bei Verknüpfungen die Verlustbehaftet sind, wie z.B. von Float auf Integer, eine entsprechendes Warndreieck im Verknüpfungsassistent (aka "DOS", das lila Fenster) erscheint.

Wir werden noch sehen, dass dies sehr praktisch ist, weil man damit dann auch eines Tages einfach ein RGB-Datum mit einem HSV-Datum verknüpfen können wird und die Umrechnung geschieht einfach im Hintergrund, ohne dass man manuell über die Logik gehen muss. Das kann im einzelnen Fall dem Einrichter einer Funktion am Timberwolf Server sehr viel Arbeit ersparen.

Logikpakete sind sicher ein guter Schritt in die richtige Richtung.

Ja, das ist eine Fortführung unserer Strategie, dem Nutzer die Anwendung von komplexen Universal-Logikeditoren so weit es geht zu ersparen und dafür - für den jeweiligen Anwendungszweck - zugeschnittene Funktionsmodule zu bieten. Mit einer Oberfläche, die jeweils auf die Aufgabe zugeschnitten und optimiert ist.

Tatsächlich sind das spezielle Logikeditoren, weil am Ende wird dort eine Logik "kompiliert" die dann von einer eigenen Instanz der selben Logikengine gerechnet wird. Dies deshalb, weil deren Stabilität ist über viele Millionen Betriebsstunden ausgetestet.

Die Bedienung der Logikpakete wird ähnlich einfach sein, wie die der Gerätemanager. Also gruppierbare Listen, deren Elemente über mehrere Stufen erweiterbar sind.

Wir denken, dass dies nicht nur sehr übersichtlich ist, sondern auch skalierbar.

2) Logikpaket Beschattung

Zumindest meine Beschattung treibt mich in den Wahnsinn. Die Funktionen von KNX Wetterstation und KNX Aktoren (SMI + konventionell) kommen sich in die Quere. Die Wetterstation hat einen suboptimalen Aufstellungsort und lässt sich in Einzelwerten nicht übersteuern usw.

Ja, das kennen wir. Daher haben wir auch, als es an die 1-Wire Outdoor Sensoren ging, nicht solche "All-in-One" Sensoren gebaut (aka "Wetterstation"), sondern die Funktionen in einzelne Sensoren gepackt, damit man diese jeweils dort anbringen kann, wo die Messung auch sinnvoll ist. Weil alles an einem Standort mag meteorologisch praktisch sein, aber eigentlich sich nicht für eine Haussteuerung.

Da ist ein wenig das Viel-Hersteller-Konzept von KNX im Weg und der Versuch der Hersteller, sich durch immer mehr Leistungsmerkmale gegenseitig zu übertrumpfen, ohne sich darüber ordentlich abzustimmen. Da knirscht es etwas.

Aber es gibt noch ein anderes Problem mit den Wetterstationen, die eigentlich komplexe Beschattungssteuerungen mit ein paar Sensoren sind. In diesen laufen komplexe Programme und sind mit sehr vielen speziellen Einstellungen ausgestattet. Es ist eine Elektronik, die sehr viel im Haus steuert und sich gleichzeitig am schlechtesten Ort dafür findet: Maximal dem Wetter ausgesetzt.

Damit geht eine deutlich häufigere Ausfallrate einher. Ich kenne Kunden, die mussten für Ihre - hoch über dem Haus auf einem Mast installierte viereckige Wetterstation - schon zweimal die entsprechende Hausseite eingerüsten lassen, um für Wartungszwecke da dran zu kommen (das Gerüst dann zwei Wochen stehen lassen bis die aus der Reparatur wieder zurück kommt). Haleluja...

Dazu kommt noch der Innovationsdruck und schon kann man bei Defekt die gleiche Wetterstation nicht mehr nachkaufen. Und die gesamte Parametrierung für die neue - natürlich noch komplexere Wetterstation - muss neu erarbeitet werden. Wenn man dafür eine Integrator braucht, dann muss die Familie von den Kosten her dieses Jahr auf den Urlaub verzichten....

Insofern denken wir schon, dass eine zentrale Beschattungssteuerung im kühlen Keller mit einer deutlich besseren Lebensdauer einhergeht und mit einem grafischen Interface auch viel einfacher bedienbar ist.

Wie oben schon gesagt finde ich einen Ausbau der Logikengine wünschenswert. Oder man geht hier den Umweg über Node-RED. Dann wäre ein Modul für Node-RED schöne, mit dem ich Zugriff auf die Timberwolf Objekte habe...

Das kannst Du selbst einrichten. Node-RED in einem Docker Container installieren und per MQTT kannst Du jedes Objekt des Timberwolf Servers verknüpfen.

Ich verstehe aber was Du meinst, wir sollen Node-RED als zusätzliche Logikengine im Timberwolf Server integrieren. Nun, die Idee ist nicht schlecht (und auch nicht neu), wir haben aber jetzt noch ein paar andere Baustellen, aber man kann das durchaus aufgreifen.


lg

Stefan

[Dragonos2000]

Ich muss sagen, dass die Custom-Logiken für mich gerade das Gegenteil von sperrig und unübersichtlich sind:
Was ich sonst aus mehreren einzelnen Bausteinen zusammensetzen müsste, habe ich in einem Monolithen, der für genau die Funktion da ist, die ich haben will. Aber ja: Die Custom-Logiken und der Programmieransatz sind nicht jedermanns Sache...

@carpi2001 Vielleicht ist es Dir entgangen, aber u.a. auch für die Beschattungsthematik findest Du Community-Logiken hier:
viewforum.php?f=65