neues Modul 98_powerMap

Begonnen von igami, 19 Dezember 2016, 05:36:36

Vorheriges Thema - Nächstes Thema

Markus Bloch

Zitat von: Loredo am 16 Januar 2017, 02:33:49
Support dafür wird es in der Forum Sektion "Unterstützende Dienste" geben. Falls ein Forum-Moderator hier mitliest: Verschieben dieses Threads wäre klasse  :)

Ich habe soeben verschoben.

Zitat von: igami am 16 Januar 2017, 06:19:43
Worin bestand denn das Problem?

Guggst du hier: https://forum.fhem.de/index.php/topic,64716.msg561943.html#msg561943

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Loredo

#31
Zitat von: igami am 16 Januar 2017, 06:19:43
Also dafür hätte ich schon einen Ansatz mit meinem archetype modul. Das nutze ich selbst um die breite Masse zu pflegen.

Der Anwendungszweck scheint mir auf den ersten Blick ein ganz anderer zu sein.

Die Anforderungen sehe ich hier auch etwas anders. Ich habe vorgesehen, dass Modulautoren bei sich im eigenen Modul einen Hash pflegen, da ich davon ausgehe, dass gerade bei Modulen mit unterschiedlichen Gerätemodellen so ein Hash ohnehin schon grundsätzlich dort gepflegt wird. Alle Einzelheiten zu einem bestimmten Modell soll also möglichst nah dort erfassbar sein, wo es ohnehin schon gepflegt wird. Das ist im Grundsatz auch schon so eingebaut; powerMap selbst läd ein gesetztes 'powerMap' Attribut ebenfalls in $defs{$n}{powerMap}{map} ab. Dort kann aber auch das Modul bereits selbst was ablegen (wenn die Werte modellabhängig sind) oder  bei sich direkt im Modul Hash unter $modules{$TYPE}{powerMap}{map}. Letzteres führt das HP1000 Wetterstationsmodul schon vor, da es dort keine unterschiedlichen Gerätemodelle gibt.


sub X_Initialize($) {
[...]

    # 98_powerMap.pm support
    $hash->{powerMap} = {
        rname_E => 'energy',
        rname_P => 'power',
        map     => {
            Activity => {
                'dead'  => 0,
                'alive' => 5,
            },
            state => {
                '*' => 5,
            },
        }
    };

[...]
}


Dort sieht man auch, dass auch die Device Attribute hier optional im Hash angegeben werden können, um z.B. aus dem Modul heraus direkt einen anderen Readingnamen mit anzugeben, ohne dass dafür extra ein Attribut in $attr gesetzt werden muss. Über das 'powerMap' Attribut am Gerät kann die Mapping-Tabelle jederzeit manuell vom Benutzer übersteuert werden.

Für die Module, die (noch) keine direkte Unterstützung eingebaut haben, wird zusätzlich ein eigener Hash in 98_powerMap.pm gepflegt. Dieser wird aktuell aber noch nicht beachtet, ich habe erstmal nur Daten gesammelt und versucht eine geeignete Struktur zu definieren.

Direkt verwendet werden von powerMap aber lediglich die fertigen Definitionen unter $defs{$n}{powerMap}{map} und $modules{$TYPE}{powerMap}{map}.
Bei allen anderen Quellen ist vorgesehen, dass diese als Input für einen Setter im powerMap Device selbst dienen, um sie dann nach $attr{$n}{powerMap} rauszuschreiben (und darüber dann nach $defs{$n}{powerMap}{map}), damit der Benutzer sie dann als Template verwenden und ggf. abändern kann.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

justme1968

ich habe eben kurz ins modul geschaut und folgende fragen/bemerkungen:

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

- bei 50_HP1000 gibt es im $hash->{powerMap} einträge für Activity und state.
  heisst das es können einträge für mehrere readings vorhanden sein? wie ist der vorrang wenn es
  mehr als eins matched?

- bei den hue devices in powerMap_tmpl wird model als internal verwendet. tatsächlich gibt es aber nur modelid

- wo hast du du die zahlen für die hue devices her? stehen dort auch die fehlenden?

- wie genau funktioniert das interpolieren zwischen den werten? ich vermute bei den meisten lampen ist das
  alles andere als linear.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Loredo

#33
Hi André,

Zitat von: justme1968 am 16 Januar 2017, 16:17:02
- die einträge aus powerMap_tmpl sollen nach und nach direkt in $hash->{powerMap} der module?

Im Grunde ja, wenn auch vielleicht nicht 1-zu-1 in diesem Format. Die Model-Ebene würde dort wegfallen, wenn du mit $hash $defs{$n}{powerMap} meinst.
Jedes Modul ist selbst dafür zuständig dort im richtigen Format die Mapping-Tabelle (und ggf. eben weitere Attribute) abzulegen. Für Module, die das nicht selbst machen, übernimmt dies das powerMap Modul über die User Attribute powerMap.*.

Bei $modules{$TYPE}{powerMap} soll das Format identisch zu dem in $powerMap_tmpl sein (also sowohl mit als auch ohne Model Ebene für einfache Module wie mein HP1000 Modul). Matchende Definitionen in $modules bekommen Vorrang, $powerMap_tmp dient als Fallback. So entscheidet auch der Modulautor selbst, wann Einträge in 98_powerMap.pm obsolete werden.
Sowohl $modules{$TYPE}{powerMap} als auch $powerMap_tmpl sollen für den geplanten Setter im powerMap Device dienen, worüber Benutzer das powerMap-Attribut in Devices anlegen lassen können.

Zitat von: justme1968 am 16 Januar 2017, 16:17:02
- bei 50_HP1000 gibt es im $hash->{powerMap} einträge für Activity und state.
  heisst das es können einträge für mehrere readings vorhanden sein? wie ist der vorrang wenn es
  mehr als eins matched?

Ja, das stimmt. Allerdings handelt es sich streng genommen um die Namen in Events, denn die Berechnung der Leistungsaufnahme erfolgt ausschließlich Event-basiert.
Das löst zum großen Teil auch, dass unterschiedliche Events/Readings angegeben werden können. Nur wenn während der selben Eventverarbeitung von deviceEvents() mehrere Events zurückgeliefert werden, von denen auch mehrere in der Mapping Tabelle vorhanden sind, kommt es auf die Reihenfolge an, in der deviceEvents() die Events liefert. Vermutlich ist das in der Reihenfolge, wie diese entstanden sind. Sobald das erste Event in der Mapping Tabelle gefunden wurde, wird dies für die Berechnung der Leistungsaufnahme hergenommen; nachfolgende bleiben außen vor.
In der Praxis sollten in der Mapping Tabelle die Events also so gewählt werden, dass sie nicht zusammen auftreten. Kombinationen aus "wenn, dann, oder, sonst" gehen also so nicht, sollten aber eben aufgrund des Event-Characters auch eigentlich nicht notwendig sein. Davon wollte ich nur abrücken, wenn es notwendig wird. Bisher habe ich das nicht gesehen, dass es nicht ausreichend wäre.

Zitat von: justme1968 am 16 Januar 2017, 16:17:02
- bei den hue devices in powerMap_tmpl wird model als internal verwendet. tatsächlich gibt es aber nur modelid

Tatsächlich habe ich den Hash wie gesagt bisher nur grob zusammengewürfelt und noch nicht unbedingt die passenden Internals/Attribute überall angegeben. "model" ist also im Zweifel auch einfach nur ein Platzhalter für die Ebene im Hash :-)
Ich habe es für HUE.* gerade geändert.

Zitat von: justme1968 am 16 Januar 2017, 16:17:02
- wo hast du du die zahlen für die hue devices her? stehen dort auch die fehlenden?

Die ausführlicheren Zahlen für die HUE White sind von igami hier aus dem Thread; ich nehme an er hat sie über ein Messgerät bei unterschiedlichen Helligkeitsstufen einmalig ermittelt.
Die anderen Werte habe ich aus den technischen Beschreibungen von Philips, deshalb sind dort auch nur Standby- und Maximalwert sind. Selbes habe ich für die Homematic und andere Geräte gemacht (was ich halt hier so verwende).
Ist zwar dann natürlich komplett linear, aber anfänglich schonmal eine Näherung. Ich selbst habe leider kein Steckermessgerät.

Zitat von: justme1968 am 16 Januar 2017, 16:17:02
- wie genau funktioniert das interpolieren zwischen den werten? ich vermute bei den meisten lampen ist das
  alles andere als linear.

Der Hash unter {map} wird zunächst nach Höhe/Wert sortiert und es werden die zwei Werte gesucht, zwischen denen der aktuelle Wert liegt. Diese werden dann verwendet, um die lineare Leistungsaufnahme dazwischen zu errechnen. Diese Logik habe ich nahezu 1-zu-1 von igami übernommen (siehe "# value interpolation" in powerMap_power() ).

Je mehr Zwischenwerte also vorhanden sind, desto exakter die Annäherung an die reale, exponentielle Leistungskurve. Diese Werte muss halt einmal jemand ermittelt haben - da liegt unsere Hoffnung natürlich auf der Community, um hier exakter und besser zu werden als das Hersteller Datenblatt es hergibt  ;)




Gruß
Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

igami

Zitat von: justme1968 am 16 Januar 2017, 16:17:02
- wo hast du du die zahlen für die hue devices her? stehen dort auch die fehlenden?
Wie Julian schon vermutet hat, habe ich fur die HUE White mehrere Werte mit einem Zwischenstecker von HomeMatic gemessen.

Zitat von: justme1968 am 16 Januar 2017, 16:17:02
- wie genau funktioniert das interpolieren zwischen den werten? ich vermute bei den meisten lampen ist das
  alles andere als linear.
Es wird linear anhand der nächsten beiden Messpunkte interpoliert. Wie man an dem Beispiel für HUE White sieht ist dies tatsächlich nicht linear, aber wie Julian schon geschrieben hat wird es genauer je mehr Messwerte man hat.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

Loredo

Ich habe gerade eine aktualisierte Version eingecheckt.
Neben ein paar kleineren behobenen Bugs ist nun der Template Support mit eingebaut. Für diverse Module sind damit vordefinierte powerMap Attribute hinterlegt und können einfach zugewiesen werden. Über devspec lassen sich auch für mehrere Geräte gleichzeitig nach einer vorhandenen powerMap Definition suchen und anschließend zuweisen.


Ab morgen dann wie immer per Update.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

igami

Hallo Julian,

habe mir die Version von gestern, also nicht die aktuelle einmal genauer angeschaut. Soweit ich es verstehe werden bei get devices die devices welche über ein template versorgt werden nicht aufgelistet. Ich fände es aber sinnvoll, dass man das mit einbaut. Werde ich mir nachher noch mal was zu überlegen.

Grüße
igami
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

Loredo

#37
Der neue Setter zeigt bereits alle konfigurierbaren und konfigurierten Devices an. Mit einer kleineren Änderung kann die selbe Prozedur dann auch für den Getter verwendet werden.  :)


Die Liste wird nur für die Darstellung in FHEMWEB verwendet, der Setter ansich nutzt ja devspec, sprich da kann es auch so aussehen:


set pm assign .*


Damit wird für alle Geräte, für die eine powerMap gefunden wird, die entsprechenden Attribute explizit im Gerät gesetzt (entweder weil bereits aktiviert, z.B. durch ein Modul in %modules oder %defs oder weil dort bereits manuell powerMap Attribute gesetzt waren).
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

klausw

Hallo, ich habe heute dieses Modul entdeckt und auch gleich die erste Frage/Problem  8)

Bei mir werkelt ein Panstamp in meiner 25 Jahre alten Ölheizung und gibt unter anderem den Status von Brenner und Pumpen zurück.

Im passenden Modul gibt es die Redings:
Brenner
Pumpe_Boiler
Pumpe_Heizkreis

welchen den Staus "an" bzw. "aus" haben

powerMap sieht wie folgt aus:

{'Pumpe_Heizkreis' => {
'aus' => 0,
'an' => 30,},
'Pumpe_Boiler' => {
'aus' => 0,
'an' => 30,},
'Brenner' => {
'aus' => 0,
'an' => 40,},
}


Mein Problem ist jetzt, das scheinbar nur Brenner den Weg nach pM_power und pM_energy findet.
Gibt es die Möglichkeit, das die Werte, die auf "an" stehen zu addieren?
Schließlich läuft der Brenner nur im Zusammenhang mit einer der Pumpen. Die Pumpen können aber auch allein laufen.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

Loredo

#39
Nein.


Das Modul arbeitet Event-basiert und kann nicht unterscheiden, wann etwas zusammengerechnet werden müsste und wann nicht.
Einzige Ausnahme, die aber aktuell so nicht eingebaut ist, wäre, dass alle 3 Readings gemeinsam in einem einzigen Event Zyklus aktualisiert werden.


Du kannst dir aber mit einem userReading behelfen, in dem die Zustandswerte zunächst so addiert werden, dass du jede mögliche Kombination anschließend als Value hast.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Loredo

#40
Bitte einmal beiliegende Version ausprobieren.
Damit solltest du das powerMap Attribut jetzt so definieren können:


'Pumpe_Heizkreis' => {
  'aus' => "0,Pumpe_Boiler,Brenner",
  'an'  => "30,Pumpe_Boiler,Brenner",
},
'Pumpe_Boiler' => {
  'aus' => "0,Pumpe_Heizkreis,Brenner",
  'an'  => "30,Pumpe_Heizkreis,Brenner",
},
'Brenner' => {
  'aus' => "0,Pumpe_Heizkreis,Pumpe_Boiler",
  'an'  => "40,Pumpe_Heizkreis,Pumpe_Boiler",
},



Gruß
Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

klausw

Daumen hoch, funktioniert jetzt super.
Die Werte werden jetzt addiert.
Danke fürs einbauen!
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

Loredo

Danke für's Feedback, habe es jetzt so offiziell eingecheckt.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

BOFH

Hallo,

tolles Modul - Ich hau muss auch gleich mal eine Frage stellen.

Ich habeine HUE Birne, die mit Schalter im Raum AUS bzs EIN geschaltet wird.

das powermap sieht so aus


{
  'state' => {
               '0' => '0.1',
               '100' => '10',
               'unreachable' => 0
             },
'pct' => {
            '0' => 0.1,
            '10' => 1,
            '20' => 2,
            '30' => 3,
            '40' => 4,
            '50' => 5,
            '60' => 6,
            '70' => 7,
            '80' => 8,
            '90' => 9,
            '100' => 10,
          }
}


Problem ist nun, wenn ich den Lichtschalter betätige, so dass das Reading noch pct 100 anzeigt , die lampe den State  Unreachable bestitz.
Er rechnet aber mit 10W vom pct weiter. 

Ist die letzte Bedingung höherwertig ? Müsste ich erst PCT und dann STATE schreiben oder mach ich falsch?

RasPi 4
ZWave.me ZME_UZB (Fibaro Auge Gen.2)/ HM-USB2 (Thermostat | Hutschienen Relais | 1-/2fach Schalter) / Enigma2 / PhilipsTV / Philips HUE (GO|Bulb|Stripe (plus)) / Somfy IO Rollos / BOSCH HSG636XS6 / SONOS (P1, P3, P5 2.Gen, SUB, Bar)

Loredo

#44
Ich vermute mal, dass die Aktualisierung des Readings state bei dir kein Event auslöst, weil du event-on-* verwendest und es dort nicht enthalten ist.
Da das HUE Modul aber bei unreachable das pct Reading nicht aktualisiert, gibt es einfach gar kein Event, was ausgewertet werden kann.

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


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


Es reicht vollkommen aus nur das state Reading zu verwenden.
Wenn du deine Glühbirne genauer nachgemessen hasst, kannst du entsprechend mehr Abstufungen mit hinein nehmen.
Wenn dir im powerMap-Device kein Template angeboten wird, dann wäre es prima, wenn du Messergebnisse hier bekanntgibst, damit wir sie mir in die Datenbank aufnhemen können. Dafür bräuchten wir immer die genaue Modellbezeichnung.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER