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

[thymjan]

fhem ist mit folgender Fehlermeldung wieder abgestürzt:

Code: [Auswählen]

Undefined subroutine &ArduCounter::DevIo_getState called at ./FHEM/98_ArduCounter.pm line 437.
EDIT:
Habe im Import-Abschnitt noch "DevIo_getState" hinzugefügt.

[thymjan]

Wie ich gesagt habe, läuft der ArduCounter auf dem ESP32 jetzt weitestgehend ohne Unterbrechungen durch.
Aber ich habe ein seltsames Verhalten beobachtet: Der ArduCounter hat jetzt auch schon mehrfach seine IP-Adresse geändert. Damit verliert er dann dauerhaft die Verbindung zu fhem. Habe dann versucht statt der IP-Adresse den DNS-Namen anzugeben.
Das scheitert dann an folgendem Verhalten:
Ist der ArduCounter im Konfigurationsmodus nennt er sich "espressif". Ist er im Zählmodus nennt er sich "esp32-xxxxxxxxxxxx" (xxxxxxxxxxxx=MAC-Adresse).
Ist das so gewollt, dass sich der DNS-Name im Betrieb (bzw. beim Reset) ändert?

[DerD]

Dass sich die IP-Adresse ändert, hängt doch am Router. Ich habe seither eine Fritzbox, und da die IP fixiert.

Was meinst du mit Konfigurationsmodus? Arbeitet dabei der ESP selber als AP? meine Erfahrung mit DNS-Namen ist, dass die etwas brauchen bis man sie sie ansprechen kann. Verifiziieren kann man das über einen Ping

[DerD]

Ich habe folgendes Problem, per Reflexlichtschranke am Ferraris werden die Pulse als Dip erkannt. Soweit gut:

Code: [Auswählen]

Seq      4 2022-11-27 19:19:05 Pin A0 232.073 seconds at 1 (analog 732) -> gap
Seq      5 2022-11-27 19:22:57 Pin A0  11.405 seconds at 0 (analog 28) -> pulse counted

Erwarten würde ich, dass PowerA0 mir den aktuellen Verbrauch in W anzeigt, je nach Pulsdauer. Der ändert sich aber nicht kontinuierlich, sondern springt von 0W direkt auf 800W.

Ich verstehe auch nicht, wie die Pulsdauer in die Rechnung eingeht. Meine Vermutung wäre dauer-Gap plus dauer-Puls, bzw. von einem fallenden Trigger zum nächsten. Oder bin ich damit falsch?

Code: [Auswählen]

attr ESP_Hauptstrom pinA0 falling pullup min 4 analog out 27 threshold 60,550
attr ESP_Hauptstrom readingPulsesPerUnitA0 75
attr ESP_Hauptstrom enableAnalogDebug 1
attr ESP_Hauptstrom enableHistory 1
attr ESP_Hauptstrom verboseReadingsA0 1
attr ESP_Hauptstrom readingFlowUnitTimeA0 3600000


[thymjan]

Dass sich die IP-Adresse ändert, hängt doch am Router. Ich habe seither eine Fritzbox, und da die IP fixiert.

Was meinst du mit Konfigurationsmodus? Arbeitet dabei der ESP selber als AP? meine Erfahrung mit DNS-Namen ist, dass die etwas brauchen bis man sie sie ansprechen kann. Verifiziieren kann man das über einen Ping

Meine Vermutung ist, dass die FritzBox neue IP-Adressen im laufenden Betrieb vergibt, da der ArduCounter zwischen 2 DNS-Namen gelegentlich wechselt. Nach einem Reset durchläuft der ArduCounter kurz das Espressif-Modul zur Konfiguration (blauer Hintergrund bei ESP mit Display). Nach dem ich den IP-Adress-Wechsel bemerkt habe, habe ich die feste IP-Adresse jetzt in der FritzBox eingestellt.

[thymjan]

@DerD Zu Deiner zweiten Frage:
Wie hast Du denn Dein interval-Attribut konfiguriert?
Hiermit kann man die Kurve "glätten". Wenn sich die Scheibe nur langsam dreht, passiert ja lange Zeit (mehrere Minuten) bei der Messung nichts bis der kurze Impuls (wenige Minuten oder Sekunden) kommt.
Im Diagramm sieht man dann jeweils einen Balken und dann wieder nichts. Obwohl vermutlich ein kleiner Verbraucher dauerhaft Strom zieht.

Ich habe mein Interval-Attribut so konfiguriert:

Code: [Auswählen]

interval 30,1800,5,2,10,3Damit wird in der Regel alle 30 Sekunden, höchstens nach 5 Sekunden und mindestens alle 30 Minuten ein Wert ausgegeben/berechnet.
Eine analoge Messung findet nach 10ms wieder statt, und es werden jeweils 3 analoge Messungen miteinander verrechnet.

interval <normal> <max> [<min> <min count> [<analog interval> <analog samples>]]
Defines the parameters that affect the way counting and reporting works. This Attribute expects at least two and a maximum of six numbers as value. The first is the normal interval (s), the second the maximal interval (s), the third is a minimal interval (s) and the fourth is a minimal pulse count. The last two numbers are only needed for counting with reflective light barriers. They specify the delay between the measurements (ms) and the number of samples for each measurement.

In the usual operation mode (when the normal interval is smaller than the maximum interval), the Arduino board just counts and remembers the time between the first impulse and the last impulse for each pin.
After the normal interval is elapsed the Arduino board reports the count and time for those pins where impulses were encountered.
This means that even though the normal interval might be 10 seconds, the reported time difference can be something different because it observed impulses as starting and ending point.
The Power (e.g. for energy meters) is then calculated based of the counted impulses and the time between the first and the last impulse.
For the next interval, the starting time will be the time of the last impulse in the previous reporting period and the time difference will be taken up to the last impulse before the reporting interval has elapsed.

The second, third and fourth numbers (maximum, minimal interval and minimal count) exist for the special case when the pulse frequency is very low and the reporting time is comparatively short.
For example if the normal interval (first number) is 60 seconds and the device counts only one impulse in 90 seconds, the the calculated power reading will jump up and down and will give ugly numbers.
By adjusting the other numbers of this attribute this can be avoided.
In case in the normal interval the observed impulses are encountered in a time difference that is smaller than the third number (minimal interval) or if the number of impulses counted is smaller than the fourth number (minimal count) then the reporting is delayed until the maximum interval has elapsed or the above conditions have changed after another normal interval.
This way the counter will report a higher number of pulses counted and a larger time difference back to fhem.

[DerD]

Bisher hatte ich "interval" noch nicht definiert, einerseits weil ich eigentlich keine Mittelung der Werte wollte, sondern direkte Anzeige des letzten Durchganges. Und zweitens weil ich den Parameter nicht vollständig durchschaue,

Ich habe das Attribut jetzt mal gesetzt auf

Code: [Auswählen]

attr ESP_Hauptstrom interval 30,1800,5,2,10,1und beobachte. Da die Durchgänge gerade relativ gleichmäßig lang sind, ist kann ich noch nichts näheres sagen.

edit: Tippfehler korrigiert

[thymjan]

Du hast jetzt nur 5 Werte angegeben. Nach Definition müssten es 6 sein.

[DerD]

War nur ein Eingabefehler oben, den letzten habe ich auf 1 gesetzt, was aber unnötig war (hatte es immer noch nicht verstanden): Mittelung der analogen Messwerte, nicht Mittelung der Umdrehungsperioden

Jetzt geht es in fhem daran, mit den Werten was zu machen, zumindest erst einmal eine Zeitreihe zu speichern. Das gehört dann aber nicht mehr hierher

[thymjan]

Sorry - neuer Versuch ...

Gruss
    Stefan

Hallo Stefan,

mit den zwei Änderungen: Im Import-Abschnitt noch "DevIo_getState" hinzufügen und in meiner FritzBox dem ArduCounter eine feste IP-Adresse zuweisen, läuft die Kommunikation jetzt ohne Unterbrechungen.

Grüße,
Stefan

[StefanStrobel]

Vielen Dank!
Hab die Änderung schon übernommen und checke dann demnächst die neue Version ins SVN ein.

Gruß
    Stefan

[RalfRog]

... ohne stateFormat läufts wie geschmiert! Keine längeren disconnect-Episoden mehr.

Puh warum auch immer hat es mich jetzt auch erwischt (mit alter Version). Seit kurz vor Mitternacht am 2.12 sehe ich im Log alle 2 sek.:

Code: [Auswählen]

2022.12.02 23:48:22.026 3: Zaehler_ESP32: device didn't reply to k(eeepAlive), count=1
2022.12.02 23:48:34.611 3: 10.20.30.13:80 disconnected, waiting to reappear (Zaehler_ESP32)
2022.12.02 23:48:34.640 3: 10.20.30.13:80 reappeared (Zaehler_ESP32)
Ein Update auf die Version vom "98_ArduCounter.pm:0.267900/2022-12-05" bringt keine Abhilfe.
Muss ich wohl auch mal was tiefer einsteigen ggfs. erstmal den Arducounter neu starten. Ich berichte.

[RalfRog]

Nachdem ich den Ardcounter stromlos gemacht habe sieht es erstmal wieder normal aus:

Code: [Auswählen]

2022.12.07 22:40:49.924 5: Zaehler_ESP32: sending k(eepAlive) to device
2022.12.07 22:40:49.926 5: DevIo_SimpleWrite Zaehler_ESP32: 1,60k.
2022.12.07 22:40:49.963 5: Zaehler_ESP32: device sent alive response: AR-76Analog zu Stefans Antwort #734   https://forum.fhem.de/index.php/topic,19285.msg1246900.html#msg1246900

Hoffen wir es bleibt so 

Edit:
Feste IP nutze ich immer für Nicht-Endgeräte und was bedeuet >Import-Abschnitt noch "DevIo_getState" hinzufügen"< ?

[RalfRog]

... und nach Spielerrei mit dem FritzBox-Fork und einigen Restarts will der Arducounter sich nicht mehr "connecten" trotz existierender WLAN Verbindung mit Dauerping.
Hmm..

Code: [Auswählen]

2022.12.10 16:40:30.786 3 : Zaehler_ESP32: device didn't reply to k(eeepAlive), count=1
2022.12.10 16:40:30.793 3 : 10.20.30.13:80 disconnected, waiting to reappear (Zaehler_ESP32)
2022.12.10 16:40:30.823 3 : 10.20.30.13:80 reappeared (Zaehler_ESP32)
2022.12.10 16:40:32.838 3 : Zaehler_ESP32: device didn't reply to k(eeepAlive), count=2
2022.12.10 16:40:32.843 3 : 10.20.30.13:80 disconnected, waiting to reappear (Zaehler_ESP32)
2022.12.10 16:40:32.888 3 : 10.20.30.13:80 reappeared (Zaehler_ESP32)

Mit dem Browser erreiche ich über 10.20.30.13:80 den WIFI-Manager. War das korrekt so wenn der ArduCounter richtig läuft?

uups war wohl was leichtfertig im WIFI-Manager die Seite /restart auszuführen...

[thymjan]

Versuch nochmal in der FritzBox die Einstellung zur festen IP-Adresse und sonstige Verbindungen zum ArduCounter zu löschen (wenn der ArduCounter aus ist).
Bevor ich dem ArduCounter eine feste IP in der FritzBox vergeben habe, hat die FritzBox mit jedem Reboot eine neue IP vergeben.
Wenn der ArduCounter sich (dann hoffentlich) wieder mit der FritzBox verbunden hat und eine Verbindung zu FHEM hergestellt hat würde ich in der FritzBox die feste IP wieder aktivieren.