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

[StefanStrobel]

Hallo Otto,

wenn im Log "device sent setup message, V1.8" steht, dann ist im Ardiuno die setup()-Funktion gelaufen. Sieht nach Reset aus.
Bei mir kommt das ja nicht. Statt dessen wird hello gesendet und danach kommt "device replied to hello, V1.8".

Schau doch mal im Log weiter in die Vergangenheit, seit wann das so ist.
Eventuell hängt es an der Übertragungsrate?

Gruss
    Stefan

[Otto123]

Hallo Stephan,

naja genau genommen hat er das noch nie gemacht 
Ich bin mir zwar sicher diese hello message schon gesehen zu haben, aber das kann auf einem anderen System gewesen sein.

Ich glaube: als ich das auf dem "quasi Produktiven" testen wollte, waren die Pins beim Start weg und da bin ich dann abgestorben. 

Ich überprüfe das und melde mich zurück!

Gruß Otto

[BillyPbg]

Hallo Stefan,
hallo Otto,

vielleicht kann ich bei der Lösung des Problems mit meinen Log ein wenig beitragen:

Fakt ist, auch bei mir sind nach einem "Shutdown Restart" die Zähler  bzw. "Get Info..."auf "0".
Konstellation: Raspi 3, Arduino Nano 3.0 - Aktueller Softwarestand...

Log-Auszug ("Shutdown Restart"-Vorgang, Verbose 5, gekürzt...):
2017.01.06 18:57:56.469 3: ArduCOUNTER: Sending info command to device
2017.01.06 18:57:56.469 5: SW: sh

2017.01.06 18:57:56.471 5: ArduCOUNTER: ReadAnswer called
2017.01.06 18:57:56.586 4: ArduCOUNTER: device reported firmware 1.8
2017.01.06 18:57:56.589 3: ArduCOUNTER: device: normal interval 15000
2017.01.06 18:57:56.589 3: ArduCOUNTER: device: max interval 1200000
2017.01.06 18:57:56.590 3: ArduCOUNTER: device: min interval 5000
2017.01.06 18:57:56.590 3: ArduCOUNTER: device: min count 1
2017.01.06 18:57:56.590 3: ArduCOUNTER: device: pin 4 PCInt pin 20, iMode change, min len 30 ms falling, count 0 (+0) in 664069 ms Rej 0
2017.01.06 18:57:56.590 3: ArduCOUNTER: device: pin 5 PCInt pin 21, iMode change, min len 90 ms falling, count 9934 (+0) in 14472 ms Rej 0
2017.01.06 18:57:56.591 3: ArduCOUNTER: device: pin 6 PCInt pin 22, iMode change, min len 30 ms falling, count 0 (+0) in 664093 ms Rej 0
2017.01.06 18:57:56.591 3: ArduCOUNTER: device: Next report in 10881 Milliseconds
2017.01.06 18:57:56.591 5: ArduCOUNTER: ReadAnswer matched Next report in [0-9]+ Milliseconds
2017.01.06 18:58:22.449 4: ArduCOUNTER: Pin 5 (pin5) count 9935 (diff 1) in 25.766s, reject 0, result 0.140
2017.01.06 18:58:22.450 5: ArduCOUNTER: interval 18:57:56 until 18:58:22, First at 25766
2017.01.06 18:58:22.451 5: ArduCOUNTER: readingStartTime5 specified: setting reading timestamp to 18:57:56
2017.01.06 18:58:22.451 5: ArduCOUNTER: set readings power5 to 0.140, timeDiff5 to 25766 and countDiff5 to 1
2017.01.06 18:58:22.629 5: ArduCOUNTER: Device Time 78700.172, Drift -25.666s in 78604.308s, -0.03%
2017.01.06 18:58:37.481 4: ArduCOUNTER: Pin 5 (pin5) count 9936 (diff 1) in 25.517s, reject 0, result 0.141
2017.01.06 18:58:37.481 5: ArduCOUNTER: interval 18:58:11 until 18:58:37, First at 25517
2017.01.06 18:58:37.482 5: ArduCOUNTER: readingStartTime5 specified: setting reading timestamp to 18:58:11
2017.01.06 18:58:37.482 5: ArduCOUNTER: set readings power5 to 0.141, timeDiff5 to 25517 and countDiff5 to 1
2017.01.06 18:58:37.657 5: ArduCOUNTER: Device Time 78715.172, Drift -25.634s in 78619.340s, -0.03%
2017.01.06 18:59:07.679 4: ArduCOUNTER: Pin 5 (pin5) count 9937 (diff 1) in 25.887s, reject 0, result 0.139
2017.01.06 18:59:07.679 5: ArduCOUNTER: interval 18:58:41 until 18:59:07, First at 25887
2017.01.06 18:59:07.680 5: ArduCOUNTER: readingStartTime5 specified: setting reading timestamp to 18:58:41
2017.01.06 18:59:07.680 5: ArduCOUNTER: set readings power5 to 0.139, timeDiff5 to 25887 and countDiff5 to 1
2017.01.06 18:59:07.855 5: ArduCOUNTER: Device Time 78745.172, Drift -25.436s in 78649.538s, -0.03%
2017.01.06 18:59:28.962 0:
-             ---------------   SHUTDOWN !  ---------------
-
2017.01.06 18:59:29.163 0: Server shutdown

2017.01.06 19:00:21.542 1: Including ./log/fhem.save
2017.01.06 19:00:23.814 5: ArduCOUNTER: Notify called with events: INITIALIZED, open device and set timer to send hello to device
2017.01.06 19:00:23.815 3: Opening ArduCOUNTER device /dev/serial/by-path/platform-3f980000.usb-usb-0:1.2.2:1.0-port0
2017.01.06 19:00:23.822 3: Setting ArduCOUNTER serial parameters to 38400,8,N,1
2017.01.06 19:00:23.839 3: ArduCOUNTER device opened
2017.01.06 19:00:29.279 0: Featurelevel: 5.7
2017.01.06 19:00:29.279 0: Server started with 708 defined entities (fhem.pl:12955/2017-01-04 perl:5.020002 os:linux user:fhem pid:3909)
2017.01.06 19:00:32.649 3: ArduCOUNTER: sending h(ello) to device to ask for version
2017.01.06 19:00:32.649 5: SW: h
2017.01.06 19:00:36.093 4: ArduCOUNTER: Pin 5 (pin5) count 9938 (diff 1) in 26.271s, reject 0, result 0.137
2017.01.06 19:00:36.093 5: ArduCOUNTER: interval 19:00:09 until 19:00:36
2017.01.06 19:00:36.094 5: ArduCOUNTER: readingStartTime5 specified: setting reading timestamp to 19:00:09
2017.01.06 19:00:36.094 5: ArduCOUNTER: set readings power5 to 0.137, timeDiff5 to 26271 and countDiff5 to 1
2017.01.06 19:00:36.182 5: ArduCOUNTER: Initialize clock offset to 1483646860.9212
2017.01.06 19:00:36.183 5: ArduCOUNTER: Device Time 78775.172, Drift 0.000s in 0.000s
2017.01.06 19:00:36.183 3: ArduCOUNTER: device reported count
2017.01.06 19:00:36.184 3: ArduCOUNTER: device sent setup message, V1.8
2017.01.06 19:00:36.185 4: ArduCOUNTER: device reported firmware 1.8
2017.01.06 19:00:36.185 3: ArduCOUNTER: ConfigureDevice calls Attr with interval 15 1200 5 1
2017.01.06 19:00:36.185 5: SW: 15,1200,5,1i
2017.01.06 19:00:36.187 3: ArduCOUNTER: ConfigureDevice calls Attr with pinD5 falling pullup 90
2017.01.06 19:00:36.188 5: SW: 5,2,1,90a
2017.01.06 19:00:36.192 3: ArduCOUNTER: ConfigureDevice calls Attr with pinD6 falling pullup 30
2017.01.06 19:00:36.192 5: SW: 6,2,1,30a
2017.01.06 19:00:36.196 3: ArduCOUNTER: ConfigureDevice calls Attr with pinD4 falling pullup 30
2017.01.06 19:00:36.196 5: SW: 4,2,1,30a
2017.01.06 19:00:36.202 3: ArduCOUNTER: device replied to hello, V1.8
2017.01.06 19:00:36.202 4: ArduCOUNTER: device reported firmware 1.8

2017.01.06 19:01:12.182 3: ArduCOUNTER: device: intervals set to 15 1200 5 1
2017.01.06 19:01:12.182 3: ArduCOUNTER: device: defined pin 5 PCInt pin 21, iMode change, min len 90 ms falling, count 0 (+0) in 2 ms Rej 0
2017.01.06 19:01:12.183 3: ArduCOUNTER: device: defined pin 6 PCInt pin 22, iMode change, min len 30 ms falling, count 0 (+0) in 4 ms Rej 0
2017.01.06 19:01:12.183 3: ArduCOUNTER: device: defined pin 4 PCInt pin 20, iMode change, min len 30 ms falling, count 0 (+0) in 4 ms Rej 0
2017.01.06 19:01:51.179 4: ArduCOUNTER: Pin 5 (pin5) count 1 (diff 1) in 31.270s, reject 1, result 0.115
2017.01.06 19:01:51.180 5: ArduCOUNTER: interval 19:01:19 until 19:01:51
2017.01.06 19:01:51.180 5: ArduCOUNTER: readingStartTime5 specified: setting reading timestamp to 19:01:19
2017.01.06 19:01:51.181 5: ArduCOUNTER: set readings power5 to 0.115, timeDiff5 to 31270 and countDiff5 to 1
2017.01.06 19:01:51.305 5: ArduCOUNTER: device clock wrapped (now 85.919, before 78775.172). New offset is 1483725625.25978
2017.01.06 19:01:51.305 5: ArduCOUNTER: Device Time 85.919, Drift 0.000s in 75.086s, 0.00%

2017.01.06 19:02:36.164 4: ArduCOUNTER: Pin 5 (pin5) count 2 (diff 1) in 45.876s, reject 0, result 0.078
2017.01.06 19:02:36.164 5: ArduCOUNTER: interval 19:01:50 until 19:02:36, First at 45876
2017.01.06 19:02:36.165 5: ArduCOUNTER: readingStartTime5 specified: setting reading timestamp to 19:01:50
2017.01.06 19:02:36.166 5: ArduCOUNTER: set readings power5 to 0.078, timeDiff5 to 45876 and countDiff5 to 1
2017.01.06 19:02:36.353 5: ArduCOUNTER: Device Time 130.919, Drift -0.015s in 120.070s, -0.01%

2017.01.06 19:03:21.148 4: ArduCOUNTER: Pin 5 (pin5) count 3 (diff 1) in 46.496s, reject 0, result 0.077
2017.01.06 19:03:21.149 5: ArduCOUNTER: interval 19:02:34 until 19:03:21, First at 46496
2017.01.06 19:03:21.150 5: ArduCOUNTER: readingStartTime5 specified: setting reading timestamp to 19:02:34
2017.01.06 19:03:21.150 5: ArduCOUNTER: set readings power5 to 0.077, timeDiff5 to 46496 and countDiff5 to 1
2017.01.06 19:03:21.303 5: ArduCOUNTER: Device Time 175.92, Drift -0.031s in 165.055s, -0.02%

Gruß
BillyPbg

PS:
Ist die Log- und Info-Angabe "iMode change" im Modus "falling" korrekt - ein wenig verwirrend wegen rising-falling-change...

[StefanStrobel]

Was für Arduinos verwendet Ihr denn?
Ich denke das ganze ist ein Hardware-Thema ...
http://playground.arduino.cc/Main/DisablingAutoResetOnSerialConnection
Ich habe sowohl einen Jeenode als auch einen UNO von Sainsmart, die keinen Reset machen ...
Unabhängig davon sollte es aber auch nicht wirklich stören wenn der Arduino sich beim Neustart von Fhem auch neu startet. Der interne Zähler ist ja unabhängig von der Ausgabe der Impulse je Intervall und alle paar Wochen läuft der sowieso über.

Zum iMode: wenn eine Impulsdauer überwacht werden soll, steht iMode automatisch auf change. Rising der falling bedeutet dann ob der Puls steigend oder fallend beginnt. Sonst werden die Pausen statt der Impulslängen gemessen.
Ich könnte die Ausgbe von iMode natürlich auch weglassen - es ist ja eher eine interne Angabe.

Gruß
    Stefan

[BillyPbg]

Hallo Stefan,

Danke für die "iMode" Infos.
Bezüglich der Hardware - wie bereits erwähnt, ist es bei mir ein Nano 3.0, Modell "China-Direct".

Bisher hatte ich die Nullung über die "monotonic"-Userreadings als Basis für weitere Auswertungen gelöst.
Und diesen Mechanismus könntest Du ja auch - somit wäre das Ganze unabhängig von der Hardware - in das Modul  für die beiden Werte implementieren, was zudem das Thema des Überlaufs somit sowieso erschlagen würde.

Ergänzenderweise fände ich (Achtung Idee...  noch einen Lösungsansatz interessant, zwecks fiktive Ergänzung für die verlustig gehenden Impulse während der "Shutdown Restart" Pausen:

Zum Beispiel in der Art, dass wenn man die letzten (z.B.) fünf Werte abgleicht mittels Durchschnittsbildung, diesen in Beziehung setzt mit der Länge der "Pause" bis zum nächsten regulären Impuls, vorausgesetzt dass die Pause nur maximal (z.B.) eine Minute, oder mindestens aber einen "Durchschnitts"-Impuls dauert und der regulär folgende Wert in einem Karenzraum von (z.B.) +-5%, ersatzweise der nächsten (z.B.) fünf Werte im Durchschnitt +-XX Prozent.

Die zur Berechnung nötigen Werte und Daten würde ich unbedingt mittels Temp- oder Log-Datei absturzsicher machen wollen, was dann die Zuverlässigkeit des durchgehenden Zählens und somit die Qualität des Moduls nochmal enorm steigern würde.

Und sollte dann eine "Unterbrechung" stattfinden, die nicht mehr nachberechnet werden kann, sollte das z.B. per INTERNAL Reading eindeutig signalisiert werden (z.B. "Unterbrechung von XX:XX bis XX:XX Uhr/ Datum - Zählerstände prüfen!").
Über dieses Reading könnte man dann auch nachberechnete Impulse im selben Stil mit Handlungsaufforderung, sprich Warnung anzeigen (z.B. "Nachberechnete Impulse von XX:XX bis XX:XX Uhr/ Datum, Anzahl XX - Zählerstände prüfen!")
Dies wiederum könnte dann vom User oder bereits mittels Modulattribut mit einem DevStateIcon (z.B. farbige Warndreiecke) oder entsprechend DevStateStyle (rot/gelb/grün) signalisiert werden.

Zudem würde ich diese berechneten Werte in einem gesonderten Reading (parallel zum "pinDx", oder als Attribut: 'Erkannte verarbeitete Impulse/ Getrennt (verarbeitete und berechnete Impulse, zwei Readings)/ Beide zusammen' ) deklarieren wollen, um diese gesondert mittels Log je nach persönlicher Situation und Gusto auswerten lassen zu können.

Was hältst Du davon, machbar ?

Gruß
BillyPbg

[StefanStrobel]

Hallo BillyPbg,

machbar ist vieles. Ich nehme es mal in die langfristige Wunschliste auf.

Übrigens habe ich den Wiki-Eintrag zum ArduCounter heute mal überarbeitet.
Falls jemand noch Fehler / wichtige fehlende Details hat, dürft Ihr das gerne ergänzen.

Gruss
    Stefan

[StefanStrobel]

Hallo,

ich habe die letzt Version im svn eingecheckt und von contrib in den normalen Bereich verschoben, so dass sie per update verteilt wird. Schaut doch mal ob es bei Euch problemlos ankommt.

Gruss / Thanx
    Stefan

[Otto123]

Hallo Stefan,

die version ist angekommen -> 98_ArduCounter.pm           13345 2017-02-06 18:22:20Z StefanStrobel
Vielen Dank.
Wegen dem Reset Verhalten bin ich noch am prüfen, ich denke es ist wohl normal/so gewollt. Wenn die serielle Schnittstelle initialisiert wird, wird über DTR ein reset ausgelöst. Aber wie gesagt, habe ich bisher nur gelesen und bin noch dabei zu testen.

Was mir jetzt noch auffiel: Man kann keinen leeren Arduino nano damit in Betrieb nehmen. Das Modul prüft immer ob die Schnittstelle geöffnet ist, ist natürlich ohne Firmware nicht der Fall.
Damit bekommt man leider die Firmware nicht drauf. Geht man ins Terminal und kopiert die Zeile flashCommand dann geht es sofort. Danach habe ich FHEM neu gestartet (reload 98_ArduCounter.pm hätte vielleicht gereicht?) und alles lief.

Vielleicht noch als Idee für Verbesserung, flash auch versuchen wenn Schnittstelle nicht geöffnet. 

Gruß Otto

[Otto123]

Hallo Stefan,

ich habe jetzt die "Eigenheit" des Arduino nano ermittelt.
Das Reset Pin ist mit einem 1 kOhm Widerstand nach 5 Volt geführt und wird über einen Kondensator vom DTR Pin beim Initialisieren der seriellen Schnittstelle kurz nach Masse gezogen. Das löst den Reset aus, da beim Neustart von FHEM auch die serielle Schnittstelle zurückgesetzt/initialisiert wird. Sieht dann so aus:

Code Auswählen Erweitern

2017.02.08 14:02:31 3: Opening AC device /dev/ttyUSB0
2017.02.08 14:02:31 3: Setting AC serial parameters to 38400,8,N,1
2017.02.08 14:02:31 3: AC device opened
2017.02.08 14:02:32 0: Server started with 16 defined entities (fhem.pl:13334/2017-02-05 perl:5.020002 os:linux user:fhem pid:17892)
2017.02.08 14:02:34 3: AC: device sent setup message, V1.8
2017.02.08 14:02:34 3: AC: ConfigureDevice calls Attr with pinD4 falling pullup
2017.02.08 14:02:34 3: AC: device: defined pin 4 PCInt pin 20, iMode falling, no min len, count 0 (+0) in 0 ms

Mit einem zusätzlichen Widerstand von 220 Ohm von RST nach 5 Volt kann man den Reset über DTR verhindern, sieht dann so aus:

Code Auswählen Erweitern

2017.02.08 14:35:00 3: Opening AC device /dev/ttyUSB0
2017.02.08 14:35:00 3: Setting AC serial parameters to 38400,8,N,1
2017.02.08 14:35:00 3: AC device opened
2017.02.08 14:35:00 0: Server started with 16 defined entities (fhem.pl:13334/2017-02-05 perl:5.020002 os:linux user:fhem pid:18652)
2017.02.08 14:35:03 3: AC: sending h(ello) to device to ask for version
2017.02.08 14:35:03 3: AC: device replied to hello, V1.8
2017.02.08 14:35:03 3: AC: ConfigureDevice calls Attr with pinD4 falling pullup
2017.02.08 14:35:03 3: AC: device: defined pin 4 PCInt pin 20, iMode falling, no min len, count 296 (+0) in 47944 ms

Also irgendwie erklärbar.

Wie schon gesagt, vielleicht kannst Du das Flashen von einem frischen Arduino nano ja noch umstricken, also nicht abfragen ob das Modul schon opened ist. 

Gruß Otto

[StefanStrobel]

Hallo Otto,

vielen Dank für den Hinweis.
Das klingt sinnvoll und ich schau mal wie ich das umgesetzt bekomme.

Gruss
   Stefan

[Otto123]

Hallo Stefan,

zur Commandref: Das Modul braucht ja keine besonderen Perlmodule, die FHEM nicht sowieso braucht. Aber zum Flashen braucht man avrdude.  Das solltest Du vielleicht in der commandref am Anfang mit erwähnen, auch das man keine besonderen Berechtigungen braucht. Es ist wirklich simpel. Hier stand ja mal in einem Post: man bräuchte eine Wikianleitung für avrdude, kann ich nicht  nachvollziehen -> das geht einfach.

Ich mag es wenn klar da steht, was ich zusätzlich installieren muss. 

Gruß Otto

[StefanStrobel]

Guter Hinweis, kommt in der nächsten Version.

Gruss
   Stefan

[Naiszen]

Nach dem Update habe ich jetzt ständig dieses Problem...

2017.02.13 12:35:11 3: Setting AC serial parameters to 9600,8,N,1
2017.02.13 12:35:11 3: AC device opened
2017.02.13 12:35:11 3: NTFY return:  AC:1486985714.53514
2017.02.13 12:35:14 3: AC: sending h(ello) to device to ask for version
2017.02.13 12:35:17 3: AC: device didn't reply to h(ello). Is the right sketch flashed?

vorher ging alles mit der alten Version ohne Probleme

[Otto123]

Hi,

Der Sketch (Firmware Arduino) und das Modul wurden geändert.
du musst entweder (einfach):
aus dem Restore Verzeichnis  die alte Modul Version wieder nehmen.
Oder (etwas aufwendiger):
den neuen sketch flashen (geht direkt aus dem Modul, du musst nur avrdude installiert haben)
die DEF von 9600 auf 38400 ändern

Gruß Otto

[Naiszen]

Sehr schon, Vielen Dank.
Ich hatte schon alles gemacht, mir leider nicht die DEF auf 38400. Das habe ich wohl übersehen, jedenfalls nicht gelesen. nun klappt alles wieder.

Jetzt habe ich aber doch noch eine Frage, kann man beim Arducounter etwas gegen dieses Alzheimer machen, wenn das Gerät mal kurz ohne Strom ist?
Habe das Problem z.b. wenn ich immer mal wieder von der Karte ein Backup mache.

Viele Grüße