Hallo zusammen,
meine Installation ist schon Jahre alt, aber trotzdem hakt es gerade irgendwie. Zugegebenermaßen bin ich weißgott kein Experte beim Thema notify. Habe mich an DOIF gewöhnt und setze damit alles Mögliche um.
Zu meinem Problem: Ich habe das Modul PowerMap für mich entdeckt und will damit statische Verbraucher erfassen. Diese sollen mit den schaltbaren Steckdosen inkl. Strommessung addiert werden und mir den momentanen Gesamtverbauch des Hauses anzeigen.
Die Steckdosen laufen über MQTT, die "dummen" Geräte ohne Messung über HUEDevice.
Mein notify was ich mir zusammengeklaut habe:
.*:ENERGY_Power:.* {
my @power = devspec2array("TYPE=HUEDevice|MQTT2_DEVICE");
my $powerPerformance = 0;
foreach (@power) {
my $energypower = ReadingsVal($_, "ENERGY_Power", 0);
if ($energypower >= 0) {
$powerPerformance += $energypower;
}
}
fhem("setreading $SELF energypower " . $powerPerformance);
}
Problem: Das reagiert nur auf das MQTT Device mit der echten Messung. Das HUEDevice mit dem hinterlegten PowerMap löst nicht aus. Im Event Monitor aber schon. Das aufaddieren passiert später, wenn MQTT wieder ausgelöst hat.
Zwei exemplarische Lists:
MQTT:
Internals:
CID multimedia
DEF multimedia
DEVICETOPIC wz_multimedia
FUUID 601a99e5-f33f-774e-ef03-16e6630fea1dc17b
IODev MQTT2_CLIENT
LASTInputDev MQTT2_CLIENT
MQTT2_CLIENT_MSGCNT 1786
MQTT2_CLIENT_TIME 2022-02-01 21:40:23
MSGCNT 1786
NAME wz_multimedia
NR 443
STATE aktuell: 83.0 W Tag: 0.57 kWh Gestern: 0.462 kWh Gesamt: 555.1150 kWh
TYPE MQTT2_DEVICE
Helper:
DBLOG:
ENERGY_Power:
DBLogging:
TIME 1643748023.97306
VALUE 83
ENERGY_Total:
DBLogging:
TIME 1643748023.97306
VALUE 555.115
JSONMAP:
Channel_0 0
Channel_1 0
Channel_2 0
Channel_3 0
Channel_4 0
Color 0
Dimmer 0
HSBColor 0
POWER1 0
POWER2 0
POWER3 0
POWER4 0
READINGS:
2022-02-01 21:40:23 ENERGY_ApparentPower 109
2022-02-01 21:40:23 ENERGY_Current 0.463
2022-02-01 21:40:23 ENERGY_Factor 0.76
2022-02-01 21:40:23 ENERGY_Period 7
2022-02-01 21:40:23 ENERGY_Power 83
2022-02-01 21:40:23 ENERGY_ReactivePower 71
2022-02-01 21:40:23 ENERGY_Today 0.569
2022-02-01 21:40:23 ENERGY_Total 555.115
2022-02-01 21:40:23 ENERGY_TotalStartTime 2019-01-31T22:34:26
2022-02-01 21:40:23 ENERGY_Voltage 236
2022-02-01 21:40:23 ENERGY_Yesterday 0.462
2022-02-01 21:40:23 Heap 15
2022-01-29 22:22:18 IODev MQTT2_CLIENT
2022-01-31 11:53:03 LWT Online
2022-02-01 21:40:23 LoadAvg 19
2022-02-01 21:40:23 Sleep 50
2022-02-01 21:40:23 SleepMode Dynamic
2022-02-01 21:40:23 Time 2022-02-01T21:40:23
2022-02-01 21:40:23 Uptime 335T01:54:34
2022-02-01 21:40:23 Wifi_AP 1
2022-02-01 21:40:23 Wifi_BSSId 74:AC:B9:94:0E:85
2022-02-01 21:40:23 Wifi_Channel 11
2022-02-01 21:40:23 Wifi_Downtime 0T00:03:32
2022-02-01 21:40:23 Wifi_LinkCount 15
2022-02-01 21:40:23 Wifi_RSSI 74
2022-02-01 21:40:23 Wifi_SSId Julie
2022-02-01 15:23:52 state on
Attributes:
DbLogExclude .*
DbLogInclude ENERGY_Power,ENERGY_Total
IODev MQTT2_CLIENT
alias Multimedia (WZ)
autocreate 0
comment NOTE: For on-for-timer SetExtensions are used. You may add on-for-timer option running on the device. The following is limited to 1h max duration, but will not affect future simple "on" commands:
on-for-timer {my $duration = $EVTPART1*10; 'cmnd/tasmota/SZ/multimedia/cmnd/Backlog POWER1 1; delay '.$duration.'; POWER1 0'}
See the "Praxisbeispiele" in the wiki for "pulseTime1" alternative option and it's restrictions.
devStateIcon {my $text = ' uptime: '.ReadingsVal($name,"Uptime","unknown").sprintf(" aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1")); my $onl = ReadingsVal($name,"LWT","false") eq "Online"?"10px-kreis-gruen":"10px-kreis-rot"; my $light = ReadingsVal($name,"state","off");"
".FW_makeImage($onl).' '.FW_makeImage($light)."$text"}
event-on-change-reading .*
genericDeviceType outlet
homebridgeMapping clear
On=state,cmdOn=on,cmdOff=off,valueOn=on
E863F10A-079E-48FF-8F27-9C2605A29F52=ENERGY_Voltage,name=Voltage,format=FLOAT
E863F126-079E-48FF-8F27-9C2605A29F52=ENERGY_Current,name=Current,format=FLOAT
E863F10D-079E-48FF-8F27-9C2605A29F52=ENERGY_Power,name=Power,format=FLOAT
E863F10C-079E-48FF-8F27-9C2605A29F52=ENERGY_Total,name=Energy,format=FLOAT
history:size=1024,type=energy
icon hue_filled_outlet
jsonMap POWER1:0 POWER2:0 POWER3:0 POWER4:0 Dimmer:0 Channel_0:0 Channel_1:0 Channel_2:0 Channel_3:0 Channel_4:0 HSBColor:0 Color:0
model tasmota_POW
readingList tasmota/WZ/multimedia/tele/LWT:.* LWT
tasmota/WZ/multimedia/tele/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }
tasmota/WZ/multimedia/tele/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }
tasmota/WZ/multimedia/tele/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }
tasmota/WZ/multimedia/tele/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }
tasmota/WZ/multimedia/stat/POWER1:.* state
tasmota/WZ/multimedia/stat/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
room System->Homekit,System->MQTT2-NEU,Wohnzimmer
setList off:noArg tasmota/WZ/multimedia/cmnd/POWER1 0
on:noArg tasmota/WZ/multimedia/cmnd/POWER1 1
toggle:noArg tasmota/WZ/multimedia/cmnd/POWER1 2
setStateList on off toggle
stateFormat {sprintf("aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"))}
webCmd :
HUE:
Internals:
DEF 11 IODev=deCONZ
FUUID 5e0f743f-f33f-774e-b7df-6dcfa25e49b43353
FVERSION 31_HUEDevice.pm:0.255380/2022-01-21
ID 11
INTERVAL
IODev deCONZ
NAME HUEDevice11
NR 333
STATE off
TYPE HUEDevice
desired 0
lastannounced 2022-02-01T18:58:22Z
manufacturername IKEA of Sweden
modelid TRADFRI bulb E14 W op/ch 400lm
name Dimmable light 11
swversion 1.2.214
type Dimmable light
uniqueid 08:6b:d7:ff:fe:81:eb:d8-01
Helper:
DBLOG:
ENERGY_Total:
DBLogging:
TIME 1643743632.92785
VALUE 0.002
READINGS:
2022-02-01 21:33:44 ENERGY_Power 0
2022-02-01 21:41:38 ENERGY_Total 0.004
2022-01-29 22:22:17 IODev deCONZ
2022-01-29 22:22:27 alert none
2022-02-01 21:26:26 bri 254
2022-02-01 21:41:38 lastseen 2022-02-01T20:40Z
2022-02-01 21:33:44 onoff 0
2022-02-01 21:33:44 pM_energy 3.70757407407407
2022-02-01 20:03:07 pM_energy_begin 1643742187.14483
2022-02-01 21:33:44 pct 0
2022-02-01 20:42:25 reachable 1
2022-02-01 21:33:44 state off
helper:
alert none
battery -1
bri 254
colormode
ct -1
devtype
effect
hue -1
lastseen
mode
on 0
pct 0
reachable 1
rgb
sat -1
update_timeout -1
xy
json:
etag 548ab3ef276e18eb75e8799177c4e37f
lastannounced 2022-02-01T18:58:22Z
lastseen 2022-02-01T20:40Z
manufacturername IKEA of Sweden
modelid TRADFRI bulb E14 W op/ch 400lm
name Dimmable light 11
swversion 1.2.214
type Dimmable light
uniqueid 08:6b:d7:ff:fe:81:eb:d8-01
state:
alert none
bri 254
powerMap:
map:
pct:
0 0
10 1
100 5
20 1
30 1
40 1
50 1
60 1
70 2
80 2
90 4
state:
* pct
unreachable 0
map.module:
pct:
0 0
10 1
100 5
20 1
30 1
40 1
50 1
60 1
70 2
80 2
90 4
state:
* pct
unreachable 0
readingsDesc:
ENERGY_Power:
rtype w
pM_energy:
rtype whr
Attributes:
DbLogExclude .*
DbLogInclude ENERGY_Power,ENERGY_Total
IODev deCONZ
alexaName Stehlampe
alias Stehlampe Anton
color-icons 2
devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
event-on-change-reading .*
genericDeviceType light
group Licht
model TRADFRI bulb E14 W op/ch 400lm
powerMap 'pct' => {
'0' => 0,
'10' => 1.0,
'20' => 1.0,
'30' => 1.0,
'40' => 1.0,
'50' => 1.0,
'60' => 1.0,
'70' => 2.0,
'80' => 2.0,
'90' => 4.0,
'100' => 5.0,
},
'state' => {
'unreachable' => 0,
'*' => 'pct',
},
powerMap_rname_P ENERGY_Power
room Kinderzimmer,System->Homekit,System->Zigbee
subType dimmer
userReadings ENERGY_Total {sprintf("%.3f",ReadingsVal($name,"pM_energy",0)/1000)}
webCmd pct:toggle:on:off
Ich komme nach stundenlangem Probieren einfach nicht auf die Lösung :(
Evtl. ein Zahlenproblem?
Im Voraus vielen Dank!
ZitatProblem: Das reagiert nur auf das MQTT Device mit der echten Messung. Das HUEDevice mit dem hinterlegten PowerMap löst nicht aus.
powerMap erzeugt in dem Event-Handler einen weiteren Event.
Um eine Endlos-Rekursion zu vermeiden, wird die Abarbeitung nicht erneut von vorne angestossen, stattdessen wird dieses Event an das aktuelle "Event-Paket" angehaengt, und der Rest der Notify-Kette abgearbeitet. Wenn das notfy vorher dran war, dann sieht es das powerMap Event nicht.
Da der Event-Monitor ganz hinten in der Reihenfolge ist, sind da beide Events (der Ausloesende und der vom powerMap) sichtbar.
Die Loesung ist das notify hinter powermap zu stecken.
Da beide Module keine Vorkehrungen unternommen haben, die Abarbeitungsreihenfolge zu aendern, entscheidet der Name vom powermap und notify ueber die Reihenfolge.
Danke schonmal.
Vielleicht habe ich mich falsch ausgedrückt oder ich verstehe die Antwort nicht richtig.
Das MQTT Device hat die Strommessung integriert und löst das Notify aus (Kein Powermap).
Das HUEDevice hat die Strommessung nicht integriert und bekommt die Watt-Zahl über Powermap.
Zitat von: andy19850 am 01 Februar 2022, 22:48:53
[...] oder ich verstehe die Antwort nicht richtig.
Wenn du die Namen der beiden Devices (powerMap und notify) gezeigt hättest, wäre es ggf. klarer...
@Rudi: Das steht lt. MAINTAINER noch auf igami, ist also orphan. Übernehmen möchte ich es nicht, kann aber anbieten, die commandref einigermaßen zeitnah auf "id"-Standard zu überarbeiten (und die globalen Attribute als zu powerMap gehörig zu kennzeichnen).
Stellt sich die Frage, ob man den notify-Prefix (konfigurierbar?) ändern sollte, damit sowas nicht mehr passiert? (wenn für dich ok, würde ich stellvertretend direkt die Änderungen ins svn schubsen).
Zitatkann aber anbieten, die commandref einigermaßen zeitnah auf "id"-Standard zu überarbeiten (und die globalen Attribute als zu powerMap gehörig zu kennzeichnen).
Ich nehme Hilfe gerne an :)
ZitatStellt sich die Frage, ob man den notify-Prefix (konfigurierbar?) ändern sollte, damit sowas nicht mehr passiert?
Ich sehe hier noch nicht die Notwendigkeit eines weteren Attributes.
Einfaches Umbenennen der Beteiligten duerfte das Problem loesen.
Zitat von: rudolfkoenig am 02 Februar 2022, 09:18:47
Ich nehme Hilfe gerne an :)
OK, werde mich kümmern.
Zitat
Ich sehe hier noch nicht die Notwendigkeit eines weteren Attributes.
Die Attribut-Idee habe ich gedanklich auch bereits verworfen.
Es stellt sich eher die Frage, ob es nicht (bei diesem Modul) sinnvoll ist, das NotifyOrderPrefix (z.B. auf 30) zu setzen. Es geht da nach meinem Verständnis um was ähnliches wie bei readingsChange und userReadings: es soll ein (künstliches) zusätzliches Reading (bzw. mehrere?) erzeugt werden.
Zitat
Einfaches Umbenennen der Beteiligten duerfte das Problem loesen.
Sehe ich zwar auch so, aber das wird vermutlich sonst (ohne das Internal) ein support-Dauerbrenner, weil diese Abhängigkeiten sich üblicherweise Usern nicht erschließen (hier war dein Hinweis ja auch nicht ausreichend).
Würde daher lieber den Präfix setzen und den einmaligen support-Aufwand ertragen, der eventuell (!) bei dem doch eher überschaubaren Userkreis entstehen kann...
ZitatIch sehe hier noch nicht die Notwendigkeit eines weteren Attributes.
Einfaches Umbenennen der Beteiligten duerfte das Problem loesen.
Wenn das Sachdienlich ist, mache ich das gerne. Ich frage mich nur wie...?
Notify: n_stromleistung
HUEDevice: HUEDevice11 (funktioniert nicht)
Sonoff: ESPEasy_sonoff_02 (funkioniert nicht)
MQTT-Device(s): wz_multimedia / MQTT2_PK_Deckenspots_CH2 / ku_kaffeemaschine (funkionieren alle)
Das Notify habe ich schon mit "1_" und "w_" getestet, das hat nichts verändert.
Zitat von: andy19850 am 02 Februar 2022, 09:50:13
Wenn das Sachdienlich ist, mache ich das gerne. Ich frage mich nur wie...?
qed.
Wie heißt dein powerMap-Device? Und wie wird die Leistung im "ESPEasy_sonoff_02" erzeugt? Direkt oder via powerMap..?
ZitatWürde daher lieber den Präfix setzen und den einmaligen support-Aufwand ertragen, der eventuell (!) bei dem doch eher überschaubaren Userkreis entstehen kann...
Ok, ich sehe das Problem jetzt auch langsam :)
Zitat von: rudolfkoenig am 02 Februar 2022, 09:56:33
Ok, ich sehe das Problem jetzt auch langsam :)
Ich bau' was ein und erläutere in der commandref (kurz), wie man das Modul zu nutzen hat...
30?
ZitatWie heißt dein powerMap-Device? Und wie wird die Leistung im "ESPEasy_sonoff_02" erzeugt? Direkt oder via powerMap..?
Habe mir richtig was einfallen lassen und es "powerMap" genannt :)
ESPEasy_sonoff_02: via powerMap. Nur die MQTT-Devices erzeugen selbst das Reading
...gib mal "list .*" ein und schau, in welcher Reihenfolge die kommen...
Anbei die komplette Moduldatei - du kannst die ja mal (mit den passenden Rechten!) in das Modulverzeichnis kopieren und schauen, ob dein Problem damit (nach einem FHEM-Neustart) der Vergangenheit angehört ;) .
@Rudi: auch als patch (einschl. MAINTAINER auf dich/orphan) gewünscht, oder reicht das so?
PS: Der code gefällt mir nicht so wirklich (die Idee dahinter schon), und den link für/auf "do_not_notify" habe ich mal "pro forma" gesetzt, das Ziel (und dessen Verbreitung in der allgemeinen join-commandref) ist "bemerkenswert".
MEGA!
Ja, das Problem gehört damit der Vergangenheit an. Vielen Dank!
Danke für die Rückmeldung.
@Rudi: Bzgl. der Präfix-Diskussion gab es wohl schon mal unter den damaligen Beteiligten eine Diskussion:
https://forum.fhem.de/index.php/topic,63016.msg550975.html#msg550975
Habe aber nicht wirklich versucht zu verstehen, was das damalige Problem eigentlich war - kann sein, dass da dummy-Wert-Geschubse im Spiel war, und da bin ich dann eh' gedanklich raus...
Zitat@Rudi: auch als patch (einschl. MAINTAINER auf dich/orphan) gewünscht, oder reicht das so?
Das reicht vollkommen, habs eingecheckt. Was meinst Du mit MAINTAINER?
Zitat[...] den link für/auf "do_not_notify" habe ich mal "pro forma" gesetzt, das Ziel (und dessen Verbreitung in der allgemeinen join-commandref) ist "bemerkenswert".
Dieses Attribut habe ich komplett verdraengt, das Ding stammt aus 2009...
Keine Ahnung, welches Problem es urspruenglich loesen sollte.
An dieser Stelle möchte ich mal ausdrücklich ein Lob für die FHEM-Community (in dem Falle, euch) aussprechen!
Ich bin seit ca. 6 Jahren User und mittlerweile sind ja andere Systeme auch empor gekommen. Natürlich liebäugelt man mal mit was Anderem, weil schickere Oberfläche usw.
Schlussendlich geht's um Automatisierung, um ein Backend das alles mit kleinen Ressourcen regelt und dafür ist es stabil und perfekt. Frontends kann man ohne weiteres dran pappen, je nach Wunsch. Muss man bei richtiger Programmierung aber gar nicht.
Was hier kurzfristig und vor allem ohne Premium-Services geleistet wird: Unfassbar gut. Ich melde mich relativ wenig mit Fragen weil ich den Anspruch habe, die Sachen selbst zu erarbeiten. Hier kam ich jetzt aber nicht mehr weiter und wurde innerhalb kürzester Zeit mit einem wohl nicht genutzten Modul perfekt versorgt. Einfach gut!
Kleine Lobhuldigung meinerseits, möchte ich aber in der Sache nicht unerwähnt lassen.
Zitat von: andy19850 am 02 Februar 2022, 21:05:17
An dieser Stelle möchte ich mal ausdrücklich ein Lob für die FHEM-Community (in dem Falle, euch) aussprechen!
:) Danke!
Zitat von: rudolfkoenig am 02 Februar 2022, 19:18:49
Das reicht vollkommen, habs eingecheckt. Was meinst Du mit MAINTAINER?
:o Ähm, sorry, hatte offenbar in eine alte Version der MAINTAINER.txt geschaut, hat sich erledigt..
Zitat
Dieses Attribut habe ich komplett verdraengt, das Ding stammt aus 2009...
Keine Ahnung, welches Problem es urspruenglich loesen sollte.
Na ja, wie dem auch sei, es scheint sowas ähnliches wie ein generisches Interface-Attribut zu sein, das u.A. auch bei CUL vorkommt, das (zumindest zwischenzeitlich) wohl eine deutlich größere Verbreitung hat wie FHZ.
Jedenfalls passt jetzt der Link in powerMap, aber (vielleicht, weil es kein "id"-Verweis ist?) die Beschreibung wird nicht unmittelbar unter dem Attribut angezeigt.
Weiß nicht, ob das hilft, aber ggf. könnte man die Beschreibung samt "general-id" nach CUL verschieben und nur den Link in FHZ lassen?
(Hab's versucht, aber vermutlich irgendwas falsch gemacht...)