Tuya steuerung per Arduino + Taster

[Eiskuh]

Hallo,

bin neu hier und ziemlich unerfahren mit OH. Ich benoetige hilfe mit der Steuerung von meinen Tuya RGBW Lichtern per Arduino mit Taster per MqTT.

Ich habe OH3 (OpenHabian) mit Mqtt Binding + Tuya Binding und experimentell einen Arduino der MqTT befehle zum Ein und Ausschalten der Lichtergruppe hinbekommen, soweit funktioniert es schonmal. Ziel ist jedoch komplexer und da benoetige ich eure hilfe

Folgende Situation:
- Beispielraum Treppenhaus mit Lichttaster + Arduino auf jeder Etage, d.h. min. 2 Arduino welche befehle weiterleiten an OH3
- Die einzelnen Arduinos kommunizieren direkt mit OH3 aber nicht miteinander, d.h. Arduino 1 weiss nicht das Arduino 2 Taste gedrueckt wurde. (Minimieren von Kommunikationsaussetzern)

Befehle von Arduino an OH3
1) 1 x Taste kurz druecken sendet den Befehl "AnAus", OH3 soll dann Licht an bzw. ausschalten je nachdem of das Licht an/aus ist
2) 1 x Taste lang druecken sendet den Befehl "Dimmen" alle x millisekunden, OH3 soll das Licht dann dimmen bzw heller machen. Bei jedem empfangenen Beffehl wird runter gedimmt bis minimum wert erreicht, anschliessen heller machen bis maximum erreicht....
3) 1 x Taste kurz + Taste lang druecken sendet den Beffehl "Farbwert" alle x millisekunden und soll Farbwert aendern, also von Weiss nach Gelbton und dann zurueck.
4) 2 x Taste kurz sendet den Befehl "Farbmodus" aendern, also weisses Licht, farbiges Licht etc...


Zur Fragen
a) Situation 1, wie bekomme ich es hin, dass OH3 das Licht Ein- bzw. Ausschaltet mit dem selben Befehl "AnAus". Meine Testarduino senden "An" und "Aus", aber ich habe es noch nicht mit "AnAus" hinbekommen
b) Situation 2, wie kann ich die Lichter dimmen mit dem Befehl "Dimmen", und zwar so das es beim minwert umkehrt und heller wird bis zum Max wert usw. OH3 muss sich merken koennen ob der Dimmbefehl heller oder dunkler einstellen soll und dann umkehren wenn min/max Wert erreicht wurde

Ich glaub alles weitere wird sich von alleine klaeren wenn ich Frage a &b verstanden habe. Ich vermute ich werde mit Rules und Scripts arbeiten muessen. Vom Programmieren her fehlen mir irgendwie selbst definierte variablen zum Zwischenspeichern von information, aber bin halt sehr neu mit OH

Danke schonmal

Michael

[udo1toni]

Herzlich willkommen im openHAB Forum!

Zunächst mal zu den Tastern (mehrere Taster -> ein Ziel): Es gibt dafür letztlich zwei Möglichkeiten, entweder Du sammelst alle Tastendrücke in einem Topic ein, oder Du verwendest für jeden Taster ein eigenes Topic. Mit separaten Topics pro Taster kannst Du in openHAB immer noch entscheiden, ob Du ein gemeinsames Item für alle zu einer Leuchte gehörenden Taster nutzt oder einzelne Items pro Topic/Taster.

So oder so sollte klar sein, dass Probleme vorprogrammiert sind, sollten an beiden Tastern gleichzeitig unterschiedliche Befehle gesendet werden Das ist allerdings auch bei konventionellen Schaltungen so, also kein openHAB-exklusives Problem.

Befehl AnAus: Ich hoffe mal, Du meinst einen einzelnen Befehl, der auf neudeutsch toggle heißt, also Umschalten.
openHAB kennt selbst kein toggle, weil das Ergebnis eines solchen Befehls nicht eindeutig ist. die Philosophie eines Smarthomes sollte nicht darauf basieren, bei dem selben Steuerbefehl unterschiedliche Ergebnisse zu bekommen.
Allerdings ist es selbstverständlich kein Problem, openHAB anzuweisen, den Schaltzustand zu ändern. Innerhalb einer Rule geht das so:

Code: Alles auswählen

rule "taster Treppenlicht"
when
    Item Taster1 received update or
    Item Taster2 received update
then
    if(newState.toString == "TOGGLE") {
        Leuchte.sendCommand(if(Leuchte.getStateAs(OnOffType) != OFF) OFF else ON)
    }
end

Einer der beiden Taster wird kurz gedrückt, woraufhin das verlinkte Item ein Status Update erhält.
Ist der neue Status als String "TOGGLE", so sendet die Rule einen Befehl an das Item Leuchte.
Dabei prüft die Rule zunächst, welchen Schaltzustand das Item Leuchte hat. Da es sich bei Leuchte um ein Color Item handelt, wird explizit der Status als OnOffType abgerufen (ansonsten bekäme man HSBType zurück und müsste erst mal analysiseren, ob der Helligkeitswert ungleich 0 ist...)
der ternäre Operator (if(Bedingung) OFF else ON) ist die elegante Art man könnte auch so verfahren:

Code: Alles auswählen

...
if(Leuchte.getStateAs(OnOffType) != OFF) {
    Leuchte.sendCommand(OFF)
} else {
    Leuchte.sendCommand(ON)
}

aber man ist ja faul...

Die Rule lässt sich relativ leicht um das Dimmen erweitern:

Code: Alles auswählen

// globale Variablen müssen vor der ersten Rule definiert werden!
var Boolean bLeuchteDir = false // Merker für Dimmrichtung

rule "Taster Treppenlicht"
when
    Item Taster1 received update or
    Item Taster2 received update
then
    if(newState.toString == "TOGGLE") {
        Leuchte.sendCommand(if(Leuchte.getStateAs(OnOffType) != OFF) OFF else ON)
    }
    if(newState.toString == "DIMMEN") {
        var nBright = Leuchte.getStateAs(PercentType) as Number
        if(bLeuchteDir) {            // true
            nBright += 5             // Helligkeit erhöhen
            if(nBright > 100) {      // Falls Obergrenze überschritten
               nBright = 100         // Obergrenze als Wert setzen
                bLeuchteDir = false  // und Dimmrichtung umkehren
            }
        } else {                     // false
            nBright -= 5             // Helligkeit verringern
            if(nBright < 1) {        // Falls Untergrenze unterschritten
               nBright = 1           // Untergrenze als Wert setzen
                bLeuchteDir = true   // und Dimmrichtung umkehren
            }
        }
        Leuchte.sendCommand(nBright)
    }
end

Die gewählte Notation ist die der DSL (DomainSpecificLanguage) von openHAB, und zwar so, wie man sie in eine Textdatei schreibt.
Grundsätzlich kann diese Rule auch über die UI erstellt werden, dort kann man frei wählen, welche der installierten Scripting Engines man dafür nutzen möchte. Die Rules DSL ist aber auf jeden Fall eingerichtet, da sie als einzige (noch) Bestandteil des openHAB Core ist, alles andere muss nachinstalliert werden. Wenn man die Rule über die UI als DSL Rule anlegt, gibt es keine globalen Variablen, stattdessen muss man dann auf den PrivateCache zurückgreifen, so wie in den anderen Scriptsprachen auch.

Es ist möglich, dass der Befehl mit dem Helligkeitswert nicht korrekt ausgeführt wird, dann müsste man sich über den Status des Items die aktuelle Farbe holen, dort die Helligkeit anpassen und die komplette Farbe senden.
Eine ähnliche Erweiterung ist auch für die Erweiterung um die Farbsteuerung möglich, wobei es jetzt etwas heikel wird:
Wie verhält sich die Taste genau? Wird beim kurzen Drücken zunächst gewartet, ob ein weiterer Tastendruck folgt und die Taste entscheidet dann darüber, was sie sendet, kann die Rule relativ stumpf genauso arbeiten wie für den Dimmvorgang, nur dass hier halt die Farbtemperatur angepasst würde, welche mutmaßlich über ein separates Item zu steuern ist (openHAB kann nicht beide Funktionen Farbe und Farbtemperatur über das selbe Item abbilden).
Und für den "Doppelklick" (also Fall 4) läuft es wieder genauso, nur dass hier mutmaßlich eine Liste mit zuvor festgelegten Farbwerten zum Einsatz kommen wird. Es böte sich an, dafür eine HashMap zu verwenden, um jeweils vollständige HSB-Werte "durchzublättern".

Gewöhnlich wird man übrigens gar kein Item für die Taster verwenden, sondern stattdessen einen Trigger Channel definieren. Die Rule selbst unterscheidet sich nicht großartig von der Variante oben, nur die impliziten Variablen sind andere (Channel 'channel:uid:des:Tasters' triggered als Event und receivedEvent statt newState.toString)

[Eiskuh]

Danke fuer die umfangreiche Info.

Es sind immer 1 Taster fuer mehrere funktionen, dafuer habe ich bereits ein passendes Arduino programm. Der Arduino wertet die Tasterdruecker aus und sendet dann den entsprechenden Topic an OH3, somit ist die Arbeit verteilt und ueberlastet nicht den OH3 Rasperry Pi. Am ende werden es ca. 15 Arduinos im Haus verteilt sein mit je bis zu 6 Taster, aber da muss ich auch erst mal testen ab wann es zuviel wird, evtl sind es dann halt mehr Arduinos, eigentlich Esp32.

Die Problematik mit 2 Taster die gleichzeitig gedrueckt werden ist mir bewusst, kommt sicherlich selten vor, aber dennoch. Das werde ich ausprobieren und dann entscheiden wie damit umgegangen wird.

Eine Ueberlegung die ich heute auch hatte ist, eigene Bindings zu erstellen, aber das ist dann die naechste Ausbaustufe im Lernprozess.

Dank erstmal

[udo1toni]

Der Arduino wertet die Tasterdruecker aus und sendet dann den entsprechenden Topic an OH3, somit ist die Arbeit verteilt und ueberlastet nicht den OH3 Rasperry Pi.

Ich nehme mal an, Du meinst eher, dass der Arduino je Taster ein Topic sendet, und je erkanntem Befehl eine bestimmte Payload (alles andere wäre auf openHAB-Seite mit zusätzlichem Aufwand verbunden).

Bezüglich der Überlastung: Natürlich kannst Du einen Pi überlasten, aber das wird nicht so einfach, wie Du befürchtest... Typisch 30 bis 50 Befehle pro Sekunde sollten schon verarbeitet werden können, solange also nur ein einzelner Taster verwendet wird, sollte selbst die Erkennung eines gedrückt gehaltenen Tasters mitsamt interner (oder auch externer) Befehlswiederholung den Pi nicht annähernd auslasten - anders sieht es natürlich aus, wenn Du dutzende solche Taster zeitgleich drückst, dann kommst du schnell an die Grenzen heran, aber Hand aufs Herz: außer zum Probieren kommt so etwas im realen Leben nicht vor.

Auch die Sache mit mehreren Steuerstellen für ein Licht ist ja nicht gleichbedeutend mit einer quasi unvermeidbaren Kollision von Steuerbefehlen, man sollte es lediglich im Hinterkopf behalten, falls man mal durch einen blöden Zufall in die Situation kommt und sich dann wundert, warum der Tastendruck nicht so ausgeführt wurde, wie programmiert.
Da viel Arbeit reinzustecken, ist in meinen Augen eher eine Fehlinvestition von Lebenszeit.

Eine Ueberlegung die ich heute auch hatte ist, eigene Bindings zu erstellen, aber das ist dann die naechste Ausbaustufe im Lernprozess.

Wenn Du Spaß am Programmieren hast und Dich gut mit Java auskennst, kannst Du das natürlich machen, sinnvoller wäre aber vermutlich, die Arduino-Seite so zu gestalten, dass sie sich an etablierten Datenmodellen orientiert (z.B. Tasmota). Warum etwas neu erfinden, was es schon gibt? MQTT als Protokoll ist universell - so sehr, dass Du nicht mal an openHAB gebunden bist, sondern jederzeit auch zu einem der Konkurrenzprodukte wechseln kannst - nicht, dass das sinnvoll wäre, aber es ist ja nett die Option zu haben - solange dieses Produkt MQTT unterstützt (und ich kenne kein Universalsystem, welches das nicht tut).