powerMap wurde mit Loredo als Maintainer ofiziell in fhem eingechecked. Die Doku ist in der commandref zu finden.
Hallo,
hört sich gut an und ich würde das gerne verwenden.
Kannst du bitte mal ein komplettes Beispiel der CFG insbesodnere für das Attribut Powermap anhängen.
Wie muss dieses gefüllt werden, damit dein Modul das weiter verarbeiten kann.
Danke für die Infos
Jörg
Zitat von: jnewton957 am 19 Dezember 2016, 16:29:46
Kannst du bitte mal ein komplettes Beispiel der CFG insbesodnere für das Attribut Powermap anhängen.
Wie muss dieses gefüllt werden, damit dein Modul das weiter verarbeiten kann.
steht doch in der commandref ;)
hier die Raw definition von einer HUE white
Edit: habe noch "state.on" hinzugefügt, da beim einschalten pct nur aktualisiert wird, wenn es vorher nicht 100 war.
defmod HUEDevice2 HUEDevice 2 IODev=HUEBridge
attr HUEDevice2 IODev HUEBridge
attr HUEDevice2 alias Arbeitszimmer: Deckenlampe Leuchtmittel 1
attr HUEDevice2 color-icons 2
attr HUEDevice2 devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
attr HUEDevice2 event-on-change-reading energy,power,state
attr HUEDevice2 event-on-update-reading pct
attr HUEDevice2 group Beleuchtung
attr HUEDevice2 icon light_ceiling_light
attr HUEDevice2 model LWB006
attr HUEDevice2 powerMap "state.unreachable" => 0,\
"pct.0" => 0.4,\
"pct.10" => 1.2,\
"pct.20" => 1.7,\
"pct.30" => 1.9,\
"pct.40" => 2.3,\
"pct.50" => 2.7,\
"pct.60" => 3.4,\
"pct.70" => 4.7,\
"pct.80" => 5.9,\
"pct.90" => 7.5,\
"pct.100" => 9.2,\
"state.on" => 9.2
attr HUEDevice2 room Arbeitszimmer
attr HUEDevice2 subType dimmer
attr HUEDevice2 webCmd pct
Und hier noch die von meinem Modem
defmod modem dummy
attr modem alias Wohnzimmer: Modem
attr modem devStateIcon off:ios-off:on .*:ios-on-blue:off
attr modem group Unterschrank
attr modem icon it_router
attr modem powerMap "state.on" => 5.7,\
"state.off" => 0
attr modem room Wohnzimmer
Es ist noch ein grober Fehler in dem Modul, werde heute Abend mal überlegen wie ich den Beheben kann.
Neue Version im ersten Beitrag.
- energy wird nun korrekt berechnet und aktualisiert
- Logging hinzugefügt
ToDo:
Unit.pm verwenden
Besteht der Bedarf, dass nur ein energy Reading berechnet wird? Ich selbst habe da keinen Bedarf, kann mir aber vorstellen, dass es Sensoren gibt die nur Leistung (power) messen, jedoch keinen Zähler für den Verbrauch haben.
Hi,
erstmal Danke für das Modul. Bei mir funktioniert die neuste Version nicht (161220). Ich erhalte folgende Fehlermeldung:
Too many arguments for main::energy_energy at ./FHEM/98_energy.pm line 163, near "$power)"
Und ich verstehe die Definition der Funktion energy_energy nicht so ganz. Das steht:
sub energy_energy($$;$);
Müsste das nicht so aussehen:
sub energy_energy($$$);
Viele Grüße,
David
Hallo David,
hast du die Meldung auch nach einem Neustart von fhem? Das "Problem" ist, dass die alten subs noch im Speicher sind. Die alte sub energy_energy hat nur zwei Argumente zugelassen.
Zitat von: dferch am 22 Dezember 2016, 17:59:23
Und ich verstehe die Definition der Funktion energy_energy nicht so ganz. Das steht:
Argumente nach einem Semikolon sind optional. Die sub wird beim ändern des power Readings mit 3 Argumenten aufgerufen, bei einem zyklischen Update aber nur mit 2 Argumenten.
Hi igami,
Dann versuche ich Morgen mal einen Restart von FHEM.
Und danke für die Erläuterung mit dem Semikolon - dessen Funktion kannte ich so noch nicht.
VG,
David
Gesendet von iPad mit Tapatalk
Zitat von: dferch am 22 Dezember 2016, 19:52:26
Dann versuche ich Morgen mal einen Restart von FHEM.
Auf die Rückmeldung freue ich mich schon :) Von allen anderen die das Modul bisher getestet haben natürlich auch ;)
Bin momentan noch dabei ein ElectricityCalculator device passend für mehrere Zähler zu konfigurieren.
Schön. Scheint zu funktionieren. Die Einheiten sind bei power wohl W und bei energy Wh oder? Ich werde mich morgen auch mal daran machen das in mein ElectricityCalculator einzubauen. Damit ist meine alte Lösung per EMONITOR dann wohl hinfällig. Den Modulnamen "energy" finde ich etwas vermessen generalisierend. Und es geht nicht nur um energy, sondern auch um power und es geht um monitoring. Für "energy" überlege ich mir gerade etwas in Richtung Carbon-Footprint, also CO2-Gesamtbilanz, also Stromverbrauch und Heizungsenergie und Mobilitätsenergie (Auto/Bahn/Flugreisen) zu erfassen und in Tonnen CO2 auszudrücken. Stromverbrauch geht einfach, bei Heizenergie braucht man noch Faktoren wie Energiegehalt des Erdgases oder Heizöls, CO2 für Flugreisen kann man eventuell aus einem Portal der Fluggesellschaft auslesen, zumindest wird es auf der Buchung immer mit angegeben. Dann kann man den persönlichen Energieverbrauch durch Strom, Heizung, Reisen in Relation setzen.
Zitat von: hartenthaler am 23 Dezember 2016, 00:01:00
Schön. Scheint zu funktionieren. Die Einheiten sind bei power wohl W und bei energy Wh oder?
siehe commandref:
- energy
Ein Zähler für die bisher bezogene Energie in Wh.
- power
Die aktuelle Leistungsaufnahme des Gerätes in W.
Zitat von: hartenthaler am 23 Dezember 2016, 00:01:00
Ich werde mich morgen auch mal daran machen das in mein ElectricityCalculator einzubauen. Damit ist meine alte Lösung per EMONITOR dann wohl hinfällig.
Da bin ich gespannt, ich komme da momentan nicht auf einen grünen Zweig. ElectricityCalculator überforfdert mich noch ein bisschen :D
Zitat von: hartenthaler am 23 Dezember 2016, 00:01:00
Den Modulnamen "energy" finde ich etwas vermessen generalisierend. Und es geht nicht nur um energy, sondern auch um power und es geht um monitoring.
Für Vorschläge bin ich offen. Wie wäre es mit powerMap?
Zitat von: hartenthaler am 23 Dezember 2016, 00:01:00
Für "energy" überlege ich mir gerade etwas in Richtung Carbon-Footprint, also CO2-Gesamtbilanz, also Stromverbrauch und Heizungsenergie und Mobilitätsenergie (Auto/Bahn/Flugreisen) zu erfassen und in Tonnen CO2 auszudrücken. Stromverbrauch geht einfach, bei Heizenergie braucht man noch Faktoren wie Energiegehalt des Erdgases oder Heizöls, CO2 für Flugreisen kann man eventuell aus einem Portal der Fluggesellschaft auslesen, zumindest wird es auf der Buchung immer mit angegeben. Dann kann man den persönlichen Energieverbrauch durch Strom, Heizung, Reisen in Relation setzen.
Das hört sich kompliziert an. Ich wünsche dir viel Erfolg bei der Umsetzung und warte gespannt :)
Zitat von: igami am 23 Dezember 2016, 05:13:34
Da bin ich gespannt, ich komme da momentan nicht auf einen grünen Zweig.
Hier meine Definition des zu meinen HUE-Lampen gehörigen ElectricityCalculator
defmod Energie.HUE_Lampen ElectricityCalculator HUE.*:energy.*
attr Energie.HUE_Lampen BasicPricePerAnnum 0
attr Energie.HUE_Lampen Currency €;
attr Energie.HUE_Lampen ElectricityCounterOffset 0
attr Energie.HUE_Lampen ElectricityKwhPerCounts 0.001
attr Energie.HUE_Lampen ElectricityPricePerKWh 0.2567
attr Energie.HUE_Lampen MonthOfAnnualReading 5
attr Energie.HUE_Lampen MonthlyPayment 0
attr Energie.HUE_Lampen ReadingDestination CalculatorDevice
attr Energie.HUE_Lampen SiPrefixPower W
attr Energie.HUE_Lampen group Kosten_Verbrauch
attr Energie.HUE_Lampen room Energie
attr Energie.HUE_Lampen stateFormat {sprintf("Heutige Kosten: 1: %.2f €, 2: %.2f €, 3: %.2f €, 4: %.2f €, 5: %.2f €, 6: %.2f €, 7: %.2f €, 8: %.2f €, 10: %.2f €, 11: %.2f €, 12: %.2f €",\
ReadingsVal("Energie.HUE_Lampen","HUEDevice1_energy_EnergyCostDay",""),\
ReadingsVal("Energie.HUE_Lampen","HUEDevice2_energy_EnergyCostDay",""),\
ReadingsVal("Energie.HUE_Lampen","HUEDevice3_energy_EnergyCostDay",""),\
ReadingsVal("Energie.HUE_Lampen","HUEDevice4_energy_EnergyCostDay",""),\
ReadingsVal("Energie.HUE_Lampen","HUEDevice5_energy_EnergyCostDay",""),\
ReadingsVal("Energie.HUE_Lampen","HUEDevice6_energy_EnergyCostDay",""),\
ReadingsVal("Energie.HUE_Lampen","HUEDevice7_energy_EnergyCostDay",""),\
ReadingsVal("Energie.HUE_Lampen","HUEDevice8_energy_EnergyCostDay",""),\
ReadingsVal("Energie.HUE_Lampen","HUEDevice10_energy_EnergyCostDay",""),\
ReadingsVal("Energie.HUE_Lampen","HUEDevice11_energy_EnergyCostDay",""),\
ReadingsVal("Energie.HUE_Lampen","HUEDevice12_energy_EnergyCostDay","")\
)}
Und hier eine passende readingsGroup zur Anzeige als ersten Wurf
defmod rg_Energie.HUE_Lampen readingsGroup <%measure_power>,<Zählerstand>,<aktuelle Leistung>,<Tagesverbrauch=>>,<Heute>,<Tagesverbrauch=>>,<Gestern>,<Monat>,<Jahr> \
Energie.HUE_Lampen:@2,<#1>,(.*)_CounterCurrent,#1_PowerCurrent,#1_EnergyDay,#1_EnergyCostDay,#1_EnergyDayLast,#1_EnergyCostDayLast,#1_EnergyCostMonth,#1_EnergyCostMeter
attr rg_Energie.HUE_Lampen group Kosten_Verbrauch
attr rg_Energie.HUE_Lampen nameStyle style="color:blue"
attr rg_Energie.HUE_Lampen nonames 1
attr rg_Energie.HUE_Lampen room Energie,Preis
attr rg_Energie.HUE_Lampen sortColumn 5
attr rg_Energie.HUE_Lampen valueFormat {\
if ($READING =~ "_CounterCurrent") {return "%09d";;}\
elsif ($READING =~ "_PowerCurrent") {return "%.0f W";;}\
elsif ($READING =~ "_EnergyDay") {return "%.3f kWh";;}\
elsif ($READING =~ "_EnergyCostDay") {return "%.2f €";;}\
elsif ($READING =~ "_EnergyDayLast") {return "%.3f kWh";;}\
elsif ($READING =~ "_EnergyCostDayLast") {return "%.2f €";;}\
elsif ($READING =~ "_EnergyCostMonth") {return "%.2f €";;}\
elsif ($READING =~ "_EnergyCostMeter") {return "%.2f €";;}\
}
attr rg_Energie.HUE_Lampen valueStyle { if($READING =~ "_PowerCurrent" && $VALUE >= 0 && $VALUE <= 5){'style="color:green;;text-align:right"'}\
elsif( $READING =~ "_PowerCurrent" && $VALUE > 5 && $VALUE < 10){'style="color:orange;;text-align:right"'}\
elsif( $READING =~ "_PowerCurrent" && $VALUE >= 10){'style="color:red;;text-align:right"'}\
elsif( $READING =~ "_EnergyDay" && $VALUE <= 0.05){'style="color:green;;text-align:right"'}\
elsif( $READING =~ "_EnergyDay" && $VALUE > 0,05 && $VALUE < 0.1 ){'style="color:orange;;text-align:right"'}\
elsif( $READING =~ "_EnergyDay" && $VALUE >= 0.1){'style="color:red;;text-align:right"'}\
elsif( $READING =~ "_EnergyCostDay" && $VALUE <= 0.015){'style="color:lightgreen;;text-align:right"'}\
elsif( $READING =~ "_EnergyCostDay" && $VALUE > 0.015 && $VALUE < 0.03 ){'style="color:orange;;text-align:right"'}\
elsif( $READING =~ "_EnergyCostDay" && $VALUE >= 0.03){'style="color:red;;text-align:right"'}\
elsif( $READING =~ "_EnergyCostMonth" && $VALUE <= 0.3){'style="color:lightgreen;;text-align:right"'}\
elsif( $READING =~ "_EnergyCostMonth" && $VALUE > 0.3 && $VALUE < 0.06){'style="color:orange;;text-align:right"' }\
elsif( $READING =~ "_EnergyCostMonth" && $VALUE >= 0.06){'style="color:red;;text-align:right"'}\
elsif( $READING =~ "_EnergyCostMeter" && $VALUE <= 3){'style="color:lightgreen;;text-align:right"'}\
elsif( $READING =~ "_EnergyCostMeter" && $VALUE > 3 && $VALUE < 6 ){'style="color:orange;;text-align:right"'}\
elsif( $READING =~ "_EnergyCostMeter" && $VALUE >= 6){'style="color:red;;text-align:right"'}\
else{'style="color:grey;;text-align:right"'}\
}
Was mir aber noch nicht gefällt: es sind derzeit etliche HUE-Lampen an, aber nur bei einer wird etwas aufsummiert. Woran es liegt, muss ich noch untersuchen. Aber zumindest die Struktur steht schon mal.
Zitat
Für Vorschläge bin ich offen. Wie wäre es mit powerMap?
Ja. PowerMon oder EnergyMonitor fände ich auch ok.
Zitat von: hartenthaler am 23 Dezember 2016, 21:22:32
Was mir aber noch nicht gefällt: es sind derzeit etliche HUE-Lampen an, aber nur bei einer wird etwas aufsummiert. Woran es liegt, muss ich noch untersuchen. Aber zumindest die Struktur steht schon mal.
Wie sieht es denn mit event-on-change-reading und event-on-update-reading bei den HUE Leuchten aus? Desweiteren habe ich bei mir state.on noch in das powerMap attribut hinzugefügt.
Zitat von: hartenthaler am 23 Dezember 2016, 21:22:32
Was mir aber noch nicht gefällt: es sind derzeit etliche HUE-Lampen an, aber nur bei einer wird etwas aufsummiert. Woran es liegt, muss ich noch untersuchen. Aber zumindest die Struktur steht schon mal.
Das liegt einfach an dem geringen Verbrauch. Bei mir stehen die Zählerstände auch noch auf 0, da sie noch nicht 1 kWh verbraucht haben :D
Anbei auch mal meine readingsGroup: alias wird ausgewertet, power wird aus dem device gelesen und nicht die Berechnung aus ElectricyCalculator benutzt
defmod ElectricityCalculator_readingsGroup readingsGroup <%measure_power>,<Zählerstand>,<Leistung>,<Heute>,<Gestern>,<Monat>,<Jahr>\
ElectricityCalculator:@2,!alias@#1,(.*)_energy_CounterCurrent,power@#1,#1_energy_EnergyDay,#1_energy_EnergyCostDay,#1_energy_EnergyDayLast,#1_energy_EnergyCostDayLast,#1_energy_EnergyMonth,#1_energy_EnergyCostMonth,#1_energy_EnergyYear,#1_energy_EnergyCostYear
attr ElectricityCalculator_readingsGroup nameStyle {return 'style="font-weight: bold;; color: #025995"' if($READING =~ /Heute|Gestern|Monat|Jahr/);;\
return 'style="text-align: left;; font-weight: bold;; color: #025995"';;\
}
attr ElectricityCalculator_readingsGroup noheading 1
attr ElectricityCalculator_readingsGroup nonames 1
attr ElectricityCalculator_readingsGroup room Messstation
attr ElectricityCalculator_readingsGroup style style="text-align: center"
attr ElectricityCalculator_readingsGroup valueColumn {return 2 if($READING =~ "_CounterCurrent");;\
}
attr ElectricityCalculator_readingsGroup valueColumns {"Heute" => "colspan = 2",\
"Gestern" => "colspan = 2",\
"Monat" => "colspan = 2",\
"Jahr" => "colspan = 2"\
}
attr ElectricityCalculator_readingsGroup valueFormat {return(AttrVal("$DEVICE", "alias", "$DEVICE")) if($READING =~ /alias/);;\
return "%09d" if($READING =~ /_CounterCurrent/);;\
return "%.1f W" if($READING =~ "power");;\
return "%.3f kWh" if($READING =~ "_EnergyDay");;\
return "%.2f €" if($READING =~ "_EnergyCostDay");;\
return "%.3f kWh" if($READING =~ "_EnergyDayLast");;\
return "%.2f €" if($READING =~ "_EnergyCostDayLast");;\
return "%.3f kWh" if($READING =~ "_EnergyMonth");;\
return "%.2f €" if($READING =~ "_EnergyCostMonth");;\
return "%.3f kWh" if($READING =~ "_EnergyYear");;\
return "%.2f €" if($READING =~ "_EnergyCostYear");;\
}
attr ElectricityCalculator_readingsGroup valueStyle {return 'style="text-align: left"' if($READING =~ /alias/);;\
return 'style="text-align: center"' if($READING =~ /_CounterCurrent/);;\
return 'style="text-align: right"';;\
}
Neue Version im ersten Beitrag:
- update durch pruefung auf P1 verbessert
- Modul von energy in powerMap umbenannt
- commandref: Hinweis zu timestamp-on-change-reading hinzugefuegt
Könnte sich noch jemand den code angucken?
Irgendwie werden im Event monitor zwar power und energy angezeit, in der Detailansicht von dem Device die Readings jedoch nicht aktualisiert.
Der wichtige Teil sollte der hier sein
sub powerMap_Notify($$) {
my ($hash, $dev_hash) = @_;
my $name = $hash->{NAME};
return if(IsDisabled($name));
my $dev = $dev_hash->{NAME};
my $powerMap = AttrVal($dev, "powerMap", undef);
return unless($powerMap or $dev eq "global");
my $events = deviceEvents($dev_hash, 1);
return unless($events);
foreach my $event (@{$events}) {
next if(!$event);
next if(AttrVal($dev, "noPower", 0));
Log3($name, 5, "powerMap ($name) - triggered by $dev $event");
if($event !~ /^(energy|power): / and $powerMap){
my $power = powerMap_powerMap($name, $dev, $event, $powerMap);
readingsBeginUpdate($dev_hash);
unless(AttrVal($dev, "noEnergy", 0)){
my $energy = powerMap_energy($name, $dev, $power);
readingsBulkUpdate($dev_hash, "energy", $energy);
}
readingsBulkUpdate($dev_hash, "power", $power)
if($power ne "no match");
readingsEndUpdate($dev_hash, 1);
}
if($event eq "INITIALIZED" and $dev eq "global"){
for(devspec2array("powerMap=.+:FILTER=noEnergy!=1")){
powerMap_update("$name|$_");
}
}
if
($event =~ /^ATTR.(.+).no(Energy|Power).0$/ or
$event =~ /^DELETEATTR.(.+).no(Energy|Power)$/
){
powerMap_update("$name|$1");
}
}
return;
}
Habe schon mit NotifyOrderPrefix gespielt, aber keine Verbesserung erzielt. Kann es daran liegen, dass das ganze im notify Block liegt?
Ich habe mir die aktuelle Version jetzt auch mal gezogen und derzeit wird kein Power-Reading angelegt und das Energy-Reading bleibt nur auf 0.
Den Code habe ich mir noch nicht angesehen, mal schauen ob ich da ein paar sinnvolle Debugging-Logs einbauen kann.
Den Fehler, weshalb die Longpoll Events nicht auf der Detailseite übertragen werden, habe ich bisher nicht finden können.
Anbei ist jedoch eine überarbeitete Version.
Changelog:
# enhanced logging
# enhanced event handling
# rewrite of powerMap_powerMap
# added Unit.pm support
Bei dieser hat sich das Format des powerMap Attributs geändert, um damit eine stabilere und performantere Eventverarbeitung zu erhalten.
Ich habe die CommandRef entsprechend angepasst.
Zitat von: hartenthaler am 23 Dezember 2016, 00:01:00Damit ist meine alte Lösung per EMONITOR dann wohl hinfällig.
Bevor hier mehr Arbeit reingesteckt wird:
Was ist denn an EMONITOR besser/schlechter, außer dass es auch "nur" ein inoffizielles Modul ist? Ich kenne es nicht und möchte es mir nicht so im Detail anschauen müssen, um das beurteilen zu können.
Zitat von: Loredo am 07 Januar 2017, 17:43:29
Bevor hier mehr Arbeit reingesteckt wird:
Was ist denn an EMONITOR besser/schlechter, außer dass es auch "nur" ein inoffizielles Modul ist? Ich kenne es nicht und möchte es mir nicht so im Detail anschauen müssen, um das beurteilen zu können.
Ich habe EMONITOR vorher getestet. Was mir daran nicht gefällt, dass es nur on und off unterstützt, also nicht für dimmer geeignet ist. Das war eigentlich der hauptgrund für das Modul hier. Weiterhin erzeugt es automatisch eine readingsGroup die bei mir dazu führt, dass mein fhem komplett abstürzt. Es wurde seit über einem Jahr nicht weiterentwickelt. Es ist so programmiert, dass es Attribute wie event-on-change-reading oder icon durch folgende Meldung blockiert:
EMONITOR_Attr: icon must at least one of: auto-save,disable,room,track-within-hour,types,use-power-event,verbose
Zitat von: Loredo am 05 Januar 2017, 23:55:04
Anbei ist jedoch eine überarbeitete Version.
Habe ich bisher noch nicht getestet, sondern nur angeschaut.
Die Änderung im powerMap Attribut finde ich sehr gut. Hatte das anfangs auch so vorgehabt, nur nicht gewusst wie das geht ::)
Werde jetzt hoffentlich nächste Woche mal dazu kommen das zu testen.
Ok, das sind mir genug Gründe 8)
Hier die aktuelle Version:
# 170108-loredo:
# initial hash defining powerMap default values for FHEM devices
# (not in use so far)
# permanent and standby power may be defined by using '*' => <value>
# attributes renamed to be unique
# new attributes to optionally rename power and energy reading to
# avoid interference
# let FHEM modules define their powerMap in
# $modules{ $defs{$name}{TYPE} }{powerMap}{map}
# or per device definition/instance in
# $defs{$name}{'.powerMap'}{map}
Damit sind deine ToDo's glaube ich soweit abgearbeitet. Ich habe folgende neue aufgenommen:
# - let FHEM modules define their powerMap in $defs{$name}{powerMap}
# - help users setting powerMap attribute using internal hash database or
# by copying from $defs{$name}{powerMap}
Gruß
Julian
Ich habe jetzt noch den Support für die direkte Modulunterstützung eingebaut.
Meinem Modul HP1000 habe ich den Support gerade bereits verpasst.
Das Attribut powerMap wird jetzt auch nur noch bei einer Änderung neu eingelesen und wird ansonsten dauerhaft im Device Hash mit abgelegt.
Außerdem ist es nun optional, wenn ein Modul die Definition entweder unter $modules{ $defs{$name}{TYPE} }{powerMap}{map} oder $defs{$name}{'.powerMap'}{map} selbst ablegt.
Das vom User angelegte powerMap Attribut erhält jedoch Vorrang, damit die Vorgaben aus Modulen bei Bedarf überschrieben werden können.
Ahoi,
wollte das Modul gerade mal testen, bekomme aber nach Eingabe von
reload 98_powerMap
folgende Fehlerausgabe:
Can't locate Unit.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/98_powerMap.pm line 53.
BEGIN failed--compilation aborted at ./FHEM/98_powerMap.pm line 53.
Kann mir jemand weiterhelfen?
Danke schonmal!
Gruß
Andreas
Bitte immer FHEM neu starten und kein reload verwenden (alte Regel).
Außerdem fehlt dir Unit.pm, was für eine alte FHEM Installation spricht, die nicht auf dem aktuellen Stand ist.
Jau, hast recht,
unit.pm und uconv.pm fehlten mir...habe auch lange kein update mehr gemacht... :-[
Gruß
Andreas
EDIT: So, nu passt alles und es läuft... Danke!
Ahoi,
so, habe das Modul nun erfolgreich mit einer E-Heizung (und HM-LC-SW1-FM) testen können.
Vielen Dank für dieses Modul!
Eine Frage hätte ich dazu noch. Das reading pM_energy wird ja, glaub ich, standardmäßig alle 15 min aktualisiert. Solange die Heizung läuft wird dieser Wert auch alle 15 min in das log des devices geschrieben. Wenn ich die Heizung nun vor der nächsten Aktualisierung des readings abschalte, wird zwar der zu diesem Zeitpunkt aktuelle Wert in das reading des devices geschrieben, aber nicht in das logfile. Dort findet man "nur" die Werte der jeweiligen "15-min-Aktualisierungen".
Kann man das irgendwie umsetzen, dass der Wert bei Ausschalten der Heizung ins log des devices geschrieben wird? Wenn ja, wie?
Danke schonmal für jegliche Hilfe!
Gruß
Andreas
Das hört sich noch nach dem longpoll Problem an, welches momentan noch unerklärt ist.
Nachdem Markus heute ganz doll geholfen hat das longpoll Problem zu beseitigen, habe ich gerade eine erste offizielle Version ins SVN eingecheckt, die ab morgen/heute früh per Update bereitsteht.
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 :)
Was in der nächsten Zeit noch nachkommen wird sind die Template Funktionen, um sich für bekannte Gerätemodelle vordefinierte Attribute erzeugen zu lassen.
Zitat von: Loredo am 16 Januar 2017, 02:33:49
Nachdem Markus heute ganz doll geholfen hat das longpoll Problem zu beseitigen, habe ich gerade eine erste offizielle Version ins SVN eingecheckt, die ab morgen/heute früh per Update bereitsteht.
Worin bestand denn das Problem?
Zitat von: Loredo am 16 Januar 2017, 02:33:49
Was in der nächsten Zeit noch nachkommen wird sind die Template Funktionen, um sich für bekannte Gerätemodelle vordefinierte Attribute erzeugen zu lassen.
Also dafür hätte ich schon einen Ansatz mit meinem archetype modul (https://forum.fhem.de/index.php/topic,53402.0.html). Das nutze ich selbst um die breite Masse zu pflegen.
Ich finde es wirklich schön, dass hier auch zusammen an Modulen entwickelt wird :)
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
Zitat von: igami am 16 Januar 2017, 06:19:43
Also dafür hätte ich schon einen Ansatz mit meinem archetype modul (https://forum.fhem.de/index.php/topic,53402.0.html). 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.
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
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
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.
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.
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
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).
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.
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.
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
Daumen hoch, funktioniert jetzt super.
Die Werte werden jetzt addiert.
Danke fürs einbauen!
Danke für's Feedback, habe es jetzt so offiziell eingecheckt.
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?
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.
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?
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
Ich habe bei meinen Hues folgende Attribute gesetzt
event-on-change-reading energy,power,state
event-on-update-reading pct
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.
Zitat von: Loredo am 22 Januar 2017, 12:00:13
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.
Zitat von: igami am 22 Januar 2017, 13:48:41
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.
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.
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
Zitat von: justme1968 am 22 Januar 2017, 15:56:28
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.
Zitat von: justme1968 am 22 Januar 2017, 15:56:28
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
;)
Zitat von: justme1968 am 22 Januar 2017, 15:56:28
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.
Zitat von: justme1968 am 22 Januar 2017, 15:56:28
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.
Zitat von: igami am 22 Januar 2017, 17:48:47
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.
Zitat von: Loredo am 21 Januar 2017, 20:03:24
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.
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:
pct => {
0 => 0.4,
100 => 8.5,
},
state => {
unreachable => 0,
'*' => 'pct',
},
Ich finde es übrigens super, dass sich das Modul entwickelt. An diese Funktionen habe ich bei der Erstellung gar nicht gedacht :)
Zitat von: igami am 23 Januar 2017, 17:49:26
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 ;D
die idee wäre in %hueModels nur die pct werte (oder rgb :) ) zu haben und dann $hash->{powerMap} = {
rname_E => 'energy',
rname_P => 'consumption',
map => {
state => {
unreachable => 0,
'*' => 'pct',
},
},
};
ein mal fest im modul zu haben und dann dynamisch $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.
also...
auf die schnelle ein paar stichproben: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.
Zitat von: Loredo am 23 Januar 2017, 18:57:52
Find ich auch. Jetzt nur nicht aufhören ;)
Dachte schon du hast dich abgemeldet ;D
Ne, habe nicht vor mich abzumelden nur so ganz folgen kann ich auch nicht mehr ::)
Bei mir im Log finden sich jede Menge Einträge dieser art:
2017.01.23 22:57:04 1: powerMap Heizkessel: Pumpe_Heizkreis: Adding to total
2017.01.23 22:57:04 1: powerMap Heizkessel: Pumpe_Boiler: Adding to total
Verbose für das powerMap habe ich aber genau aus diesem Grund auf 0 gestellt.
Dadurch müsste es doch unterdrückt werden.
Ich glaube verbose=0 gibt es so nicht.
Ist auch ein Versehen, ich habe das gerade korrigiert.
Hallo zusammen,
ich bräuchte einen Tip wie die Powermap Daten von verschiedenen Geräten in das Modul Electricity Calculator eingebunden werden können.
Das verfolgte Ziel ist eine Verbrauchsanzeige pro Room sowie eine Gesamtverbrauchsanzeige minus der zugeführten Energie der Solaranlage.
Die Messung erfolgt in der Regel via KNX-Switche mit Strommessung und zusätzlich der nicht messbaren Werte einzelner Verbraucher mittels PowerMap.
Viele Grüße
Gruby
Zitat von: Gruby am 29 Januar 2017, 15:51:49
ich bräuchte einen Tip wie die Powermap Daten von verschiedenen Geräten in das Modul Electricity Calculator eingebunden werden können.
Das verfolgte Ziel ist eine Verbrauchsanzeige pro Room sowie eine Gesamtverbrauchsanzeige minus der zugeführten Energie der Solaranlage.
Das ist ja eher eine ElectricityCalculator spezifische Frage und so auch glaube ich nicht umsetzbar.
Ich habe bei mir folgendes definiert
defmod ElectricityCalculator ElectricityCalculator .*:energy.*
defmod powerMap powerMap
attr powerMap powerMap_rname_E energy
attr powerMap powerMap_rname_P power
attr powerMap room helper
Dadurch bekomme ich im ElectricityCalculator für jedes device einzelne Readings, diese werden aber nicht zusammen gefasst.
Die Interpolation des Moduls muss noch angepasst werden.
In dem Thread Kennlinie / Lookup table in Perl umsetzen (https://forum.fhem.de/index.php/topic,57967.msg575767.html#msg575767) geht es darum von einem Analogthermometer PLC Werte in Temperatur zu mappen. Dabei gehen die PLC Werte von 1793 bis 15501 (aufsteigend) und die Temperatur Werte von +80°C bis -30°C (absteigend) dadurch, dass im powerMap davon ausgegangen wird, dass es immer aufsteigend, aufsteigend ist kommen falsche Werte zustande. Schuld daran dürften die Zeilen ab 1401 sein
foreach ( sort keys %{ $powerMap->{$reading} } ) {
next unless ( looks_like_number($_) );
$val1 = $_ if ( $_ < $num );
$val2 = $_ if ( $_ > $num );
last if ( defined($val2) );
}
Hier wird erstmalig geschaut wo die nächsten beiden Variablen sind, aber eben sehr plump und es wird davon ausgegangen, dass sie aufsteigend sind. Ich wollte mir nachher mal Gedanken dazu machen wie man das eleganter Lösen kann, aber vielleicht hat ja schon jemand einen Ansatz parat. Auf ein zusätzliches Perl Modul wie Math::Interpolate würde ich gerne verzichten, aber man kann da ja mal rein schauen wie es gelöst wurde.
Edit: Es scheint doch ein anderer Fehler zu sein, auch bei meiner HUE Leuchte wird nicht korrekt interpoliert
2017.02.03 06:33:03 5: powerMap HUEDevice2: pct: val=71 num=71
2017.02.03 06:33:03 5: powerMap HUEDevice2: pct: Interpolating power value between 10 and 100
2017.02.03 06:33:03 4: powerMap HUEDevice2: energy calculation results:
energyOld : 2724.9165543209 Wh
powerOld : 4.7 W
power : 6.62222222222222 W
timeframe : 0.000555555555555556 h
energyDiff: 0.00261111111111111 Wh
energy : 2724.91916543201 Wh
Es wird zwischen 10 und 100 Interpoliert obwohl powerMap so aussieht:
{
'pct' => {
'0' => '0.4',
'10' => '1.2',
'100' => '9.2',
'20' => '1.7',
'30' => '1.9',
'40' => '2.3',
'50' => '2.7',
'60' => '3.4',
'70' => '4.7',
'80' => '5.9',
'90' => '7.5'
},
'state' => {
'off' => '0.4',
'on' => '9.2',
'unreachable' => 0
}
}
Die Sortierreihenfolge habe ich gerade korrigiert.
Hallo zusammen,
erstmal danke an alle Beteiligten für die Entwicklung und Umsetzung dieses Moduls.
Gibt es eine Möglichkeit das "pM_energy"-Reading durch powerMap in kWh umrechnen zu lassen, oder muss ich alle Watt-angaben in Kilowatt-angaben ändern?
Gruß Mathias
Die Einheiten-Umrechnung ist in Unit.pm vorgesehen und kann dann darüber erfolgen.
Derzeit ist es noch nicht möglich und die Einheiten sind in Watt bzw. Wattstunden.
Bitte beachten: Wenn du die Wattangaben im powerMap Attribut in Kilowatt änderst, dann bleibt die Einheit intern trotzdem auf Watt gesetzt. Zukünftig kann es dadurch also u.U. zu Fehlern kommen.
Hallo wie kann ich denn diesen State eines HM Dimmer Kanals Mappen?
STATE chn:off phys:30
benötigt wird natürlich der phys wert.
Merci für die Hilfe
Alex
Sofern chn: keinen Wert einer Ziffer annehmen kann, kannst du es direkt so verwenden. Es werden automatisch alle Nicht-Ziffern aus dem Wert ignoriert.
Hallo zusammen,
habe hier u.U. ein etwas seltsames Phänomen.
Gestern habe ich ein HHTPMOD-Device mit geänderten Daten aktualisiert.
Seitdem werden automatisch die Readings für/von powerMap in diesem Device erzeugt, obwohl die Attribute darin gar nicht vergeben sind...
In den Internals des HTTPMOD-Devices findet sich das:
Powermap:
Readingsdesc:
Pm_consumption:
rtype w
Pm_energy:
rtype whr
Die Attribute sehen so aus, also keine Spur von powerMap:
disable 0
enableControlSet 1
enableCookies 1
reAuthRegex .*Error.*
reading01Format %.0f
reading01JSON fuelgauge
reading01Name Akku-Füllstand
replacement1Mode key
replacement1Regex %%password%%
replacement1Value password
sid1Header1 Content-Type: text/html
sid1Header2 Accept: */*
sid1URL https://mein-senec.de/
sid2Data username=XXX&passwort=%%password%%
sid2Header1 Accept: */*
sid2Header2 Content-Type: application/x-www-form-urlencoded
sid2IgnoreRedirects 1
sid2URL https://mein-senec.de/endkunde/auth/authenticate
sid3Header1 Accept: */*
sid3Header2 Content-Type: text/html
sid3URL https://mein-senec.de/endkunde
stateFormat { sprintf("%.0f",ReadingsVal($name,"Akku-Füllstand",0)) }
timeout 20
userattr reading01Format reading01JSON reading01Name replacement1Mode:reading,internal,text,expression,key replacement1Regex replacement1Value sid1Data sid1Header1 sid1Header2 sid1URL sid2Data sid2Header1 sid2Header2 sid2IgnoreRedirects:0,1 sid2URL sid3Header1 sid3Header2 sid3URL
verbose 2
Ist dazu etwas bekannt?
Das Kuriose daran ist, dass ich gestern ebenfalls ein anderes Device in gleicher Weise aktualisiert habe.
Dort tritt dieses Verhalten aber nicht auf...
Ergänzung: In diesem Device stehen ebenfalls in den Internals die Sachen zu Powermap, die Readings tauchen aber wie gesagt nicht auf...
Wenn noch weitere Infos fehlen, bitte einfach Bescheid geben...
Danke schonmal!
Gruß
Andreas
Moin,
hat niemand eine Idee oder einen Hinweis?
Viele Grüße
Andreas
Ich habe spontan keine konkrete Idee dazu, weil du nur unvollständige Infos lieferst und man es so nicht nachstellen kann.
Moin,
welche Infos brauchst du denn noch, bzw. was wäre hilfreich?
Kurios ist halt, dass es (bisher) nur bei einem HTTPMOD-Device auftritt...
Gruß
Andreas
Am einfachsten die raw-Definition des betreffenden HTTPMOD Devices, zur Not ein vollständiges List des Devices.
Hallo Loredo,
hier die raw-Definition:
defmod httpmod_senec_akku HTTPMOD https://mein-senec.de/endkunde/api/status/getaccusavings.php?anlageNummer=0 300
attr httpmod_senec_akku userattr reading01Format reading01JSON reading01Name replacement1Mode:reading,internal,text,expression,key replacement1Regex replacement1Value sid1Data sid1Header1 sid1Header2 sid1IgnoreRedirects:0,1 sid1URL
attr httpmod_senec_akku disable 0
attr httpmod_senec_akku enableControlSet 1
attr httpmod_senec_akku enableCookies 1
attr httpmod_senec_akku reAuthRegex .*Error.*
attr httpmod_senec_akku reading01Format %.0f
attr httpmod_senec_akku reading01JSON fuelgauge
attr httpmod_senec_akku reading01Name Akku-Füllstand
attr httpmod_senec_akku replacement1Mode key
attr httpmod_senec_akku replacement1Regex %%password%%
attr httpmod_senec_akku replacement1Value password
attr httpmod_senec_akku sid1Data username=e@mail.de&passwort=%%password%%
attr httpmod_senec_akku sid1Header1 Content-Type: application/x-www-form-urlencoded
attr httpmod_senec_akku sid1Header2 Accept: */*
attr httpmod_senec_akku sid1IgnoreRedirects 1
attr httpmod_senec_akku sid1URL https://mein-senec.de/endkunde/auth/authenticate
attr httpmod_senec_akku stateFormat { sprintf("%.0f",ReadingsVal($name,"Akku-Füllstand",0)) }
attr httpmod_senec_akku timeout 20
attr httpmod_senec_akku verbose 2
setstate httpmod_senec_akku 48
setstate httpmod_senec_akku 2017-03-21 12:27:02 Akku-Füllstand 48
setstate httpmod_senec_akku 2017-03-21 12:27:02 pM_consumption 0
setstate httpmod_senec_akku 2017-03-21 12:27:02 pM_energy 0
setstate httpmod_senec_akku 2017-03-21 12:27:02 pM_energy_begin 1490095622.67961
Keine Ahnung, wie die pM_ Sachen unter setstate da rein kommen, bzw. wie man sie wieder los wird...
Gruß
Andreas
Hallo,
habe noch ein device gefunden, in dem die o.g. pM_ -Readings auftauchen.
Ist eine readingsGroup...
Gruß
Andreas
ich habe vorhin auch mal das Modul PowerMap getestet.
Bei mir werden die Readings PM_engergy und PM_consumption angelegt. Zusätzlich auch noch die gleichen Readings engergy und consumption.
Ist das so gewollt oder noch ein Bug? Ich habe das bei mehreren HueDevices festgestellt.
Gruß Michael
EDIT: hat sich erledigt. Attribut powerMap_rname_E wurde gesetzt.
Zitat von: Vize am 22 März 2017, 17:22:36
habe noch ein device gefunden, in dem die o.g. pM_ -Readings auftauchen.
Ist eine readingsGroup...
Es lässt sich für mich so leider nicht nachvollziehen. Die HTTPMOD Definition ist für mich unvollständig, da die INTERNALs fehlen und ich mit der Raw-Definition ohne einen Account dort offenbar keine 1-zu-1 Kopie deines Gerätes bekomme.
Bist du sicher, dass du die aktuellste Version per Update installiert hast und keine ältere Version?
Was passiert denn, wenn du folgendes ausführst:
{Dumper powerMap_findPowerMaps($modules{powerMap}{defptr}{NAME})}
und
{Dumper powerMap_findPowerMaps($modules{powerMap}{defptr}{NAME}, "httpmod_senec_akku")}
Zitat von: l2r am 23 März 2017, 22:21:44
ich habe vorhin auch mal das Modul PowerMap getestet.
Bei mir werden die Readings PM_engergy und PM_consumption angelegt. Zusätzlich auch noch die gleichen Readings engergy und consumption.
Ist das so gewollt oder noch ein Bug? Ich habe das bei mehreren HueDevices festgestellt.
Gruß Michael
EDIT: hat sich erledigt. Attribut powerMap_rname_E wurde gesetzt.
Genau. Wenn man das Attribut verändert, sind ggf. bereits Readings mit dem alten Namen angelegt, die man dann händisch mit deletereading löschen muss.
Ich bekomme folgenden Logfile-Eintrag 32x hintereinander:
Zitat2017.04.30 13:00:52 2: powerMap LBE: WARNING - Attribute event-min-interval is not compatible when using powerMap with reading 'Auto-Standby'
Hier der Auszug aus der raw-definition des Geräts:
defmod LBE dummy
attr LBE event-aggregator Verdunstungsmenge_24h:300:const:integral:86400
attr LBE event-min-interval .*:300
attr LBE event-on-change-reading .*
attr LBE icon vent_ambient_air
attr LBE powerMap 'Auto-Standby' => { 'ein' => 1, 'aus' => 25,}
attr LBE room LBE250Das Attribut event-on-change-reading ist für alle Readings des Geräts gesetzt, d.h. der Anspruch von PowerMap lt. CommandRef sollte erfüllt sein.
Warum stört das event-min-interval dann?
(Das habe ich deshalb, um im Logfile auch für Readings, die sich selten ändern, Einträge zwecks durchgängiger Plots zu erhalten...)
Zitat von: TheTrumpeter am 30 April 2017, 13:07:06
Warum stört das event-min-interval dann?
Das liegt an der Art, wie das Modul arbeitet (und arbeiten muss).
Du kannst es so dann nicht verwenden, tut mir leid.
Die Berechnung scheint aber trotzdem korrekt zu sein.
Ich könnte natürlich die Berechnung mit PowerMap und die relevanten Statusgrößen in ein neues Dummy-Modul auslagern, um die Fehlermeldung nicht mehr zu bekommen.
Würde nur gerne verstehen, wo der Fehler herkommt, da das Modul trotz der Fehlermeldung (eigentlich Warnung) korrekt zu arbeiten scheint.
Einzig im Filelog habe ich die Readings nicht regelmässig drin, sondern nur sporadisch. Hängt das damit zusammen?
Das Modul arbeitet Event basiert. Wenn du event-min-interval verwendest, schneidest du diese Events ab.
Es wird zwar richtig gerechnet, aber bei Devices wie einer Lampe wird damit der Zustand an/aus nicht korrekt übertragen, weil das Event dann eben fehlt. Bei Geräten, die regelmäßig ein Event erzeugen, ist das allerdings weniger ein Problem.
Filelog: Ohne Event kann auch nichts verarbeitet werden und wieder ein neues Event fürs Filelog erzeugt werden.
Mit event-aggregator ist das Modul ebensowenig kompatibel. Es wird empfohlen über DbLog zu loggen und die dortigen Möglichkeiten (z.B. für wie häufig etwas geloggt werden soll) zu nutzen.
Ich habe powerMap nun in ein Dummy-Gerät ausgelagert, das per Notify vom "echten" Gerät gefüttert wird. Damit klappt es wunderbar.
Hallo,
habe heute mal Versuche mit powerMap gemacht, dabei ist mir folgendes aufgefallen.
Wenn ich das richtig aus der CommandRef verstanden habe zeigt pM_energy Wh an.
powerMap {
'state' => {
'off' => 0,
'on' => 10
}
pM_consumption 10 2017-09-05 13:50:41
pM_energy 2.51111111111111 2017-09-05 13:50:41
pM_energy_begin 1504609688 2017-09-05 13:08:08
Bei einem Verbrauch von 10 W kann das aber nicht passen. Es handelt sich um eine Lampe an einem Bewegungsmelder die seit dem Einschalten von powerMap vielleicht 10 min an war.
Habe ich irgendwo einen Denkfehler oder wird eine anderer Wert bei pM_energy angezeigt?
Gruß
Eisix
Zitat von: Eisix am 05 September 2017, 14:02:45
Bei einem Verbrauch von 10 W kann das aber nicht passen. Es handelt sich um eine Lampe an einem Bewegungsmelder die seit dem Einschalten von powerMap vielleicht 10 min an war.
Wie lange sie an war dürftest du doch mit einem Blick in dein Logfile/DbLog herausfinden können.
Bei ~15 Minuten würde es ja passen.
Ok, passt.
Noch eine Frage wie macht Ihr das aufsummieren von Räumen oder des ganzen Hauses?
Mit ElectricityCalculator oder was geht am einfachsten?
Gruß
Eisix
Zitat von: Eisix am 05 September 2017, 14:39:26
Noch eine Frage wie macht Ihr das aufsummieren von Räumen oder des ganzen Hauses?
Mit ElectricityCalculator oder was geht am einfachsten?
Wenn es nur um die Leistung geht mache ich das mit DOIF
Raw definition:
defmod myElectricityConsumption DOIF
attr myElectricityConsumption state [#sum:d2:".+_Hauptschalter:.+":power]
".+_Hauptschalter" ist dabei die Regex für die devices. Kann man natürlich auch auf ".+" setzen.
Hallo,
zur Info:
bei Verwendung von readingsProxy muss event-on-update-reading auf 1 gesetzt werden damit es funktioniert.
Gruß
Eisix
Zitat von: Eisix am 06 September 2017, 10:39:46
Hallo,
zur Info:
bei Verwendung von readingsProxy muss event-on-update-reading auf 1 gesetzt werden damit es funktioniert.
Gruß
Eisix
sicher??
https://fhem.de/commandref.html#readingFnAttributes
Hallo,
Vielleicht etwas falsch ausgedrückt. event-on-update-reading wird ohne Parameter zugefügt und dann von fhem auf 1 gesetzt.
Was im Endeffekt zu dem in der von dir verlinkten Doku zu Punkt 1. führt. Also wird bei jeder Änderung eines readings ein Event generiert.
event-on-change-reading state
sollte aber auch funktionieren da hier nur bei state ein event generiert. Sofern man auf state filtert.
Ich bin sicher das es bei mir danach funktioniert hat. Mehr kann ich dazu nicht sagen.
Gruß
Eisix
Zitat von: TheTrumpeter am 02 Mai 2017, 07:07:23
Einzig im Filelog habe ich die Readings nicht regelmässig drin, sondern nur sporadisch. Hängt das damit zusammen?
Sorry to write in english, but I'm facing the same issue that the
pM_energy and
pM_consumption are updated for the device and I see the events generated in event monitor, but the FileLog doesn't capture these every time, only sporadically. It looks like these events are logged only first time after restart or something like that. I'm using powerMap with EnOcean devices from Eltako.
Thanks for help!
Petr
Are you sure you are not working with attributes like event-on-change-reading/update?? If you see the event in the event Monitor the logfile should log it. Post a list of the device and the log file device.
@Amenophis86: I'm pretty sure, here are the relevant devices:
define EnO_FFEB0424 EnOcean FFEB0424
attr EnO_FFEB0424 IODev TCM_ESP3_0
attr EnO_FFEB0424 comMode confirm
attr EnO_FFEB0424 eep A5-38-08
attr EnO_FFEB0424 gwCmd switching
attr EnO_FFEB0424 manufID 00D
attr EnO_FFEB0424 powerMap {'state' => {'off' => 0,'on' => 320}}
attr EnO_FFEB0424 subDef XXXXXXXX
attr EnO_FFEB0424 subType gateway
attr EnO_FFEB0424 switchMode switch
attr EnO_FFEB0424 verbose 5
setstate EnO_FFEB0424 on
setstate EnO_FFEB0424 2017-11-15 13:49:47 pM_consumption 320
setstate EnO_FFEB0424 2017-11-15 13:49:47 pM_energy 30615.3000000003
setstate EnO_FFEB0424 2017-08-31 19:29:42 pM_energy_begin 1504200582.10656
setstate EnO_FFEB0424 2017-11-15 13:49:47 state on
define FileLog_EnO_FFEB0424 FileLog ./log/EnO_FFEB0424-%Y.log EnO_FFEB0424
attr FileLog_EnO_FFEB0424 logtype text
setstate FileLog_EnO_FFEB0424 active
setstate FileLog_EnO_FFEB0424 2017-11-15 13:49:47 linesInTheFile 12684
and this what I get in the logfile
2017-11-15_11:25:47 EnO_FFEB0424 off
2017-11-15_12:04:44 EnO_FFEB0424 block: unlock
2017-11-15_12:04:46 EnO_FFEB0424 on
2017-11-15_12:07:44 EnO_FFEB0424 block: unlock
2017-11-15_12:07:46 EnO_FFEB0424 on
2017-11-15_12:10:44 EnO_FFEB0424 block: unlock
2017-11-15_12:10:47 EnO_FFEB0424 off
2017-11-15_12:49:45 EnO_FFEB0424 block: unlock
2017-11-15_12:49:46 EnO_FFEB0424 on
2017-11-15_12:52:45 EnO_FFEB0424 block: unlock
2017-11-15_12:52:47 EnO_FFEB0424 on
2017-11-15_12:55:45 EnO_FFEB0424 block: unlock
2017-11-15_12:55:48 EnO_FFEB0424 on
2017-11-15_12:58:45 EnO_FFEB0424 block: unlock
2017-11-15_12:58:47 EnO_FFEB0424 off
2017-11-15_13:49:46 EnO_FFEB0424 block: unlock
2017-11-15_13:49:47 EnO_FFEB0424 on
2017-11-15_13:52:46 EnO_FFEB0424 block: unlock
2017-11-15_13:52:48 EnO_FFEB0424 on
There are few lines with pM_energy, last one is
2017-11-14_19:53:13 EnO_FFEB0424 pM_energy: 29773.9666666669
I found that this line occurs when I modify the powerMap attribute (by adding a space or just clicking the attr button)
Is there anything else I can do to help to debug this?
Thanks for help!
Petr
I dont know powermap this much but you are right the Events are coming as on and off. I think the problem is the change from on/off to the value. This event is not happening. How you get this to happen I dont know.
And try working with list <device> not with the raw-definition. With list you can Show others more Information.
Just FTR, here are the non-raw definitions. Thanks everyone for help!
Internals:
DEF FFEB0424
IODev TCM_ESP3_0
LASTInputDev TCM_ESP3_0
MSGCNT 210
NAME EnO_FFEB0424
NR 640
NTFY_ORDER 50-EnO_FFEB0424
STATE off
TCM_ESP3_0_DestinationID FFFFFFFF
TCM_ESP3_0_MSGCNT 210
TCM_ESP3_0_PacketType 1
TCM_ESP3_0_RSSI -49
TCM_ESP3_0_ReceivingQuality excellent
TCM_ESP3_0_RepeatingCounter 0
TCM_ESP3_0_SubTelNum 3
TCM_ESP3_0_TIME 2017-11-16 09:34:55
TYPE EnOcean
READINGS:
2017-11-16 09:34:54 block unlock
2017-11-16 09:34:55 pM_consumption 0
2017-11-16 09:34:55 pM_energy 31567.3888888891
2017-08-31 19:29:42 pM_energy_begin 1504200582.10656
2017-11-16 09:34:55 state off
2017-01-17 17:00:18 teach 4BS teach-in sent
helper:
powerMap:
map:
state:
off 0
on 320
map.module:
state:
off 0
on 320
readingsDesc:
pM_consumption:
rtype w
pM_energy:
rtype whr
Attributes:
IODev TCM_ESP3_0
comMode confirm
eep A5-38-08
gwCmd switching
manufID 00D
powerMap {'state' => {'off' => 0,'on' => 320}}
room EnOcean,1NP koupelna,PWM
subDef XXXXXXXX
subType gateway
switchMode switch
Internals:
DEF ./log/EnO_FFEB0424-%Y.log EnO_FFEB0424
NAME FileLog_EnO_FFEB0424
NOTIFYDEV EnO_FFEB0424
NR 641
NTFY_ORDER 50-FileLog_EnO_FFEB0424
REGEXP EnO_FFEB0424
STATE active
TYPE FileLog
currentlogfile ./log/EnO_FFEB0424-2017.log
logfile ./log/EnO_FFEB0424-%Y.log
READINGS:
2017-11-16 09:34:55 linesInTheFile 12840
Attributes:
logtype text
room EnOcean
Hallo,
ich nutze powerMap zusammen mit Homemode. Dabei ist mir ein Problem aufgefallen. Das energie reading wird bei powerMap in Wh auf summiert während meine Fibaro Zwischenstecker und Homemode in kWh summieren. Gibt es eine Möglichkeit das über powerMap attribut zu beinflussen oder geht das nur über z.B. userreading?
Gruß
Eisix
Hallo zusammen,
ich habe gerade PowerMap bei mir implementiert. Grundsätzlich funktioniert alles sehr gut; auch in Zusammenarbeit mit dem ElectricityCalculator.
Bei der Implementierung eines Lichts, das über einen FS20 Zwischenstecker geschaltet wird, bin ich jetzt allerdings auf ein Problem gestoßen. Der FS20 Zwischenstecker kann direkt über einen FS20 vier-Kanal Aufputzschalter geschaltet werden und natürlich über Fhem.
Beim Schalten über Fhem werden direkt 'on' und 'off' Events gesendet; in sofern kein Problem.
Beim Schalten über den 4-Kanal Schalter werden jedoch toggle-Events gesendet, da 3 Kanäle bereits belegt sind. Im 'state' des Zwischenstecker-Device steht also 'toggle'. Das führt dazu, dass PowerMap das Reading 'pM_consumption' auf 0 stellt, da es ja nicht weiß, ob die Lampe nun an oder aus ist. Im PowerMap-Attribut kann ich 'toggle' ja keinen bestimmten Wert zuweisen.
Ich bin nun den Weg gegangen das 'toggle' über die in Fhem eingebaute Funktion UntoggleDirect aufzulösen, so dass nun ein 'on' oder 'off'übermittelt wird. Das funktioniert soweit auch, nur leider wird das 'on' und 'off' nicht in das Reading 'state' geschrieben, sondern in das Internal 'STATE'.
Dieses Internal kann ich aber scheinbar im PowerMap Attribut nicht abfragen.
Gibt es irgendeine Möglichkeit dieses Internal abzufragen oder könnte man das eventuell einbauen?
Beste Grüße und schonmal einen guten Rutsch.
Wolle
Hallo,
ich habe bei mir auch mal angefangen für einige Devices powerMap zu benutzen und leider habe ich scheinbar wie auch andere das Problem dass nicht alle geloggt bzw. an ElectricityCalc weitergereicht werden.
Folgende Module mit unterschiedlichen Ergebnissen habe ich einer PowerMap zugeordnet:
Dummy - funzt problemlos im PM update intervall, also Daten kommen bei ElectricityCalc an
Presence - PM_energy reading wird aktualisiert, häufiger als PM intervall, auch sichtbar im EventMonitor, aber keine Daten kommen im ElectricityCalc an. Ausser fhem restart oder set powermap assign <device> scheint ein update zu triggern. DBlog wird auch nicht eingetragen obwohl im event Monitor sichtbar.
FirtzBox - identisch mit Presence
pilight_switch - identisch mit Presence
fhem> list powermap
Internals:
.DbLog_splitFn Unit_DbLog_split
INTERVAL 900
NAME powermap
NR 401
NTFY_ORDER 50-powermap
STATE Last device: host.tv_sz
TYPE powerMap
READINGS:
2018-01-05 22:48:16 state Last device: host.tv_sz
powerMap:
readingsDesc:
pM_consumption:
rtype w
pM_energy:
rtype whr
Attributes:
room x_Einstellungen
Dummy welches einwandfrei funzt:
fhem> list wohnzimmer.beamer
Internals:
.DbLog_splitFn Unit_DbLog_split
NAME wohnzimmer.beamer
NR 392
STATE aus
TYPE dummy
pM_interval 900
pM_update 2018-01-05 22:58:59
READINGS:
2018-01-05 00:23:18 pM_consumption 0.5
2018-01-05 22:43:59 pM_energy 26.0023333333334
2018-01-05 00:03:49 pM_energy_begin 1515107029.48726
2018-01-05 00:23:18 state aus
powerMap:
map:
state:
an 280
aus 0.5
map.module:
state:
an 280
aus 0.5
readingsDesc:
pM_consumption:
rtype w
pM_energy:
rtype whr
Attributes:
alias Beamer
group Media
icon scene_cinema
powerMap {
'state' => {
'an' => 280,
'aus' => '0.5'
}
}
room Wohnzimmer
setList an aus
Presence Module mit problem:
fhem> list host.tv_sz
Internals:
.DbLog_splitFn Unit_DbLog_split
ADDRESS tv-sz
DEF lan-ping tv-sz 30 10
MODE lan-ping
NAME host.tv_sz
NOTIFYDEV global
NR 17
NTFY_ORDER 50-host.tv_sz
STATE present
TIMEOUT_NORMAL 30
TIMEOUT_PRESENT 10
TYPE PRESENCE
pM_interval 900
pM_update 2018-01-05 23:04:33
READINGS:
2018-01-05 22:49:33 .absenceThresholdCounter 0
2018-01-05 22:49:33 .presenceThresholdCounter 0
2018-01-05 16:28:15 model lan-ping
2018-01-05 22:49:33 pM_consumption 133
2018-01-05 22:49:33 pM_energy 2291.74013888885
2018-01-04 23:52:47 pM_energy_begin 1515106367.14131
2018-01-05 22:49:33 presence present
2018-01-05 22:49:33 state present
helper:
CURRENT_STATE present
PRESENT_COUNT 0
powerMap:
map:
state:
absent 0.1
present 133
readingsDesc:
pM_consumption:
rtype w
pM_energy:
rtype whr
Attributes:
absenceThreshold 3
alias TV Schlafzimmer
devStateIcon present:rc_GREEN:on absent:rc_RED:off
group Media
icon it_television
powerMap {
'presence' => {
'absent' => '0.1',
'present' => 133
}
}
room Schlafzimmer
Hat irgendwer eine Idee was da schief läuft?
Nach Absprache mit Loredo werde ich das powerMap Modul nun wieder betreuen.
Bitte gebt mir aber erst Zeit mich wieder zurecht zu finden.
Zitat von: Wolle02 am 28 Dezember 2017, 18:32:32
Hallo zusammen,
ich habe gerade PowerMap bei mir implementiert. Grundsätzlich funktioniert alles sehr gut; auch in Zusammenarbeit mit dem ElectricityCalculator.
Bei der Implementierung eines Lichts, das über einen FS20 Zwischenstecker geschaltet wird, bin ich jetzt allerdings auf ein Problem gestoßen. Der FS20 Zwischenstecker kann direkt über einen FS20 vier-Kanal Aufputzschalter geschaltet werden und natürlich über Fhem.
Beim Schalten über Fhem werden direkt 'on' und 'off' Events gesendet; in sofern kein Problem.
Beim Schalten über den 4-Kanal Schalter werden jedoch toggle-Events gesendet, da 3 Kanäle bereits belegt sind. Im 'state' des Zwischenstecker-Device steht also 'toggle'. Das führt dazu, dass PowerMap das Reading 'pM_consumption' auf 0 stellt, da es ja nicht weiß, ob die Lampe nun an oder aus ist. Im PowerMap-Attribut kann ich 'toggle' ja keinen bestimmten Wert zuweisen.
Ich bin nun den Weg gegangen das 'toggle' über die in Fhem eingebaute Funktion UntoggleDirect aufzulösen, so dass nun ein 'on' oder 'off'übermittelt wird. Das funktioniert soweit auch, nur leider wird das 'on' und 'off' nicht in das Reading 'state' geschrieben, sondern in das Internal 'STATE'.
Dieses Internal kann ich aber scheinbar im PowerMap Attribut nicht abfragen.
Gibt es irgendeine Möglichkeit dieses Internal abzufragen oder könnte man das eventuell einbauen?
Beste Grüße und schonmal einen guten Rutsch.
Wolle
Kannst du mal bitte Beschreiben wie du das mit dem untoggle genau gemacht hast (Link zur Anleitung sollte auch reichen)? Eventuell kann man das anpassen, dass das Reading aktualisiert wird anstelle von STATE.
Eine Abfrage auf Internals wird es nicht geben, das wäre ein Bekämpfen der Symptome, die Ursache, dass das Reading keine eindeutige Angabe macht ist dadurch aber nicht behoben.
Zitat von: albundy118 am 05 Januar 2018, 22:51:31
Hat irgendwer eine Idee was da schief läuft?
Dafür muss ich mich wieder einarbeiten, also bitte Geduld.
Hallo Michael,
schön, dass du dich kümmerst. Vielen Dank.
ZitatKannst du mal bitte Beschreiben wie du das mit dem untoggle genau gemacht hast (Link zur Anleitung sollte auch reichen)?
Die Untoggle-Funktionen (direct und indirect) sind fest von Rudi in Fhem eingebaute Funktionen und in der 99_Utils.pm zu finden.
Der Code für das UntoggleDirect sieht so aus:
######## UntoggleDirect ###########################################
# What : For devices paired directly, converts state 'toggle' into 'on' or 'off'
# Call : { UntoggleDirect("myDevice") }
# define untoggle_myDevice notify myDevice { UntoggleDirect("myDevice") }
# Source: http://www.fhemwiki.de/wiki/FS20_Toggle_Events_auf_On/Off_umsetzen
sub UntoggleDirect($)
{
my ($obj) = shift;
Log 4, "UntoggleDirect($obj)";
if (Value($obj) eq "toggle"){
if (OldValue($obj) eq "off") {
{fhem ("setstate ".$obj." on")}
}
else {
{fhem ("setstate ".$obj." off")}
}
}
else {
{fhem "setstate ".$obj." ".Value($obj)}
}
}Da setstate ja STATE schaltet, trat in PowerMap aber das beschriebene Problem auf.
ZitatEventuell kann man das anpassen, dass das Reading aktualisiert wird anstelle von STATE.
Genau das habe ich gemacht, indem ich in meiner 99_myUtils.pm eine eigene UntoggleDirect Funktion eingebaut habe, die ich leicht modifiziert habe, damit auch das Reading state geschaltet wird.
#################################
#eigene UntoggleDirect Funktion für Reading state
#
sub UntoggleDirectOwn($) {
my ($obj) = @_;
if (Value($obj) eq "toggle"){
if (OldValue($obj) eq "off") {
{fhem ("setstate ".$obj." on;
setreading ".$obj." state on")}
}
else {
{fhem ("setstate ".$obj." off;
setreading ".$obj." state off")}
}
}
else {
{fhem "setstate ".$obj." ".Value($obj);
"setreading ".$obj." state ".Value($obj)}
}
}Damit funktioniert PowerMap bei mir jetzt. Aber eigentlich ist das ja keine wirklich saubere Lösung.
Gruß
Wolle
Hi,
nachdem ich das Modul jetzt lange Zeit nicht verwendet habe, möchte ich es jetzt wieder einsetzen. Ich möchte allerdings keine Verbrauchsmessung verwenden, daher habe ich im powerMap device das Attribut powerMap_noEnergy auf 1 gesetzt.
Auf den ersten Blick funktioniert das wie gewünscht, auf den zweiten dann aber nicht mehr:
Nach einem shutdown restart werden die konfigurierten devices nicht mehr korrekt initialisiert. D.h. ein
get powerMap devices
liefert keine Devices mehr zurück.
Auf der Suche nach der Ursache bin ich im Code auf folgende Stelle gestoßen:
sub powerMap_Notify($$) {
[...]
# initialize or terminate powerMap for each device
if ( $event =~ /^(INITIALIZED|REREADCFG|SHUTDOWN)$/ ) {
foreach ( keys %{ powerMap_findPowerMaps( $name, ":PM_$1" ) } )
{
next
if ( $_ eq "global"
or $_ eq $name
or
powerMap_AttrVal( $name, $_, $TYPE . "_noEnergy", 0 ) );
[...]
Die letzte zitierte Zeile scheint schuld zu sein, dass kein Device initialisiert wird, wenn ich noEnergy gesetzt habe.
Ich würde da ja eher sowas erwarten wie
[...]
or
(powerMap_AttrVal( $name, $_, $TYPE . "_noEnergy", 0 ) && powerMap_AttrVal( $name, $_, $TYPE . "_noPower", 0 )
Kann da jemand was zu sagen? Oder hat jemand ähnliche Erfahrung? Oder mach ich was falsch?
LG
Christian
Ich schreibe das Modul jetzt mal oben auf meine Liste und lese mich wieder aktiv ein :D
@choenig: du scheinst nicht ganz unerfahren im Programmieren zu sein, ich würde mich freuen, wenn du das ganze testen könntest und mir dann eine Rückmeldung gibt ob es damit so funktioniert wie erwartet.
Hi,
Zitat von: igami am 20 Februar 2018, 19:44:34
@choenig: du scheinst nicht ganz unerfahren im Programmieren zu sein
das ist mein Beruf, da aber kein Perl, sondern eher C++/Qt ;-).
Ich kann das gerne ausprobieren, werd' aber vermutlich erst am Wochenende wieder dazu kommen. Ich wollte vorerst mal abfragen, ob vielleicht jemand schon die Antwort kennt :-).
LG
Christian
Hallo,
ich hätte da mal eine Frage die vielleicht schnell zu klären ist.
Ich nutze mehrere Dummys mit dem Modul.
Das PowerMap sieht wie folgt aus.
'state' => {
'off' => 0,
'on' => '13',
},
Ich würde jetzt gern anstatt des Verbrauchs im powerMap (in dem Bsp. die 13) gern ein Reading oder Attribut aus dem Device verwenden wo der Wert steht. Leider bekomme ich es nicht hin.
Zitat von: Snappo am 27 Februar 2018, 14:00:25
Ich nutze mehrere Dummys mit dem Modul.
Das PowerMap sieht wie folgt aus.
'state' => {
'off' => 0,
'on' => '13',
},
Ich würde jetzt gern anstatt des Verbrauchs im powerMap (in dem Bsp. die 13) gern ein Reading oder Attribut aus dem Device verwenden wo der Wert steht. Leider bekomme ich es nicht hin.
Soweit ich weiß ist das aktuell nicht möglich. Bevor ich nun eine solche Funktion implementiere würde ich gerne mehr über die Anwendung erfahren. Warum hast du es so vor?
Extra implementiert werden muß nichts. Wollte nur wissen ob es grundlegend möglich ist.
Plan war, dass ich meinen Dummys den Verbrauch einfach via einem set cmd zuweisen kann ohne gleich das ganze powerMap Attribut zu schreiben.
Aber ist vermutlich eh nicht so leicht zu realisieren da ja andere Geräte viel mehr Verbrauchswerte haben als nur an/aus. Aber so ist ja auch Okay so, macht man ja eigentlich nur einmal. Von daher hab ich nichts gefragt. ;)
Hi,
Zitat von: igami am 20 Februar 2018, 19:44:34
@choenig: du scheinst nicht ganz unerfahren im Programmieren zu sein, ich würde mich freuen, wenn du das ganze testen könntest und mir dann eine Rückmeldung gibt ob es damit so funktioniert wie erwartet.
hat jetzt etwas länger gedauert, aber so konnte es auch einige Zeit laufen. Ich habe es so umgesetzt:
[...]
# initialize or terminate powerMap for each device
if ( $event =~ /^(INITIALIZED|REREADCFG|SHUTDOWN)$/ ) {
foreach ( keys %{ powerMap_findPowerMaps( $name, ":PM_$1" ) } )
{
next
if ( $_ eq "global"
or $_ eq $name
or (
powerMap_AttrVal( $name, $_, $TYPE . "_noEnergy", 0 ) &&
powerMap_AttrVal( $name, $_, $TYPE . "_noPower", 0 )
));
[...]
Das läuft hier, wie gewollt: Ich habe keine Energy-Readings mehr, nur die von mir gewünschten Power-Readings. Ich konnte keine Seiteneffekte feststellen.
LG
Chrisitan
Vielen Dank, werde ich dieses Wochenende einbauen.
Hi,
eben fiel mir auf, dass seit dem 08.02. das Modul die readings nicht mehr aktualisiert. Ich schau heute Abend Mal welche Version ich aktuell nutze.
Gab's da ne Änderung?
Grüße
Achim
Zitat von: CBSnake am 02 April 2018, 10:13:19
Gab's da ne Änderung?
Nicht von meiner Seite. Ob es Änderungen in der fhem.pl gab die dazu führen können kann ich nicht sagen.
OK, dann geh ich die Tage mal auf die Suche.
Obwohl bei einem Dutzend Lampen das PowermapReading drin ist und auch schon funktionierte liefert ein get devices nur
No powerMap enabled devices found.
Moin,
bin dem Fehler noch immer nicht auf der Spur, auch Verbose 5 beim powerMap Modul liefert nichts.
hier mal ein List von einem Dummy
Internals:
NAME dummy_test
NR 255
STATE 100
TYPE dummy
.attraggr:
.attrminint:
OLDREADINGS:
READINGS:
2018-04-25 08:29:11 state 100
Attributes:
powerMap 'state' => {
'0' => 0,
'100' => 60,
},
room 500 Testraum
wie man sieht werden die Readings pM_energy_begin, pM_energy und pM_consumption nicht mehr angelegt.
Hier ein List vom powerMap Device
Internals:
CFGFN
INTERVAL 900
NAME powerMap
NR 16638
NTFY_ORDER 50-powerMap
STATE Initialized
TYPE powerMap
READINGS:
Attributes:
hier die fhem.pl
version
fhem.pl:16609/2018-04-13
Wo müsste ich denn ansetzen um weitere Infos liefern zu können?
Grüße
Achim
Nachtrag: Ich hab den Fehler wohl gefunden, das Device global hat das Attribut powerMap_noPower 1 :o :o
Hallo,
ich habe in der Commanref ein rein sprachliches Verständnisproblem:
ZitatFür den Fall, dass mehrere Verbrauchswerte addiert werden sollen, kann der Name von anderen Readings direkt hinter dem eigentliche Wert mit einem Komma abgetrennt angegeben werden. Der aktuelle Status dieses Readings wird dann bei der Berechnung des Gesamtverbrauchs ebenfalls ber&uumL;cksichtigt.
Ich kapier den ersten Satz irgendwie nicht. Hinter welchem Wert muss der Name des anderen Readings geschrieben werden? Muss der Readingname ebenfalls mit Hochkommata umschlossen werden?
Kann mir jemand mit einem Beispiel weiterhelfen?
Danke und Gruß
Wolle
Moin, wie vorhin erwähnt sind die Nachkommastellen etwas großzügig gewählt.
Ich hab es jetzt erstmal per userreading formatiert aber vielleicht magst du (igami) ja mal im Modul die Stellen begrenzen. :)
energyForm { sprintf("%.2f", ((ReadingsVal($name,"energy",0)))) ;;}
Hi,
ich habe gerade für meine Geräte Powermap implementiert. Leider reagieren die Schalter, an denen zB Stehlampe, LED Strip,... hängen nicht auf den Statuswechsel. Anbei meine Definitionen:
PowerMap:
Internals:
FUUID 5ed908c8-f33f-fdbd-eff4-e0da527f8ec27182
INTERVAL 900
NAME powermap
NR 341
NTFY_ORDER 50-powermap
STATE Initialized
TYPE powerMap
READINGS:
2020-06-05 17:44:47 pM_energy 0
2020-06-05 17:44:47 pM_energy_begin 1591371887.23786
powerMap:
map:
state:
off 0
on 15
readingsDesc:
pM_consumption:
rtype w
pM_energy:
rtype whr
Attributes:
room System->Funktionen
Beispielhaft ein Schalter:
Internals:
Command sudo /usr/bin/send 11100 3
DEF sudo /usr/bin/send 11100 3 1 0
FUUID 5d222b11-f33f-fdbd-f2af-a90eacfbe16b10af
NAME ST_LED
NR 305
OffValue 0
OnValue 1
STATE off
TYPE GenShellSwitch
READINGS:
2020-06-05 18:05:02 pM_energy 0
2020-06-05 18:05:02 pM_energy_begin 1591373102.16937
2020-06-05 18:04:40 state off
powerMap:
map:
state:
off 0
on 15
map.module:
state:
off 0
on 15
readingsDesc:
pM_consumption:
rtype w
pM_energy:
rtype whr
Attributes:
event-on-change-reading state
powerMap {
'state' => {
'off' => 0,
'on' => 15
}
}
powerMap_interval 900
nach dem Einschalten entstehen bei den Schaltern keine Readings mit den gesezten Wattwerten. Die einzigen Readings bleiben
Readings
pM_energy 0
pM_energy_begin 1591373102.16937
state off
Hat jemand eine Idee? oder ist das Modul inzwischen durch generelle FHEM-Änderungen defekt?
Hi,
I have a problem with the Hue bulbs connected behind an electrical switch:
When I switch off the light with the electrical switch , then state = unreachable after a while, so pM_consumption= 0 as expected.
But if in that state (electrical power off) I switch off the light with FHEM , then the "pct: 0" event triggers pM_consumption = 0.4 without taking care that current state is unreachable. I would expect that pM_consumption stays 0 in that case.
Is it something that could be corrected within the module ?
Thanks for your help