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

[StefanStrobel]

Hallo birdy,

das Problem mit dem Flashen und der Fehlermeldung "not in Sync" liegt vermutlich am Aufruf von avrdude (Attribut flashCommand).
Bei einem ArduCounter auf Basis eines Arduino Nano muss man z.B. ein -b57600 einfügen.

Code Auswählen Erweitern


attr ArduColunterDevice flashCommand avrdude -p atmega328P -c arduino -b 57600 -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]


Ich habe versucht das im Wiki so zu beschreiben:

flash
flashes the ArduCounter firmware ArduCounter.hex from the fhem subdirectory FHEM/firmware
onto the device. This command needs avrdude to be installed.
The attribute flashCommand specifies how avrdude is called.
If it is not modifed then the module sets it to
avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
This setting should work for a standard installation and the placeholders are automatically replaced when the command is used. So normally there is no need to modify this attribute.
Depending on your specific Arduino board however, you might need to insert -b 57600 in the flash Command.

Unabhängig davon habe ich vermutlich das Problem mit den fehlenden Impulsen identifiziert. Ich konnte das Problem in der Simulation mit einem zweiten Arduino als Signalgeber nachstellen.
Auslöser ist der prellende Reed-Kontakt. Das bringt den Mechanismus zur Pulslängenkontrolle durcheinander so dass der Puls nach dem Prellen rejected wird.
Eine einfache Lösung wäre daher ein elektrisches Entprellen mit einem Kondensator und Widerstand:
siehe https://www.mikrocontroller.net/articles/Entprellung

Das erklärt auch warum die Anwender mit Stromzählern mit S0-Ausgang keine Probleme haben. Ein S0-Signal prellt nicht und hat eine Signalbreite von 30ms.
Ich überarbeite gerade den entsprechenden Code-Teil im ArduCounter Sketch und habe hoffentlich bald eine neue Version fertig, die dann auch mit unsauberen Signalen klar kommt.

Mit weiteren Tests kannst Du daher erst mal warten. Ich melde mich sobald ich die neue Version fertig und getestet habe.

Gruss / Thanx
   Stefan

[birdy]

Hallo Stefan

Vielen Dank für Dein Update.
Ich habe - b 57600 eingefügt, das Flashen funktioniert nun. Vielen Dank für den Hinweis

Ich habe versucht mich bezüglich dem elektrischen Entprellen etwas schlau zu machen.
Dabei musste ich zur Kenntnis nehmen, dass von einer Hardware Lösung tendenziell abgeraten und eine Software Lösung empfohlen wird.
Eine Kondensator Lösung kann ich auf die Schnelle nicht realisieren. 1. müsste ich zuerst ausfindig machen wie die Bauteile zu dimensionieren sind. 2. Müsste ich diese dann zuerst noch besorgen.

Welche Flanke müsste Deiner Ansicht nach entprellt werden?


Ich habe mal versucht das Prellen sichtbar zu machen. Ich habe div. Schalvorgänge aufgezeichnet, die haben alle wie folgt ausgesehen....

Bin gerne bereit weitere Test durchzuführen.

Gruss birdy

[StefanStrobel]

Hallo birdy,

anbei mal ein Zwischenstand zum Jahresende.
Bei Verbose 4 oder 5 wird eine "History" der letzten Pulse je Pin ausgegeben...
Eigentlich sollte der Sketch so mit dem Prellen klar kommen.

Im Oszi wirst Du das Prellen erst bei entsprechender Sample-Rate bzw. Zeitbasis sehen.
Ein Reed-Kontakt prellt (wenn er prellt) angeblich im Bereich < 1ms.
In der History im Fhem-Log sollte es aber angezeigt werden.

Die Zeiten im History-Log sind in ms angegeben, die Buchstaben bedeuten:

C - Puls, wird gezählt
X ignoriere kurzen Drop
R ignoriere kurzen Puls
P Rest eines Puls der schon gezählt wurde (nach einem kurzen Drop)
G Gap zwischen Impulsen

Gruss
   Stefan

[FunkOdyssey]

Hallo birdy,

anbei mal ein Zwischenstand zum Jahresende.
Bei Verbose 4 oder 5 wird eine "History" der letzten Pulse je Pin ausgegeben...
Eigentlich sollte der Sketch so mit dem Prellen klar kommen.

Meinst du das normale verbose oder das verboseReading?

Im Oszi wirst Du das Prellen erst bei entsprechender Sample-Rate bzw. Zeitbasis sehen.
Ein Reed-Kontakt prellt (wenn er prellt) angeblich im Bereich < 1ms.
In der History im Fhem-Log sollte es aber angezeigt werden.

Die Zeiten im History-Log sind in ms angegeben, die Buchstaben bedeuten:

Sorry, kurze Frage: Was ist ein History-Log? Ich logge das Device ganz normal per FileLog.

[StefanStrobel]

Hallo,

in dem zuletzt geposteten Sketch und Modul erzeugt das Modul nach jeder Meldung des Zählerstandes auch eine Protokollierung der letzten Änderungen an den überwachten Arduino-Eingängen im Fhem-Log mit Loglevel 4. Das meinte ich mit "History-Log".
Ich werde das aber noch weiter umbauen, so dass diese Ausgabe nur bei "get info" oder im Loglevel 5 ausgegeben wird.

Wenn Ihr es schon mal testen wollt, dann am besten für den ArduCounter verbose 4 oder 5 und für die relevanten Pins eine minimale Pulsdauer von 30ms und verboseReadingsX 1 setzen.

Beispiel:

Code Auswählen Erweitern


attr ACTest flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
attr ACTest interval 10 20
attr ACTest pinD4 falling pullup 30
attr ACTest pinD5 falling pullup 30
attr ACTest pinD6 falling pullup 30
attr ACTest verbose 4
attr ACTest verboseReadings4 1
attr ACTest verboseReadings5 1
attr ACTest verboseReadings6 1


Die Ausgabe im Fhem-Log sieht dann z.B. so aus:

Code Auswählen Erweitern


2017.12.31 12:31:02 4: ACTest: Pin 4 (pin4) count 201 longCount 350625 interpCount 351292 (diff 200) in 19.845s, reject 0, Avg Len 50
ms, result 36.281
2017.12.31 12:31:02 4: ACTest: interval 12:30:43 until 12:31:02, First at 0, Last at 19845
2017.12.31 12:31:03 4: ACTest: Pin 5 (pin5) count 168 longCount 174047 interpCount 1227898 (diff 84) in 9.997s, reject 0, Avg Len 59m
s, result 30.249
2017.12.31 12:31:03 4: ACTest: interval 12:30:52 until 12:31:02, First at 119, Last at 9997
2017.12.31 12:31:03 4: ACTest: Pin 6 (pin6) count 20 longCount 16426 interpCount 146170 (diff 10) in 9.918s, reject 0, Avg Len 495ms,
result 3.630
2017.12.31 12:31:03 4: ACTest: interval 12:30:53 until 12:31:02, First at 991, Last at 9918
2017.12.31 12:31:03 4: ACTest: device: pulse history:
2017.12.31 12:31:03 4: ACTest: device: slot 3 pin 5 start 10314 len 60 at 1 G
2017.12.31 12:31:03 4: ACTest: device: slot 4 pin 4 start 10357 len 49 at 1 G
2017.12.31 12:31:03 4: ACTest: device: slot 5 pin 6 start 9918 len 495 at 1 G
2017.12.31 12:31:03 4: ACTest: device: slot 6 pin 5 start 10374 len 59 at 0 C
2017.12.31 12:31:03 4: ACTest: device: slot 7 pin 4 start 10406 len 50 at 0 C
2017.12.31 12:31:03 4: ACTest: device: slot 8 pin 5 start 10433 len 60 at 1 G
2017.12.31 12:31:03 4: ACTest: device: slot 9 pin 4 start 10456 len 50 at 1 G
2017.12.31 12:31:03 4: ACTest: device: slot 0 pin 5 start 10493 len 59 at 0 C
2017.12.31 12:31:03 4: ACTest: device: slot 1 pin 4 start 10506 len 49 at 0 C
2017.12.31 12:31:03 4: ACTest: device: slot 2 pin 4 start 10555 len 50 at 1 G


Gruss
   Stefan

[StefanStrobel]

Hallo,

anbei nun der letzte Stand. Die letzten Impulse mit jeweiliger Länge sieht man nun am Ende von get info.
Die Probleme mit prellenden Reed-Kontakten sollten damit eigentlich gelöst sein.
@birdy / @FunkOdissey: Wenn Ihr das bestätigen könnt, checke ich die neue Version ein.

Gruss
   Stefan

[birdy]

Danke Stefan

Das Update ist durchgeführt, die neuen Versionen sind im Einsatz.
Ich schaue mal wie es läuft, und berichte dann wieder.

Ich habe noch 2-3 Messungen mit deutlich erhöhter Sample –Rate gemacht. Doch ein Prellen konnte ich (noch) nicht messen. Ich denke, der Reedkonkakt prellt auch nicht grundsätzlich /immer, und man müsste Glück haben einen entsprechenden Schaltvorgang aufzuzeichnen.

Vielen Dank für Deine hervorragende Unterstützung.
Gruss birdy 

[StefanStrobel]

Hier noch ein Update vor dem CheckIn:
Die Doku ist aktualisiert, die Darstellung der Impuls-History optimiert und die Readings etwas angepasst.
Die Long-Counter werden jetzt immer erzeugt. verboseReadingsX ist nur noch nötig wenn man die Impuls-History sowie countDiffX und timeDiffX als Reading sehen möchte.

Gruss
   Stefan

[Kornelius777]

Hallo Stefan,

das ist schon ziemlich klasse, was Du hier so auf die Beine gestellt hast! Danke!

Ich war gerade im Wiki - da steht jetzt noch:

readingNameLongCount[0-9]+
Change the name of the long counter reading longX (only created when verboseReadingsX is set to 1) to something more meaningful.

Ist das jetzt noch aktuell?

Grüße!

Kornelius

[FunkOdyssey]

Hallo,

anbei nun der letzte Stand. Die letzten Impulse mit jeweiliger Länge sieht man nun am Ende von get info.
Die Probleme mit prellenden Reed-Kontakten sollten damit eigentlich gelöst sein.
@birdy / @FunkOdissey: Wenn Ihr das bestätigen könnt, checke ich die neue Version ein.

Gruss
   Stefan

Du hast aber ne ordentliche Schlagzahl drauf in den letzten Tagen. Da komme ich mit dem Flashen und Aktualisieren kaum hinterher.
Ich weiß nicht, ob meine Test wirklich repräsentativ sind. Ich habe in den letzten Wochen ein wenig den Überblick verloren über die neuen Features (long, interpolated, Impuls-History, etc.). Da ich noch geringe Abweichungen hatte, habe ich gestern meinen Counter erst einmal auf das long-Reading umgestellt. Ich muss halt nur immer einige Tage warten bis ich die Abweichung feststelle. Zwar verbrauche ich im Winter mehr Gas, aber die Abweichungen sind bei mir halt nicht nach wenigen Stunden sichtbar. Vom Gefühl her könnten die neuen Readings (bei mir) aber besser passen. Ich werde das mal beobachten.

Ich meine, dass seitdem ich mit einem 10uF Kondensator entprelle, die Abweichungen auch geringer geworden sind. Ich habe halt - wie gesagt - noch keinen repräsentativen Zeitraum, da irgendwie immer etwas war. Einige Wochen habe ich bewusst mit einer Differenz gelebt, die durch eine Offline-Phase des Raspberrys entstanden ist. Dies im Nachhinein zu rekonstruieren, ist ein wenig schwierig.

Aber danke für deine Unterstützung und die neuen Möglichkeiten.

[birdy]

Hallo Stefan

Seit knapp 2 Tagen habe ich die Version aus Post #260 im Einsatz. Die Funktioniert einwandfrei, keinerlei Abweichung bis jetzt. Hervorragende Arbeit, Chapeau. (Die neueste Version habe ich noch nicht getestet, wird aber in Kürze folgen).

Meine Testes sind mit einer Pluslängenkontrolle von 200 gelaufen. Aufgefallen ist mir lediglich, dass in der Kombination Firm-/Software 2.03 / 5.6 keine Rejects gezählt wurden. In der Vergangenheit hatte ich immer ein paar pro Tag.
Ist die Pulslängenkontrolle immer noch sinnvoll oder notwendig. Was ist Deine Empfehlung?

Gruss birdy

[StefanStrobel]

Hallo,

Ich würde grundsätzlich eine minimale Pulslänge angeben und damit die Pulslängenkontrolle aktivieren. Bei einem S0–Ausgang eines Stromzählers sollten das 30ms sein.

Die frühere Version der Arducounter–Firmware hatte einen Bug in der Pulslängenkontrolle, so dass bei prellenden Kontakten auch gültige Signale rejected wurden. Die neue Version sollte das Problem behoben haben.

Das verwirrende bei Deinem Reed–Kontakt war, dass er so schnell geprellt hat und die Debug–Funktionen in der Firmware die Analyse etwas verlangsamt haben, so dass das Prellen ,,übersehen" wurde. Mit Debug–Funktionen hat deshalb vermutlich alles funktioniert und ohne Debug–Funktionen war das Problem wieder da.

Die Pulse–History–Funktion, die ich jetzt in der neuen Version eingebaut habe, verlangsamt den Sketch auch ein klein wenig, ist aber deutlich effizienter implementiert als die frühere Debug-Funktion.

Ich habe die neue Version auf einem Arduino UNO getestet und an 15 Eingängen jeweils Signale mit nur 5–10 Millisekunden Puls- und Pausenlänge angelegt. Das hat problemlos funktioniert. Deshalb würde ich die Funktion dauerhaft drin lassen. Wenn dann mal etwas seltsam aussieht, kann man mit diesem Feature viel besser nachvollziehen, was passiert ist.

Die Pulse-History speichert zwar insgesamt nur 20 Potential-Änderungen an allen Eingängen zusammen, aber man kann ja das Intervall-Attribut entsprechend klein machen und die pulseHistory-Readings in ein Filelog packen, so dass man tatsächlich alle Änderungen nachvollziehen kann.
Für mehr als 20 Einträge ist der RAM eines Uno etwas knapp. Da müsste man den Zähler für einen Arduino Mega compilieren.

@Kornelius: Danke für den Hinweis auf den Fehler im Wiki. Das korrigiere ich gleich noch.

Gruss
    Stefan

[Kornelius777]

Hallo Stefan,

gestern habe ich (endlich) einen passenden Reedkontakt für meinen Gaszähler geliefert bekommen. Nun tickert ArduCounter fröhlich vor sin hin. Keinerlei Abweichung - kein Reject, keine "vergessenen" Zähler. Läuft klasse!

Jetzt noch eine Newbie-Frage:
Pro "interval" liefert mir ArduCounter ja "ArduCounter.powerX" als Reading.
Was muss ich nun wie anpassen, damit ich ein Delta-Reading bekomme in der Form von: "Während des letzten "interval" hat ArduCounter Y Ticks (Ganzzahl) gezählt"?

Vielen Dank für Deinen großartigen Einsatz!

Kornelius

[Otto123]

Hallo Kornelius,

so richtig klar ist mir Deine Frage nicht. Was willst Du denn mit dieser Ganzzahl? Willst Du die Differenz zum vorhergehenden Zählerstand?
Dann mach Dir ein Userreading mit dem modifier difference aber nicht mit Power sondern mit pinx.

difference: das Reading wird auf die Differenz zw. dem aktuellen und dem vorherigen Wert gesetzt.

Power liefert die Momentanleistung.
So habe ich mir das mal mit Power für mich verdeutlicht, damit mir klar wird wie ich den factor angeben muss:
Power ist der Wert für die momentane Leistung in Impulsen/h ((delta count) / (delta time) * factor).

Gruß Otto

[Kornelius777]

Danke, Otto!

Genau, was ich gesucht hatte!
Ist eine steile Lernkurve hier! 

Vielen Dank!

Kornelius