sofern morgen mein NodeMCU (ESP12) eintrifft, möchte ich endlich mit dem Ablesen des analogen Stromzählers (Ferraris) beginnen.
Die Voraussetzungen hab ich schon geschaffen (Webservice, SQL-Datenbank, optischer Sensor PBC FC-03, WLAN-Integration, etc.).
Die analogen Rückgabewerte des Sensors nach der Montage über dem Zähler-Rad bewegen sich bei mir zwischen 120 / +-10 am Gesamtumfang des Rades und 450 / +-10 an der roten Markierung.
Ich möchte aber nicht jede Umdrehung des Rades über das Webservice als Timestamp speichern und dann am SQL-Server ausrechnen, sondern am besten gleich den tatsächlichen Verbrauch (in Watt) in der letzten Zeiteinheit.
Ein bisschen unsicher bin ich mir darüber wie ich die Logik aufbaue um die Berechnung direkt am ESP machen zu können.
Mein Plan:
Ich teile die Umdrehung des Rades logisch in 3 Modi (die Einteilung gibts programmtechnisch nicht, höchsten noch in meinen Kommentaren)
Die Loop() startet automatisch mit Modus 1:
Modus 1:
Ich geh davon die Markierung wurde gerade erkannt
Ich speichere den aktuellen Zeitpunkt in Millis() als int in zeit_alt;
Danach automatisches wechseln nach
Modus 2:
while (Sensorwert > 300) {delay(10)} --jetzt warte ich bis die Markierung wieder weg ist
sobald das passt, wechseln nach
Modus 3:
while (Sensorwert < 300) {delay(10)} --jetzt warte ich bis die nächste Markierung kommt
sobald die Markierung da ist:
umlauf_sec = Differenz in sekunden ausrechnen zwischen zeit_alt und aktuellen Millis()
Berechnung der Leistung in diesem Zeitraum: x = 13,3333 * 3600 / umlauf_sec
Schreiben dieses Wertes in Watt mittels Webservice in meine SQL-Datenbank, die kümmert sich
dann auch um einen TimeStamp
Fertig - Loop kann jetzt neu gestartet werden
Klingt das alles halbwegs logisch oder hab ich irgendwo einen gröberen Schnitzer nicht bemerkt beim Durchdenken ?
Hallo,
MEIN PLAN:
erst einmal alle delay() auf den Müll.
Dann in den dunklen tiefen Keller zum Ferrariszähler. Typenschild aufmeksam
lesen. Was steht dort!?
Ja- genau "75 U/kWh"
Es sind IMMER- 75 Umdrehungen für eine kWh. Die Zeitspanne spielt keine Rolle.
75 U in einer viertel Std oder 75 U in zwei Stunden, alles eine Grütze…
Also, Markierung erfaßt, millis() starten, Markierung wieder erfaßt. millis()
stoppen. Differenz errechnen.
Der Rest ist Geschichte.
Jetzt hast Du die aktuelle Wirkleistung zu einer bestimmten (Uhr)Zeit.
Wenn Du jetzt noch millis() starten zählst hast Du einen Zähler.
Abrufen kannst Du das, wann Du willst. Ist immer aktuell.
Gruß und Spaß
Andreas
ich hab einen österreichischen, der macht 75 Umin - Energie AG
ich hab sogar zwei, beide machen 75 und die von den meisten Bekannten auch
zu DEINEM Plan Skoby:
Ich reagiere also auf den ersten "Tick" - d.h. Markierung erkannt.
Jetzt muss ich aber irgendwie den Zeitraum abwarten bis die Markierung wieder weg ist. Im Moment (Abend, wenig los) sind das bei mir knapp 4 Sekunden, wenn Heizung und Herdplatte laufen sinds wahrscheinlich <1 sek.
Ich könnte natürlich ein festes Delay (10000) einbauen, dann stimmt aber die Auswertung nicht mehr sobald ich > 5000 Watt verbrauche
Gawan:
ich hab einen österreichischen, der macht 75 Umin - Energie AG
ich hab sogar zwei, beide machen 75 und die von den meisten Bekannten auch
zu DEINEM Plan Skoby:
Ich reagiere also auf den ersten "Tick" - d.h. Markierung erkannt.
Jetzt muss ich aber irgendwie den Zeitraum abwarten bis die Markierung wieder weg ist. Im Moment (Abend, wenig los) sind das bei mir knapp 4 Sekunden, wenn Heizung und Herdplatte laufen sinds wahrscheinlich <1 sek.
Ich könnte natürlich ein festes Delay (10000) einbauen, dann stimmt aber die Auswertung nicht mehr sobald ich > 5000 Watt verbrauche
Was willst du in einer "zeitkritischen" Auswertung mit einem delay.
Vergiss das es delays gibt, die habe in einem Sketch "fast" nichts mehr zu suchen.
Ein delay(10000) erst recht nicht.
Du mustt einfach die Zeit messen, bis die Markierung wieder auftaucht.
Andreas (SkobyMobil) hat es dir doch gut erklärt.
HotSystems:
Was willst du in einer "zeitkritischen" Auswertung mit einem delay.
Vergiss das es delays gibt, die habe in einem Sketch "fast" nichts mehr zu suchen.
Ein delay(10000) erst recht nicht.
Du mustt einfach die Zeit messen, bis die Markierung wieder auftaucht.
Andreas (SkobyMobil) hat es dir doch gut erklärt.
Nein, hat er eben nicht
--> Also, Markierung erfaßt, millis() starten, Markierung wieder erfaßt. millis()
Das Problem ist aber dass "Markierung erfasst" kein atomares Ereignis ist, sonder je nach Verbrauch unterschiedlich lang dauert. D.h. ich muss auch erkennen wenn die Markierung wieder abfällt
Ich kenne deinen Sketch nicht, aber normalerweise wird die Variable "AltMillis" immer wieder auf den aktuellen Stand gebracht, damit ist kein Überlauf möglich.
Gawan:
Nein, hat er eben nicht
--> Also, Markierung erfaßt, millis() starten, Markierung wieder erfaßt. millis()
Das Problem ist aber dass "Markierung erfasst" kein atomares Ereignis ist, sonder je nach Verbrauch unterschiedlich lang dauert. D.h. ich muss auch erkennen wenn die Markierung wieder abfällt
Es reicht, nur die Markierung erfasst zu erkennen und die Zeit dazwischen messen.
Das ist eine Umdrehung.
Gawan:
Nein, hat er eben nicht
--> Also, Markierung erfaßt, millis() starten, Markierung wieder erfaßt. millis()
Das Problem ist aber dass "Markierung erfasst" kein atomares Ereignis ist, sonder je nach Verbrauch unterschiedlich lang dauert. D.h. ich muss auch erkennen wenn die Markierung wieder abfällt
Du kannst aber die Änderung von Nicht-Markierung zu Markierung und Markierung zu Nicht-Markierung detektieren und das sind zwei einmalige Ereignisse pro Umdrehung.
Wenn millis() richtig verwendet wird, dann ist die Intervallmessung auch beim Überlauf richtig, solange das Intervall kleiner als ca 49 Tage ist. Bei einem Stromzähler ist ein Intervall von einigen Minuten schon gleichbedeutend mit fast keinem Verbrauch. Die Anzahl der Umdrehungen absolut ist ja unabhängig von der Zeitmessung zwischen 2 Markierungen.
HotSystems:
Es reicht, nur die Markierung erfasst zu erkennen und die Zeit dazwischen messen.
Das ist eine Umdrehung.
Hallo,
entweder ich verstehs echt nicht oder ich kann das Problem nicht ordentlich erklären
Ich detektiere die Markierung. Im Moment springt mir der Rückgabewert des Sensors dabei von ca. 40 auf 300.
.... 40 40 40 40 40 40 40 150 250 300 300 300 250 150 40 40 40 40 40 40 40 ....
So, jetzt ist der Wert aber relativ lang auf ca. 300 und zwar so lang bis die Markierung wieder weg ist.
Meine Start-Bedingung um die Zeit zu messen ist SensorValue > 100.
Das schlägt natürlich andauernd an solange die Markierung im Blickfeld ist und nicht nur ein einziges Mal !
und bzgl. der millis ()
Ich messe immer START der Runde und ENDE der Runde. Danach rechne ich die Differenz der beiden millis-Werte aus (neu minus alt) und bekomme die Dauer der Runde in Milisekunden.
Wenn jetzt aber der ALT-Wert kurz vor dem Überlauf des unsigned long ist (z.B. 4.294.967.000) und der NEU-Wert kurz nach dem Überlauf (z.B. 50), dann ergibt die Rechnung ALT minus NEU -4.294.966.950.
Damit kann ich keinen Verbrauch rechnen.
Ich kann bestenfalls negative Rechenergebnisse ignorieren, d.h. einmal in 50 Tagen fehlt mir ein Wert.
Ist zwar nicht gravierend, aber ganz exakt ist es auch nicht
Gawan:
Hallo,
entweder ich verstehs echt nicht oder ich kann das Problem nicht ordentlich erklären
Ich detektiere die Markierung. Im Moment springt mir der Rückgabewert des Sensors dabei von ca. 40 auf 300.
.... 40 40 40 40 40 40 40 150 250 300 300 300 250 150 40 40 40 40 40 40 40 ....
So, jetzt ist der Wert aber relativ lang auf ca. 300 und zwar so lang bis die Markierung wieder weg ist.
Um dein erstes Problem zu klären, wie misst du denn die Markierung?
Bzw. wo hast du die Lichtschranke angeschlossen?
Und was ist das für eine Lichtschranke?
der schaut ganz grade von vorne auf das Zählerrad und hängt analog an einem Arduino UNO
je nach Kontrast liefert er analoge Werte - in meinem Fall ca. 35-40 am silbernen Teil des Rades und ca. 300 an der roten Markierung
Und warum verwendest du keinen digitalen Input, der Sensor hat doch einen TTL (digital) Ausgang den du direkt an den digitalen Port anschließen kannst. Der hat doch sogar einen Schmitt-Trigger drauf.
Und warum verwendest du keinen digitalen Input, der Sensor hat doch einen TTL (digital) Ausgang den du direkt an den digitalen Port anschließen kannst. Der hat doch sogar einen Schmitt-Trigger drauf.
Sehr gute Idee
Ich habe auch sowas gebaut, also eine Lichtschranke auf die Scheibe des alten Ferraris-Zähler geklebt.
Diese triggert einen ext. Interrupt, z.b steigenden Flanke.
Ich lasse dort eine Variable hochzählen die von außen in einer einer definierten Zeit ausgelesen /verrechnet wird und dann wieder auf 0 gestellt wird.
Bei geringem Verbrauch (niedriger Drehzahl der Scheibe) wird dies natürlich sehr ungenau.
Besser dann so:
In der ext. ISR ein Start/Ende Flag Flipflop einbauen das wiederum z.b in einer Timer2 ISR das Inkrementieren zweier Variablen im Wechsel Start und Stoppt, und wieder auf 0 setzt.
Wenn jetzt länger kein ext. ISR auftritt, (weil sehr wenig Stromverbrauch) würde Timer2 die Variablen bis zum Überlauf hochzählen.
Hier ein Maximum festlegen.
Bei einem anderen Projekt von mir, ein alter Ferraris-zähler loggt so den Stromertrag einer kleinen PV Anlage, das funktioniert so recht zuverlässig.
Meine Lichtschranken sind diese aus alten Industriebeständen. Link
