UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[DISKUSSION] [V4.0 IP2] Funktion Logik Dim-Aktor

Informationen und Diskussionen über Logik-Engine und Logik-Editor
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

Ersteller
Marko
Reactions:
Beiträge: 13
Registriert: So Dez 04, 2022 8:36 am
Hat sich bedankt: 2 Mal
Danksagung erhalten: 3 Mal

[V4.0 IP2] Funktion Logik Dim-Aktor

#1

Beitrag von Marko »

Hallo zusammen,

ich beschäftige mich gerade mit dem Logikbaustein Dim-Aktor. So wie ich es verstanden habe, transferiert er 4-Bit Dimm-Befehle in einen 1Byte Absolutwert. Ich habe daher meinen MDT Glastaster mit einem Dimmobjekt belegt, welches dann auch die entsprechenden relativen Dimmbefehle aussendet (Break, +100%, -100%). Ich sehe das auch so in der Logik, allerdings ist der Ausgabewert mit dem ersten Dimmbefehl vom Glastaster sofort auf 100% oder 0%. Am anderen Ende der Kette hängt ein Shelly Dimmaktor - das Ziel ist demnach das Dimmen des Shelly Aktors, der nur absolute Dimmbefehle verarbeitet, mit den relativen Dimmbefehlen des Datentyps 4Bit (3.007). Kann der Dim-Aktor dafür verwendet werden - und wenn ja wie habt ihr ihn parametriesiert, um das hinzubekommen? Oder gibt es einen alternativen Weg?

Vielen Dank vorab und beste Grüße

Marko
TWS3500 / ID1009 / Support-VPN: Ja / Reboot: Ja /

tomknocke
Reactions:
Beiträge: 15
Registriert: Di Dez 06, 2022 7:35 am
Danksagung erhalten: 14 Mal

#2

Beitrag von tomknocke »

Hallo,

ich habe leider auch das Problem mit dem Glastaster. In meinen Fall soll eine Hue Lampe gedimmt werden. Ich komme auch nur auf 0 oder 100%.
Damit es funktioniert müsste sich die Logik langsam an das Ziel heranarbeiten. D.h. der Glastaster sendet 100% und sendet ein Stop sobald die Taste losgelassen wird. Die Logik muss sich also etwas Zeit auf dem Weg zu 100% lassen.

Lässt sich dieses Verhalten irgendwie mit dieser Logik oder einer anderen umsetzen?

Danke für jeden Hinweis.

VG Tom
TWS 3500 XL ID: 1057 - VPN inaktiv, Reboot nur nach Absprache - 4.0 Insider Preview 3

maggyver
Reactions:
Beiträge: 364
Registriert: So Okt 14, 2018 1:48 pm
Hat sich bedankt: 228 Mal
Danksagung erhalten: 274 Mal

#3

Beitrag von maggyver »

Hallo @Marko und @tomknocke,


zu eurer Information beim KNX gibt es zwei Arten beim Relativen Dimmen.

1. Relatives Dimmen mit Telegrammwiederholung

Wie schon der Name vermuten lässt wird hierbei das Telegramm und somit der Dimmschritt (Wert, meistens kleiner 100%) solange wiederholt, bis die Taste vom Anwender nicht mehr betätigt wird.

2. Relatives Dimmen mit Stopptelegramm

Wie ihr schon feststellen musstet, wird hierbei ein fester Dimmschritt (Wert meistens 100%) einmalig am Anfang gesendet und beim Loslassen der Taste dann eben das sogenannte Stopptelegramm.

Die Funktion Logik Dim-Aktor würde im ersten Fall das von euch gewünschte Ergebnis liefern.

Ich kenne nicht die Einstellmöglichkeiten des bzw. der Glastaster(s). Entweder könnt ihr die Dimmimplementation von "Dimmen mit Stopptelegram" auf "Dimmen mit Telegrammwiederholung" stellen (Achtung erhöhte Buslast) oder Marko du schaust dir mal die Shelly API an und kannst dann darüber eventuell eine Anpassung realisieren.

Bild

Tom, mit den HUE Leuchten steh ich auf Kriegsfuß ...

Nachtrag: Schreibfehler korrigiert
Zuletzt geändert von maggyver am So Feb 19, 2023 10:43 am, insgesamt 4-mal geändert.
Grüße
René
_______________________________________________________________________________

TWS 2600LW ID:504 + PBM ID:892 + PBM ID:910 , VPN offen , Reboot erlaubt, Offline, Insider
TWS 950QL ID:379 , VPN offen, Reboot erlaubt, Offline, Insider

tomknocke
Reactions:
Beiträge: 15
Registriert: Di Dez 06, 2022 7:35 am
Danksagung erhalten: 14 Mal

#4

Beitrag von tomknocke »

4.0 IP3

Hallo René,

danke für deine gute Erklärung. So in der Art habe ich es mir schon gedacht.

Ich habe inzwischen eine Lösung mit dem MDT Glastaster gefunden.
Glastaster_Dimmen.jpg
Die Funktion Werte senden=>Werte verschieben ist eine gute Alternative.
Leider kann man hier nicht per langem Tastendruck an/ausschalten. Aber zumindest sauber dimmen.

Die Rechner Logik im TW wandelt es dann von % zu 254 für Hue um und schiebt es auf die API.
Auslesen des Status für die Rückmeldung läuft ebenfalls sauber über API über Rechnerlogik zu KNX.

Eine Dimm Logik mit Verzögerung wäre natürlich trotzdem nochmal eine tolle Bereicherung für den TW.

Die HUE API funktionert ganz gut mit dem TW. An/Aus, Dimmen, Szenenwahl auch auf Gruppen sind leicht umsetzbar.
Nur Farben direkt wählen habe ich noch nicht versucht. Das Hue System scheint mir nicht direkt zu den KNX Standards zu passen. Aber über Szenen auch für mich ausreichend. Ich hatte schon HUE vor dem TW von daher bin ich dabei geblieben.

Danke
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
TWS 3500 XL ID: 1057 - VPN inaktiv, Reboot nur nach Absprache - 4.0 Insider Preview 3

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#5

Beitrag von StefanW »

Hi,
tomknocke hat geschrieben: So Feb 19, 2023 5:57 pmEine Dimm Logik mit Verzögerung wäre natürlich trotzdem nochmal eine tolle Bereicherung für den TW.
Bitte genauer erklären. Ich kann nur etwas an die Entwickler geben, das ich verstanden habe.

Bitte in einem separaten Thread als Diskussion, an der sich andere beteiligen können.

lg

Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

maggyver
Reactions:
Beiträge: 364
Registriert: So Okt 14, 2018 1:48 pm
Hat sich bedankt: 228 Mal
Danksagung erhalten: 274 Mal

#6

Beitrag von maggyver »

Hallo,

ich habe jetzt gerade mal im Node-Red geschaut.

Meine bessere Hälfte hatte glaub die gleiche Problematik in Bezug mit SHELLY und hat das dann so gelöst.

Die KNX Schaltfunktion, Dimmfunktion und der Statusfunktion wurden an an die benötigten Funktion des Gerätes angepasst.

Bild

Bild

Bild

Anbei die Skizzen bei der Entwicklung ...

Bild

... das passiert wenn die Freundin gefallen an "Ihrem" Hauswolf hat ... :-D :-o :shock: :-?

Danke, liebes ElabNET-Team für den extrem ansteckenden Virus. :dance:



Nachtrag: Eine Umsetzung im TWS direkt möchte Sie auf jeden Fall haben ... :!:
Zuletzt geändert von maggyver am So Feb 19, 2023 6:44 pm, insgesamt 2-mal geändert.
Grüße
René
_______________________________________________________________________________

TWS 2600LW ID:504 + PBM ID:892 + PBM ID:910 , VPN offen , Reboot erlaubt, Offline, Insider
TWS 950QL ID:379 , VPN offen, Reboot erlaubt, Offline, Insider

Robosoc
Reactions:
Beiträge: 1876
Registriert: Di Okt 09, 2018 9:26 am
Hat sich bedankt: 635 Mal
Danksagung erhalten: 775 Mal

#7

Beitrag von Robosoc »

StefanW hat geschrieben: So Feb 19, 2023 6:03 pm Hi,
tomknocke hat geschrieben: So Feb 19, 2023 5:57 pmEine Dimm Logik mit Verzögerung wäre natürlich trotzdem nochmal eine tolle Bereicherung für den TW.
Bitte genauer erklären.
Genau das trifft auch meinen Gedanken.
Der Betreff fragt nach der Funktion eines Bestandbausteins des Logikeditors, aber im Text scheint mir das garnicht wirklich noch die Frage zu sein und ggf. auch nie gewesen zu sein.

Ich habe eine Interpretation von dem im Kopf, was hier gewünscht ist, aber da ich die Herausforderung nicht habe, interpretiere ich hier wahrscheinlich eher falsch.

Habe ich Folgendes richtig verstanden:

Wollt ihr einen Logikbaugstein, der in Bruchteilen einer Sekunde nacheinander neue Dimm-Ziel Befehle auf den KNX Bus sendet, damit "einfache " Dimmaktoren, die leider von Haus aus nur das sofortige Schalten auf einen neuen Dimmwert zwischen 0 und 100% kennen, quasi sanft über einen längeren Zeitraum (auch länger als eine Sekunde) auf den neuen Wert fahren?

Das wäre keine gute Funktion für ein KNX System und sollte auf keinen Fall durch die Entwicklung von Elabnet realisiert werden. Wir könnten sowas als Customlogik schreiben, aber bitte erklärt einmal genau, was das Ziel ist.
Zuletzt geändert von Robosoc am Mo Feb 20, 2023 8:37 pm, insgesamt 1-mal geändert.
VG, Sven - TWS 950Q ID:335 & 291, VPN offen, Reboot OK

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#8

Beitrag von gbglace »

Da muss man schon ganz alte KNX-Aktoren haben die nur neue Absolutwerte anfahren können. Ich kann mir aber vorstellen das es eine Menge non-KNX IoT Dimmer gibt, die nur AN/AUS oder absoluten Dimmwert als Eingang haben, ob die den absoluten Dimmwert dann faden oder direkt anspringen wäre zu prüfen. Wobei wenn da wer nur anspringen kann, ergibt das gewaltig Augenkrebs wenn man da an einem KNX-Taster oder einer Visu mit relativen Dimmbefehlen zyklisch +x% sendet.

Zumindest in der IoT-üblichen Befehlsweitergabe gibt es solche Kandidaten. Eine Alexa kann nur absolute Dimmwerte, da kommt nichts anderes durch die API. Spricht man hingegen mach heller, dann erinnert Alexa sich an den zuletzt bekannten Status und addiert da einfach x% drauf und sendet das Ergebnis ans Device. Fading haben dann hoffentlich die Leuchtmittel implementiert. Bei HUE muss man damit leben was Phillips als gute fade Zeit versteht.

Wie der Shelly hier reagiert kann ich nicht beurteilen und was man da einstellen kann. Da man den aber nicht per KNX bedient und eine Visu dann besser auch nicht auf dem Medium KNX-läuft könnte man aber schon einen Logikbaustein designen der eben so lange der Finger auf einer Taste ist in einer einstellbaren Taktung Telegramme generiert. Aber ja auf den KNX oder DALI Bus sollte man damit nicht zielen. So ein Baustein sollte aber auch den Status kennen, weil Werte in % größer 100 zu senden ergibt eben auch keinen Sinn.
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#9

Beitrag von StefanW »

Hi Sven und Göran,
gbglace hat geschrieben: Mo Feb 20, 2023 8:56 pmAber ja auf den KNX oder DALI Bus sollte man damit nicht zielen.
So schlimm wäre das auch nicht. Ich denke mal, öfters als ein bis zweimal pro Sekunde müsste ein Logikbaustein keinen neuen Dimmwert senden, schließlich muss dazwischen auch erstmal der zuvor gesendete Dimmwert vom Aktor angefahren werden. Da reden wir dann also von 2 bis 4 Prozent der Buskapazität und das für einen übersichtlichen Zeitraum von ein paar Sekunden. Das schafft der KNX schon.

Bei DALI ist ein wenig anders, weil der hat nur 15% der Kapazität des KNX, wobei der (von den sechs möglichen Befehlen pro Sekunde) durchaus auch nicht untergeht, wenn da mal ein oder zwei Telegramme pro Sekunde für eine Dimmsequenz drüber gehen.

KNX schafft unter guten Bedingungen bis 3.888.000 Telegramme in 24 Stunden, da muss man sich jetzt wegen ein paar Dimmbefehlen keine Sorgen machen.

Die Timberwolf Visu wird direkt mit dem Verteiler kommunizieren, da gehen keine Telegramme mehr über den KNX. Spart auch was ein.

lg

Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

maggyver
Reactions:
Beiträge: 364
Registriert: So Okt 14, 2018 1:48 pm
Hat sich bedankt: 228 Mal
Danksagung erhalten: 274 Mal

#10

Beitrag von maggyver »

Hallo,

ich denke eher das es einer Logik bedarf der das "KNX relatives Dimmen mit Stopptelegramm" versteht und sich wie ein Dimmaktor selbst verhält.

Durch den Startbefehl (Dimmrichtung und 100%) wird in der Logik selbst dann über eine einstellbare Zeitbereich, der einstellbare relative Dimmwert je Dimmrichtung zum Startwert addiert oder subtrahiert. Das Stopptelegramm bricht den internen Zyklus ab, wobei der Ausgang den letzten Wert beibehält. Der Ausgang bringt immer den absoluten Dimmwert heraus.

Der bestehende Logikbaustein brauch diesbezüglich nur einer Erweiterung am Eingangsbereich, am besten einen zusätzlichen Eingang der dann auf den den internen Zeit/Wertgeber führt.
Man könnte diesem Logikbaustein gleich noch einen weiteren Eingang spendieren, der Ein/Aus auch in einen absoluten Dimmwert umsetzt.

Eventuell noch einen Statusausgang des Logikbausteines der größer 0% des absoluten Dimmwertes am Ausgang dann ein Ein/Aus ausgibt.


Bei den meisten Dimmeraktoren, die mit absoluten Dimmwerten angesprochen werden, ist die Zeitkennlinie im Dimmaktor selbst hinterlegt. Bringt aber nichts für die Verarbeitung im Logikbaustein, da der Dimmaktor ja erstmal einen absoluten Dimmwert erhalten muss um seine Arbeit beginnen zu können.

Der Knackpunkt ist eben die Umsetzung bzw. Anpassung des vorhandenen Logikbaustein über zusätzlich Eingänge und Ausgänge um eine Art "Universellen Dimmaktorlogikanpassung" zu erschaffen.


Zu den Shellys im allgemeinen:

In der API der ersten Generation gibt es die Moglichkeit eben auch relative Dimmwerte und die Dimmrichtung zu übergeben. Das ist etwas versteckt und wie ihr in den vorherigen Post sehen könnt bedarf dies einiger Anpassungen über "Logikbausteine" und im Shelly selbst. Dank der Tasmota-Firmeware, die eine brauchbare Dokumentation beinhaltet, geht das dann auch recht gut. Jedoch ist das eher dann etwas für den Nerd unter den Smarthomenutzern.

Fazit:

Absolute Dimmwerte unterstützen, mit der Option das es möglich sein sollte einen weiteren Ausgang zu erzeugen, der Ein/Aus auch ohne absoluten Dimmwert direkt umsetzt, anhand des oder der Eingänge (Bemerke : Kurzer bzw. Langer Tastendruck beim KNX löst ja andere DPT bzw. Gruppenadresse mit anderem Inhalt aus).


Nachtrag: Shelly
Zuletzt geändert von maggyver am Di Feb 21, 2023 6:24 am, insgesamt 3-mal geändert.
Grüße
René
_______________________________________________________________________________

TWS 2600LW ID:504 + PBM ID:892 + PBM ID:910 , VPN offen , Reboot erlaubt, Offline, Insider
TWS 950QL ID:379 , VPN offen, Reboot erlaubt, Offline, Insider
Antworten

Zurück zu „Logikengine & Logik-Editor“