Timberwolf Server - Logikengine als Ersatz für Logikprozessor.pl

[PhelliBunny]

Hallo,

bei einem Zustandsautomaten spielt der aktuelle Zustand auch eine entscheidende Rolle.
Beispiel:
Du hast 3-x Szenen, zwischen diesen willst du mit 1 Taster hin- und herschalten.
Du bist aktuell in Zustand_1 (Szene1), dann wird der Taster betätigt, mit dem du die nächste Szene einschaltest. Du wechselst in den Zustand_2 (Szene2) und schaltest dementsprechend die Aktoren. Wird der Schalter wieder betätigt, wechselst du in Zustand3 und beim nächsten Mal in Zustand1.

Die Bedingung zum Weiterschalten ist also immer dieselbe und zwar die Tastenbedienung. Aber welche Szene als nächstes eingeschaltet wird, bzw. welche Ausgänge geschaltet werden, ist abhängig von der aktuellen.
Szene1 -> Szene2 -> Szene3 -> Szene1

Ich hoffe das konnte helfen

[supernode]

Hallo,

ich würde mir folgende Funktionen wünschen.
Da mein Server noch nicht da ist kann ich mir leider ist das natürlich ein Schuss ins Blaue. Vielleicht hilft es euch ja trotzdem. Die Klammern [] sollen meinen Anwendungsfall zeigen.

Logik:
- Grundlegende Logikgatter beliebiger Größe
- Vergleichsoperationen
- LUT (Look-up Table, 8 Eingänge sollte für viele Fälle ausreichen), Auswahl wäre bspw. ein Boolean [beliebige logische Operationen mit weniger Gattern, Übersichtlichkeit, Werteauswahl]
- LUT Änderung (Schreiben) [LUT regelt ob Zugriffsberechtigung erlaubt (Fingerprint, iButton), Änderung via Visualisierung]
- Zustandsautomat (FSM) [Szenen-Ablauf, unterschiedliches Verhalten je nach eingestellter Szene]
- Hierarchische FSM [Szenen-Ablauf und Szenen-Umschaltung]
- Kommentare ["In-line" Dokumentation]
- Hierarchische Strukturierung [Übersichtlich nach Funktion untergliederung, z.B "Licht Keller"]
- Debug-Modus mit Breakpoints, Auslesen der Variablenwerte [Fehlersuche am echten System, Inbetriebnahme]
- Neustart / Umschaltung der Logik-Engine
- Snapshot des Logik-Engine-Programms und Wiederherstellung [Ausprobieren ob eine Funktion funktioniert, zurückschalten auf Produktivsystem]

Schnittstellen:
- UDP TX, Daten beliebig zusammenstellbar (Script?)
- UDP RX, jedoch nur Sinnvoll wenn man die Empfangsdaten irgendwie (Script?) extrahieren kann.
- HTTP-Requests, Parsen / RegEX der Antwort [Status-Informationen von Gerät abfragen welches nur HTTP anbietet]
- SQL-Abfrage [Zugriffsbrechtigung (Fingerprint) ist in DB abgelegt und wird dort verwaltet]
- Wetterdaten aus dem Netz
- Kalendersynchronisation (CalDAV), Auswertung der Kalenderinformation
- E-Mail
- Einbindung weiterer Timberwolf-Server [... welche bspw. in einer Unterverteilung sitzen]

Fremdsysteme
- E-key (net) [Fingerprinterkennung]
- LED Stripes (bspw. WS2812b)
- Sprachsteuerung, möglichst Offline ohne Cloud

Habt ihr mal überlegt eine Schnittstelle anzubieten mit der ein Anwender beliebige Gatter / Funktionen / Erweiterungen / Plugins selbst erstellen kann?
So könnte die Community Dinge beitragen die sonst vmtl. nicht so schnell oder gar nicht verfügbar werden. Oder, wenn man sowas via Docker lösen sollte, gibt es eine Möglichkeit Logiken / Interfaces in einen Docker-Container auszulagern und das dann in die Logik-Engine zu integrieren?

(M)ein Smart-Home krankt daran dass viele Schnittstellen / Syteme zusammenspielen müssen. An allen Ecken wird gebastelt was dann zwar funktionieren mag, aber eben leider auch sehr speziell ist - viele Scripte / Progrämmchen die irgendwie nur in Kombination funktionieren. Wenn mir was passiert geht Nichts mehr und meine Frau darf dann erst mal ein E-Technik-Studium machen damit sie wieder zur Tür herein kommt. Besser wärs wenn ein kommerzielles System (z.b: Timberwolf Server) mit dessen Logik-Engine das alles übernimmt. So ist wenigstens alles an einem Ort und über eine Art administrierbar. Da kommt dann (hofentlich) auch meine Frau zurecht - im Fall der Fälle. Damit das klappt brauch ich aber eine einfache Erweiterbarkeit der Logik-Engine um meine Fremdsystemanbindungen.

Wie wäre es mit einer Fall-Back-System-Umschaltung? Abhängig von einer Schalterstellung startet die Logik-Enginge unterschiedliche "Programme". So könnte eine Basisfunktion dafür sorgen dass zumindest das nötigste wie Licht und Heizung funktionieren. Das Normalsystem hat dann noch Effektbeleuchtung und erweiterte Regelfunktionen, welche aber nicht unbedingt notwendig sind.
Alternativ könnte man die Logik-Enginge auch aus der Logik-Engine raus neu starten unter Angabe des Programmpfades. So könnte ein "Bootloader-Programm" die Schalterstellung auswerten und unterschiedliche Logik-Engine-Programme laden.

Noch eine Sache zu Erweiterungen: Man ließt in einigen Beiträgen dass Erweiterungen über CAN-Bus angebunden werden sollen.
Wäre es nicht universeller wenn stattdessen Netzwerk mit Standard-Protokoll (MQTT, OPC UA, ...) als Anbindung dient? So könnte man die Gateways, welche in naher Zukunft von euch dazu kommen sollen - für bspw. DALI, DMX oder 1-Wire (PBM) - auch von anderen Geräte nutzen.


Grüße
Martin

[StefanW]

Hallo Martin,

ein paar kurze Anmerkungen:

• Bitte erkläre mir, wie Du Die dir LUT konkret vorstellst. Also auch optisch (skizze). Sehe Dir dazu die BEscheibung des Logikeditors im Katalog an.

In etwa die Hälfte dessen, was Du beschreibst, haben wir in der Planung für die ersten beiden Versionen drin. Die komplexeren Dinge mit Protokollen kommen später dazu.

Habt ihr mal überlegt eine Schnittstelle anzubieten mit der ein Anwender beliebige Gatter / Funktionen / Erweiterungen / Plugins selbst erstellen kann?

Ja. Zunächst kann man sich eine Kombination aus Gattern zusammenstellen und mit einfachem json definieren. Beispiel ist im Katalog.

Dann haben wir daran gedacht, dass man Docker-Scripte starten kann, da muss aber noch eine Schnittstelle her.

Die Logikengine ist in purem C geschrieben, da will ich nichts vom Kunden integrieren, das macht schnell was kaputt. Aber man könnte eine parallel Engine für Scripte haben.

(M)ein Smart-Home krankt daran dass viele Schnittstellen / Syteme zusammenspielen müssen. An allen Ecken wird gebastelt was dann zwar funktionieren mag, aber eben leider auch sehr speziell ist - viele Scripte / Progrämmchen die irgendwie nur in Kombination funktionieren. Wenn mir was passiert geht Nichts mehr und meine Frau darf dann erst mal ein E-Technik-Studium machen damit sie wieder zur Tür herein kommt.

Danke für Deine Ehrlichkeit, ich fürchte das haben viele so, ohne an die Nachwelt oder die eigene Erkrankung zu denken. Wir sind alle sehr endlich, stärker als wir das im täglichen Handeln berücksichtigen. Bei mehr als 5.000 Kunden hatte ich durchaus schon auch mit Erben der Kunden zu tun. Am schlimmsten - neben all der Trauer - sind Passwörter um an alles zu kommen. Und Dokumentation.

Besser wärs wenn ein kommerzielles System (z.b: Timberwolf Server) mit dessen Logik-Engine das alles übernimmt. So ist wenigstens alles an einem Ort und über eine Art administrierbar. Da kommt dann (hofentlich) auch meine Frau zurecht - im Fall der Fälle. Damit das klappt brauch ich aber eine einfache Erweiterbarkeit der Logik-Engine um meine Fremdsystemanbindungen.

Dein Gedanke ist völlig richtig. Weil die zig, irgendwo verbauten Raspis, mit unterschiedichem Systemstand, Version und unklarer Aufgabe kann niemand supporten. Deshalb haben wir den Timberwolf Server auch so projektiert wie er ist, als Server der maximal integrationsunterstützend ist. Wer Angst vor zuviel Macht in einem System hat, kann sich auch zwei hinstellen. Wichtig ist, dass es ein bekanntes und supportbares System ist.

Weil Deiner Frau kann umso leichter geholfen werden, wenn es ein System ist, für das es (in einigen Jahren) Partner und Fachleute gibt, die wissen, wo sie was nachsehen müssen und mit einem Hersteller zu tun haben, der hier helfen kann. Hier kommt dann auch der Timberwolf Care Vertrag insofern zum tragen, weil prinzipiell Fachleute vorgehalten werden (auch wenn die einzelne Tätigkeit abgerechnet wird).

Wie wäre es mit einer Fall-Back-System-Umschaltung? Abhängig von einer Schalterstellung startet die Logik-Enginge unterschiedliche "Programme". So könnte eine Basisfunktion dafür sorgen dass zumindest das nötigste wie Licht und Heizung funktionieren. Das Normalsystem hat dann noch Effektbeleuchtung und erweiterte Regelfunktionen, welche aber nicht unbedingt notwendig sind.

Abgesehen davon, dass dies einfach möglich wäre, frage ich nach dem Grund. Du meinst, wenn der Server wegen einer Logik hängenbleibt, dass dann andere wenigstens noch funktionieren? Ich denke nicht, dass hier was hängenbleibt, weil Datenstrukturen durchgerechnet werden. Irgendwie müsste der Kunde dann auch wichtige von unwichtigen Logiken trennen durch Markierung. Ich glaube weder dass dies nötig ist noch dass es erklärbar ist. Aber vielleicht habe ich auch nicht ganz richtig verstanden.

Noch eine Sache zu Erweiterungen: Man ließt in einigen Beiträgen dass Erweiterungen über CAN-Bus angebunden werden sollen.

Das ist nur für "kleinere" Interfaces gedacht, die keine Netzwerkschnittstelle haben.

Wäre es nicht universeller wenn stattdessen Netzwerk mit Standard-Protokoll (MQTT, OPC UA, ...) als Anbindung dient? So könnte man die Gateways, welche in naher Zukunft von euch dazu kommen sollen - für bspw. DALI, DMX oder 1-Wire (PBM) - auch von anderen Geräte nutzen.

Theoretisch ein guter Gedanke. Praktisch muss man dass dann alles dokumentieren und hat womöglich einen großen Support-Aufwand für die kleineren Geräte, der nicht durch Einnahmen gedeckt ist.

Wer sich unser Pricing ansieht, wird bemerken, dass unsere Interfaces wie PBM / TP-UART in keiner Weise teuer sind, obwohl der Kunde, wenn er den Server hat, nur unsere Interfaces verwenden kann. Wir machen also kein Extrageschäft mit überteuertem Zubehör - und müssen das auch nicht, weil wir den aufwändigen Server nicht subventioniert verkaufen. Man sehe sich nur mal die L....e M...Server an. Da kostet der Server sehr wenig, aber die Erweiterungen sind extrem. Ein Busmaster der nur 20 Slaves kann kostet mehr als unser PBM der zum gleichen Preis 40 Slaves auf ehrliche 400m kann und zum kleinen Preis dann noch um zwei weitere unabhängige Kanäle erweitern kann. Im Vollausbau kostet ein PBM mit 3 Kanälen und 240 Slaves dann geau soviel wie zwei Erweiterungen des Wettbewerbs mit dann zwei Kanälen und zusammen 40 Slaves.
Worauf ich hinaus will, dieses günstige Pricing unserer Erweiterungen ließe sich nicht halten, wenn wir diesen Erweiterungen eine Netzwerkschnittstelle, eine zusätzliche Software und Dokumentation über die Schnittstelle geben müssten. Damit würden wir diese Erweiterungen deutlich teurer machen müssen, nur damit externe Server diese auch benutzen können? Ich glaube das ist nicht im Sinn unserer Kunden. Für verschiedene Versionen reicht die Stückzahl nicht.

Deine Idee ist zwar ein nachvollziehbarer Wunsch, aber bei den Stückzahlen die wir hier haben wirtschaftlich nicht umsetzbar.

Was allerdings im Plan ist, dass man mehrere Timberwolf Server zusammenschalten kann. Schließlich ist es ein Rudeltier.


lg

Stefan
.

[supernode]

Hallo Stefan,

danke für die flotte Rückmeldung - trotz wunderbarem Wetter draußen. Wo findest du nur immer die Zeit.

LUTs:
Die LUT würde ich mir als Tabelle vorstellen welche in jeder Zeile eine Menge an Eingängen (Bool, Integer) mit einer Menge an Ausgängen (Mehrere Typen) verbindet.
Auch einfache Zustandsautomaten könnten so realisiert werden.

Eingänge:
- Eingang = vorgegebener/fester Wert
- Eingang = Wertebereich (bspw. -5 ... 10)
- Eingang = Don't Care -> erlaubt jeden Wert, womit sich eine Priorisierung der Eingänge durchsetzen ließe.

Ausgänge:
- Ausgang = vorgegebener/fester Wert
- Ausgang = Function(Eingangswert)
- Ausgang = vorheriger Wert
- "Calculated"-Signal um zu erkennen wann eine Logik ausgeführt wurde
- "Changed"-Signal um zu erkennen wenn der Ausgang / Zustand geändert wurde.

Grafisch würde das ja sehr gut in euer Konzept vom Katalog passen.
Bei Doppelklick auf das LUT-Gatter geht eben die Tabelle auf. Eine Zeile entspricht einer Eingangs-/Ausgangs-Kombi.
Die letzte Zeile enthält eine Reihe "Don't Cares", so dass in jedem Fall eine Kombination greift. Diese Default / Fallback-Variante wird eingenommen wenn keine der vorherigen Eingangskombination greift.
Die Zeilen müsste man dann sortieren können, da die Reihenfolge Einfluss auf die Auswertung haben kann.

Ich komme aus dem Bereich digitale Logik (FPGAs) wo LUTs die Basis jeglicher Verschaltung sind. Natürlich kann man viel auch mit einzelnen Vergleichern und UND-ODER-Stufen erreichen. In einer tabellarischen Auflistung wo nur bestimmte Werte betrachtet werden, finde ich es jedoch übersichtlicher.
Sicher kann man bei längerer Überlegung den obigen Vorschlag noch weiter ausfeilen und mehr funktionalität / Features hinzu nehmen. Aber so als Gedankenanstoß reicht es sicherlich erst mal aus. Ansonsten muss ich wohl doch mal zu nem Kaffee bei euch vorbei schauen.

Im Katalog steht dass pro Ein- oder Ausgang eine Logikzelle verwendet wird. Bei einem 4-fach AND mit einem Ausgang brauch ich also schon 5 Zellen, richtig?
Hierzu gibt es ja die Lizenzerweiterungen gemäß Preisliste. Muss ich diese vor/bei der Bestellung buchen oder kann man es dann (zum gleichen Preis) später dazu ordern?
Gibt es ein Maximum an verwaltbaren Logikzellen? (in meinem Fall TS 2600)


Umschaltung der Logik-Engine
Zugegeben vllt. war es noch nicht ganz zu Ende gedacht, aber wir sind hier ja im Brainstorming und Wünsch-dir-was-Forum! Was ihr dann daraus macht kann ich dann nicht beeinflussen.
Es geht mir nicht darum dass euer Server hängen bleiben könnte - so viel Vertrauen habe ich schon.
Mir geht es viel mehr darum dass ich bei einem Smart Home des Öfteren mal Dinge ausprobieren will oder bei der Implementierung bin. Dies dauert aber mitunter auch etwas Zeit und die ist bekanntlich knapp. Eine Umschaltung zwischen Produktivsystem und Testsystem auf einfache Weise wäre daher wünschenswert.
Das kann natürlich auch via Webinterface möglich sein. Der Suspendierungs-Eingang (Katalog) ist ja schon mal ein guter Ansatz. Vielleicht will ich jedoch zwischen zwei Programmständen hin- und herwechseln. Die Logikressourcen sind begrenzt, so dass ich die ganzen Blöcke nicht zweifach vorhalten kann.



Erweiterung via Ethernet
Deine Argumente sind schon verständlich. Als Anwender lege ich mich so halt auf einen Anbieter fest, was man ja bei Verwendung von KNX gerade vermeiden will.
Daher auch die Netzwerkschnittstelle - die wird vermutlich die längste Zeit nutzbar sein wenn man an 20+ Jahre in die Zukunft blickt.

Zusammenschaltung mehrer TS
Super, vielen Dank! Dann war die Bestellung des 950Q für die Garage doch keine schlechte Idee.


Grüße
Martin

[StefanW]

danke für die flotte Rückmeldung - trotz wunderbarem Wetter draußen. Wo findest du nur immer die Zeit.

Ich nehme sie mir. Sitze allerdings auch im Garten.

Aber so als Gedankenanstoß reicht es sicherlich erst mal aus. Ansonsten muss ich wohl doch mal zu nem Kaffee bei euch vorbei schauen.

Gerne, weil das Thema LUT würde ich gerne mehr im Detail wissen

Im Katalog steht dass pro Ein- oder Ausgang eine Logikzelle verwendet wird.

Ich hoffe, dass es nicht so da steht.

Mit Logikzelle ist eine ganze Logik gemeint mit Ein- Und Ausgängen und eben der Box in der Mitte.

Ein Ein- oder Ausgang stellt einen Logikpunkt dar. Danach wird auch lizensiert.

Bei einem 4-fach AND mit einem Ausgang brauch ich also schon 5 Zellen, richtig?

Ja. 5 Logikpunkte

Hierzu gibt es ja die Lizenzerweiterungen gemäß Preisliste. Muss ich diese vor/bei der Bestellung buchen oder kann man es dann (zum gleichen Preis) später dazu ordern?

Kann man jetzt noch gar nicht ordern, sondern dann später, wobei der Preis nicht auf Lebenszeit fest angeschlagen ist.

Gibt es ein Maximum an verwaltbaren Logikzellen? (in meinem Fall TS 2600)

Das kommt auch darauf an, was sonst noch drauf läuft. Das Limit ist dann erreicht, wenn alle vier CPU Kerne auf 100 % stehen. Aus den bisherigen Tests zu urteilen, wird es keine auch noch so große Logik geben, die das schafft. Als wir die Engine entwickelt haben, war die Vorgabe noch der 950 ohne Q, also die in der Leistung stark limitierte Version. Der 2600er hat etwa die 40 bis 50 fache Leistung davon, was als Zielhardware ursprünglich für die Entwicklung der Logikengine stand. Also ich denke, man muss sich keine Sorgen machen. Wenn natürlich in Docker ein Plex läuft, das ein Video transkodiert, ist das was anderes.

Mir geht es viel mehr darum dass ich bei einem Smart Home des Öfteren mal Dinge ausprobieren will oder bei der Implementierung bin. Dies dauert aber mitunter auch etwas Zeit und die ist bekanntlich knapp. Eine Umschaltung zwischen Produktivsystem und Testsystem auf einfache Weise wäre daher wünschenswert.

Verstanden. Ja wir haben einen Debug-Modus mit Simulation geplant. Du würdest das für mehrere zusammenhängende Logiken haben wollen. Über das zusammenhängende müssen wir nachdenken.

Der Suspendierungs-Eingang (Katalog) ist ja schon mal ein guter Ansatz.

Ist auch für Verschaltung gedacht, damit kann die eine Logik die andere suspendieren. Z.b auch durch einen durchgereichten Error-Ausgang einer vorhergehenden Logik.

Deine Argumente sind schon verständlich. Als Anwender lege ich mich so halt auf einen Anbieter fest, was man ja bei Verwendung von KNX gerade vermeiden will.

Naja die Erweiterungen sind eigentlich usätzliche Möglichkeiten um noch mehr Schnittstellen mit einem gerät zu unterstützen. Das ist ein Vorteil, den andere gar nicht erst haben. Oder kannst Du an übliche KNX-to-DMX Gateways noch weitere DMX-Kanäle anschließen?

Super, vielen Dank! Dann war die Bestellung des 950Q für die Garage doch keine schlechte Idee.

Ahh, Du warst das.

lg

Stefan

[Dragonos2000]

Als Idee/Feature Request, falls das halbwegs vernünftig möglich ist:
Lässt sich aus Außenhelligkeit, Sonnenstand und Fensteröffnung mit Korrekturfaktor ein sinnvoller Lichteinfall errechnen (quasi eine virtuelle Raumhelligkeit)? Wäre doch dann evtl. eine interessante Funktion "out of the box"...

StefanW : Macht's nicht Sinn, den Thread anzupinnen, um weitere Ideen zu sammeln ?

Lg
Jochen.

[StefanW]

Hallo Jochen,

Lässt sich aus Außenhelligkeit, Sonnenstand und Fensteröffnung mit Korrekturfaktor ein sinnvoller Lichteinfall errechnen (quasi eine virtuelle Raumhelligkeit)? Wäre doch dann evtl. eine interessante Funktion "out of the box"...

Hmm, interessante Idee. In welcher Einheit?

• Beleuchtungsstärke (nur sichtbares Licht) in Lux?
• Bestrahlungsstärke (also auch IR) in W/m²
• Auch In welcher Raumtiefe?
• Auch In welcher Raumhöhe (weil man die Tageslichthelligkeit auf dem Schreibtisch wissen möchte)?

Könnte man als Bestandteil einer Beschattung realisieren...

Macht's nicht Sinn, den Thread anzupinnen, um weitere Ideen zu sammeln ?

Schaun wir mal, ich habe Deinen Wunsch mal umgesetzt

lg

Stefan

[Dragonos2000]

Gedanke ist in Lux, abhängig von der Entfernung vom Fenster (also Raumtiefe), keine Höhe, um Beschattung aber auch Beleuchtung steuern zu können.
Über die Idee mit der Bestrahlungsstärke muss ich mal hirnen...

Lg
Jochen.