Seite 1 von 2

Massenmodus für Logikeditor (via assoziativem Array)

Verfasst: Fr Aug 23, 2019 4:23 pm
von jensgulow
Ich würde ganz gerne all meine plugins usw. vom WG-Server auf den TWS umziehen. Der LE scheint mir ein mächtiges Werkzeug hierzu.

Nun gibt es durchaus Szenarien, wo die gleichen Berechnungen mit gleichen Eingängen und Ausgängen aber unterschiedlichen Datenquellen durchgeführt werden. Beispiel ist hier gerade der Beschattungsbaustein. Dieser müsste zumindest für jede Fassadenseite einmal angelegt werden (bei mir noch deutlich mehr).
Meine Frage ist: Könnte man prinzipiell den Bausteinen jeweils einen Hash an Datenquellen vorsetzen und diese auf die entsprechenden Ausgänge mappen - quasi einen "Hash-Baustein" entwickeln, welcher bei Bedarf den Baustein dann eben x-mal durchrechnet und das Ergebnis an die entsprechend gematchten Ausgänge weitergibt ?

Zum Beispiel ist die Datenquelle meines Beschattungsplugins ein hash in folgender Form (abgespeckt und gekürzt):

Code: Alles auswählen

my @AlleRolllaeden;
push @AlleRolllaeden, { name => "WZ Erker Mitte", winkel1 => 9, winkel2 => 169, wertZuBesch => 40, wertAufBesch => 0,wertZuNacht => 60, wertAufNacht => 0, sonnenAufUnter => 0, raumSollTemp => 22, GAraumSollTemp => "", GAraumIstTemp => "2/5/30", GAaufzu => "2/2/80", GAfahren => "2/2/83", GAstatus => "2/2/81", GAsperre => "2/2/89", Sperre => "Global_Jalousie_WZ_Erker_Mitte_Sperre"  };
push @AlleRolllaeden, { name => "WZ Erker Seite", winkel1 => 9, winkel2 => 169, wertZuBesch => 40, wertAufBesch => 0,wertZuNacht => 60, wertAufNacht => 0, sonnenAufUnter => 0, raumSollTemp => 22, GAraumSollTemp => "", GAraumIstTemp => "2/5/30", GAaufzu => "2/2/70", GAfahren => "2/2/73", GAstatus => "2/2/71", GAsperre => "2/2/79", Sperre => "Global_Jalousie_WZ_Erker_Seite_Sperre"  };
Nun arbeitet das plugin beim Aufruf brav einen Rolladen nach dem anderen in einer foreach-Schliefe ab und gibt die entsprechenden Befehle raus.

Code: Alles auswählen

foreach my $element (@AlleRolllaeden) {.....};
Wahrscheinlich ein nicht erfüllbarer Wunsch, aber ich wollte ihn wenigstens einmal vortragen falls doch eine Möglichkeit besteht. Vorteil wäre, dass man im LE nicht soviele Bausteine anlegen muss.

Re: Hash als Datenquelle für Eingänge+ Ausgänge einer Logik im LE

Verfasst: Fr Aug 23, 2019 5:05 pm
von Dragonos2000
Soll jetzt nicht besserwisserisch klingen oder so: Du meinst ein selbst definiertes Array oder Objekt übergeben, oder?
Also quasi eine Sammlung mehrerer Parameter auf einmal übergeben, richtig?

Bei "Hash" denke ich nämlich an was ganz anderes: Das ist nämlich ein irreversibel errechneter Wert, quasi ein einmaliger Fingerabdruck...

Re: Hash als Datenquelle für Eingänge+ Ausgänge einer Logik im LE

Verfasst: Fr Aug 23, 2019 5:10 pm
von jensgulow
Sorry, war vielleicht missverständlich... ich meinte einen Hash wie er in perl benutzt wird. Oder eben auch assoziatives Array genannt. Habe den Titel angepasst.

Re: Hash/ assoziatives Array als Datenquelle für Eingänge+ Ausgänge einer Logik im LE

Verfasst: Fr Aug 23, 2019 9:12 pm
von Chris M.
Ich schrecke auch noch etwas davor zurück meine Heizungsregelung auf den LE-PID umzuziehen - da hätte ich dann gleich etliche Bausteine auf einmal und ich bin mir noch nicht sicher (weil ich keine Erfahrung darin habe) wie gut sich das einfach anlegen und pflegen lässt.

Beim WireGate hatte ich extra den PID-Regler zum Multi-PID dafür erweitert... Vgl. https://github.com/OpenAutomationProjec ... lti-RTR.pl

Ob das jetzt mit Array / Hash die geeignete Lösung ist oder nicht kann ich nicht beurteilen.

Aber ein "Massen-Modus" wäre schon schön.

Re: Hash/ assoziatives Array als Datenquelle für Eingänge+ Ausgänge einer Logik im LE

Verfasst: Fr Aug 23, 2019 9:21 pm
von StefanW
Hallo Foristen,

der Timberwolf Server ist dafür ausgelegt, vor allem EINFACH und möglichst Intuitiv nutzbar zu sein, wenn das Grundkonzept verstanden ist.

Wir wollen vor allem, dass Elektriker, Integratoren und Industriekunden sich damit einfach zurecht finden und Funktionen einfach umsetzen können. Wir wollten absichtlich nicht, dass ein Kunde sich mit Programmierung und so weiter befassen muss, sondern dafür eben einfach und intuitiv nutzbare Logikelemente hat.

Für erweiterte Konzepte durch Schleifen, Hash- und Array-Modi würden wir Hemmschwellen einbauen, die nur ein Prozent der Nutzer überhaupt versteht. Wenn Ihr das wollt, könnt ihr Euch im Container in jeder beliebigen Programmiersprache austoben. Wir hoffen, dass wir zügig auch eine Implementierung von MQTT* erreichen und das ist eine sehr geeignete und weit bekannte und von allen Sprachen unterstützte Schnittstellen zwischen Server und Container. Weil ich fürchte, die Profis werden erst zufrieden sein, wenn sie was selbst programmieren können.

*Nicht für jeden Server / Care-Vertrag. Wird noch definiert, aber es soll nicht heißen, das hätte ich für jeden Versprochen. Nein, keine Anfragen, das ist noch nicht ausgerechnet und bestimmt.

lg

Stefan

Re: Hash/ assoziatives Array als Datenquelle für Eingänge+ Ausgänge einer Logik im LE

Verfasst: Fr Aug 23, 2019 9:31 pm
von jensgulow
Verstanden.

Re: Hash/ assoziatives Array als Datenquelle für Eingänge+ Ausgänge einer Logik im LE

Verfasst: Fr Aug 23, 2019 10:19 pm
von Chris M.
@StefanW genau deswegen hab ich geschrieben, dass ich nicht weiß was hier die optimale Lösung für ist.

Gerade bei dem RTR würde aber auch genau die "Brauche-simple-Lösung"-Zielgruppe von einem Massenmodus profitieren. Der natürlich auch simpel zu nutzen sein müsste :)

Re: Hash/ assoziatives Array als Datenquelle für Eingänge+ Ausgänge einer Logik im LE

Verfasst: Fr Aug 23, 2019 10:45 pm
von jensgulow
Danke Chris, natürlich ist mir bewusst, dass das initial angesprochene Hash /Array nicht alltagstauglich ist. Du hast meinen Wunsch mit "Massenmodus" bestens beschrieben. Und ich pflichte auch Stefan bei, dass das Ganze nach dem Keep it simple Prinzip funktionieren muss.

Re: Hash/ assoziatives Array als Datenquelle für Eingänge+ Ausgänge einer Logik im LE

Verfasst: Fr Aug 23, 2019 10:50 pm
von Robert_Mini
Nachdem ich nun schon einige Zeit mit Logiken Arbeite, muss ich hier Stefan schon recht geben.
Keep it simple. 10 Jalousien =>10 Jalousienbausteine. Abgesehen davon, dass dann doch oft Dinge unterschiedlich sind, bleibt es bei Verwendung der Tags doch sehr übersichtlich. Einfach nach "Jalousie" gefiltert, dann sieht man eben genau diese 10 Logiken.

Wenn man dann noch mit den Namen der Logiken ein wenig Ordnung schafft, ist das doch sehr übersichtlich.
Ich meine inzwischen übersichtlicher, als Plugins, in denen dann wiederum ein 10-fach hash abgearbeitet wird.

Und ja, am Ende wird man je nach Umfang mehrere 100 Logikzellen sehen und dann wird eine gewisse Sortierung bzw. Verwendung von Tags notwendig sein. Dafür hat man für jede Zelle eine Analyse mit Doc-Mode, kann sie getrennt deaktivieren, etc.

lg
Robert

PS: Aber mir ist schon klar, dass die Anwendung von hash in plugins sehr mächtig war.

Re: Hash/ assoziatives Array als Datenquelle für Eingänge+ Ausgänge einer Logik im LE

Verfasst: Sa Aug 24, 2019 9:11 am
von StefanW
Oki,

nicht falsch verstehen, es ist nicht so, dass wir Euch nicht geben wollen, was wichtig und sinnvoll ist. Ich muss nur als Produktmanager an alle Zielgruppen denken.

Erklärt mir doch bitte, wie Ihr Euch einen "Massenmodus vorstellt)

Ein Baustein mit den üblichen Eingängen, aber man kann mehrere Raffstore / Jalousien auf einmal ansteuern, weil man mehrere Ausgänge hat?

Da bräuchte man quasie eine im Baustein anklickbare Tabelle, in der die Variablen der Fenster (Himmelsausrichtung, Behanghöhe, Verfahrzeit) angebbar sind?

Stefan