Ferraris Zähler mit TCRT5000 und esp8266
-
Hi,
ich geb hier auch mal meinen Senf dazu:
Ich hatte in der der Vergangheit mit dem Normealen ESPeasy Skript Ständig das Problem, dass er zu wenig gezählt hat.Beim beobachten sah ich dass jeder Rotdurchlauf gezählt wird. Ich habe also endlos an dem Muliplikator für die Ferrarisscheibe rumgedoktort aber das Problem haben ich nicht in den Griff bekommen. Die Diode war perfekt eingestellt also habe ich das als Ursache ausgeschlossen
Ich vermutete, dass es an der WLAN Verbindung lag da ich nur die Differenzen gezählt hatte und kam dann auf dieses Projekt, da es ja Absolutwerte speichert würde ich so meine Verbindungsprobleme umgehen. Leider hab ich das nicht auf meinen NodeMCU bekommen da die bin nicht funktioniert und habe dann aus Frust mal mit ESPeasy im IioBroker den Absolutwert statt der Differenz bei Update erfasst und die Differenz selbst gebildet. (Hier unbedingt den Nulldurchgang beachten) Keine Verbesserung.
Nach einiger Diskussion mit @Menne (Vielen Dank für Deine Zeit) kam mir eine Idee:Da ich mich nicht eingehend mit dem Projekt befasst habe und einfach damals alles was ich bei @SchimmerMediaHD gesehen Hatte nachgebaut hatte hab ich mich nicht mit den Einstellungen beschäftigt.
Ich erfasse beide Flanken des Rotdurchlaufs um Parität zu wahren und der Entprellwert (debounce) war auf 1000ms. Das ist natürlich viel zu Hoch wenn beispielsweise Die Sauna oder Trockner und Waschmaschine, Tischkreissäge laufen.
Als ich darüber nachdachte wurde mir auch klar, dass die Abweichungen auch keinerlei System folgten, ich hatte tagelang Tabellen erfasst wie weit ich weg bin und da konnte ich keine Regelmäßigkeit errechnen. Also passiert das immer wenn die Scheibe sich schnell dreht. Und mein debounce war zu hoch, hab ihn jetzt mal auf 100ms Gestellt und seit gut 10 Tagen bin ich sehr genau. Der debounce ist hier entscheidend, man muss einen Mittelweg zwischen zu klein und zu groß finden. Ist er zu groß filtert er bei schneller Scheibe den Rotdurchgang raus. Ist er zu klein habt ihr Jitter.Testen mit einem Starken Verbraucher (Toaster, Wasserkocher, Backofen mit Grillfunktion, Sauna oder TKS)
Zählt zu viel: debounce zu klein.
Zählt zu wenig: debounce zu hoch.Es spricht so einiges dafür den debounce als Parameter aufzunehmen.
-
@jmeister79 sagte in Ferraris Zähler mit TCRT5000 und esp8266:
Ich erfasse beide Flanken des Rotdurchlaufs um Parität zu wahren
Das würde ich in diesem Fall nicht tun, weil das Tastverhältnis zu unsymmetrisch ist. Das wäre dann angemessen, wenn es wirklich paritätisch wäre, also die Rotmarkierung etwa einen halben Umfang lang. Ist es aber nicht.
Wenn man nur eine Flanke zählt, hat man etwas mehr Spielraum mit der debounce Zeit.Beim Sternrad meiner Wasseruhren nutze ich zwar auch beide Flanken, achte bei der Einstellung darauf, daß das Tastverhältnis ziemlich symmetrisch ist,
-
Es ist eindeutig so, dass der TCRT5000 prellt. Seit der Umstellung auf Interrupts wird jetzt eben jeder, auch der kürzeste Impuls erfasst. Das bringt natürlich neue Problem mit sich. Mein Sensor prellt eindeutig wie man hier sieht:
Ich bin mir nur nicht sicher, ob man das wirklich softwareseitig in Griff bekommt, oder ob ich an den Sensoren noch Änderungen machen muss. Mal sehen. -
@eisbaeeer
Ich habe anhand der Infos aus https://nachbelichtet.com/so-funktioniert-der-tcrt5000-mit-espeasy-als-pulse-counter/
meinen TCRT5000 mit einem Schmitt-Trigger versehen, damit ein klar definierter Rechteck-Impuls übermittelt wird.Ggf. hilft dies weiter?
-
Sodele sagt der Schwabe
Ich habe jetzt einiges am Code umgebaut. Ich musste die Interrupt Routinen umbauen, damit die Entprellung ohne "delay" realisiert werden konnte. Im Moment sieht es bei mir sehr gut aus. Der TCRT5000 hat bei meiner zweiten Zählstelle, bei der abfallenden Flanke derart geprellt, dass er 4 Impulse detektiert hat. Wer gerne testen möchte, hier das Binary für den ESP8266 NodeMCU1.0 und höher.
a73280a4-8a14-4485-95ce-b256cf3ff18a-firmware.bin
Falls ich auf die Schnelle noch das Binary für den Wemos-mini hinbekomme, füge ich die hier noch ein.
Gebt mal Rückmeldung, ob ihr jetzt passende Zählerstände bekommt.
-
@w00dst0ck , wenn man diesen Thread aufmerksam gelesen hätte, wäre der Hinweis hinfällig. Das schrieb ich schon in meinen Posts, das ich einen Schmittrigger vorgeschaltet habe.
-
@eisbaeeer , jetzt noch MQTT Import und ein OLED einbauen....sowie ein Eingang für Gas und einer für Wasser....dann wäre ich Happy.....
btw....habe nur laut gedacht.
-
@menne Wenn das jetzt mal passt, könnte ich mir das schon noch vorstellen. OLED ist ja kein Problem. Hast du ein Beispiel wie das aussehen könnte? Was soll drauf?
-
@menne
Sorry, das Detail habe ich bei über 270 Antworten leider übersehen.
Denke aber, dass mein Hinweis nicht so schlimm war.
-
@eisbaeeer , antworte später, muss weg.
@w00dst0ck , das sollte kein Vorwurf sein, nur ein Hinweis...... -
@eisbaeeer
Hab noch dieses Projekt aus dem Home Assistent Universum entdeckt, das Deinem sehr ähnelt.
Hier wurde schon ein OLED eingebunden.Vielleicht sind da Anregungen dabei?!
-
Die Impulse funktionieren bei mir jetzt zuverlässig. Kein Prellen mehr.
Die liebe Nachkommastelle macht aber noch Probleme. Ich habe in der aktuellen Version die Nachkommastelle entfernt, da hier bei jedem Impuls falsch addiert wird, wenn der Zählerstand größer ist (bei mir 5 stellig). Deshalb hatte ich auch nach der Verbesserung immer zu viel KWh auf dem Zähler.
Der Grund liegt darin, dass die Variable float bei krummen Teilern (bei mir z.B. 75 Umdrehungen pro KWh) beim Addieren überläuft. Ich muss mir erst noch überlegen, wie ich den Zählwert vor dem Komma von der Nachkommastelle entkopple, da float für den Zählerstand dann zu klein ist.
Jetzt teste ich erstmal eine längere Zeit ohne Nachkomma, ob alles passt. Wer mitmachen möchte, hier die Binary:
firmware.bin
Grüße Eisbaeeer -
also irgendwie habe ich mit den zwei letzten Updates Probleme.
Ich habe jetzt drei NodeMCU getestet. Alle drei verlieren die Mqtt Einstellungen
und den Zählerstand. Das einzigste, was erhalten bleibt, sind die WLAN Einstellungen.Bin ich der einzige, der die "Probleme" hat?
-
@eisbaeeer darauf hab ich gewartet, danke
-
@falke69 Das liegt daran, dass sich die Konfiguration geändert hat. Ist also richtig so. Zusätzliche Felder auf der Konfigurationsseite zieht nach sich, dass man die Einstellungen neu machen muss.
-
das bedeutet also, dass das normal und gewünscht ist, das es immer wieder die Standardwerte einträgt?
Edit: habe soeben nochmal getestet. Sobald ich den Namen "Messplatz" gegen "Stromzaehler"
ersetze, löscht es meine eingetragenen Mqtt Einstellungen, auf die Standartvorgabe und
ich verliere damit jedesmal die Verbindung zu iobroker. -
Hallo Zusammen,
Erstmal Vielen Dank @Eisbaeeer für dieses Projekt.
Ich bin auch ein wenig am testen und habe wohl ein ähnliches oder das gleiche Problem wie falke69 mit dieser neuen v.0.91.
Im Serial Monitor ist mir aufgefallen dass der NodeMCU irgendwann abstürzt:...
3fffffb0: feefeffe feefeffe 3ffe8900 401012c5
<<<stack<<<
--------------- CUT HERE FOR EXCEPTION DECODER ---------------ets Jan 8 2013,rst cause:2, boot mode:(3,6)
load 0x4010f000, len 3460, room 16
tail 4
chksum 0xcc
load 0x3fff20b8, len 40, room 4
tail 4
chksum 0xc9
csum 0xc9
v000d6620
~ld
Connected to stored WiFi details
192.168.1.78
Config data checksum mismatch
Internal data checksum mismatch
Connected.
IP-address : 192.168.1.20
Silver detected; waiting for red
Red detected; Waiting for silver
New WS client
Attempting MQTT connection...
failed, rc=-2 try again in one minuteAb diesem Zeitpunkt sind alle Einstellungen unter Configuration wieder auf Standard gesetzt (auch wenn ich den Namen Messplatz nicht geändert hatte, nur die IP).
Mir ist etwas Ähnliches schon ab Version 0.8 aufgefallen - hier musste ich einen MQTT zwingend konfigurieren sonst kam es wiederholt zum Absturz, aber da wurde die Konfiguration nie auf Standard zurück gesetzt. (das ist jetzt neu)
Auch die Einträge zu Config data checksum mismatch und Internal data checksum mismatch sind neu, die v0.9 war mit konfigurietem MQTT auch stabil.Ich habe hier NodeMCUv3 im Einsatz, vielleicht mach ich auch etwas falsch ? Ich teste bis jetzt nur am Basteltisch da ich den Ferraris Zähler den ich smart machen möchte erst im November besuche
-
@falke69 Ähm, nein, das sollte nicht so sein. Ich habe mich eben auch gewundert, dass meine Werte weg waren. Ich schau gleich mal in den Code, was da noch schief läuft.
-
@mahumuc sagte in Ferraris Zähler mit TCRT5000 und esp8266:
Config data checksum mismatch
Internal data checksum mismatchDanke für den Hinweis. Das kann ich bei mir nachstellen. Ich vermute gerade noch ein Problem beim Speichern der Werte und den Interrupt Routinen. Scheinbar mögen sich die beiden nicht
Das Problem beim ESP8266 ist ja, dass es keinen wirklichen EEPROM gibt und das ganze über den Flash Speicher realisiert wird. Und das ganze scheint sich wohl mit den Interrupts zu beißen.
Eure Rückmeldungen helfen auf jeden Fall! Danke dafür.
Grüße Eisbaeeer -
kein Problem, dann warten wir auf ein Update
