Gibt es im LE für Custom Logiken die Möglichkeit, optionale Eingänge genau einmal auswählen zu können (wie bei den Ausgängen) ?
Bisher ist mir nur bekannt definieren zu können, dass es beliebig viele oder mindestens einen geben kann/muss. Ich möchte aber, dass ein optionaler Eingang höchstens genau einmal (per +-Zeichen im LE) hinzugefügt werden kann.
Noch besser wäre, einen Satz von Eingängen definieren zu können. Beispiel:
Mein Rolladen Baustein hat viele verschiedene Eingänge, die teilweise auch Parameter erfordern, wenn genutzt. Nehmen wir mal den Frostschutz mit einem Eingang und 2 Parametern. Diese Funnktion würde ich gerne als optional definieren, d.h. sie wird erst einmal nicht angezeigt und bei Bedarf füge ich sie per Auswahl nach Klick auf das +-Zeichen (genau einmal) hinzu. Dabei wäre es optimal, wenn ich nur einmal "Frostschutz" auswählenn muss und der Eingang samt der beiden Parameter werden eingeblendet.
Geht das aktuell irgendwie?
Insider Preview 3 veröffentlicht

Wir haben seben die Insider Preview 3 zur Version 4.8 veröffentlicht
Komplett überarbeiteter Logik Katalog mit verbesserter Übersicht und Suche für einfachere Auswahl der Lgik Module
Sechs neue Logiken für Farbraum-Umrechnungen (siehe Bild)
Fünfzehn neue Logiken aus der Community
Damit sind es nun 99 Logiken
Einundzwanzig neue winterliche Hintergründe für die VISU
Verbesserte Mouse-Over im VISU Editor für klarere Information
Das HTTP-API Subsystem liefert nun im Header stets Header Access-Control-Allow-Origin = * aus
Der Modbus Register Auswahlassistent erlaubt nun verschiedene Sortierungen beim Anlegen einer Transaktion
Viele Bugfixes
Release Notes: https://elabnet.atlassian.net/wiki/x/AYDD0
AKTION: Wir haben noch viele tolle Updates und 150 Videos (und 800 Wiki Seiten) geplant. Bitte unterstütze uns mit einem Software-Wartungsvertrag, damit wir dieses alles erreichen können. Und damit Dein Server weiterhin Updates, Upgrades und Support erhält. Jetzt in der Aktion schenken wir Dir den Insider Club mit derselben Laufzeit wie der am längsten laufende aktive Wartungsvertrag dazu - bei sofortigem Laufzeitbeginn. Damit profitierst Du auch von einer vorzeitigen Verlängerung. Alle Infos: https://elabnet.atlassian.net/wiki/x/GQB8z
[Frage] Optionale Eingänge/Set von Eingängen definieren
Forumsregeln
- Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
- Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
- Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
- Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
-
Dragonos2000
- Beiträge: 2208
- Registriert: So Aug 12, 2018 1:38 pm
- Wohnort: Karlsruher Raum
- Hat sich bedankt: 502 Mal
- Danksagung erhalten: 902 Mal
Optionale Eingänge/Set von Eingängen definieren
Lg
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit
-
Robert_Mini
- Beiträge: 3914
- Registriert: So Aug 12, 2018 8:44 am
- Hat sich bedankt: 1287 Mal
- Danksagung erhalten: 2227 Mal
Nein - Bug oder fehlendes Feature.
Das würd ich mir auch wünschen, denn damit kann man die Übersichtlichkeit deutlich erhöhen, was der Verbreitung der Custom Logiken dienen würde.
Machst du den FR?
Lg
Robert
Das würd ich mir auch wünschen, denn damit kann man die Übersichtlichkeit deutlich erhöhen, was der Verbreitung der Custom Logiken dienen würde.
Machst du den FR?
Lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297
-
Dragonos2000
- Beiträge: 2208
- Registriert: So Aug 12, 2018 1:38 pm
- Wohnort: Karlsruher Raum
- Hat sich bedankt: 502 Mal
- Danksagung erhalten: 902 Mal
Schon erledigt
Lg
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit
-
TobiasLessing
- Beiträge: 58
- Registriert: Do Dez 10, 2020 11:24 pm
- Wohnort: Zwochau
- Hat sich bedankt: 40 Mal
- Danksagung erhalten: 56 Mal
Guten Morgen,
ich würde hier mal meine Frage anhängen ob es bereits möglich ist oder im Zuge des o.g. FR* mit zu implementieren, die optionalen Eingänge näher zu definieren, d.h.:
wenn ich eine Input-Variable via $VAR<name!> definieren, dann wird mindestens ein Eingang benötigt, es sind aber beliebig viele möglich. Ich frage mich ob auch Einschränkungen oder Erweiterungen möglich wären, z.B.
Ist meine Frage ganz exotisch oder hätte da noch jemand Vorschläge oder gar eine Lösung?
*Ist da bereits was geplant? Oder sogar geschehen? Hab's nicht ganz auf dem Schirm
Vielleicht noch am Rande wozu das Ganze:
Ich sitze aktuell an der Lichtsteuerung via DMX und habe da Unmengen an Kanälen. Dabei könnte ich entweder Decoder (z.B. mit 1,3,4,12,16,24,32 Kanälen**) in jeweils einem Logikbaustein zusammenfassen oder ich mache für jeden Raum/jede Leuchtgruppe einen Baustein. So oder so werden es mehreren Bausteine mit unterschiedlichen Anzahlen von Eingängen.
**Bis das DMX-Subsystem vorhanden ist muss man mit den Hutschienenmodellen noch den Umweg über das DMX_Test-Modul gehen. Das ist aber derzeit auf 16 Kanäle begrenzt. Darüber hinaus müsste dann getrickst (zwei DMX_Test-Module) werden, was es einem mit den variablen Eingängen aber wieder erheblich erschwert.
OK. Schönen Sonntag euch allen noch!
Viele Grüße aus Sachsen
Tobias
ich würde hier mal meine Frage anhängen ob es bereits möglich ist oder im Zuge des o.g. FR* mit zu implementieren, die optionalen Eingänge näher zu definieren, d.h.:
wenn ich eine Input-Variable via $VAR<name!> definieren, dann wird mindestens ein Eingang benötigt, es sind aber beliebig viele möglich. Ich frage mich ob auch Einschränkungen oder Erweiterungen möglich wären, z.B.
- maximal zulässige Eingänge 1 .. 10
- minimal erforderliche Eingänge 3 .. n
- kombination aus beidem 3 .. 10
- eventuell auch eine Art Default/Vorschlag, also Anzahl der Inputs die üblicherweise genutzt werden 3 ..(7).. 10
- ganz abwegig, aber möglich: eine Anzahl ausschließen "alles außer 4" - 1..4..n
Ist meine Frage ganz exotisch oder hätte da noch jemand Vorschläge oder gar eine Lösung?
*Ist da bereits was geplant? Oder sogar geschehen? Hab's nicht ganz auf dem Schirm
Vielleicht noch am Rande wozu das Ganze:
Ich sitze aktuell an der Lichtsteuerung via DMX und habe da Unmengen an Kanälen. Dabei könnte ich entweder Decoder (z.B. mit 1,3,4,12,16,24,32 Kanälen**) in jeweils einem Logikbaustein zusammenfassen oder ich mache für jeden Raum/jede Leuchtgruppe einen Baustein. So oder so werden es mehreren Bausteine mit unterschiedlichen Anzahlen von Eingängen.
**Bis das DMX-Subsystem vorhanden ist muss man mit den Hutschienenmodellen noch den Umweg über das DMX_Test-Modul gehen. Das ist aber derzeit auf 16 Kanäle begrenzt. Darüber hinaus müsste dann getrickst (zwei DMX_Test-Module) werden, was es einem mit den variablen Eingängen aber wieder erheblich erschwert.
OK. Schönen Sonntag euch allen noch!
Viele Grüße aus Sachsen
Tobias
TWS 950Q ID:458, vormals 960Q mit FreshUp, VPN offen, Reboot erlaubt nach Rücksprache
TWS 950Q ID:488, offline
PBM SN 1048
TWS 950Q ID:488, offline
PBM SN 1048