Richtige Roles und States für Relais und Taster?
-
@Jey-Cee Vielen Dank. Das war hilfreich! Habe ich das richtig verstanden, dass ich die Tasterevents alle drinlassen sollte, dann aber zur Sicherheit alle auf den gleichen Typ setzen und nicht einen Teil auf indicator und einen auf button.press und einen auf button.long. Ich dachte, dass IO Broker ggf. irgend etwas aus button.press ableitet und ich deshalb den auf jeden Fall verwenden sollte. Ich würde dann aber jetzt bei allen Tasterevents auf indicator gehen.
Und dann ists es best pratice, dass der Value solcher Events einfach immer true bleibt und sich bei jedem Tastendruck nur der Timestamp ändert, ja ?Wie setzt man Aufrufe mit Parametern am besten um. Wenns nur einer ist (z.b. on mit Dauer) könnte man anstatt boolean einfach number verwenden, wo man dann die gewünschte Schaltdauer in Sekunden angeben kann. Wie macht man es am besten, wenn es zwei Parameter gibt (z.b. Einschaltverzögerung + Dauer). Verwendet man dann einen String mit Kommaseparierung oder besser ein Array oder ein Object wo die beiden Werte drin sind ?
Danke!
Herm -
@HausBusDe sagte:
auf button.press und einen auf button.long.
Laut Doku sind button "write only" und indicator "read only".
@HausBusDe sagte in Richtige Roles und States für Relais und Taster?:
Wie macht man es am besten, wenn es zwei Parameter gibt (z.b. Einschaltverzögerung + Dauer).
Zwei Datenpunkte "number", aktiviert durch Datenpunkt state / on = true.
@HausBusDe sagte in Richtige Roles und States für Relais und Taster?:
State "covered" - Role indicator -> Taste wurde gedrückt
State "free" - Role indicator -> Taste wurde losgelassenDiese Bezeichnungen sind unüblich. Üblich:
- "pressed" -> Taste wurde gedrückt
- "released" -> Taste wurde losgelassen
@HausBusDe sagte in Richtige Roles und States für Relais und Taster?:
State "hold_end" - Role indicator -> Gehaltene Taste wurde losgelassen
Das beinhaltet gegenüber "Taste wurde losgelassen" keine zusätzliche Information.
-
@paul53
Laut Doku sind button "write only" und indicator "read only".- Ok, dann verwende ich tatsächlich besser indicator
Zwei Datenpunkte "number", aktiviert durch Datenpunkt state / on = true.
- Da müsste dann bei jedem Schalten quasi 3 Datenpunkte ändern?
Diese Bezeichnungen sind unüblich. Üblich:
"pressed" -> Taste wurde gedrückt
"released" -> Taste wurde losgelassen- Das kommt ein bishen daher, dass an einem Eingang Taster aber auch einfach ein Schalter angeschlossen sein kann. Wenn der geschlossen ist, wäre pressed auch etwas unpassend. Aber vielleicht ist es dann doch gefälliger, wenn ich auf pressed und released gehe und damit beim Schalterszenario lebe
State "hold_end" - Role indicator -> Gehaltene Taste wurde losgelassen
Das beinhaltet gegenüber "Taste wurde losgelassen" keine zusätzliche Information.- Das hat schon eine Zusatzinfo in dem Fall, wo man mit einer Taste eine Lampe schaltet und dimmed. Dann würde man bei Event clicked nur an und ausschalten und bei hold_start würde man das Dimmen starten und bei hold_end das Dimmen stoppen. Wenn man hold_end nicht hätte, müsste man über released beide Sacheverhalte abbilden und müsste sich künstlich merken, was man gerade bei der Lampe gestartet hat.
-
@HausBusDe sagte:
Da müsste dann bei jedem Schalten quasi 3 Datenpunkte ändern?
Nur, wenn auch Einschalt-Verzögerung und -Dauer benötigt werden. Standard sollte unverzögert ohne Einschaltdauer-Begrenzung sein.
-
@paul53 Das stimmt. Wie ist das im IO Broker eigentlich mit der Parallelität? Kann es sein, dass zwei Regeln beide ein Relais kurz nacheinander schalten wollen und der erste das eine Property schon wieder verstellt, wo der vorherige gerade den State auf on schalten will ?
-
@HausBusDe sagte:
Kann es sein, dass zwei Regeln beide ein Relais kurz nacheinander schalten wollen
Welche zwei Regeln ?
-
@paul53 Ich meinte, wenn man später Regeln programmiert die das Licht schalten. (Weiß nicht, wie man das in IO Brokersprache nennt). Also sowas wie "Um 18 Uhr Licht anschalten mit Helligkeit 50%" und "Wenn jemand diese Taste drückt, dann Helligkeit 100%". Wenn beides gleichzeitig passiert könnte ich mir schon vorstellen, dass der Zugriff auf einen Datenpunkt synchronisiert ist, aber nicht über mehrere oder? Dann könnten die sich da schon gegenseitig überschreiben ?
-
@HausBusDe sagte:
Wenn beides gleichzeitig passiert
Gleichzeitig gibt es nicht. Der letzte gewinnt - auch wenn er nur wenige ms später ist.
-
@paul53 Ist das auch sichergestellt, wenn 3 Datenpunkte geändert werden müssen? Oder kann halt folgendes passieren:
Erster will Relais mit Dauer schalten und zweiter will Relais ohne Dauer schalten. Da es nun getrennte Datenpunkte sind, passiert folgendes:Erster setzt den Datenpunkt für die Dauer auf 10 Sekunden
Zweiter setzt den Datenpunkt für die Dauer auf 0
Erster setzt den State auf ON
Zweiter setzt den State auf ON -
@HausBusDe sagte:
Erster setzt den Datenpunkt für die Dauer auf 10 Sekunden
Zweiter setzt den Datenpunkt für die Dauer auf 0Auch hier gilt: Der letzte siegt. Der zugehörige Timer wird erst mit ON gestartet.
-
@HausBusDe sagte in Richtige Roles und States für Relais und Taster?:
Ist das auch sichergestellt, wenn 3 Datenpunkte geändert werden müssen?
Also sollte es passieren das es zu einer Überschneidung kommt, was wirklich unwahrscheinlich ist, dann kann das nicht sicher gestellt werden.
Am ende muss der User wissen was er will und tut. Der sollte verhindern das so etwas passiert, immerhin kann ioBroker nicht wissen was das Ziel ist.
-
@paul53 sagte in Richtige Roles und States für Relais und Taster?:
@HausBusDe sagte in Richtige Roles und States für Relais und Taster?:
Wie macht man es am besten, wenn es zwei Parameter gibt (z.b. Einschaltverzögerung + Dauer).
Zwei Datenpunkte "number", aktiviert durch Datenpunkt state / on = true.
Getrennte Datenpunkte sollten verwendet werden wenn jeder Parameter für sich stehen kann. Sollten sie nur in Kombination funktionieren kann man einen daraus machen. (Macht auch sinn um nicht unnötigen traffic zu erzeugen)
Beispiel:
On, Einschaltverzögerung und Dauer -> Datenpunkt delayed -> Parameter: 2, 10 //das on kann man sich als eigenen Parameter sparen weil ja schon klar ist das dieser Befehl mit den gegebenen Parametern einschaltet. Das Format der Parameter sollte so einfach wie möglich gehalten werden, wenn man nur Zahlen ohne Kommastellen verwendet ist ein Komma völlig ok. Bei Zahlen mit Nachkommastellen ist ein Semikolon zu verwenden, weil ioBroker international ist und sowohl Punkt als auch Komma für Dezimal Zahlen in frage kommen.Ist sowohl die Möglichkeit gegeben sie in Kombination als auch einzeln zu verwenden ist es sinnvoll beides an zu bieten.
-
@Jey-Cee genau so mache ich das. Mit mehreren Datenpunkten wird es auf jeden Fall Probleme geben. In der Firmware ist es schließlich auch nur ein Aufruf mit 2 Parametern. Ich wollte nur wissen, ob ein kommaseparierter String ok ist oder ob dann ein IO Broker User ein Anfall bekommt
-
@HausBusDe sagte in Richtige Roles und States für Relais und Taster?:
ob ein kommaseparierter String ok ist oder ob dann ein IO Broker User ein Anfall bekommt
Ganz bestimmt. Es gibt dafür keine Vorgabe, weswegen man nie weis wad man eingeben muss.
-
@Jey-Cee Ich könnte ja zusätzlich eine Conveniencefunktion machen, die nur an und ausschaltet und eine mit Parametern. Dann sollte eigentlich alle glücklich werden
-
@HausBusDe sagte:
und eine mit Parametern.
Welcher Wert soll an diesen Datenpunkt übergeben werden ?
-
@paul53 z.b. Einschaltverzögerung und Einschaltdauer
-
@HausBusDe sagte:
Einschaltverzögerung und Einschaltdauer
Als String mit Semikolon separiert und mit festgelegter Reihenfolge ?
-
@paul53 Semikolon oder Komma, ja. Wieso ?
-
@HausBusDe sagte:
Wieso ?
Du hast oben gefragt
Verwendet man dann einen String mit Kommaseparierung oder besser ein Array oder ein Object wo die beiden Werte drin sind ?
Arrays und Objekte sind für einen Blockly-Programmierer schwer darzustellen. Auch im Tab "Objekte" dürften sie Probleme bereiten.
