Ankündigung

Einklappen

Hinweis

Die Forenregeln wurden überarbeitet (Stand 7.11.22). Sie sind ab sofort verbindlich. Wir bitten um Beachtung.
Mehr anzeigen
Weniger anzeigen

Brainstorming Anforderungen generischer OpenKNX Taster / Tasterkanal

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    #16
    Zitat von philipp900 Beitrag anzeigen

    Ich habe mir jetzt eine eigene UI für das Sonoff NSPanel gebaut und dazu eine eigene Firmware mit der KNX-IP library für den ESP32 programmiert.​
    Hi,
    Das klingt sehr interessant, zumindest für mich. Kannst du das (ggf in einen eigenen Thread) mal genauer vorstellen?
    Vielen Dank dafür

    Kommentar


      #17
      Zitat von SirSydom Beitrag anzeigen
      Ich fang mal an was mir wichig wäre was so eine Taste können sollte:

      - Schalten (Ein, Aus, Um)
      - Kurzer, Langer, Ganz Langer Tastendruck ggf. Doppelklick
      - Dimmen (mit 1 und 2 Tasten)
      - Jalousie (mit 1 und 2 Tasten)
      - Wert senden (div. DPT)
      - Szenensteuerung (abrufen/speichern)
      • Wert ändern fände ich noch interessant: Also Schrittweise erhöhen ("+")/reduzieren("-"). Relativ einfach für Ganzzahl-DPTs. Hatte ich auch schon mal irgendwo gesehen. Ggf. auch in Kombination mit Wert-Senden z.B. bei langem Druck.
      • Taster: Senden von Wert beim Drücken und Loslassen
      Da Du bereits eine Abstraktion vorgeschlagen hast: Könnte das evtl. auch interessant sein Taster-Ereignisse und Funktion unabhängig von einander zu betrachten?
      Also z.B. folgende Events:
      • DOWN: Taste runter gedrückt
      • CLICK: Taste einmal kurz betätigt (gedrückt/losgelassen)
      • CLICK_LONG: Taste einmal lang betätigt (gedrückt/losgelassen)
      • CLICK_EXTRA_LONG: Taste einmal ganz lang betätigt (gedrückt/losgelassen)
      • DOUBLE_CLICK: Taste doppelt betätigt, klare Unterscheidung von CLICK erforderlich
      • TRIPPLE_CLICK: Taste dreifach betätigt
      • N_TIMES_CLICK: Taste n-fach betätigt (sicher nur begrenzt sinnvoll)
      • REPEATED: Wiederholtes Ereignis, bei längerem Tastendruck (analog zu Tastatureingaben und so läuft das doch auch teilweise beim Dimmen?)
      • UP: Taste losgelassen, ggf. in Kombination mit der Halte-Dauer
      Wobei sicher nicht alle Kombinationen von Ereignissen sinnvoll kombiniert werden können.


      Zitat von willisurf Beitrag anzeigen
      Reihum, ist ganz nett um Szenen oder Playlist durchzuschalten. Bei max. 4 Möglichkeiten geht das auch ohne Feedback noch mit dem Überblick, zumal man einen Defaulteintrag bei langem Tastendruck einstellbar machen kann. Auch ob es am Ende einen Überlauf (rundum) oder Anschlag gibt, ist einstellbar sinnvoll.
      Erinnert mich an die Funktionalität von MDT. Die sieht AFAIR auch noch vor, dass bei geordneter Angabe der Werte auch zum jeweils nächsten in eine Richtung gesprungen wird..

      Kommentar


        #18
        Was mir an den ganzen zu kaufenden Tasterinterfaces fehlt ist eine bessere Output Nutzbarkeit.
        Einige (wie MDT) bieten ja schon mal an, daß man pro I/O wählen kann ob Eingang oder Ausgang , bei Eingang hat man dann auch vielfältigste Möglichkeiten der Konfiguration. Bei Ausgang sieht es jedoch nicht so Toll aus.

        Ich bräuchte da dann z.B. wenigstens eine PWM Möglichkeit pro I/O und nicht nur Ein/Aus.

        Bei den Eingängen würde ich mir z.B. noch Analog Input wünschen, und wenn es nur ein simple ADC Inputkanal ist.
        Auch wäre eine Inc/Dec Phaseneingang super, also zweier Eingangsgruppen an welche man Drehencoder mit Phasenversetzen Impulsen anschließen kann.

        -also I/Os als Ausgang konfigurbar mit PWM Funktion
        -bei Eingängen optional Analog wählbar (z.B. 0V - 3.3V)
        -bei Eingängen Inc/Dec Phaseneingang welcher z.B. eine Gruppenadresse hoch und runter zählen lasen kann mit Verknüpfungen für Reset (Externe GA oder über Logik Modul ...)

        Alles andere gibt es doch schon.




        Kommentar


          #19
          Zitat von wknx Beitrag anzeigen
          Die sieht AFAIR auch noch vor, dass bei geordneter Angabe der Werte auch zum jeweils nächsten in eine Richtung gesprungen wird.
          Ja genau, ein Statuseingang sollte dabei auch noch berücksichtigt werden.
          Gruß Bernhard

          Kommentar


            #20
            Zitat von Techi Beitrag anzeigen
            Was mir an den ganzen zu kaufenden Tasterinterfaces fehlt ist eine bessere Output Nutzbarkeit.
            Einige (wie MDT) bieten ja schon mal an, daß man pro I/O wählen kann ob Eingang oder Ausgang , bei Eingang hat man dann auch vielfältigste Möglichkeiten der Konfiguration. Bei Ausgang sieht es jedoch nicht so Toll aus.

            Ich bräuchte da dann z.B. wenigstens eine PWM Möglichkeit pro I/O und nicht nur Ein/Aus.

            Bei den Eingängen würde ich mir z.B. noch Analog Input wünschen, und wenn es nur ein simple ADC Inputkanal ist.
            Auch wäre eine Inc/Dec Phaseneingang super, also zweier Eingangsgruppen an welche man Drehencoder mit Phasenversetzen Impulsen anschließen kann.

            -also I/Os als Ausgang konfigurbar mit PWM Funktion
            -bei Eingängen optional Analog wählbar (z.B. 0V - 3.3V)
            -bei Eingängen Inc/Dec Phaseneingang welcher z.B. eine Gruppenadresse hoch und runter zählen lasen kann mit Verknüpfungen für Reset (Externe GA oder über Logik Modul ...)

            Alles andere gibt es doch schon.
            stop langsam. Hier gehts um Tasterkanäle, nicht um Binäreingänge. Ein Binäreingang kann zwar ein Taster sein, insofern wäre das hier genannte eine Untermenge bei einem Binäreingang.

            Evtl. muss man das bei der SW / KNXPROD Struktur schon mit vordenken ? mumpf
            so dass man, wenn man später mal einen Binäreingangskanal realisiert ohne großen Aufwand die bereits realisierte Tasterfunktionalität mit dazubringt.
            Ob das praktikabel ist weiß ich nicht..
            Formerly known as SirSydom
            KNX Transceiver für Arduino&Co und OpenKNX Module: NanoBCU

            Kommentar


              #21
              Warnung, der Beitrag hat auch nichts mit dem Tasterkanal zu tun. Greift aber die Idee von diesem Beitrag auf sich Gedanken über einen LED Kanal zu machen:

              Zitat von mumpf Beitrag anzeigen
              Von der Idee her eher eine Art LED-Tableau, dass über Farben bestimmte Zustände realisieren kann. Hier würde man LED-Funktionen (ähnlich den Tastenfunktionen) definieren (Farbe, Leuchten/Blinken/Pulsieren, was uns auch immer da noch einfällt). Und natürlich auch KO, die das Eingangssignal für die LED bieten, sinnvollerweise DPT1 (Schalten), DPT17 (Szene), DPT232 (RGB), vielleicht auch noch andere.
              Ich verwende BUSCH-JAEGER 6108/07 Taster. Diese haben eine entkoppelte LED die aber extrem dämlich ist. Sie kennt nur Ein/Aus, Alarm (blinken), Tag/Nacht (hell/dunkel). Für Ein/Aus kann man dann fix eine Farbe definieren.
              Alternativ kann die LED über einen byte Wert angesteuert werden und kennt dann Schwellen, damit hat man die Möglichkeit 5 Farben über den Byte Wert vorzugeben.

              Ich habe mir eine PrioritySwitch Logik gebaut. Diese hat eine ganze Menge Bit-Eingänge. Der Eingang mit der höchsten Prio gibt die Ausgängswerte über die Konfiguration vor. In diesem Fall einen für Blinken, einen für Tag/Nacht und einen für Farbe über das Byte.

              Verwenden wird dass, um eine Reihe an Zuständen mit der LED anzuzeigen. Z.b. für die Jalousie: Automatische Beschattung Eingeschalten, Automatische Beschattung Aktiv, Windsperre, Manuell geschlossen.

              Wozu schreibe ich das ganze hier? Weil eventuell das Konzept mehrere Bit-Eingänge für die Steuerung der LED interessant sein könnte. Ich würde dann allerdings jeden Bit-Eingang direkt den RGB Wert und zusätzlich Blinken vorgeben lassen.

              Alternativ wäre allerdings auch gut im LogikModul aufgehoben. Was ist eure Meinung?

              Kommentar


                #22
                Zitat von mumpf Beitrag anzeigen
                Freie Tastenzuordnung
                Virtueller Taster
                Tasten und LED trennen
                Freie LED-Zuordnung
                Ich glaub MDT ist da mit Ihrer neuen Smart 86 Revision auf diesem Weg.
                wenn ich da so nachdenke, dann wäre es aber auch schön wenn man bei all der referenziererei nichts an der GA-Verdrahtung ändern müsste. Wenn also die Funktionen der HW-Taste#1 mit der von HW-Taste#7 getauscht wird sollte man die Option haben die KO beizubehalten damit alles weiter funktioniert wie bisher, nur eben bei ner anderen Taste…

                falls dann auch eine Visualisierung der Tasterkanäle ermöglicht werden sollte würde ich mir neben einem solchen Tasten- und LED-Kanal Icon-Kanäle wünschen, mit denen dann Stati angezeigt werden könnten und angezeigt werden könnte was beim nächsten kurzen, langen, Doppel-Tasten etc. passieren wird.

                was mir noch gefiele wäre ein „Funktionstaster“, der einen eingang und mehrere Ausgänge hat, mit einer Tabelle, was nach Empfang des Eingangs durch Tastenbetätigung (lang, kurz, doppelt etc.) am welchen Ausgängen was gesendet werden soll.

                Kommentar


                  #23
                  Zitat von TabSel Beitrag anzeigen
                  Wenn also die Funktionen der HW-Taste#1 mit der von HW-Taste#7 getauscht wird sollte man die Option haben die KO beizubehalten damit alles weiter funktioniert wie bisher, nur eben bei ner anderen Taste…
                  Ja klar, das ist der Gedanke. Das KO hängt an der Tastenfunktion, nicht an der Taste. Die Taste (oder Tasten) werden einer Tastenfunktion zugewiesen. Wenn also erst HW-Taste#1 an der Tastenfunktion "Wohnzimmer Deckenlicht dimmen" war und später HW-Taste#7, dann ändert sich an den KO oder den GA gar nichts.

                  Zitat von TabSel Beitrag anzeigen
                  falls dann auch eine Visualisierung der Tasterkanäle ermöglicht werden sollte
                  Abstraktion ist schön und gut, aber ich werde erstmal einen Taster mit LEDs, nicht mit Display vorsehen. Wenn die Schlauen Hardware-Kollegen einen Display-Taster machen wollen, dann kann man über weitere Anzeigemöglichkeiten nachdenken.

                  Zitat von TabSel Beitrag anzeigen
                  was mir noch gefiele wäre ein „Funktionstaster“, der einen eingang und mehrere Ausgänge hat, mit einer Tabelle, was nach Empfang des Eingangs durch Tastenbetätigung (lang, kurz, doppelt etc.) am welchen Ausgängen was gesendet werden soll.
                  Das sehe ich eher in der Logik (die der Taster ganz sicher haben wird, wahrscheinlich sind sogar 99 Kanäle möglich): Taster schaltet Werte 1-4 durch, einzelne Logikkanäle reagieren auf die Werte und senden was anderes weiter.

                  Gruß, Waldemar

                  Kommentar


                    #24
                    Zitat von mgeramb Beitrag anzeigen
                    Wozu schreibe ich das ganze hier? Weil eventuell das Konzept mehrere Bit-Eingänge für die Steuerung der LED interessant sein könnte. Ich würde dann allerdings jeden Bit-Eingang direkt den RGB Wert und zusätzlich Blinken vorgeben lassen.

                    Alternativ wäre allerdings auch gut im LogikModul aufgehoben. Was ist eure Meinung?
                    So wie ich das verstehe, willst Du n Eingänge für einen Kanal haben. Das bläht die Anzahl der benutzten KO mächtig auf, was wiederum richtig viel Speicher kostet. Insofern bin ich immer vorsichtig mit solchen n:1 Ansätzen.
                    Was ich mir aber gut vorstellen könnte, wäre eine Szenensteuerung der LEDs, wobei man pro Szene das Verhalten der LED in paar aspekten definieren kann (Blinken/Pulsieren, Farbe). An bzw. Aus könnten genau so definiert werden, wie Szenen.

                    Will man wirklich DPT1 zur Ansteuerung, nutzt man Logikkanäle, die Bit->Szene umsetzen.

                    Tag-Nacht ist noch eine interessante Frage: nut globaler Einfluss (Helligkeitsreduktion für alle LEDs bis hin zur Helligkeit 0) oder pro LED (also pro Szene 2 Definitionen für Tag/Nacht). Schließlich muss da ja auch alles parametrisiert werden...

                    Gruß, Waldemar


                    Kommentar


                      #25
                      Zitat von mumpf Beitrag anzeigen
                      So wie ich das verstehe, willst Du n Eingänge für einen Kanal haben. Das bläht die Anzahl der benutzten KO mächtig auf, was wiederum richtig viel Speicher kostet. Insofern bin ich immer vorsichtig mit solchen n:1 Ansätzen.
                      Was ich mir aber gut vorstellen könnte, wäre eine Szenensteuerung der LEDs, wobei man pro Szene das Verhalten der LED in paar aspekten definieren kann (Blinken/Pulsieren, Farbe). An bzw. Aus könnten genau so definiert werden, wie Szenen.
                      Je länger ich nachdenke desto mehr komme ich zum Schluss dass die Funktion in einem Logikbaustein muss. Mit Szenen ist mein Szenario nicht umsetzbar da meine Bit-Zustände Prioritäten haben müssen, Z.b. würde Manuell Geschlossen vor Windalarm kommen, in welcher Reihenfolge die Bits gesetzt werden ist aber nicht definiert.

                      Trotzdem finde ich die Szenen Idee für die LED-Ansteuerung super.

                      Liebe Grüße, Michael

                      Kommentar


                        #26
                        Hi
                        ich verwende die Logikkanäle um Szenen in Bits zu Zerlegen und auch umgekehrt um aus den Rückmelde Bits eine aktuel geschaltete Szene zurükzumelden.
                        Da die Logikkanäle ja in großer Anzahl vorhanden sind gehe ich damit großzügig um.
                        Die Priorität müsste dann die Logik abbilden.

                        Zurück zu den Grundlagen:
                        Was benötigte eine LED?
                        AN/AUS
                        ​Farbe (RGB-WW-CW)
                        Helligkeit
                        Blinkmuster

                        Was kann ein Taster signalisieren?
                        Das ist denke ich in #17 ausreichend aufgeführt

                        Sensoren liefern binäre, analoge oder digitale Informationen.
                        Im Binären Fall könnte man Sie ggf. wie Taster behandeln sie sind aber ggf nicht Potentialfrei.
                        Analog kommt es auf die auslesende/wandelnde Hardware an und wie diese Angebunden ist.
                        Digitale Sensoren sind im Prinzip gleich den Analogen nur ist die Wandlung und eventuell Logik integriert.
                        Analoge Eingagnssignale müssen immer Interpretiert werden. Sie benötigen also Gleichungen um das empfangene Signal einer Messgröße zuordnen zu können.

                        Kombinierte Eingänge:
                        SIN/COS Signal, Impulsdrehgeber

                        Welche Schnittstellen zum Anbinden gibt es?
                        CAN, Modbus, I2C, 1Wire,GPOI,USB,...

                        Ausgänge:
                        Binär (potentialfrei), Analog, PWM, RC-Servo, Modulierte Signale, Audio

                        Die Liste kann sicherlich noch ergänzt werden.

                        Gruß
                        Stefan

                        Kommentar


                          #27
                          Zitat von SirSydom Beitrag anzeigen
                          stop langsam. Hier gehts um Tasterkanäle, nicht um Binäreingänge..
                          Da ich die MDT BE .... also diese kleinen UP Gerätchen bei allen meinen Tastern im Haus verwenden um damit eben die Tasten einzulesen und um die in den Tastern verbauten LEDs anzusteuern, wäre das für mich per Definition kein Unterschied.
                          Wenn ich die Leds in den Gira Tastern (Tastwippe mit LED) dann halt auch noch Dimmen könnten, dann wäre das der Mehrwert, der einen Selbstbau für mich rechtfertigen könnten.
                          Wenn das Gerätchen dann halt auch noch einen über dem Taster angebrachten Drehencoder mit Drucktaster einlesen könnten dann wäre dass ein noch größerer Mehrwert. 😉


                          Aber ja, ich gebe dir natürlich recht, per Definition würde ich einen Taster/Tasterkanal auch nur als kleine Untergruppe der Binäreingänge sehen.

                          Zuletzt geändert von Techi; 08.10.2022, 11:45.

                          Kommentar


                            #28
                            Damit es nicht verloren geht, ein Punkt aus einer Diskussion mit Waldemar in Bezug auf die Funktionalität zum relativen Dimmen.

                            Aktuelle Taster steuern die Dimmrichtung auf Basis des Aktorstatussignales und danach alternierend.
                            Gerade wenn einige Beleuchtungen über Szenen auf sehr niedriger Dimmstufe aktiviert sind, führt dies dazu das beim ersten Betätigen zuerst abwärts gedimmt wird, obwohl dies mit großer Wahrscheinlichkeit nicht gewünscht ist.

                            Eine funktionale Verbesserung wäre eine Auswahlmöglichkeit für eine Steuerung der Dimmrichtung in Abhängigkeit vom aktuellen Dimmwert, verbunden mit der Angabe einer Helligkeitsgrenze bis zu der immer mit aufwärtsdimmen gestartet wird.
                            Gruß Bernhard

                            Kommentar

                            Lädt...
                            X