ArduCounter Support und neue Versionen (war: Stromzähler mit S0 Schnitt...)

[StefanStrobel]

Hallo,

anbei eine neue Version zum Testen.
Der Bug sollte behoben sein und es gibt ein neues Attribut readingFactor[0-9]+ zum setzen eines Faktors je Pin.

Gruss
    Stefan

[Otto123]

Hallo Stefan,

Du hast ja freie Spitzen! 

Viele dank ich teste das dann gleich, ich habe heute meinen IT Zoo neu verkabelt und u.a. dem Arduino nano einen aktive "powered Hub" spendiert. 

Gruß Otto

[Otto123]

Hallo Stefan,

funktioniert alles prima. Der Bug ist behoben und die Sache mit dem zusätzlichen Faktor ist super.

Danke!

Schönes WE
Otto

[Otto123]

Hallo Stefan,

ich habe jetzt noch ein paar Tage gespielt und insgesamt drei Zähler angebunden. Jetzt ist mir folgendes aufgefallen:

• Offenbar werden die Zähler in dem Arduino beim Neustart von FHEM zurückgesetzt. Das macht doch eigentlich keine Sinn, der soll doch gerade unabhängig von FHEM zählen? Ich habe den Arduino extra getrennt versorgt.
  
• Bei einem Neustart von FHEM oder ich habe sogar den Eindruck nur bei Änderung der Attribute passiert irgendwas mit den power Werten. Ich habe dann irgendwie unregelmäßig plötzlich Spitzen von vielen Tausend kW in den Werten.
  

Wobe ich gerade bemerke offenbar nicht nur beim Neustart, in diesem Zeitarum habe ich nichts gemacht:

Code Auswählen Erweitern

2016-10-22_13:58:30 AC pin6: 300.000
2016-10-22_13:58:30 AC power6: 1.654
2016-10-22_13:59:30 AC pin6: 302.000
2016-10-22_13:59:30 AC power6: 19199.520
2016-10-22_14:00:30 AC pin6: 304.000
2016-10-22_14:00:30 AC power6: 1.668
2016-10-22_14:01:29 AC pin6: 306.000
2016-10-22_14:01:29 AC power6: 1.595
Gruß Otto

[StefanStrobel]

Hallo Otto,

vielen Dank für den Hinweis.
Das mit dem Reset bei Neustart von Fhem liegt daran, dass Fhem des serielle Device neu öffnet und dabei der Arduino wohl einen Reset bekommt. Ich wüsste nicht wie man das verhindern kann.
Es sollte aber auch kein Problem sein, da der Sketch für die power-Berechnung immer nur die Zähler-Differenz für ein angegebenes minimal / maximal Intervall verwendet.

Wegen den Spitzen gehe ich mal auf die Suche. Das sollte nicht vorkommen.
Wie hast Du es denn konfiguriert? Ich vermute dass das mit der Einstellung der Intervalle zusammenhängt, da das Problem bei mir nicht aufgetreten ist ...

Gruss
    Stefan

EDIT: bei der Fehlersuche habe ich festgestellt, dass die ursprüngliche Beschreibung inkorrekt war. Bin weiter auf der Suche nach einer race condition ...
         Falls das Problem bei Dir reproduzierbar ist, wäre ein Log mit verbose 4 oder 5 sehr hilfreich

[Otto123]

Hallo Stefan,

das mit dem Reset und dem Zähler im Sketch habe ich mir gestern auch schon angeschaut und in etwa verstanden  da bin ich am überlegen wie man das eventuell umgehen könnte. Bei jeder erneuten Definition von Pins werden die Zähler im Sketch neu gestartet und beim Start von FHEM werden die Pins neu definiert.
Deine Bemerkung mit dem langfristigen Zähler im Sketch verstehe in nicht ganz, er liefert doch einen kontinuierlichen Zähler solange er läuft - oder?

Hier mein list

Code Auswählen Erweitern

Internals:
   DEF        /dev/ttyUSB0@9600
   DeviceName /dev/ttyUSB0@9600
   FD         11
   Initialized 1
   ModuleVersion 3.4.4 - 10.10.2016
   NAME       AC
   NR         29
   PARTIAL
   STATE      opened
   TYPE       ArduCounter
   buffer
   Readings:
     2016-10-23 11:23:33   ZaehlerHzg      2884.0225
     2016-10-23 11:23:33   ZaehlerSumme    41781.9866666667
     2016-10-23 11:23:33   ZaehlerWW       4447.42
     2016-10-23 11:23:33   pin4            4305.000
     2016-10-23 11:20:33   pin5            1157.000
     2016-10-23 11:23:33   pin6            2054.000
     2016-10-23 11:23:33   power4          0.308
     2016-10-23 11:20:33   power5          0.000
     2016-10-23 11:23:33   power6          0.735
     2016-10-22 11:33:13   state           opened
     2016-10-22 11:33:16   version         ArduCounter V1.0
Attributes:
   factor     1000
   interval   60 300
   pinD4      rising pullup
   pinD5      rising pullup
   pinD6      rising pullup
   readingFactor4 2500
   readingFactor5 1000
   readingFactor6 13333
   userReadings ZaehlerHzg {ReadingsVal("AC","pin4",0)/400 + ReadingsNum("ZaehlerManuellHzg","ZaehlerHzgKorr",0) },ZaehlerWW {ReadingsVal("AC","pin5",0)/1000 + ReadingsNum("ZaehlerManuellWW","ZaehlerWWKorr",0)},ZaehlerSumme {ReadingsVal("AC","pin6",0)/75 + ReadingsNum("ZaehlerManuellSumme","ZaehlerSummeKorr",0) }

Ganz häufig sind die Spitzen bei dem Zähler (Ferrariszähler mit Abtastkopf) an pin6 - siehe auch den kurzen Auszug des Logs von gestern.

Gruß Otto

[StefanStrobel]

Hallo Otto,

Eine optimierte Version kommt demnächst. Ich bin noch am Testen.
Kann es sein, dass Dein Zähler an Pin 6 immer zwei Impulse in schneller Folge liefert?

Gruß
    Stefan

[StefanStrobel]

Hallo Otto,

hier nochmal eine neue Version. Ich habe einiges optimiert. Könntest Du das mal mit verbose 4 testen und dann ein Stück Fhem-Log posten, dann muss ich nicht so viel spekulieren, was jetzt tatsächlich die Ursache der Spitzen bei Dir gewesen sein könnte?
Im Log sollte dann die komplette Kommunikation zwischen Modul und Sketch zu sehen sein.

Im Doku-Teil des Moduls habe ich die neuen Optionen schon beschrieben, aber ich poste das dann auch nochmal ausführlich auf deutsch wenn Dein Test / Log zeigt, dass es so auch schon gut funktioniert

Gruss / vielen Dank
    Stefan

[StefanStrobel]

Hier nochmal die ausführlichere Erläuterung wie der Arducounter zählt bzw. wie man das beeinflussen kann:

Der einfachste Weg wäre einfach immer innerhalb von einem festen Intervall (z.B. 60 Sekunden) alle Impulse zu zählen.
Das funktioniert gut, wenn die Impulsfrequenz hoch ist. Wenn jedoch beispielsweise nur alle 90 Sekunden ein Impuls kommt und man immer 60 Sekunden zählt, dann hat man im ersten Intervall keinen Impuls, im zweiten dafür einen und im dritten wieder keinen.
Selbst bei doppelter Frequenz mit Impulsen alle 45 Sekunden wird es unschön, da dann im ersten und zweiten Intervall je ein Impuls gezählt würde, im zweiten vermutlich zwei und im dritten wieder einer. Für eine Stromverbrauchsrechnung würde man dann in den ersten 2 Minuten mit einem Impuls je 60 Sekunden rechnen (obwohl es in Wirklichkeit ja ein Impuls je 45 Sekunden war) und im dritten Intervall mit zwei Impulsen je 60 Sekunden, also zu viel.

Um hier genauere Werte zu bekommen habe ich im Arducounter einen anderen Weg implementiert.
Arducounter hat ein normales und ein maximales Reporting-Intervall, in dem Ergebnisse ausgegeben werden. Unabhängig vom Reporting-Intervall werden Impulse gezählt, dabei aber die Zeit zwischen dem ersten gezählten Impuls und dem zuletzt gezählten Impuls gemessen.
Wenn nun beispielsweise das normale Reporting-Intervall auf 60 Sekunden gesetzt wird und Impulse alle 45 Sekunden kommen, dann kommt beispielsweise der erste Impuls 10 Sekunden nach Beginn des Reporting-Intervalls. Dieser wird noch nicht gezählt sondern bildet nur den Startpunkt für die Zeitmessung.
Der zweite Impuls kommt dann 55 Sekunden nach Beginn des Reporting-Intervalls. Arducounter würde dann nach 60 Sekunden als Ergebnis einen Impuls und eine Zeitdifferenz von 45 Sekunden zurückgeben.

Für das nächste Intervall merkt sich Arducounter den Zeitpunkt des zuletzt gezählten Impulses (nach 55 Sekunden im vorigen Intervall) als Startpunkt und zählt weiter bis das zweite Reporting-Intervall abgelaufen ist. Dabei würde er 40 Sekunden nach Beginn des zweiten Reporting-Intervalls einen weiteren Impuls bekommen. Bis zum Ende des zweiten Report-Intervalls kommt kein neuer Impuls. Als Ergebnis würde Arducounter wieder einen Impuls und eine Zeitdifferenz von 45 Sekunden ausgeben.

Das Messergebnis und die Korrektheit wird so bei niedrigen Frequenzen deutlich genauer und sieht in Plots sichtbar weniger ausgefranst aus.

Leider hat auch diese Methode ihre Grenzen. Wenn die Impulsfrequenz nochmal geringer wird und beispielsweise nur alle 90 Sekunden ein Impuls kommt, könnte Arducounter in 60 Sekunden auch nicht vernünftig zählen. Für diesen Fall habe ich ein zweites Intervall eingebaut - das maximale Intervall. In der früheren Version hat Arducounter für den Fall dass in einem Intervall gar kein Impuls gekommen ist, einfach weitergezählt und noch kein Ergebnis ausgegeben. Nach einem weiteren Ablauf des normalen Intervalls wurde wieder geprüft, ob etwas gezählt wurde und gegebenenfalls weiter gewartet. Erst wenn auch das maximale Intervall abgelaufen ist (z.B. 5 Minuten) wurde dann die Anzahl der Impulse und die Differenz zwischen Startpunkt (letzter Impuls im vorhergehenden Intervall) und letztem gezählten Impuls zurückgegeben. Soweit hat das gut funktioniert.

Wenn nun aber auch im Maximalen Intervall kein Impuls gezählt werden konnte, dann hat Arducounter als Ergebnis 0 ausgegeben und das Ende des maximalen Intervalls als neuen Startpunkt festgelegt. Das funktioniert gut, es sei denn die Impulse kommen so unglücklich, dass direkt nach Ende des maximalen Intervalls ein Impuls kommt und dann wieder 6 Minuten lang keiner.
Dann hätte Arducounter bisher nach Ende des Maximalen Intervalls den Startpunkt auf das Ende des Intervalls gelegt, direkt danach (z.B. nach einer halben Sekunde) einen Impuls gezählt und dann nach Ende des Reporting Intervalls einen Impuls in einer halben Sekunde ausgegeben. Das wäre dann eine falsche Spitze im Stromverbrauch.

Die Spitzen sind immer dann entstanden, wenn wenige Impulse gezählt wurden und diese aber in einem sehr kurzen Zeitintervall berichtet wurden.

Um das zu vermeiden habe ich in der neuen Version ein paar neue Intervall-Parameter eingeführt, die der Anwender per Attribut wählen kann:

1) Neben dem ersten Parameter (ich nenne ihn jetzt "normales Intervall") und dem zweiten Parameter ("maximales Intervall") gibt es noch den neuen dritten Parameter ("minimales Intervall") und einen neuen vierten (minimaler Count).
Wenn am Ende des Reporting-Intervalls weniger Impulse als der minimale Count gezählt wurden oder wenn die gezählten Impulse in einer Zeitspanne gezählt wurden, die kleiner als das minimale Intervall ist, dann greift wieder das maximale Intervall und es wird noch kein Ergebnis ausgegeben sondern weiter gezählt. Die Hoffnung ist, dass dann doch noch Impulse kommen und so ein sinnvolleres Ergebnis berechnet werden kann.

Das Maximale Intervall sollte dabei durchaus ein vielfaches des normalen Intervalls sein. Das bedeutet nicht dass ein Ergebnis entweder innerhalb des ersten normalen Intervalls kommen muss, oder dann gleich auf das Ende des maximalen Intervalls verzögert wird, denn auch wenn verzögert wird, prüft Arducounter jeweils nach Ablauf eines weiteren normalen Intervalls, ob inzwischen Werte zum Reporten vorhanden sind. Beim Ablauf des maximalen Intervalls ohne dass die Kriterien erfüllt sind (minimales Intervall und minimaler Count) wird dann jedoch ein Ergebnis ausgegeben, auch wenn noch zu wenige Impulse gezählt wurden.

Wenn man das normale Intervall beispielsweise auf 60 Sekunden, das maximale auf 20 Minuten und das minimale Intervall auf 20 Sekunden setzt, dann kommen zumindest keine Spitzen heraus, wenn nach einem langen Zeitraum ohne Impulse nur ein Impuls direkt zu Beginn eines neuen Intervalls gezählt wird.

Zusätzlich kann man den minimalen Count auf 2 oder 3 setzen und so generell bei geringen Frequenzen die Zählung auf das maximale Intervall schieben. Das maximale Intervall sollte dann nur groß genug sein.

2) Falls jemand die Berechnungsweise wie oben nicht gefällt und er möchte lieber starr in einem festgesetzten Intervall zählen, dann kann er die ersten beiden Intervall-Parameter auf den gleichen Wert setzen (z.B. 60 Sekunden und 60 Sekunden). Arducounter sieht das als Signal, dass starre Intervalle gewünscht sind und zählt nur Impulse im vorgegebenen Reporting-Intervall. Die Zählung beginnt bei der ersten Sekunde und endet nach 60 Sekunden, egal wie viele Inpulse jeweils darin gezählt wurden. Das Ergebnis wird immer nach 60 Sekunden ausgegeben.

3) Ein weiterer unschöner Effekt war bisher dass der Stromverbrauch am Ende eines Intervalls berechnet und ins Log geschrieben wurde. Zunächst mal ist das "normal", da ja zuerst gezählt werden muss. Aber für weitere Berechnungen in Fhem wird typischerweise davon ausgegangen, dass ein Reading so lange den gleichen Wert hat, bis es sich ändern.
Beim Stromverbrauch ist das aber nicht so. Der ausgegebene Stromverbrauch war bisher so wie er jetzt ausgegeben wurde und nun beginnt die neue Messung.
In der neuen Version wird nun die Stromverbrauchs-Messung mit dem Zeitpunkt des Intervall-Beginns ins Log geschrieben und nur die Zähler- und Zeitwerte bekommen den Zeitstempel der Ausgabe vom Arduino.

Dieses Verhalten werde ich noch per Attribut wählbar machen, denn wenn die Ergebnisse zusammen mit anderen Zählern im gleichen Log landen sollen, kann das zu Problemen führen, da dann die Logeinträge keine starr aufsteigenden Zeitstempel mehr haben könnten.

Ich hoffe das erklärt ein paar Internas. Ich freue mich über Feeback, weitere Tests oder sonstige sinnvolle Verbesserungsvorschläge.

Gruss
    Stefan

[BillyPbg]

Hallo Stefan,

vorweg vielen Dank für Deine echt tolle Arbeit!

Wenn Du gerade an Deinem Modul so kräftig Dir den Kopf zerbrichst, hätte ich noch - wie ich meine - eine sinnvolle Idee-Anregung-Bitte für Deinen ArduCounter:

Wie Dir bereits ja auch bekannt ist, gibt es immer wieder Störimpulse zwecks Kabellängen, ungeschirmter bzw. falscher Kabel, ungenügend gefilterter Versorgungsspannung etc...

Bau doch bitte eine wählbare Option  "S0-Prüfung" ein, in der Du die Impulslänge von 30ms und Minimal-Impulspause von ebenfalls 30ms (plus Flanken) prüfen läßt (Genauere Daten dazu siehe Anlage...).

Dies noch versehen mit einer zusätzlichen "S0-Karenzzeit"-Option, in der man "+-  X" Millisekunden frei definieren kann, für die nicht ganz so genauen Zähler. Dies würde viele Probleme lösen..
.
Diese Auswertung könnte man dann als aufsummierte Gegenüberstellung "x verworfen von x Impulsen" in FORM eines Readings dem User zur Verfügung stellen oder per "Get" abrufen lassen.

Ich bin nämlich überzeugt, dass viele Spitzen nicht nur aufgrund der Zählmethode entstanden sind, sondern vielmehr aufgrund der Tatsache von unerkannten Störimpulsen, die sonst ja weiterhin unerkannt bleiben würden, und so den Gesamteindruck Deines Moduls und Deiner super Arbeit verfälschen würde.

Viel Grüße aus dem sonnigen Bayern!
Billy

[StefanStrobel]

Hallo Billy,

vielen Dank für die gute Anregung.
Das bau ich noch ein.

Gruss / Thanx
   Stefan

[Otto123]

Hallo Otto,

hier nochmal eine neue Version. Ich habe einiges optimiert. Könntest Du das mal mit verbose 4 testen und dann ein Stück Fhem-Log posten, dann muss ich nicht so viel spekulieren, was jetzt tatsächlich die Ursache der Spitzen bei Dir gewesen sein könnte?
Im Log sollte dann die komplette Kommunikation zwischen Modul und Sketch zu sehen sein.

Im Doku-Teil des Moduls habe ich die neuen Optionen schon beschrieben, aber ich poste das dann auch nochmal ausführlich auf deutsch wenn Dein Test / Log zeigt, dass es so auch schon gut funktioniert

Gruss / vielen Dank
    Stefan

Hallo Stefan,

vielen Dank! Ich war ein paar Tage nicht da und mache mich jetzt ans testen.
Das mit den zwei Impulsen hintereinander an Pin6 würde ich von der Überlegung her ausschließen, da ich ja die gezählten Impulse am  Pin6 mit dem tatsächlichen Zählerstand vergleichen kann. Aber ich prüfe das.

Ich melde mich mit Ergebnissen zurück.

Gruß Otto

[Otto123]

Hallo Stefan,

so alles "eingebaut" und schon nach wenigen Minuten gibt es wieder Spitzen -> 13:01.
Zunächst mal die Messwerte:

Code Auswählen Erweitern

2016-11-02_12:52:33 AC power6: 0.000
2016-11-02_12:53:07 AC pin6: 9
2016-11-02_12:53:05 AC power4: 1.029
2016-11-02_12:54:07 AC pin4: 89
2016-11-02_12:54:06 AC power4: 1.029
2016-11-02_12:55:07 AC pin4: 96
2016-11-02_12:53:17 AC power6: 0.436
2016-11-02_12:55:07 AC pin6: 10
2016-11-02_12:55:06 AC power4: 1.036
2016-11-02_12:56:07 AC pin4: 103
2016-11-02_12:55:01 AC power6: 1.470
2016-11-02_12:56:07 AC pin6: 12
2016-11-02_12:56:06 AC power4: 1.030
2016-11-02_12:57:07 AC pin4: 110
2016-11-02_12:52:05 AC power5: 0.000
2016-11-02_12:57:07 AC pin5: 2
2016-11-02_12:56:34 AC power6: 1.464
2016-11-02_12:57:07 AC pin6: 13
2016-11-02_12:57:05 AC power4: 1.029
2016-11-02_12:58:07 AC pin4: 117
2016-11-02_12:57:01 AC power6: 1.463
2016-11-02_12:58:07 AC pin6: 15
2016-11-02_12:58:13 AC power6: 0.902
2016-11-02_12:59:06 AC pin6: 16
2016-11-02_12:58:32 AC power4: 0.096
2016-11-02_13:00:07 AC pin4: 118
2016-11-02_12:58:43 AC power6: 0.572
2016-11-02_13:00:07 AC pin6: 17
2016-11-02_12:59:38 AC power4: 0.306
2016-11-02_13:01:06 AC pin4: 121
2016-11-02_13:01:00 AC power6: 7.319
2016-11-02_13:01:07 AC pin6: 18
2016-11-02_13:01:07 AC power4: 0.306
2016-11-02_13:02:06 AC pin4: 123
2016-11-02_12:57:06 AC power5: 0.000
2016-11-02_13:02:06 AC pin5: 2
2016-11-02_13:02:08 AC power4: 0.306
2016-11-02_13:03:06 AC pin4: 125
2016-11-02_13:02:01 AC power6: 0.731
2016-11-02_13:03:06 AC pin6: 19
2016-11-02_13:03:08 AC power4: 0.306
2016-11-02_13:04:06 AC pin4: 127
2016-11-02_13:03:01 AC power6: 0.730
2016-11-02_13:04:06 AC pin6: 20
2016-11-02_13:04:07 AC power4: 0.305
2016-11-02_13:05:06 AC pin4: 129
2016-11-02_13:04:01 AC power6: 0.734
2016-11-02_13:05:06 AC pin6: 21
2016-11-02_13:05:07 AC power4: 0.305
2016-11-02_13:06:06 AC pin4: 131
2016-11-02_13:05:01 AC power6: 0.740
2016-11-02_13:06:06 AC pin6: 22
2016-11-02_13:06:07 AC power4: 0.304
2016-11-02_13:07:06 AC pin4: 133
2016-11-02_13:02:06 AC power5: 0.000
2016-11-02_13:07:06 AC pin5: 2
2016-11-02_13:06:01 AC power6: 0.735
2016-11-02_13:07:06 AC pin6: 23

Und hier das Log

Code Auswählen Erweitern

2016.11.02 12:58:07 4: AC: Read match msg: Pin 4 count 117 (diff 7) in 61254 Millis, first at 442?, last at 56918
2016.11.02 12:58:07 4: AC: Read match msg: Pin 6 count 15 (diff 2) in 65616 Millis, first at 817, last at 33730
2016.11.02 12:59:06 4: AC: Read match msg: Pin 6 count 16 (diff 1) in 53225 Millis, first at 26955, last at 26955
2016.11.02 13:00:06 4: AC: Read match msg: Pin 4 count 118 (diff 1) in 94090 Millis, first at 91008, last at 91008
2016.11.02 13:00:07 4: AC: Read match msg: Pin 6 count 17 (diff 1) in 83975 Millis, first at 50130, last at 50130
2016.11.02 13:01:06 4: AC: Read match msg: Pin 4 count 121 (diff 3) in 88276 Millis, first at 359, last at 59284
2016.11.02 13:01:07 4: AC: Read match msg: Pin 6 count 18 (diff 1) in 6558 Millis, > Mfirst at 55716, last at 55716
2016.11.02 13:02:06 4: AC: Read match msg: Pin 4 count 123 (diff 2) in 58901 Millis, first at 28745, last at 58185
2016.11.02 13:02:06 4: AC: Read match msg: Pin 5 count 2 (diff 0) in 300800 Millis,
2016.11.02 13:03:06 4: AC: Read match msg: Pin 4 count 125 (diff 2) in 58822 Millis, first at 275<4, last at 57007
2016.11.02 13:03:06 4: AC: Read match msg: Pin 6 count 19 (diff 1) in 65677 Millis, first at 61393, last at 61393
2016.11.02 13:04:06 4: AC: Read match msg: Pin 4 count 127 (diff 2) in 58761 Millis, first at 263?4, last at 55768
2016.11.02 13:04:06 4: AC: Read match msg: Pin 6 count 20 (diff 1) in 65767 Millis, first at 7160, last at 7160
2016.11.02 13:05:06 4: AC: Read match msg: Pin 4 count 129 (diff 2) in 59079 Millis, first at 253;6, last at 54847
2016.11.02 13:05:06 4: AC: Read match msg: Pin 6 count 21 (diff 1) in 65404 Millis, first at 12564, last at 125>4
2016.11.02 13:06:06 4: AC: Read match msg: Pin 4 count 131 (diff 2) in 59086 Millis, first at 243>3, last at 53933
2016.11.02 13:06:06 4: AC: Read match msg: Pin 6 count 22 (diff 1) in 64860 Millis, first at 17424, last at 174:4
2016.11.02 13:07:06 4: AC: Read match msg: Pin 4 count 133 (diff 2) in 59194 Millis, first at 235=4, last at 53127
2016.11.02 13:07:06 4: AC: Read match msg: Pin 5 count 2 (diff 0) in 300000 Millis,
2016.11.02 13:07:06 4: AC: Read match msg: Pin 6 count 23 (diff 1) in 65345 Millis, first at :2769, last at 22769
2016.11.02 13:08:06 4: AC: Read match msg: Pin 4 count 135 (diff 2) in 59259 Millis, first at 22781, last at 52386
2016.11.02 13:08:06 4: AC: Read match msg: Pin 6 count 24 (diff 1) in 63379 Millis, first at 26148, last at 261<8
2016.11.02 13:09:06 4: AC: Read match msg: Pin 4 count 137 (diff 2) in 59291 Millis, first at 22088, last at 51677
2016.11.02 13:09:06 4: AC: Read match msg: Pin 6 count 25 (diff 1) in 63259 Millis, first at 29407, last at 29487
2016.11.02 13:10:06 4: AC: Read match msg: Pin 4 count 139 (diff 2) in 59393 Millis, first at 21391, last at 51070
2016.11.02 13:10:06 4: AC: Read match msg: Pin 6 count 26 (diff 1) in 63318 Millis, first at 32725, last at 327:5

Irgendwie sehen die Zahlen manchmal komisch aus - oder?
Gruß Otto

[StefanStrobel]

Hallo Otto,

vielen Dank für's Testen und das Log.
Damit wird die Fehlersuche einfacher

Mal unabhängig davon, dass ich an Deinem Log sehe dass das mit den Zeitstempeln im Log noch verbessert werden muss, liegt das mit den Spitzen vermutlich an Störungen.

Vor 13:01 kommen die Impulse meist im Abstand von 50 bis 80 Sekunden. Um 13:01 kommt dann aber gleich nach 6 Sekunden wieder einer. Wenn Das keine echte Lastspitze ist, wird es wohl ein Störimpuls sein.
In der nächsten Version baue ich noch den vorgeschlagenen 30ms Filter ein. Evt. können wir solche Impulse damit unterdrücken.

Gruss
    Stefan

[StefanStrobel]

Das mit den Sonderzeichen in den Zahlen ist natürlich ziemlich seltsam.
Sieht nach einem Problem mit der seriellen Ausgabe aus.
Das muss ich mir noch näher ansehen.

Gruss
    Stefan