Qubino Mini Dimmer

[skyline]

Super!

Bin im Urlaub und kann aktuell nicht weiter testen.

Bei den "dim 99" bin ich trotzdem nicht bei dir  , was aber nicht so tragisch ist.

Ich sehe Fhem als große Zentrale, welche die verschiedenen Standards unter sich vereint.
Da sollte Fhem doch sein eigenen Standard setzen und die Devices dementsprechend anpassen.
Es gibt ja sonst immer unterschiedliche Schnittstelle und somit mehr Probleme.
Aber wie schon gesagt.... ist meine Meinung 

Hier mal ein Beispiel für die Probleme
https://forum.fhem.de/index.php/topic,74583.msg663478.html#msg663478


Auch Structure wird dann doch nicht sauber funktionieren.

Du verwendest bei den Shuttern doch glaube auch schon "dim 100" und jetzt sollen wir Anwender verstehen, warum da so und da so....

Vielleicht wäre es ja auch eine Möglichkeit, ein Reading mit einem frei wählbaren Maxwert zu erstellen, als Vorgabe für den Slider. So könnten dann vielleicht Dimmer und Shutter mit einem generic Device abgefrühstückt werden.

Ist aber nur ein Vorschlag.

Vielen Dank für die Umsetzung des Dimmers!

[Beta-User]

Du verwendest bei den Shuttern doch glaube auch schon "dim 100" und jetzt sollen wir Anwender verstehen, warum da so und da so....

Das Setzen auf 100 wird zugelassen (wie auch beim Dimmer), aber die slider gehen nur bis 99, und bisher war meine Erfahrung, dass es mehr Probleme verursacht so zu tun, als verstünde das Gerät direkt 100%.

Dass man z.B. für structure dann weitere Lösungen braucht, steht auf einem anderen Blatt.

Vielleicht wäre es ja auch eine Möglichkeit, ein Reading mit einem frei wählbaren Maxwert zu erstellen, als Vorgabe für den Slider. So könnten dann vielleicht Dimmer und Shutter mit einem generic Device abgefrühstückt werden.

Die ZWave-Shutter-templates sind sehr speziell, weil man darüber auch den Betriebsmodus (drehbare Lamellen oder nicht) festlegen kann. Macht m.E. keinen Sinn, das zusammenfassen zu wollen. Für "einfache" shutter ginge es evtl., aber da wäre dann der genericDeviceType wieder unterschiedlich zu "light". Ein einfaches shutter-Template nehme ich aber gerne auf, falls jemand was beisteuert bzw. bestätigt, dass es im Prinzip das dimmer auch täte!

Ich sehr Fhem als große Zentrale, welche die verschiedenen Standards unter sich vereint.
Da sollte Fhem doch sein eigenen Standard setzen und die Devices dementsprechend anpassen.
Es gibt ja sonst immer unterschiedliche Schnittstelle und somit mehr Probleme.

Das ist ja im Prinzip richtig, die Probleme fangen aber da an, wo die Hardware sich das anders vorstellt. Ein Modulautor muss zu allererst sehen, dass er die Hardware in den Griff bekommt, und das führt halt nicht zwangsläufig dazu, dass die Readings und setter "schön" oder gar "standardisiert" wären. Es wäre ja schon schön, wenn wir wenigstens sowas wie einheitliche Reading-Namen hinbekämen (unterstellt, es verbirgt sich hinter einem Etikett auch derselbe Inhalt...).
Hier ist es aber eben (leicht) unterschiedlicher Inhalt, eben "dim" und nicht "pct"....

[skyline]

Klar, die Funktion steht an erster Stelle!

Mit "set dim 100" hatte ich aber ohne die Anpassung durch das Userreading Probleme, vielleicht sollte man das auch mit aufnehmen.
So sollte dann auch vielleicht "Structure" passen.

Gruß Marco

[Beta-User]

Klar, die Funktion steht an erster Stelle!

Darum geht es: eine möglichst funktionale Lösung anzubieten (und möglichst noch Hinweise zu verlinken, warum es ggf. soherum gemacht wurde und nicht anders...)

Mit "set dim 100" hatte ich aber ohne die Anpassung durch das Userreading Probleme, vielleicht sollte man das auch mit aufnehmen.
So sollte dann auch vielleicht "Structure" passen.

Da ist mir nicht klar, wie es im Detail gemeint ist:
- eventMap wird verwendet, um "versehentliche" dim 100-Befehle abzufangen;
- Rudi hatte vorgeschlagen, in "classes" für die "richtige" Reihenfolge zu sorgen, damit "on" funktioniert. Das sollte via attrTemplate gefixt sein;
- "dim" bekommt einen Wert via userReadings, und zwar (wenn eine Rückmeldung erfolgt) auch aus dem reportedState. Eventuell muss man da vorab noch Assoziationen fixen?
War noch was anderes gemeint?

Vermutlich wäre es besser, den Ball nach dem Urlaub aufzunehmen, Trockenübungen sind manchmal nicht zielführend?

[skyline]

Ich meinte diese eventMap (nicht userReading  )

Code Auswählen Erweitern

{ usr=>{'dim.100'=>'dim 99' } }

Das würde vielleicht einige Fehler, wie zum Beispiel durch "Structure" abfangen.

[Beta-User]

...die ist drin...

Trotzdem bleibt dann uU. das Thema, dass der Status einer structure ggf. nicht richtig angezeigt wird, weil die einen Devices da drin dann eben auf "pct 100" stehen, und die anderen auf "dim 99". Muss man ggf. nacharbeiten.

[skyline]

Nach meinem Verständnis sind das eben gerade nicht 99%, sondern "dim 99". Das ist der Maximalwert und damit entspricht "dim 99" eben "100%". Das wäre zumindest die Logik, die auch RHASSPY anwendet. Das schaut, wie ist der Wertebereich und ist "pct" der setter. Nur wenn beides paßt, wird 100% mit "pct 100" übersetzt, sonst wird gerechnet .

Ich habe das heute noch mal getestet und "Dimm das Licht auf 100%" entspricht einem "dim 100".

Das eventMap

Code Auswählen Erweitern

{ usr=>{'dim.100'=>'dim 99' } } ist dann also zwingend erforderlich.

[Beta-User]

  nochmal: Es ist mir schon klar, dass das Sinn macht, dieses eventmapping so drin zu lassen . Wie sonst sollte man "irregeleitete User-Kommandos" abfangen ...

Es ging bei "bis 99" "nur" um den slider, und den mache ich NICHT ohne Not auf bis 100, weil dim eben dim ist und nicht pct .

[skyline]

Ich wollte das nur für andere Anwender noch mal niederschreiben.
Vielleicht stolpert jemand auch darüber.