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

[DerD]

Hallo Stefan,

Gern teste ich auch die neue Version. Für ESP32dev. Könnte ja selber kompilieren, dazu müsste ich mich nur wieder in PlatformIO einarbeiten  Eine kompilierte Version wäre also toll 

Noch eine Frage: ich würde das auf einem Testsystem laufen lassen, ESPs habe ich noch hier. Gibt es eine einfache Möglichkeit, einen Puls am Eingang anstelle des Lesekopfs auch zu simulieren?

[StefanStrobel]

Hallo Dieter,

anbei eine Firmware für den ESP32. Bootloader etc. kann vermutlich gleich bleiben.
Zum Simulieren von Impulsen kannst Du einfach den Eingang mit einem Taster mit GND verbinden.

Gruss
   Stefan

[DerD]

Hallo Stefan,
habe mich gestern abend durch Platformio gekämpft, und build bzw upload erfolgreich geschafft. Soweit ich gesehen habe, ist im source ja nur das

Code Auswählen Erweitern

WiFiServer Server(80);              // For ESP WiFi connection
ersetzt durch

Code Auswählen Erweitern

WiFiServer Server(23);              // For ESP WiFi connection
. Oder gibt es sonst Änderungen?

Mein Testergebnis bisher, ohne Pulse am Eingang:
ich boote den ESP ohne Zugriff auf mein WLAN, so dass der Wifimanager anspringt, und mache dann das reguläre WLAN verfügbar. In beiden Fällen geht er im FHEM in state "opened", bei Verbindung über Port80 erfolgt allerdings alle 10s ein Reconnect, bei Port 23 nicht.
Beim boot mit verfügbarem WLAN sehe ich keinen Unterschied.

Müsste man aus den Logs, FHEM bzw. seriell, etwas herauslesen können?

So ganz aussagekräftig finde ich es noch nicht, werde wohl doch zusätzlich noch Pulse simulieren müssen.

PS: Port 23 ist doch eigentlich für unverschlüsselten Telnet vorgesehen. Ist das eine gute Idee, den dafür zu nutzen?

[StefanStrobel]

Hallo Dieter,

Ja, ich habe nur den Port geändert. 80 wird vom WifiManager verwendet. Deshalb kann das Fhem-Modul sich zwar verbinden, aber der WifiManager liefert natürlich nicht die Zählerwerte und antwortet auch nicht auf die Keepalive-Requests. Deshalb wird die Verbindung gleich wieder geschlossen.
Bei jedem anderen Port außer 80 besteht das Problem nicht. Der Arducounter auf einem ESP bietet ja sonst keine Netzwerkdiensten an. Port 23 ist dabei so gut wie irgend ein anderer und da das Protokoll unverschlüsselte Text-Befehle austauscht, fand ich 23 ganz passend.

Wenn keine Reconnects im Log auftauchen, ist das erst mal ein gutes Zeichen.

Gruß
   Stefan

[DerD]

Hallo Stefan,

doppelt überprüft, Umstellung auf Port23 löst das Problem, auf Port80 ist es wieder da. Zum Test war nur etwas lästig, dass der ESP beim Booten nie das WLAN sehen darf.

Als Taktgenerator habe ich statt Taster kurzfristig einen Digispark rangedongelt.

Wie bekomme ich das jetzt auf meinen richtigen Counter? OTA via FHEM probiere auch vorher am Test-ESP aus, klar. Das habe ich bisher noch nie gemacht. Aber dann sind ja die ganzen im ESP gespeicherten Werte weg, oder?

Edit:
OTA funktioniert irgendwie nicht, habe es auf Port23 und 80 probiert. Es kommt immer folgender Fehler:

Code Auswählen Erweitern

command: espota.py -i -p 3232 -f ./FHEM/firmware/ArduCounter-ESP32.bin 2>./log/ArduCounterFlash.log

--- flash command ---------------------------------------------------------------------------------
Sending invitation to -p failed
22:41:12 [ERROR]: Host -p Not Found
--- flash command ---------------------------------------------------------------------------------

Im Log steht folgendes

Code Auswählen Erweitern

2023.07.28 22:41:12 1: PERL WARNING: Use of uninitialized value $ip in substitution (s///) at ./FHEM/98_ArduCounter.pm line 1310.
2023.07.28 22:41:12 1: stacktrace:
2023.07.28 22:41:12 1:     main::__ANON__                      called by ./FHEM/98_ArduCounter.pm (1310)
2023.07.28 22:41:12 1:     ArduCounter::DoFlash                called by ./FHEM/98_ArduCounter.pm (1474)
2023.07.28 22:41:12 1:     ArduCounter::SetFn                  called by fhem.pl (3975)
2023.07.28 22:41:12 1:     main::CallFn                        called by fhem.pl (1966)
2023.07.28 22:41:12 1:     main::DoSet                         called by fhem.pl (1998)
2023.07.28 22:41:12 1:     main::CommandSet                    called by fhem.pl (1278)
2023.07.28 22:41:12 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2850)
2023.07.28 22:41:12 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (1024)
2023.07.28 22:41:12 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (609)
2023.07.28 22:41:12 1:     main::FW_Read                       called by fhem.pl (3980)
2023.07.28 22:41:12 1:     main::CallFn                        called by fhem.pl (784)

Problem gelöst: ich musste die IP-Adresse manuell im flash-command angeben, da der ESP über den Namen definiert ist.

[efyzz]

Moin,

ich habe den ArduCounter schon seit einigen Jahren problemlos genutzt. Der Arduino Nano ist über ein sehr langes USB-Kabel angebunden, daher habe ich eine sehr niedrige Baudrate gewählt. Nun habe ich das gesamte System auf meinem Raspberry neu aufgesetzt und folgendes merkwürdiges Problem:

Der ArduCounter ist definiert mit:

Code Auswählen Erweitern

/dev/ttyStromzaehler@19200("ttyStromzaehler" stammt aus einer udev-Rule)

Immer wenn FHEM neu startet, bleibt zwar die DEF wie oben angegeben, aber der DeviceName ist plötzlich zu

Code Auswählen Erweitern

/dev/ttyStromzaehler@38400 geworden   
Scheinbar stimmt dann wirklich die Baudrate nicht mehr, denn der Arduino sendet nur noch Hieroglyphen.

Ich kann das wieder zum Laufen bringen, indem ich die DEF einmal auf auf 38400 und wieder zurück auf 19200 stelle. Dann stehen die 19200 auch wieder im DeviceName und alles funktioniert - bis zum nächsten Neustart.

Ich habe die ArduCounter Version 3.34 auf dem Arduino.

Würde es wohl helfen, den Arduino mit der aktuellen Firmware zu flashen?

Muss ich dann damit rechnen, dass irgendwelche Einstellungen oder Zählerstände auf dem Arduino zurückgesetzt werden? Und wenn ja, kann ich davon ein Backup machen?

Und nebenbei, wieso tritt das Problem erst jetzt auf? Mein Betriebssystem auf dem Raspberry war zwar veraltet (vorher Jessie, jetzt Bookworm), aber das FHEM war immer recht aktuell. Also wird das Problem vielleicht irgendwie vom Betriebssystem hervorgerufen?

Danke euch!

[StefanStrobel]

Hallo efyzz,

wenn de Kommunikation mit dem ArduCounter nicht klappt, versucht das Modul alternative Geschwindigkeiten für den Fall dass die falsch eingestellt ist oder ein Sketch mit anderer Geschwindigkeit geflasht wurde:

Code Auswählen Erweitern

sub HelloTimeout {
    my $param = shift;
    my (undef,$name) = split(/:/,$param);
    my $hash = $defs{$name};
    delete $hash->{WaitForHello};
    RemoveInternalTimer ("hwait:$name");

    if ($hash->{DeviceName} !~ m/^(.+):([0-9]+)$/) {        # not TCP
        if (!$hash->{OpenRetries}) {
            $hash->{OpenRetries} = 1;
        }
        else {
            $hash->{OpenRetries}++;
            if ($hash->{OpenRetries}++ > 4) {
                Log3 $name, 3, "$name: device didn't reply to h(ello). Is the right sketch flashed? Is serial speed set to 38400 or 115200 for firmware >4.0?";               
                return;
            }
        }
        Log3 $name, 5, "$name: HelloTimeout: DeviceName in hash is $hash->{DeviceName}";
        if ($hash->{DeviceName} !~ /(.+)@([0-9]+)(.*)/) {   # no serial speed specified
            $hash->{DeviceName} .= '@38400';                # should not happen (added during define)
            Log3 $name, 3, "$name: device didn't reply to h(ello). No serial speed set. Is the right sketch flashed? Trying again with \@38400";
        }
        else {                                   
            if ($2 == 38400) {             
                $hash->{DeviceName} = "${1}\@115200${3}";    # now try 115200 if 38400 before
                Log3 $name, 3, "$name: device didn't reply to h(ello). Is the right sketch flashed? Serial speed was $2. Trying again with \@115200";
            }
            else {
                $hash->{DeviceName} = "${1}\@38400${3}";    # now try 38400
                Log3 $name, 3, "$name: device didn't reply to h(ello). Is the right sketch flashed? Serial speed was $2. Trying again with \@38400";
            }
        }
        Log3 $name, 5, "$name: HelloTimeout: DeviceName in hash is set to $hash->{DeviceName}";
        DoOpen($hash);                            # try again                             
    }
    return;
}

wenn Du verbose auf 5 setzt, solltest Du sehen was tatsächlich passiert.
Eventuell hat sich im OS etwas geändert und Das Modul ist zu schnell mit dem Umstellen der Geschwindigkeit.
Probier doch mal helloWaitTime von 2 auf 5 zu setzen.

Gruss
   Stefan

[efyzz]

Hallo Stefan,

vielen Dank für die umfassende Antwort 

Ich habe zunächst verbose 5 gesetzt und neu gestartet:

Code Auswählen Erweitern

2023.11.26 17:24:56 1: in INITIALIZED
2023.11.26 17:24:56 3: Stromzaehler: Notify called with events: INITIALIZED, open device and set timer to send hello to device
2023.11.26 17:24:56 4: Stromzaehler: trying to open connection to /dev/ttyStromzaehler@19200
2023.11.26 17:24:56 3: Opening Stromzaehler device /dev/ttyStromzaehler
2023.11.26 17:24:56 3: Setting Stromzaehler serial parameters to 19200,8,N,1
2023.11.26 17:24:56 3: Stromzaehler device opened
2023.11.26 17:24:56 5: Stromzaehler: DoOpen succeeded in callback
2023.11.26 17:24:56 5: Stromzaehler: DoOpen succeeded immediately
2023.11.26 17:24:56 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/10_OWServer.pm line 496.
2023.11.26 17:24:56 0: Featurelevel: 6.2
2023.11.26 17:24:56 0: Server started with 660 defined entities (fhem.pl:28126/2023-11-05 perl:5.036000 os:linux user:fhem pid:857)
2023.11.26 17:25:00 5: Stromzaehler: call configureDisplay after delay
2023.11.26 17:25:00 3: Stromzaehler: Invalid device display configuration
2023.11.26 17:25:00 3: Stromzaehler: unparseable message from device: ~�)
2023.11.26 17:25:00 3: Stromzaehler: unparseable message from device: ␌L␎L␈���{�H␌␌��
2023.11.26 17:25:00 3: Stromzaehler: unparseable message from device: @�N�((
2023.11.26 17:25:00 3: Stromzaehler: unparseable message from device: ̈␈�␌�{�H␌␌�
2023.11.26 17:25:00 3: Stromzaehler: unparseable message from device: �␌@��D got 0,0y size 2
2023.11.26 17:25:00 4: Stromzaehler: device: got 1y size 1
2023.11.26 17:25:00 4: Stromzaehler: device: got 91y size 1
2023.11.26 17:25:00 5: Stromzaehler: ArduCounter 8.01 - 04.12.2022 sending h(ello) to device to ask for firmware version
2023.11.26 17:25:00 5: DevIo_SimpleWrite Stromzaehler: h.
2023.11.26 17:25:03 5: Stromzaehler: HelloTimeout: DeviceName in hash is /dev/ttyStromzaehler@19200
2023.11.26 17:25:03 3: Stromzaehler: device didn't reply to h(ello). Is the right sketch flashed? Serial speed was 19200. Trying again with @38400
2023.11.26 17:25:03 5: Stromzaehler: HelloTimeout: DeviceName in hash is set to /dev/ttyStromzaehler@38400
2023.11.26 17:25:03 4: Stromzaehler: trying to open connection to /dev/ttyStromzaehler@38400
2023.11.26 17:25:03 3: Opening Stromzaehler device /dev/ttyStromzaehler
2023.11.26 17:25:03 3: Setting Stromzaehler serial parameters to 38400,8,N,1
2023.11.26 17:25:03 3: Stromzaehler device opened
2023.11.26 17:25:03 5: Stromzaehler: DoOpen succeeded in callback
2023.11.26 17:25:03 5: Stromzaehler: DoOpen succeeded immediately
2023.11.26 17:25:07 5: Stromzaehler: ArduCounter 8.01 - 04.12.2022 sending h(ello) to device to ask for firmware version
2023.11.26 17:25:07 5: DevIo_SimpleWrite Stromzaehler: h.
2023.11.26 17:25:09 5: Stromzaehler: HelloTimeout: DeviceName in hash is /dev/ttyStromzaehler@38400
2023.11.26 17:25:09 3: Stromzaehler: device didn't reply to h(ello). Is the right sketch flashed? Serial speed was 38400. Trying again with @115200
2023.11.26 17:25:09 5: Stromzaehler: HelloTimeout: DeviceName in hash is set to /dev/ttyStromzaehler@115200
2023.11.26 17:25:09 4: Stromzaehler: trying to open connection to /dev/ttyStromzaehler@115200
2023.11.26 17:25:09 3: Opening Stromzaehler device /dev/ttyStromzaehler
2023.11.26 17:25:09 3: Setting Stromzaehler serial parameters to 115200,8,N,1
2023.11.26 17:25:09 3: Stromzaehler device opened
2023.11.26 17:25:09 5: Stromzaehler: DoOpen succeeded in callback
2023.11.26 17:25:09 5: Stromzaehler: DoOpen succeeded immediately
2023.11.26 17:25:13 5: Stromzaehler: ArduCounter 8.01 - 04.12.2022 sending h(ello) to device to ask for firmware version
2023.11.26 17:25:13 5: DevIo_SimpleWrite Stromzaehler: h.
2023.11.26 17:25:15 5: Stromzaehler: HelloTimeout: DeviceName in hash is /dev/ttyStromzaehler@115200
2023.11.26 17:25:15 3: Stromzaehler: device didn't reply to h(ello). Is the right sketch flashed? Serial speed was 115200. Trying again with @38400
2023.11.26 17:25:15 5: Stromzaehler: HelloTimeout: DeviceName in hash is set to /dev/ttyStromzaehler@38400
2023.11.26 17:25:15 4: Stromzaehler: trying to open connection to /dev/ttyStromzaehler@38400
2023.11.26 17:25:15 3: Opening Stromzaehler device /dev/ttyStromzaehler
2023.11.26 17:25:15 3: Setting Stromzaehler serial parameters to 38400,8,N,1
2023.11.26 17:25:15 3: Stromzaehler device opened
2023.11.26 17:25:15 5: Stromzaehler: DoOpen succeeded in callback
2023.11.26 17:25:15 5: Stromzaehler: DoOpen succeeded immediately
2023.11.26 17:25:19 5: Stromzaehler: ArduCounter 8.01 - 04.12.2022 sending h(ello) to device to ask for firmware version
2023.11.26 17:25:19 5: DevIo_SimpleWrite Stromzaehler: h.
2023.11.26 17:25:21 3: Stromzaehler: device didn't reply to h(ello). Is the right sketch flashed? Is serial speed set to 38400 or 115200 for firmware >4.0?
2023.11.26 17:26:05 5: Stromzaehler: Attr called with set Stromzaehler helloWaitTime 5
2023.11.26 17:26:05 1: in ATTR
2023.11.26 17:26:09 1: in SAVE
2023.11.26 17:27:51 1: in SHUTDOWN
2023.11.26 17:27:51 0: Server shutdown
Man sieht, dass die Kommunikation scheinbar nicht erfolgreich war und die Baudrate variiert wird.

Interessanterweise sind gleich am Anfang Hieroglyphen zu sehen, noch bevor (h)ello gesendet wird. Wo kommt das denn her?

Nachdem ich helloWaitTime auf 5 gesetzt habe, hat es leider auch nicht funktioniert:

Code Auswählen Erweitern

2023.11.26 17:30:30 1: in INITIALIZED
2023.11.26 17:30:30 3: Stromzaehler: Notify called with events: INITIALIZED, open device and set timer to send hello to device
2023.11.26 17:30:30 4: Stromzaehler: trying to open connection to /dev/ttyStromzaehler@19200
2023.11.26 17:30:30 3: Opening Stromzaehler device /dev/ttyStromzaehler
2023.11.26 17:30:30 3: Setting Stromzaehler serial parameters to 19200,8,N,1
2023.11.26 17:30:30 3: Stromzaehler device opened
2023.11.26 17:30:30 5: Stromzaehler: DoOpen succeeded in callback
2023.11.26 17:30:30 5: Stromzaehler: DoOpen succeeded immediately
2023.11.26 17:30:32 0: Featurelevel: 6.2
2023.11.26 17:30:32 0: Server started with 660 defined entities (fhem.pl:28126/2023-11-05 perl:5.036000 os:linux user:fhem pid:866)
2023.11.26 17:30:35 5: Stromzaehler: call configureDisplay after delay
2023.11.26 17:30:35 3: Stromzaehler: Invalid device display configuration
2023.11.26 17:30:38 5: Stromzaehler: Initialize device clock offset to 1700556217.6687
2023.11.26 17:30:38 5: Stromzaehler: Device Time 460021.291, Offset 1700556.218, Drift 0.000s in 0.000s
2023.11.26 17:30:38 4: Stromzaehler: pin D5 (pin5) Cnt 524 (diff 1/1) in 300.404s from 17:25:38 until 17:30:38, seq 47, Rej 0, Avg 300304ms, PPU 1, FUT 3600s, result 11.984
2023.11.26 17:30:38 3: Stromzaehler: pin D5 (pin5) missed 46 reports in 366.555695056915 seconds. Last reported sequence was 0, now 47. Device count before was 522, now 524 with rDiff 1. Adding 1 to long count and intpolated count readings
2023.11.26 17:30:38 5: Stromzaehler: pin D5 (pin5) adding rDiff 1 to long count 63741 and interpolated count 63746
2023.11.26 17:30:38 1: PERL WARNING: Prototype mismatch: sub main::round ($$) vs none at /usr/lib/aarch64-linux-gnu/perl-base/Exporter.pm line 63.
2023.11.26 17:30:39 3: Stromzaehler: device is still counting
2023.11.26 17:30:39 5: Stromzaehler: ArduCounter 8.01 - 04.12.2022 sending h(ello) to device to ask for firmware version
2023.11.26 17:30:39 5: DevIo_SimpleWrite Stromzaehler: h.
2023.11.26 17:30:39 5: Stromzaehler: Device Time 460021.291, Offset 1700556.218, Drift 0.061s in 0.061s, 100.00%
2023.11.26 17:30:39 4: Stromzaehler: pin D6 (pin6) Cnt 2394 (diff 1/1) in 60.081s from 17:29:38 until 17:30:39, seq 117, Rej 0, Avg 59981ms, PPU 100, FUT 3600s, result 0.599
2023.11.26 17:30:39 3: Stromzaehler: pin D6 (pin6) missed 116 reports in 366.939298868179 seconds. Last reported sequence was 0, now 117. Device count before was 2389, now 2394 with rDiff 1. Adding 4 to long count and intpolated count readings
2023.11.26 17:30:39 5: Stromzaehler: pin D6 (pin6) adding rDiff 1 to long count 372322 and interpolated count 372333
2023.11.26 17:30:39 3: Stromzaehler: device is still counting
2023.11.26 17:30:39 5: Stromzaehler: Device Time 460021.291, Offset 1700556.218, Drift 0.092s in 0.092s, 100.00%
2023.11.26 17:30:39 4: Stromzaehler: pin D7 (pin7) Cnt 375474 (diff 196/196) in 59.896s from 17:29:39 until 17:30:39, seq 202, Rej 0, Avg 2ms, PPU 5000, FUT 3600s, result 2.356
2023.11.26 17:30:39 3: Stromzaehler: pin D7 (pin7) missed 201 reports in 367.155292034149 seconds. Last reported sequence was 0, now 202. Device count before was 374092, now 375474 with rDiff 196. Adding 1186 to long count and intpolated count readings
2023.11.26 17:30:39 5: Stromzaehler: pin D7 (pin7) adding rDiff 196 to long count 11593873 and interpolated count 11594558
2023.11.26 17:30:39 3: Stromzaehler: device is still counting
2023.11.26 17:30:39 5: Stromzaehler: Device Time 460021.291, Offset 1700556.218, Drift 0.135s in 0.135s, 100.00%
2023.11.26 17:30:39 4: Stromzaehler: pin 21 (pin21) Cnt 31221 (diff 13/13) in 57.496s from 17:29:41 until 17:30:39, seq 115, Rej 0, Avg 24ms, PPU 375, FUT 3600s, result 2.171
2023.11.26 17:30:39 3: Stromzaehler: pin 21 (pin21) missed 114 reports in 240047.598433018 seconds. Last reported sequence was 0, now 115. Device count before was 16260, now 31221 with rDiff 13. Adding 14948 to long count and intpolated count readings
2023.11.26 17:30:39 5: Stromzaehler: pin 21 (pin21) adding rDiff 13 to long count 2942384 and interpolated count 2942384
2023.11.26 17:30:39 3: Stromzaehler: device is still counting
2023.11.26 17:30:45 5: Stromzaehler: HelloTimeout: DeviceName in hash is /dev/ttyStromzaehler@19200
2023.11.26 17:30:45 3: Stromzaehler: device didn't reply to h(ello). Is the right sketch flashed? Serial speed was 19200. Trying again with @38400
2023.11.26 17:30:45 5: Stromzaehler: HelloTimeout: DeviceName in hash is set to /dev/ttyStromzaehler@38400
2023.11.26 17:30:45 4: Stromzaehler: trying to open connection to /dev/ttyStromzaehler@38400
2023.11.26 17:30:45 3: Opening Stromzaehler device /dev/ttyStromzaehler
2023.11.26 17:30:45 3: Setting Stromzaehler serial parameters to 38400,8,N,1
2023.11.26 17:30:45 3: Stromzaehler device opened
2023.11.26 17:30:45 5: Stromzaehler: DoOpen succeeded in callback
2023.11.26 17:30:45 5: Stromzaehler: DoOpen succeeded immediately
2023.11.26 17:30:49 5: Stromzaehler: ArduCounter 8.01 - 04.12.2022 sending h(ello) to device to ask for firmware version
2023.11.26 17:30:49 5: DevIo_SimpleWrite Stromzaehler: h.
2023.11.26 17:30:54 5: Stromzaehler: HelloTimeout: DeviceName in hash is /dev/ttyStromzaehler@38400
2023.11.26 17:30:54 3: Stromzaehler: device didn't reply to h(ello). Is the right sketch flashed? Serial speed was 38400. Trying again with @115200
2023.11.26 17:30:54 5: Stromzaehler: HelloTimeout: DeviceName in hash is set to /dev/ttyStromzaehler@115200
2023.11.26 17:30:54 4: Stromzaehler: trying to open connection to /dev/ttyStromzaehler@115200
2023.11.26 17:30:54 3: Opening Stromzaehler device /dev/ttyStromzaehler
2023.11.26 17:30:54 3: Setting Stromzaehler serial parameters to 115200,8,N,1
2023.11.26 17:30:54 3: Stromzaehler device opened
2023.11.26 17:30:54 5: Stromzaehler: DoOpen succeeded in callback
2023.11.26 17:30:54 5: Stromzaehler: DoOpen succeeded immediately
2023.11.26 17:30:58 5: Stromzaehler: ArduCounter 8.01 - 04.12.2022 sending h(ello) to device to ask for firmware version
2023.11.26 17:30:58 5: DevIo_SimpleWrite Stromzaehler: h.
2023.11.26 17:31:03 5: Stromzaehler: HelloTimeout: DeviceName in hash is /dev/ttyStromzaehler@115200
2023.11.26 17:31:03 3: Stromzaehler: device didn't reply to h(ello). Is the right sketch flashed? Serial speed was 115200. Trying again with @38400
2023.11.26 17:31:03 5: Stromzaehler: HelloTimeout: DeviceName in hash is set to /dev/ttyStromzaehler@38400
2023.11.26 17:31:03 4: Stromzaehler: trying to open connection to /dev/ttyStromzaehler@38400
2023.11.26 17:31:03 3: Opening Stromzaehler device /dev/ttyStromzaehler
2023.11.26 17:31:03 3: Setting Stromzaehler serial parameters to 38400,8,N,1
2023.11.26 17:31:03 3: Stromzaehler device opened
2023.11.26 17:31:03 5: Stromzaehler: DoOpen succeeded in callback
2023.11.26 17:31:03 5: Stromzaehler: DoOpen succeeded immediately
2023.11.26 17:31:07 5: Stromzaehler: ArduCounter 8.01 - 04.12.2022 sending h(ello) to device to ask for firmware version
2023.11.26 17:31:07 5: DevIo_SimpleWrite Stromzaehler: h.
2023.11.26 17:31:12 3: Stromzaehler: device didn't reply to h(ello). Is the right sketch flashed? Is serial speed set to 38400 or 115200 for firmware >4.0?
2023.11.26 17:31:55 3: Stromzaehler: Warning: connection speed 19200 is not the default for the latest ArduCounter firmware
2023.11.26 17:31:55 3: Stromzaehler: defined with /dev/ttyStromzaehler@19200, Module version 8.01 - 04.12.2022
2023.11.26 17:31:55 1: in MODIFIED
2023.11.26 17:31:55 3: Stromzaehler: Notify called with events: MODIFIED Stromzaehler, open device and set timer to send hello to device
2023.11.26 17:31:55 4: Stromzaehler: trying to open connection to /dev/ttyStromzaehler@19200
2023.11.26 17:31:55 3: Opening Stromzaehler device /dev/ttyStromzaehler
2023.11.26 17:31:55 3: Setting Stromzaehler serial parameters to 19200,8,N,1
2023.11.26 17:31:55 3: Stromzaehler device opened
2023.11.26 17:31:55 5: Stromzaehler: DoOpen succeeded in callback
2023.11.26 17:31:55 5: Stromzaehler: DoOpen succeeded immediately
2023.11.26 17:31:59 5: Stromzaehler: ArduCounter 8.01 - 04.12.2022 sending h(ello) to device to ask for firmware version
2023.11.26 17:31:59 5: DevIo_SimpleWrite Stromzaehler: h.
2023.11.26 17:31:59 4: Stromzaehler: device: got 0,0,0h size 3
2023.11.26 17:31:59 3: Stromzaehler: device sent hello with outdated Arducounter Firmware (3.34) - please update!
Der Teil mit den Hieroglyphen taucht hier komischerweise nicht auf.

Am Ende sieht man, dass ich per MODIFY wieder auf 19200 gestellt habe und dann läuft die Verbindung.

Irgendwelche Ideen?

[efyzz]

Moin,

ich musste inzwischen beobachten, dass zusätzlich die Verbindung zum ArduCounter etwa 1x täglich abbricht. Nach einem set reconnect läuft es wieder.

Ich habe mir daher ein monitoring eingerichtet, das prüft, ob jede Minute wie erwartet Daten vom ArduCounter kommen. Und dabei ist mir noch etwas Seltsames aufgefallen: Genau jede 60min kommen einmal keine Daten vom AC. In der nächsten Minute kommen sie aber wieder (auch ohne reconnect). Gelegentlich verschiebt sich der Zeitpunkt auch mal, aber dann geht es wieder alle 60min weiter. In alten Logdaten sehe ich, dass das auch schon vor dem Umstieg auf Bookworm so war. Ist also scheinbar eine Eigenheit des ArduCounter.

Vielleicht wäre doch mal ein Update des Arduinos sinnvoll. Daher nochmal die Frage:
Gehen beim Update (von V3.34) irgendwelche Zählerstände verloren oder ändern sich womöglich Reading-Namen, sodass man Funktionen drumherum anpassen müsste?


Und mal so nebenbei: Müsste es der USB-Verbindung zwischen RPi und Arduino nicht eigentlich egal sein, welche Baudrate man einstellt? Das hat doch keinen Einfluss auf die USB-Übertragungsgeschwindigkeit?! Also die Baudrate zu drosseln, weil man ein langes USB-Kabel hat, ist doch vermutlich sinnlos...?

[StefanStrobel]

Hallo efyzz,

bei einem Update des Arduino sollte nichts verloren gehen und was das lange USB-Kabel angeht, so hat die Baudrate da keinen Einfluss. Am besten entfernst Du die Angabe und übernimmst damit den Default.
Hast Du wegen den Aussetzern und den Sonderzeichen mal einen anderen Arduino probiert?

Gruss
   Stefan

[efyzz]

Moin,

wenn ich einen anderen Arduino nehme, sind aber höchstwahrscheinlich die Zählerstände verloren, oder?

Ich habe das Ganze jetzt nochmal ausgiebig beobachtet. Einen kompletten Verbindungsabriss hatte ich bisher nicht mehr, deswegen kann ich auch kein entsprechendes Log liefern.

Was ich jedoch weiterhin beobachten kann ist, dass meistens (nicht immer) genau 1x pro Stunde keine Daten kommen. Wie gesagt habe ich ein Monitoring eingerichtet, das nach 65 s ohne Daten eine Warning generiert und dabei ein Reconnect ausführt. Das passiert wie gesagt regelmäßig, ist aber jetzt kein großes Problem. Gelegentlich kommen aber auch mehrere Minuten lang keine (neuen) Daten. Das führt dann zu einem Error und es wird neben dem Reconnect noch eine Telegram Message geschickt. Das lag wohl anfangs daran, dass ich das Attribut

Code Auswählen Erweitern

event-on-change-reading .* gesetzt habe. Klar, wenn der Stromverbrauch einige Minuten konstant ist (passiert z.B. nachts häufig), gibt es kein Event mehr und somit schlägt der Monitor an. Also ich habe ich noch

Code Auswählen Erweitern

event-on-update-reading für das entsprechende Reading gesetzt.

Frage 1: Es ist doch so, dass über event-on-update-reading Ausnahmen für event-on-change-reading .* definiert werden?

Scheinbar ist es so, denn nun sehe ich auch gleiche Werte hintereinander im Log (z.B. ist die Leistung mehrere Minuten lang 300 W und dies taucht dann auch im Log jede Minute auf).

Aber trotzdem kommen gelegentlich mal für eine Minute keine Daten (neben dem 1x pro Stunde - Problem).

Daher Frage 2: Macht der AC selbst auch noch intern eine Filterung, dass er unveränderte Werte nicht sendet?

Es wäre ja möglich, dass der AC beispielsweise intern mit Float rechnet. Und ist der Wert nun in einer Minute 300.1 W und in der nächsten Minute 300.3 W, so wären das aus Sicht des AC verschiedene Werte, die übertragen werden müssen (wobei FHEM jedes Mal 300 W loggt). Hat der AC jedoch zweimal hintereinander einen identischen Wert berechnet (beipielsweise beide Male 300.1 W), so würde er den zweiten Wert nicht übertragen, da keine Veränderung.

Nur so könnte ich mir das erklären ... Kann das sein? Und wenn ja, kann ich dem AC erklären, dass er bitte immer den Wert überträgt, auch wenn unverändert?

Hier die Definition des AC (Ausschnitt):

Code Auswählen Erweitern

defmod Stromzaehler ArduCounter /dev/ttyStromzaehler@19200
attr Stromzaehler userattr pinA7 pinD4 pinD5 pinD6 pinD7
attr Stromzaehler analogThresholds 100 200
attr Stromzaehler enableHistory 1
attr Stromzaehler event-on-change-reading .*
attr Stromzaehler event-on-update-reading powerD7, powerA7
Und die Definition des Monitor:

Code Auswählen Erweitern

defmod ArduCounterUeberwachung monitoring Stromzaehler:powerD7:.*|Stromzaehler:powerA7:.* Stromzaehler:powerD7:.*|Stromzaehler:powerA7:.*
attr ArduCounterUeberwachung errorFuncAdded {fhem("set Stromzaehler reconnect");;;;\
fhem("set TelegramBot message Keine Daten vom Stromzähler!");;;;\
Log 1, "Stromzaehler ERROR timeout reached, reconnect" }
attr ArduCounterUeberwachung errorWait 130
attr ArduCounterUeberwachung room Stromzähler
attr ArduCounterUeberwachung warningFuncAdded {fhem("set Stromzaehler reconnect");;;;\
Log 1, "Stromzaehler WARNING timeout reached, reconnect" }
attr ArduCounterUeberwachung warningWait 65
Und hier noch ein Log vom Monitor:

Code Auswählen Erweitern

2023.12.29 00:01:26 1: Stromzaehler WARNING timeout reached, reconnect
2023.12.29 01:01:21 1: Stromzaehler WARNING timeout reached, reconnect
2023.12.29 02:01:16 1: Stromzaehler WARNING timeout reached, reconnect
2023.12.29 03:01:11 1: Stromzaehler WARNING timeout reached, reconnect
2023.12.29 04:01:07 1: Stromzaehler WARNING timeout reached, reconnect
2023.12.29 05:01:02 1: Stromzaehler WARNING timeout reached, reconnect
2023.12.29 06:00:57 1: Stromzaehler WARNING timeout reached, reconnect
2023.12.29 07:00:52 1: Stromzaehler WARNING timeout reached, reconnect
2023.12.29 08:00:48 1: Stromzaehler WARNING timeout reached, reconnect
2023.12.29 09:00:43 1: Stromzaehler WARNING timeout reached, reconnect
Immer schön 1x pro Stunde ...

Und gestern Abend war der Stromverbrauch länger konstant (weil niemand zuhause war). Dann sieht das so aus:

Code Auswählen Erweitern

2023.12.28 17:55:55 1: Stromzaehler WARNING timeout reached, reconnect
2023.12.28 17:58:55 1: Stromzaehler WARNING timeout reached, reconnect
2023.12.28 18:00:54 1: Stromzaehler WARNING timeout reached, reconnect
2023.12.28 18:02:54 1: Stromzaehler WARNING timeout reached, reconnect
2023.12.28 18:05:54 1: Stromzaehler WARNING timeout reached, reconnect
2023.12.28 18:07:54 1: Stromzaehler WARNING timeout reached, reconnect
2023.12.28 18:08:59 1: Stromzaehler ERROR timeout reached, reconnect
2023.12.28 18:10:53 1: Stromzaehler WARNING timeout reached, reconnect
2023.12.28 18:11:59 1: Stromzaehler ERROR timeout reached, reconnect
2023.12.28 18:13:53 1: Stromzaehler WARNING timeout reached, reconnect
2023.12.28 18:14:58 1: Stromzaehler ERROR timeout reached, reconnect

Und noch eine letzte Frage: Wie erkläre ich dem Monitor, dass er sich nach Ablauf des errorWait wieder scharf schaltet? Im Moment ist es leider so, dass wenn wirklich gar keine Daten vom AC mehr kommen, der Monitor mir zwar noch die Error-Nachricht schickt, dann aber nicht mehr monitored, weil er nicht durch neue Werte angetriggert wird. Dann ist ein manueller Eingriff erforderlich ...

Danke euch und schon mal guten Rutsch (hoffentlich nicht im überfluteten Keller )!

[StefanStrobel]

Hallo,

Frage 1: Es ist doch so, dass über event-on-update-reading Ausnahmen für event-on-change-reading .* definiert werden?

siehe https://wiki.fhem.de/wiki/Event-on-update-reading
bzw. https://wiki.fhem.de/wiki/Event-on-change-reading

Daher Frage 2: Macht der AC selbst auch noch intern eine Filterung, dass er unveränderte Werte nicht sendet?

nein, da wird nichts gefiltert. Allerdings ist das Meldeintervall innerhalb der per Attribut definierten Grenzen flexibel.
siehe Attribut "interval" bzw. https://wiki.fhem.de/wiki/ArduCounter

Mit Verbose 5 siehst Du alle Meldungen vom Arduino / ESP.

Gruss
   Stefan

[efyzz]

Hallo Stefan,

vielen Dank für die Erläuterungen!

Na klar, an "interval" wird es liegen!    Ich habe es so gesetzt:

Code Auswählen Erweitern

interval 60 3600 2 1
Die lange max-Zeit brauche ich leider für meinen Fernwärmezähler, der unter Umständen nur einen Puls pro Stunde raus gibt.

Das erklärt natürlich, warum ich nicht zwingend jede Minute neue Werte bekomme. Ich muss meinen Monitor also auf >3600s konfigurieren. Das heißt aber auch, dass ein realer USB-Verbindungsabbruch erst nach einer Stunde erkannt wird.

Gibt es noch eine bessere Möglichkeit, worauf ich den Monitor triggern könnte? So etwas wie keepAliveDelay wäre toll, aber das gibt es ja nur für tcp-Verbindung.

Nochmals danke!

[efyzz]

Mahlzeit,

nachdem ich das MONITORING entschärft habe, bin ich dem eigentlichen Problem näher gekommen.

Im Log des Raspberry (journalctl) tauchte nämlich sehr häufig auf:

Code Auswählen Erweitern

Jan 22 00:30:04 raspberryFHEM kernel: pl2303 ttyUSB2: usb_serial_generic_read_bulk_callback - urb stopped: -32
Jan 22 00:30:04 raspberryFHEM kernel: pl2303 ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
Jan 22 00:30:04 raspberryFHEM kernel: ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

Offensichtlich bricht regelmäßig die Verbindung zu allen drei USB/UART-Convertern ab (wohlgemerkt aber nicht zum vierten USB-Gerät: einer Festplatte).

Bisher konnte ich dazu nichts Sinnvolles im Netz finden, außer: "mach mal ein apt upgrade".
Das hat tatsächlich geholfen, die Fehlermeldung kommt nun wesentlich seltener und nur noch für einzelne USB-Geräte. Ganz weg ist das Problem aber nicht. Letzte Nacht ist, wie man sieht, mal wieder die Verbindung zu allen drei USB-Geräten gleichzeitig abgebrochen. Und nur dann führte es auch wieder zu einem Fehler beim ArduCounter.

Es liegt also nicht an dem 10m USB-Kabel. Sondern offensichtlich tatsächlich am Update auf Bookworm. Ich frage mich, ob außer mir sonst noch jemand Bookworm auf einem Raspi 3B benutzt, denn eigentlich müssten diese Fehlermeldungen bei vielen Usern auftauchen. PL2303 oder CH341 dürften wohl sehr verbreitet sein

Naja, warten wir mal auf weitere Updates.

[efyzz]

Ich habe jetzt hier eine Lösung gefunden:
https://github.com/raspberrypi/linux/issues/5211#issuecomment-1882917918

Keine USB-Abbrüche mehr, seit ich dtoverlay=dwc2 gesetzt habe.