neues Modul 98_powerMap

[Loredo]

Hi André,

- die einträge aus powerMap_tmpl sollen nach und nach direkt in $hash->{powerMap} der module?

Der Modul-Support ist jetzt soweit abgeschlossen.
Module können das selbe Format wie in %powerMap_tmpl entweder im Modul oder im Device Hash unter $modules{TYPE}{powerMap} resp. $defs{$n}{powerMap} ablegen.
Die Pflege der Verbrauchsdatenbank ließe sich also nun relativ einfach in andere Module wie HUEDevice verlagern.


@igami: Der Getter ist jetzt gefixt.




Gruß
Julian

[igami]

Ich habe bei meinen Hues folgende Attribute gesetzt

Code Auswählen Erweitern


event-on-change-reading energy,power,state
event-on-update-reading pct


[Loredo]

Ich habe gerade noch einen Patch eingecheckt, mit dem die Attribute event-min-interval, event-aggregator, event-on-change-reading, event-on-update-reading und timestamp-on-change-reading geprüft werden. Im Logfile werden entsprechende Warnhinweise ausgegeben, wenn Events zu den in powerMap definierten Readings möglicherweise nicht wie erwartet erzeugt würden. Sofern event-on-change-reading oder event-on-update-reading gesetzt sind und ein Reading, welches für powerMap notwendig ist, in keiner der beiden Attribute enthalten ist, wird es automatisch zu event-on-change-reading hinzugefügt.

[igami]

Ich habe gerade noch einen Patch eingecheckt, mit dem die Attribute event-min-interval, event-aggregator, event-on-change-reading, event-on-update-reading und timestamp-on-change-reading geprüft werden. Im Logfile werden entsprechende Warnhinweise ausgegeben, wenn Events zu den in powerMap definierten Readings möglicherweise nicht wie erwartet erzeugt würden. Sofern event-on-change-reading oder event-on-update-reading gesetzt sind und ein Reading, welches für powerMap notwendig ist, in keiner der beiden Attribute enthalten ist, wird es automatisch zu event-on-change-reading hinzugefügt.

Ich bin dagegen, dass powerMap die Attribute von devices verändert, sofern sich dieses nicht deaktivieren lässt. Man sollte dem Benutzer erlauben dies durch ein Attribut z.B. "modifyReadingFnAttributes" zu unterbinden. Das Attribut hat dann standardmäßig 1 und kann bei Bedarf auf 0 gesetzt werden um dann nur noch Warnhinweise mit entsprechendem verbose zu erzeugen.

[Loredo]

Ich bin dagegen, dass powerMap die Attribute von devices verändert, sofern sich dieses nicht deaktivieren lässt.

Dieser Forderung komme ich mit Revision 13186 und dem Attribut powerMap_eventChainWarnOnly nach.

[Loredo]

Ich bin grad am überlegen, wie/ob wir für Leuchten, die neben der Helligkeit auch noch Farbwerte oder verschiedene Weißtöne beherrschen, bei der Berechnung mit berücksichtigen. Dabei müsste man dann natürlich auch irgendeine Art der Interpolation zwischen fixen (Mess)Werten ableiten können.


Hab aber keine Ahnung, ob sich das überhaupt lohnen würde bzw. ob diese Faktoren sich wirklich so stark auf den Verbrauch auswirken, dass es eine Rolle spielt.

[justme1968]

dir event- attribute sind für hue lampen nicht nötig. readings werden sowieso immer nur bei änderungen aktualisiert.

ich kann die interne powerMap für hue lampen gerne einchecken.

zwischen einer einzigen farbe und weiß (alle drei farben) kann der unterschied fast 1:3 betragen. also durchaus nicht zu vernachlässigen. das lässt sich aber rein über ein einziges event vermutlich nicht mehr abbilden.

gruss
  andre

[igami]

zwischen einer einzigen farbe und weiß (alle drei farben) kann der unterschied fast 1:3 betragen. also durchaus nicht zu vernachlässigen. das lässt sich aber rein über ein einziges event vermutlich nicht mehr abbilden.

Also wäre doch jetzt interessant ob alle drei Farben gleich viel Strom benötigen oder ob es da noch unterschiede gibt.
Wie eine Farbe gemischt wird sollte sich ja heraus finden lassen.
Mit einer Messsteckdose lassen sich die theoretischen Werte dann ja auch noch überprüfen.

[Loredo]

dir event- attribute sind für hue lampen nicht nötig. readings werden sowieso immer nur bei änderungen aktualisiert.

Deshalb mag ich das Modul <3

ich kann die interne powerMap für hue lampen gerne einchecken.

Ich glaube nur einchecken alleine ist es nicht. Ich nahm an du würdest die Werte gerne direkt in %hueModels mit pflegen.
Dort müsstest du quasi einen weiteren Hash je Modell anlegen (beliebiger Name). Diesen Hash müsstest du dann entweder je Modell mit einer kleinen Schleife nach $models{TYPE}{powerMap}{modelid} referenzieren oder je Device nach $defs{$d}{powerMap}. Kommt auch noch etwas drauf an, ob du rname_P=consumption und rname_E=energy vorbelegen möchtest, damit die Readings entsprechend heißen.


Natürlich kannst du auch den hash aus 98_powerMap mehr oder weniger 1-zu-1 nach HUEDevice_Initialize() übernehmen, aber dann hättest du 2 Stellen mit Modellen zu pflegen.

das lässt sich aber rein über ein einziges event vermutlich nicht mehr abbilden.

Das ist kein Problem und kann ähnlich funktionieren wie mit der Addition, die ich neulich eingebaut habe. Man müsste nur wissen, ob der errechnete Wert z.B. für das Reading "rgb" ein Multiplikator wäre oder ein direkt zu addierender Wert.


Welche Berechnungsmethode anzuwenden wäre, ließe sich eigentlich vom aktuellen Value ableiten. Bis auf saturation sind das alles keine reinen Zahlenwerte wie wir sie sonst für die Interpolation für den Dimmwert haben.

[Loredo]

Wie eine Farbe gemischt wird sollte sich ja heraus finden lassen.

Ich vermute da kann André ein paar insights teilen, z.B. wie/ob Gamut dabei eine Rolle spielt und sich verwenden lässt.

[Loredo]

Die Standard Definition für ein HUE Gerät sieht eigentlich so aus:

Code Auswählen Erweitern


state => {
    unreachable => 0,
    0           => 0.4,
    100         => 10,
},


Es reicht vollkommen aus nur das state Reading zu verwenden.

Da muss ich mich grad selbst korrigieren.
Ich bin fälschlicherweise davon ausgegangen, dass bei HUEDevices der state Value mit dimXX% immer dem tatsächlichen Prozentwert entspricht. Es ist allerdings nur das Äquivalent zu FS20 und somit unscharf, weshalb doch das Reading pct notwendig bleibt.

Im Gegensatz zum Prototypen muss für den Wert eines Readings eine entsprechende Benennung in der powerMap Tabelle gefunden werden, ansonsten wird eine Leistung von 0 angenommen. Daher ist es notwendig dafür zu sorgen, dass man dann im Zweifelsfall auf ein Reading verweist, welches den eindeutigen Wert liefern kann, wenn das Event nicht über dieses Reading erzeugt wurde.

Eine HUE Definition müsste demnach dann also so aussehen:

Code Auswählen Erweitern


pct => {
    0   => 0.4,
    100 => 8.5,
},
state => {
    unreachable => 0,
    '*'         => 'pct',
},


[igami]

Ich finde es übrigens super, dass sich das Modul entwickelt. An diese Funktionen habe ich bei der Erstellung gar nicht gedacht

[Loredo]

Ich finde es übrigens super, dass sich das Modul entwickelt. An diese Funktionen habe ich bei der Erstellung gar nicht gedacht

Find ich auch. Jetzt nur nicht aufhören 
Dachte schon du hast dich abgemeldet 

[justme1968]

die idee wäre in %hueModels nur die pct werte (oder rgb ) zu haben und dann

Code Auswählen Erweitern

    $hash->{powerMap} = {
        rname_E => 'energy',
        rname_P => 'consumption',
        map     => {
                state => {
                        unreachable => 0,
                        '*'         => 'pct',
            },
        },   
    };   
ein mal fest im modul zu haben und dann dynamisch

Code Auswählen Erweitern

$hash->{powerMap}{map}{pct} aus $hueModels{powerMap} zuzuweisen sobald das model fest steht.

die frage wäre was passiert wenn das gerüst da ist, für ein modell aber $hash->{powerMap}{map}{pct} aber nicht gefüllt ist? kommt powerMap damit klar oder ist es besser $hash->{powerMap} dann zu löschen/nicht anzulegen?


ich vermute der gesamt verbrauch einer farbigen lampe setzt sich aus einem kleinen konstanten teil und je einer helligkeits abhängigen rampe pro farbe zusammen. bei den farbigen lampen wären das drei. ob es wirklich nötig ist die jeweils spezifischen farben der verbauten rgbs zu berücksichtigen oder ob die näherung über den rgb wert gut genug ist müsste man nachmessen. ich vermute ja. wenn nicht haben wir sowieso ein kleines problem. die daten die phillips veröffentlich passen nicht zur formel aus der api dokumentation. die formel die das modul verwendet passt besser, berücksichtig aber den gamut noch überhaupt nicht. für lightify lampen fehlt diese info komplett. ich vermute eine erste näherung über rgb sollte schon viel besser sein als nur pct auszuwerten.

für die tunable white gilt im prinzip das gleiche, mit zwei helligkeitsabhängigen rampen. die daten zu den verwendeten leds sind aber nicht veröffentlicht. hier müsste man mal nachmessen ob es reicht eine mehr oder weniger lineare verteilung anzunehmen. d.h. ww von 0-100% und kw 100-0% über den gesamten bereich.

das eigentliche problem ist aber das man z.b. das rgb event in die drei komponenten zerlegen muss, pro komponente dann den verbrauch bestimmen muss und dann alles wieder aufaddieren muss.

ein paar messungen sollten schon aufschluss geben ob sich der aufwand lohnt.

[justme1968]

also...

auf die schnelle ein paar stichproben:

Code Auswählen Erweitern

LCT001:
jeweils 100% rot -> 24mA, grün -> 47mA, blau -> 19mA
              #FFFFFF -> 51mA
              warm weiß -> 34mA, kalt weiss -> 50mA

LLC014:
  100%:  rot -> 24mA, grün -> 34mA, blau -> 26mA, #FFFFFF -> 36mA
    50%:                            blau -> 18mA, #808080 -> 21mA

d.h. die farbe hat zum teil deutlichen einfluss, bei den extendet lampen am deutlichsten.
bei voller helligkeit werden aber nicht alle kanäle auf 100% gestellt

mein messgerät sollte zwar ziemlich genau sein, lässt sich aber leider nicht automatisch auslesen.
vielleicht findet sich jemand der das ganze automatisieren kann.

vielleicht reicht es für die farbtemperatur den rgb wert auszuwerten.