Hallo,
die Datenbelieferung ist äußerst schleppend.
Beispiel: Heute Nacht finde ich unter den Readings um 00:11:42 die letzten. Das ist beileibe kein Einzelfall.
Im Log erscheint
powerfox: Read callback: Error: read from https://backend.powerfox.energy:443 timed outWeiterhin sind unter "STATE" 3x Fragezeichen angegeben.
Hier das list des Device:
Internals:
BUSY 0
DEF https://xxx%40xxx.xxx:xxxx%zzzzzz@backend.powerfox.energy/api/2.0/my/yyyyyyyyyyyy/current 300
FUUID 6077fe25-f33f-aab4-b615-c1ae47baa9c89b0e
Interval 300
MainURL https://xxx%40xxx.xxx:xxxx%zzzzzz@backend.powerfox.energy/api/2.0/my/yyyyyyyyyyyy/current
ModuleVersion 4.1.15 - 17.12.2022
NAME powerfox
NOTIFYDEV global
NR 1689
NTFY_ORDER 50-powerfox
STATE ???
TYPE HTTPMOD
value
HttpUtils:
NAME
addr https://backend.powerfox.energy:443
auth 1
buf
data
displayurl https://xxx%40xxx.xxx:xxxx%zzzzzz@backend.powerfox.energy/api/2.0/my/yyyyyyyyyyyy/current
header
host backend.powerfox.energy
httpversion 1.0
ignoreredirects 1
loglevel 4
path /api/2.0/my/yyyyyyyyyyyy/current
protocol https
pwd aaaaaaaaa
redirects 0
timeout 2
url https://xxx%40xxx.xxx:xxxx%zzzzzz@backend.powerfox.energy/api/2.0/my/yyyyyyyyyyyy/current
user xxx%40xxx.xxx:xxxx%zzz
sslargs:
QUEUE:
READINGS:
2023-03-27 00:11:42 power 397
2023-03-27 00:11:42 total_consumption 7223100
2023-03-27 00:11:42 total_feed 562372
REQUEST:
context reading
data
header
ignoreredirects 0
num unknown
retryCount 0
type update
url https://xxx%40xxx.xxx:xxxx%zzzzzz@backend.powerfox.energy/api/2.0/my/yyyyyyyyyyyy/current
Attributes:
alias powerfox
reading01JSON Watt
reading01Name power
reading02JSON A_Plus
reading02Name total_consumption
reading03JSON A_Minus
reading03Name total_feed
room Keller,PV-Anlage
verbose 3
Hat sich irgendetwas an der API geändert, die App ist stets aktuell, im ioBroker stammen die Daten vom 22.3.2023?
Diese Log Einträge habe ich auch sehr, sehr oft. :(
Heute war um 10.33 Uhr Schluss.
Hier mein List:
Internals:
BUSY 0
DEF https://XXX%40XXX:ZZZ@backend.powerfox.energy/api/2.0/my/YYY/current 300
FUUID 605b5ffc-f33f-95bd-877a-95e7437f1a0734a0
FVERSION 98_HTTPMOD.pm:0.270650/2023-01-15
Interval 300
MainURL https://XXX%40XXX:ZZZ@backend.powerfox.energy/api/2.0/my/YYY/current
ModuleVersion 4.1.15 - 17.12.2022
NAME powerfox
NOTIFYDEV global
NR 451
NTFY_ORDER 50-powerfox
STATE Stromverbrauch:
23834.5 kWH
Hour: 0.0 Day: 2.3 Month: 154.0 Year: 613.2
Einspeisung:
81182.4 kWh
Hour: 0.0 Day: 13.0 Month: 431.9 Year: 1035.5
TYPE HTTPMOD
eventCount 4712
value
HttpUtils:
NAME
addr https://backend.powerfox.energy:443
auth 1
buf
data
displayurl https://XXX%40XXX:ZZZ@backend.powerfox.energy/api/2.0/my/YYY/current
header
host backend.powerfox.energy
httpversion 1.0
ignoreredirects 1
loglevel 4
path /api/2.0/my/YYY/current
protocol https
pwd ZZZ
redirects 0
timeout 2
url https://XXX%40XXX:ZZZ@backend.powerfox.energy/api/2.0/my/YYY/current
user XXX
sslargs:
QUEUE:
READINGS:
2023-03-28 17:04:11 Input 23834.5
2023-03-28 17:04:11 Output 81182.4
2023-03-28 10:33:01 power -4473
2023-03-28 17:04:11 statInput Hour: 0.0 Day: 2.3 Month: 154.0 Year: 613.2
2023-03-28 17:04:11 statInputDay 2.3
2023-03-27 23:59:55 statInputDayLast 5.5
2023-03-28 17:04:11 statInputHour 0.0
2023-03-28 16:59:55 statInputHourLast 0.0
2023-03-28 16:59:55 statInputLast Hour: 0.0 Day: 5.5 Month: 185.4 Year: 291.4 (since: 2022-11-28 )
2023-03-28 17:04:11 statInputMonth 154.0
2023-02-28 23:59:55 statInputMonthLast 185.4
2023-03-28 17:04:11 statInputYear 613.2
2022-12-31 23:59:55 statInputYearLast 291.4
2023-03-28 17:04:11 statOutput Hour: 0.0 Day: 13.0 Month: 431.9 Year: 1035.5
2023-03-28 17:04:11 statOutputDay 13.0
2023-03-27 23:59:55 statOutputDayLast 27.6
2023-03-28 17:04:11 statOutputHour 0.0
2023-03-28 16:59:55 statOutputHourLast 0.0
2023-03-28 16:59:55 statOutputLast Hour: 0.0 Day: 27.6 Month: 489.4 Year: 136.6 (since: 2022-11-28 )
2023-03-28 17:04:11 statOutputMonth 431.9
2023-02-28 23:59:55 statOutputMonthLast 489.4
2023-03-28 17:04:11 statOutputYear 1035.5
2022-12-31 23:59:55 statOutputYearLast 136.6
2023-03-28 17:04:11 statPowerDay Min: -7197 Avg: -2312 Max: 2417
2023-03-27 23:59:55 statPowerDayLast Min: -8658 Avg: -1474 Max: 1961
2023-03-28 17:04:11 statPowerMonth Min: -9160 Avg: -473 Max: 3845
2023-02-28 23:59:55 statPowerMonthLast Min: -9109 Avg: -453 Max: 4829
2023-03-28 17:04:11 statPowerYear Min: -9160 Avg: -225 Max: 5027
2022-12-31 23:59:55 statPowerYearLast Min: -5819 Avg: 228 Max: 6403 (since: 2022-10-15_14:37:59 )
2023-03-28 10:33:01 total_consumption 23834522
2023-03-28 10:33:01 total_feed 81182425
REQUEST:
context reading
data
header
ignoreredirects 0
num unknown
retryCount 0
type update
url https://XXX%40XXX:ZZZ@backend.powerfox.energy/api/2.0/my/YYY/current
defptr:
readingBase:
power reading
total_consumption reading
total_feed reading
readingNum:
power 01
total_consumption 02
total_feed 03
readingOutdated:
requestReadings:
update:
power reading 01
total_consumption reading 02
total_feed reading 03
helper:
_98_statistics StromStatistik
Attributes:
reading01JSON Watt
reading01Name power
reading02JSON A_Plus
reading02Name total_consumption
reading03JSON A_Minus
reading03Name total_feed
room Haus
stateFormat Stromverbrauch:
Input kWH
statInput
Einspeisung:
Output kWh
statOutput
userReadings Input { sprintf("%.1f",ReadingsNum("powerfox","total_consumption",0)/1000.0);}, Output { sprintf("%.1f",ReadingsNum("powerfox","total_feed",0)/1000.0);}
Irgendwie bekommen die das nicht richtig gebacken.
Ich glaube, ich bin einen Schritt weiter und habe einen Erkenntnisgewinn:
Powerfox liefert (etwa 1x wöchentlich) keine Daten mehr, so dass ich das device neu starten muss
set powerfox stop.
Wenn ich das Device nach ein paar Minuten mit
set powerfox start wieder starte, kommen aktuelle Werte.
Da ich das nicht immer wieder händisch machen will, wäre eine Abfrage des Timestamps des letzten Readings und ein Vergleich mit dem Systemdatum sinnvoll. Bei einem Unterschied von ca. 1h wären dann die bereits genannten Befehle, mit einem sleep von z.B. 300 Sekunden dazwischen auszuführen - soweit die Theorie!
Ansich müsste das ja mit
readingsage zu machen sein. Das wäre dann mit dem aktuellen Systemdatum zu vergleichen ... weiter, siehe oben.
Allein, ich weiß nicht, wie ich das in ein notify einzubauen ist?
Müsste ja so etwa gehen mit
define powerfoxNEUSTART notify (wenn (aktuelle Zeit) minus (readingsage(powerfox)) > 3600 dann (set powerfox stop;sleep 300;set powerfox start)M.W. liefert liefert readingsage ja Sekunden!
Kann mir jemand bei der korrekten Syntax helfen?
Möglich wäre vielleicht auch ein userreadings anzulegen
attr powerfox userReadings Dauer {ReadingsAge("powerfox","power",121)}Das userreading wird offenbar aber immer nur erstellt, wenn irgend ein Reading (auch eines anderen Device?) aktualisiert wird. Anscheinend werden aber immer alle zeitgleich aktualisiert, daher gibt ReadingsAge eine 0 zurück und deswegen wird dem Vernehmen nach das userreadings nicht angelegt.
Auflösung:
Am Ende führte dann doch der Ansatz über 'readingsage' als userreadings zum Ziel.
Das userreadings wird in Sekunden ausgegeben und kann somit gut in einem notify abgearbeitet werden.
Nun komme ich mit der Abfrage von 'Readingsage' doch nicht weiter:
Das userreadings habe ich 'Readingsalter' genannt und möchte je nach "Alter" eine Aktion auslösen, es will aber nicht klappen!
define powerfoxZ2NEUSTART at +00:02:00 {if (Value("powerfox_Z2:Readingsalter") > 150) {fhem ("set powerfox_Z2 stop;;sleep 300;;set powerfox_Z2 start")}}Nachdem ich die Definition in die Eingabezeile eingegeben habe, kann ich sie unter "Everything" zwar sehen, nach dem Auslösen der Aktion verschwindet sie wieder.
Ist die Abfrage falsch - mit
at +00:02:00 müsste doch immer wieder alle 2 Minuten das Readingsalter abgefragt werden?
+00:02 bedeutet einmal in zwei Minuten was ausfuehren.
Damit es _alle_ 2 Minuten ausgefuehrt wird, muss es +*00:02 heissen.
Value("powerfox_Z2:Readingsalter") ist sicher falsch, vermutlich sollte es ReadingsNum("powerfox_Z2", "Readingsalter", 0) heissen.
Den Alter eines Readings per userreadings zu speichern ist aber an sich schon falsch, da userreadings nur beim Aenderung eines Readings im gleichen Geraet evaluiert werden, damit ist dieser Wert schlimmstenfalls immer 0.
Stattdessen wuerde ich im at direkt mit ReadingsAge operieren.
Oh je, wie konnte mir dieses Basic mit '*' nur durchgehen!?
Im 2. Punkt zum Readingsage muss ich allerdings widersprechen: Mit
attr powerfox_Z2 userReadings Readingsalter {ReadingsAge("powerfox_Z2","power",121)} bekomme ich einen Readingsalterwert >0!
Testweise habe ich ein Mail bei Readingsalter > 150 ausgelöst, das klappt wunderbar.
define MailReadingsalterZ2 at +*00:02 { if (ReadingsNum("powerfox_Z2","Readingsalter",0) > 150) {DebianMail('xxx@yyyyy.com','Readingsalter Powerfox Z2','Das Readingalter Z2 liegt länger als 2,5 Minuten hinter der Systemzeit, der Neustart müsste eingeleitet worden sein!')}}Soll FHEM jedoch eine Aktion (Stop/Start) des Device auslösen, will das nicht funktionieren:
define powerfoxZ2NEUSTART at +*00:02 {if (ReadingsNum("powerfox_Z2","Readingsalter",0) > 150) {fhem ("set powerfox_Z2 stop;;sleep 300;;set powerfox_Z2 start")}}Was übersehe ich denn hier wieder?
Im EventMonitor finde ich folgende Einträge
2023-08-26 15:14:09.619 HTTPMOD powerfox_Z2 stop
2023-08-26 15:14:09.647 at powerfoxZ2NEUSTART Next: 15:16:09
2023-08-26 15:15:09.651 HTTPMOD powerfox_Z2 start
2023-08-26 15:15:11.816 HTTPMOD powerfox_Z2 Readingsalter: 1077
Die Befehle (Stop/Start) händisch ausgeführt, führen zu einem Deviceneustart!?
Zitat von: rudolfkoenig am 26 August 2023, 12:36:27Stattdessen wuerde ich im at direkt mit ReadingsAge operieren.
Nun habe ich es einmal wie empfohlen mit
define powerfoxZ2NEUSTART at +*00:05 { if (ReadingsAge("powerfox_Z2","power",0) >= 600) {fhem ("set powerfox_Z2 stop;;sleep 60;;set powerfox_Z2 start;;sleep 60;;set powerfox_Z2 stop;;sleep 60;;set powerfox_Z2 start")}}Das Device will wirklich nicht automatisch starten. Wer hat eine Idee, warum das nicht klappt.
Nach längerem Wirktest hier das Fazit:
Powerfox startet nun doch zuverlässig und erfüllt die gewünschten Dienste in dem die Daten regelmäßig geliefert werden!