[gelöst] Wie genau ist Sonoff POW?

Begonnen von andies, 15 August 2017, 14:13:45

Vorheriges Thema - Nächstes Thema

andies

Ich habe folgende "Schaltung":

Steckdose => DECT 200 ==> Sonoff POW ==> Entkalker

und beide Geräte messen die Last, die der Entkalker hat. Da der Sonoff im DECT steckt, muss ja wohl für die Last folgendes gelten:

Last DECT = Last Sonoff + Last Entkalker

und insbesondere Last(DECT)>Last(Sonoff). Das ist aber nicht der Fall, wie die beiden Grafiken im Anhang zeigen (einmal Last DECT, einmal Last POW und zwar vom POW selbst sowie berechnet als Produkt Current*Voltage*Factor). Also misst der POW nicht so genau. Das ist schon bekannt (muss man halt kalibrieren), aber die Schwankungen kann ich so nicht erklären. Ich nehme an, dass der POW wesentlich ungenauer ist.
FHEM 6.1 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

#1
Ich habe nochmal gemessen. Vorab habe ich Leistung (3W, weil das DECT1 sagt), Spannung (gemessen mit digitalem Voltmeter) und Strom (errechnet durch Leistung:Spannung) kalibriert. Das Ergebnis überzeugt nach einem 12h-Test immer noch nicht. Im Bild unten ist DECT und Sonoff zu sehen. Mehrere Fehler:

  • Nach dem Energieerhaltungssatz muss Leistung(DECT)>Leistung(Sonoff) sein und in mindestens einem Punkt ist der nicht der Fall.
  • Die DECT-Leistungsmessung ist konstant, Sonoff schwankt (zu stark).
  • Die Die angebliche Null-last bei Sonoff ist in meinen Augen ein klarer Fehler.
Ich wollte Sonoff verwenden, um bei meinem Entkalker die "Auslösung" zu erkennen. Dabei steigt die Last von 3.4W auf etwa 6-7W an. Das kann ich mit Sonoff leider nicht tun, Sonoff ist dazu einfach zu ungenau. Schade.

PS Ich habe mal ein issue eröffnet, mal sehen, ob man da was machen kann: https://github.com/arendst/Sonoff-Tasmota/issues/749
FHEM 6.1 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

Theo sagt, das geht nicht genauer. Hat jemand von Euch mal nachgemessen? Die Fehlerhöhe (relativ gesehen, nicht absolut) irritiert mich schon.


Gesendet von iPhone mit Tapatalk Pro
FHEM 6.1 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Reinhart

Das Problem ist die Methode der Erfassung und der daraus resultierenden Ungenauigkeit bei sehr kleinen Leistungen, siehe dazu den Schaltplan auf Seite 3.

Wenn man nicht mehr als 100 Watt maximale Leistung erwartet, könnte man den Shunt von 0,001 Ohm etwas vergrößern. Die Spannungsdifferenz zwischen L und L0 ist ja der entscheidende Messwert für den Frequenzwandler HLW8012. Dafür sinkt aber die maximale Leistung die angehängt werden kann.


Um im Bereich von 230V Eingriffe am Device vorzunehmen, möchte ich keine genauen Angaben für die Vorgehensweise hier posten, da die Gefahr besteht das es von ungeschulten Personen dann durchgeführt wird. Außerdem müsste der POW dann auch neu kalibriert werden, daher das Ganze nur theoretisch betrachtet.

Mach dein Vorhaben lieber mit einem HM Modul, das funktioniert vermutlich auch bei deinen kleinen Leistungen sehr gut.


LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

andies

Ich fasse das auf keinen Fall intern an, dazu habe ich viel zu großen Respekt vor 230V. Ich hatte nur was anderes erwartet. Hast Du einen Link zu einem HM-Modul, das solche geringen Wattzahlen schafft? Dect 200 war mir eigentlich zu teuer...


Gesendet von iPhone mit Tapatalk Pro
FHEM 6.1 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Reinhart

ja, das ist der Homematic 130248 Schaltaktor mit Leistungsmessung.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Reinhart

Heute hat Theo einige Korrekturen betreffend Pow und Genauigkeit vorgenommen!

Add more precision to Sonoff Pow period and power results using command WattRes 0|1 (#759)

Das ist ab der Version 5.6.1c enthalten. Man kann jetzt mit EnergyRes die Genauigkeit von 0 - 5 einstellen. Wie sich das genau auswirkt kann ich auch nicht sagen, bin noch beim testen mit der Waschmaschine da hier die "fertig" Erkennung bei kleinen Leistungen eher schwierig war.

LG
Reinhart
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

andies

Also die Bilder sehen schon besser aus, die Schwankungen sind in der Tat geringer. Es bleiben unlogische Nullwerte und Zahlen, die höher sind als die (DECT 200-)Messstation dahinter, was nicht geht. Ich beobachte das mal eine Weile und schaue, ob ich damit im Bereich 3-5W was anfangen kann.
FHEM 6.1 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

JoWiemann

Zitat von: andies am 21 August 2017, 09:39:38
Also die Bilder sehen schon besser aus, die Schwankungen sind in der Tat geringer. Es bleiben unlogische Nullwerte und Zahlen, die höher sind als die (DECT 200-)Messstation dahinter, was nicht geht. Ich beobachte das mal eine Weile und schaue, ob ich damit im Bereich 3-5W was anfangen kann.

Du bekommst ja über Theos Software Roh-Werte. Beim DECT200 kann es durchaus sein, dass hier die Firmware eine Glättung und/oder eine Filterung der Daten vornimmt. Ich würde hier versuchen über die Messperiode einen Filter zu legen, der Ausreißer eleminiert und grundsätzlich eine Glättung vornimmt.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

andies

Bis eben war ich noch angetan, aber die beiden Bilder sagen leider alles. Der Sonoff hängt hinter DECT. Das kriege ich mit Software nicht raus...
FHEM 6.1 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

JoWiemann

Es könnte noch eine Frage der Auflösung sein. In welchen Zeitabständen kommen die Daten vom Sonoff und vom DECT? Ggf. erwischt Du ja beim Sonoff immer mal wieder einen Zeitpunkt, wo die Firmware tatsächlich noch keinen Wert hat, weil es eine Asynchronität gibt. Müsste man mal mit Theo diskutieren.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Reinhart

@andies

also die Version vom 20.08 funktionierte noch nicht weil hier in der xsns_hlw8012 die Änderungen aus mir unbekannten Gründen noch nicht eingebaut waren (Zipfile), im Git jedoch schon. Aber in der heute erschienenen 5.6.1d ist alles eingebaut und die schaut jetzt bei mir bei kleinen Leistungen auch gut aus. Mehr kann ich erst nach einer Woche sagen ob das auch über Tage hinweg so bleibt.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

andies

Ich habe schon Veränderungen gesehen, aber für eine exakte Messung (ich muss einen aufwuchs von 3W auf 6W messen) reichte das nicht aus. Ich meine aber, dass ich die Änderung schon hatte. Werde das zu Hause nochmal flashen, Danke. Berichte mal, wenn Du Werte hast!


Gesendet von iPhone mit Tapatalk Pro
FHEM 6.1 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

(Also nicht zipfile, sondern github - bin aber unsicher)


Gesendet von iPhone mit Tapatalk Pro
FHEM 6.1 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Reinhart

#14
ich bin jetzt für mich zufrieden, allerdings werte ich bei der Waschmaschine Endeerkennung nun die "Period" aus, also den Verbrauch in Wh zwischen 2 Messungen. Hier muss ich allerdings schon im 1/10 Bereich auflösen (WattRes = 1)  , weil das sonst nicht zu sehen ist.

2017-08-26_10:17:23 4.9
2017-08-26_10:19:23 1.4
2017-08-26_10:21:23 3.2
2017-08-26_10:23:23 3.5
2017-08-26_10:25:24 2.3
2017-08-26_10:27:24 4.2
2017-08-26_10:29:24 2.2
2017-08-26_10:31:24 3.2
2017-08-26_10:33:24 3.7
2017-08-26_10:35:25 2.9
2017-08-26_10:37:25 2.5
2017-08-26_10:39:25 2.8
2017-08-26_10:41:25 2.7
2017-08-26_10:43:25 4
2017-08-26_10:45:26 3.9
2017-08-26_10:47:26 2.6
2017-08-26_10:49:26 1.4
2017-08-26_10:51:26 4.9
2017-08-26_10:53:26 6
2017-08-26_10:55:28 6.1
2017-08-26_10:57:27 2.9
2017-08-26_10:59:27 0.1
2017-08-26_11:01:28 0.1
2017-08-26_11:03:28 0.1
2017-08-26_11:05:28 0.1
2017-08-26_11:07:29 0.1
2017-08-26_11:09:29 0.1
2017-08-26_11:11:29 0.1
2017-08-26_11:13:29 0.1
2017-08-26_11:15:30 0.1
2017-08-26_11:17:30 0.1
2017-08-26_11:19:35 0.1
2017-08-26_11:21:35 0.1
2017-08-26_11:23:35 0.1
2017-08-26_11:25:35 0.1
2017-08-26_11:27:35 0.1
2017-08-26_11:29:35 0.1
2017-08-26_11:31:36 0
2017-08-26_11:37:04 0.1
2017-08-26_11:39:04 0
2017-08-26_11:41:04 0.1
2017-08-26_11:43:04 0
2017-08-26_11:45:04 0
2017-08-26_11:47:04 0
2017-08-26_11:49:05 0
2017-08-26_11:51:05 0
2017-08-26_11:53:05 0
2017-08-26_11:55:05 0
2017-08-26_11:57:05 0
2017-08-26_11:59:05 0
2017-08-26_12:01:05 0
2017-08-26_12:03:05 0
2017-08-26_12:05:05 0
2017-08-26_12:07:05 0.1
2017-08-26_12:09:05 0.1
2017-08-26_12:11:05 0
2017-08-26_12:13:05 0
2017-08-26_12:15:05 0
2017-08-26_12:17:05 0
2017-08-26_12:19:05 0
2017-08-26_12:21:05 0
2017-08-26_12:23:05 0
2017-08-26_12:25:06 0
2017-08-26_12:27:06 0.1
2017-08-26_12:29:06 0
2017-08-26_12:31:07 0.1
2017-08-26_12:33:07 0
2017-08-26_12:35:07 0
2017-08-26_12:37:07 0
2017-08-26_12:39:08 0
2017-08-26_12:41:07 0
2017-08-26_12:43:08 0
2017-08-26_12:45:08 0
2017-08-26_12:47:08 0
2017-08-26_12:49:09 0
2017-08-26_12:51:09 0
2017-08-26_12:53:09 0
2017-08-26_12:55:09 0
2017-08-26_12:57:10 0
2017-08-26_12:59:10 0.1
2017-08-26_13:01:10 0
2017-08-26_13:03:10 0.1
2017-08-26_13:05:10 0
2017-08-26_13:07:10 0.1
2017-08-26_13:09:10 0
2017-08-26_13:11:10 0
2017-08-26_13:13:10 0.1
2017-08-26_13:15:10 0
2017-08-26_13:17:10 0
2017-08-26_13:19:11 0
2017-08-26_13:21:11 0
2017-08-26_13:23:11 0
2017-08-26_13:25:11 0
2017-08-26_13:27:11 0
2017-08-26_13:29:11 0
2017-08-26_13:31:11 0
2017-08-26_13:33:11 0
2017-08-26_13:35:11 0
2017-08-26_13:37:11 0
2017-08-26_13:39:12 0
2017-08-26_13:41:11 0
2017-08-26_13:43:11 0
2017-08-26_13:45:12 0
2017-08-26_13:47:12 0
2017-08-26_13:49:12 0
2017-08-26_13:51:13 0
2017-08-26_13:53:13 0
2017-08-26_13:55:13 0
2017-08-26_13:57:13 0
2017-08-26_13:59:13 0
2017-08-26_14:01:13 0
2017-08-26_14:03:13 0
2017-08-26_14:05:13 0
2017-08-26_14:07:14 0
2017-08-26_14:09:14 0
2017-08-26_14:11:14 0
2017-08-26_14:13:14 0
2017-08-26_14:15:14 0
2017-08-26_14:17:14 0
2017-08-26_14:19:14 0
2017-08-26_14:21:14 0
2017-08-26_14:23:14 0
2017-08-26_14:25:14 0
2017-08-26_14:27:14 0
2017-08-26_14:29:14 0
2017-08-26_14:31:15 0
2017-08-26_14:33:15 0
2017-08-26_14:35:15 0
2017-08-26_14:37:15 0
2017-08-26_14:39:15 0
2017-08-26_14:41:15 0
2017-08-26_14:43:15 0
2017-08-26_14:45:15 0
2017-08-26_14:47:15 0
2017-08-26_14:49:15 0
2017-08-26_14:51:16 0
2017-08-26_14:53:16 0
2017-08-26_14:55:16 0
2017-08-26_14:57:16 0
2017-08-26_14:59:16 0
2017-08-26_15:01:17 0
2017-08-26_15:03:17 0
2017-08-26_15:05:17 0
2017-08-26_15:07:17 0
2017-08-26_15:09:17 0
#Sonoff_Pow4:Period:::

10:59 Endes des Programmes, Türe geschlossen und ein paar Leds leuchten noch
12:30 Tür wird geöffnet und Maschine entleert, Tür bleibt offen
13:13 Maschine wird mit Schalter ausgeschaltet, nun brennen auch keine Leds mehr, Pow bleibt weiterhin "ON".

Wie man sieht, ist nun sogar das leuchten der Leds zu erkennen, der Period Zyklus liegt bei 2 Minuten.
Ob das für deine Änderung von 3 auf 6 W ausreicht musst einfach testen.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Reinhart

Zitat von: andies am 25 August 2017, 22:33:58
(Also nicht zipfile, sondern github - bin aber unsicher)

Gesendet von iPhone mit Tapatalk Pro

genau so wars, aber das Zipfile mit der letzten Version ist nun schon korrekt.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

andies

So, nun habe ich die letzte Version (5.6.1g, wenn ich das richtig erinnere). Sieht schon besser aus, ist aber noch immer nicht perfekt. Die rote Linie wird von DECT gemessen und muss immer größer sein als die blaue (Power direkt von Sonoff) bzw die grüne (von mir ausgerechnete power, einfach Factor*Voltage*Current). Es gibt nach wie vor Fehler, dass Sonoff mehr misst als da ist. Auch ist wieder eine Spitze da. Ich beobachte das mal, aber es könnte sein, dass ich das Gerät für meine Zwecke werde einsetzen können. Dazu müsste dann der Anstieg beim Entkalker auch in grün/blau deutlich und eindeutig sichtbar sein.

Aber es ist schon ein deutlicher Fortschritt zu 5.6.1a.
FHEM 6.1 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Reinhart

Zitat von: andies am 30 August 2017, 16:40:28
Es gibt nach wie vor Fehler, dass Sonoff mehr misst als da ist

Diese Fehler fallen mir auch immer auf, ich vermute wenn der Shunt über den gemessen wird nur Bruchteile abweicht hat man das Thema. Ich messe dann einfach die tatsächliche Spannung in der Steckdose und kalibriere dann den POW möglichst genau in der Konsole darauf. So richtig hundertprozentig ist das allerdings auch nicht, weil bei jedem Messzyklus die Spannung in der Ausgabe etwas schwankt aber besser wird es allemal.

Bei mir ist meist die angezeigte Spannung viel zu klein, 216 - 223V und tatsächlich habe ich 229 - 232, ich bin 150m neben dem Trafo.

Aber dein Plot kommt jetzt schon sehr nahe dem erwünschten Ziel.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

andies

Kalibrierst du alles: Spannung, Strom und Leistung?


Gesendet von iPad mit Tapatalk Pro
FHEM 6.1 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Reinhart

#19
Zitat von: andies am 30 August 2017, 23:01:44
Kalibrierst du alles: Spannung, Strom und Leistung?

ja aber meist nur rechnerisch ermittelt. Ich habe eine 100W Wärmelampe und da rechne ich den Strom aus und stelle diesen dann ein. Sonst braucht man einen Adapter dazwischen um den Strom zu messen.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

andies

Also, ich habe jetzt eine 48h-"Versuchsreihe". Ich hänge kein Bild an, weil auch die Verbesserung der Firmware und das Kalibrieren nichts genützt hat. Der Sonoff ist nicht genau genug im Bereich von 3-6W. Er zeigt die vorhandene Leistungsspitze nicht an, dafür mehrere Stunden später eine Leistungsspitze, die es definitiv nicht gab.

Der Shunt ist anscheinend dafür nicht ausgelegt. Deshalb ist das Gerät vermutlich auch um einiges billiger als der DECT. Ich werden Sonoff nutzen, aber eben nicht dafür, einstellige Wattleistungen genau zu messen. Schade, aber ist nun mal nicht zu ändern. Es wird sicher andere Verwendungsmöglichkeiten dafür geben, und sei es als Wifi-Lichtschalter.

(Soll ich das Thema schließen? Die Frage ist ja beantwortet.)
FHEM 6.1 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Reinhart

Fazit, mit der neuen Software ist es besser geworden, aber die Ungenauigkeit bei sehr kleinen Leistungen unter 10W ist unzureichend.

Ja schließ bitte den Thread ab und kennzeichne die Überschrift vorne als [erledigt], dann finden andere es schneller wenn sie in diesem Bereich was suchen.
Deine Plots sind ja sehr aussagekräftig um das Problem klar darzustellen!

LG
Reinhart
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

andies

Ich öffne das Thema mal wieder. Es gibt Neuigkeiten. In github hat mir jemand einen Tipp gegeben:

  • Telemetric period auf 30 (!) setzen.
  • Statt des richtigen Wertes von power einen gleitenden Durchschnitt benutzen, also PowerAv:Time.* {movingAverage("Sonoff_pow1","Power",300)} Zudem habe ich noch "event-min-interval 10" gesetzt.
Moving Average ist dem Wiki (https://wiki.fhem.de/wiki/Gleitende_Mittelwerte_berechnen_und_loggen) entnommen. Das glättet anscheinend die problematischen Stellen weg. Ich mache da mal eine Langzeitbeobachtung. Grün ist Sonoff, rot ist DECT in dem Bild unten.
FHEM 6.1 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

Hmm. Ich glaube, ich sollte das lassen. Schaut mal:
FHEM 6.1 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

Ja, das habe ich auch gemerkt. Man darf nicht Power auswerten, sondern anscheinend "difference Total". Das mittle ich dann und das ist stabiler als das gemittelte Power. Komisch. Aber so ist das nun mal.

Hier die beiden Größen graphisch abgetragen. Einmal PowerAv und einmal myPower.av
userReadings
PowerAv:Time.* {movingAverage("Sonoff_pow1","Power",300)}, myPower:Time.* difference { 1000*ReadingsVal("Sonoff_pow1","Total",0);;}, myPower.av:Time.* {movingAverage("Sonoff_pow1","myPower",300)}
 
ergibt das Bild unten.
FHEM 6.1 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

#25
Nun habe ich, nach einem Hinweis im github-Forum, die Sache doch in den Griff bekommen. Ich hatte einen Denkfehler. Power misst die unmittelbar aktuelle Last (in Watt), ich brauche aber das Integral davon - den Verbrauch in der Zeit (in Wattstunden). Also darf ich nicht Power anschauen, sondern muss die Differenz von Total beachten! Diese Differenz habe ich dann auch noch gemittelt. Ob meine Werte ideal sind, weiß ich nicht, aber sie funktionieren und der RPi läuft nicht heiß. Also lasse ich das so und in der Tat kann ich nun zwischen 3W (wahrscheinlich MilliwattStunden oder was auch immer) und 6W unterscheiden.

Die Readings lauten so
userReadings
myPower:Time.* difference { 1000*ReadingsVal("Sonoff_pow1","Total",0);;}, myPower.av:Time.* {movingAverage("Sonoff_pow1","myPower",360)}

und ich habe als Teleperiod 90 Sekunden eingestellt (hat sich als sinnvoll erwiesen, 30 war einfach zu viel). Die movingAverage-Funktion habe ich aus dem Wiki. Dann ergibt sich folgendes Bild. Rot ist der DECT, blau die ungemittelte Differenz aus Total (die schwankt schon ein wenig hin und her) und grün der gleitende Mittelwert. Grün und rot zeigen die gleiche Richtung an, ich kann sehr genau erkennen, wann der Entkalker anspringt. Vielen Dank an alle, die mir hier geholfen haben.

Ich habe das Wiki entsprechend angepasst, dort sind mehr Details zu finden. Und das Thema angepasst (erledigt -> gelöst).

<EDIT> Eine Woche später: Alles immer noch stabil, wie oben beschrieben.
FHEM 6.1 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann