Wasserzähler erfassen - hochauflösend - Leckagekontrolle

Problemlösungen und Hinweise von allgemeinem Interesse zur Haussteuerung mit HomeMatic

Moderator: Co-Administratoren

Joker971
Beiträge: 126
Registriert: 22.12.2015, 22:01
Danksagung erhalten: 2 Mal

Re: Wasserzähler erfassen - hochauflösend - Leckagekontrolle

Beitrag von Joker971 » 08.02.2017, 13:04

Das ist halt so. Die Mechanik im Zähler braucht hat einen gewissen Durchfluss damit das Anlaufdrehmoment überwunden wird. Das ist je nach Hersteller verschieden. Ein Tropfender Wasserhahn wird zwar nicht registriert aber eine leicht laufende Toilette schon (Bei Druckspüler), was eher unentdeckt bleibt und über das Jahr gesehen hohe kosten verursacht.

klassisch
Beiträge: 3974
Registriert: 24.03.2011, 04:32
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 110 Mal
Danksagung erhalten: 70 Mal

Nutzung von Interrupts

Beitrag von klassisch » 14.03.2017, 18:36

Hab jetzt - einem freundlichen Hinweis von Eugen folgend - die Zählroutine von polling auf Interrupt umgestellt. Zwar noch ohne jegliche Optimierung, aber man kann jetzt mindestens die zehnfache Eingangsfrequenz fahren, ohne daß der Zähler etwas verliert. Auch nicht beim Abrufen einer einfachen Webseite. Allerdings hatte ich bei mehrfachen schnell aufeinanderfolgenden Aufrufen einen reboot durch exception.
Also wahrscheinlich könnte man auf einen der beiden WeMos verzichten, wenn man Interrupts nutzt. Gerade läuft ein Dauertest mit simulierten 8000l/h.

Das habe ich geändert:
Die Variablen im Interrupt bekommen ein "volatile" in der Deklaration, damit sie der Compiler nicht versehentlich wegoptimiert.
Aus

Code: Alles auswählen

unsigned long inputCounter, inputCounterLastCycle, lastTransitionTime;  
unsigned long elapsedTime, elapsedTimeLastCycle; // time between two ticks
wird

Code: Alles auswählen

volatile unsigned long inputCounter, inputCounterLastCycle, lastTransitionTime;  
volatile unsigned long elapsedTime, elapsedTimeLastCycle; // time between two ticks
Dann wird der Interrupt direkt nach der Definition des Einganspins deklariert:
Aus:

Code: Alles auswählen

pinMode(INPUTPIN_FC, INPUT_PULLUP); // GPIO14, D5   or try GPIO0, D3 -> 10k pull up resistor -> 3V3
wird

Code: Alles auswählen

pinMode(INPUTPIN_FC, INPUT_PULLUP); // GPIO14, D5   or try GPIO0, D3 -> 10k pull up resistor -> 3V3

attachInterrupt(digitalPinToInterrupt(INPUTPIN_FC), handleInterruptInputCounter, CHANGE);
Netterweise kann man den Interrupt bei jedem Flankenwechsel triggern lassen (CHANGE) und erspart sich damit die SW-Lösung dafür.
Zuletzt wird das zentraleZählelement aus void loop() herausgelöst und in eine Interrupthandling-void verfrachtet. Aus:

Code: Alles auswählen

  if (digitalRead(INPUTPIN_FC) == lastDigInputState); // no transition detected do nothing
  else { // transition detected
    inputCounter++ ;
    lastDigInputState = ! lastDigInputState; // toggle
    elapsedTimeLastCycle = jetztMillis - lastTransitionTime; // calculate elapsed time
    transferData.TransferElapsedTimeLastCycle = elapsedTimeLastCycle;
    lastTransitionTime = jetztMillis; // set start of new cycle
  }
wird:

Code: Alles auswählen

void handleInterruptInputCounter(){
    inputCounter++ ;
    elapsedTimeLastCycle = jetztMillis - lastTransitionTime; // calculate elapsed time
    transferData.TransferElapsedTimeLastCycle = elapsedTimeLastCycle;
    lastTransitionTime = jetztMillis; // set start of new cycle
}
Also 1:1 übernommern, ohne Optimierung. Da könnte man noch etwas herausholen.
Läuft so und das deutlich schneller und parallelisierbar.

klassisch
Beiträge: 3974
Registriert: 24.03.2011, 04:32
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 110 Mal
Danksagung erhalten: 70 Mal

Handy-Sensor VL53L0 ungeeignet

Beitrag von klassisch » 14.03.2017, 18:55

Es kam auch die Frage auf, ob man statt des teuren EX-26 auch einen billigen Gestensensor aus dem Handybereich nutzen könnte.
Habe mir für fast 6,30 EUR den VL53l0 von ST gleistet. Klingt schön, duck's guts, alles was im Lidar-Bereich derzeit hoch gehandelt wird: VCSEL-Laser und SPAD-Array als Empfänger.
Bei mäßiger Umgebungshelligkeit kann man bis etwa 2m den Objektabstand messen.
Wenn man das Datenblatt weiter liest, sieht man auch, warum das aber für die Wasseruhr wahrscheinlich nicht taugt. Der view cone des Empfänger hat 25°, der des Senders 35°. Damit kann man das Sternrad wahrscheinlich nicht vom Hintergrund unterscheiden - von der Nichtkonzentrizität mal abgesehen.
Ansonsten interessantes Teil. Und der Nachfolger ist auch schon angekündigt, aber noch nicht bei unseren üblichen Quellen erhältlich.
Wenn Interesse besteht kann ich am WE mal etwas mehr dazu schreiben und ein paar Bilder machen.

Benutzeravatar
funkleuchtturm
Beiträge: 2362
Registriert: 13.06.2011, 16:42
Hat sich bedankt: 23 Mal
Danksagung erhalten: 355 Mal
Kontaktdaten:

Re: Wasserzähler erfassen - hochauflösend - Leckagekontrolle

Beitrag von funkleuchtturm » 14.03.2017, 20:00

klassisch hat geschrieben:Hab jetzt - einem freundlichen Hinweis von Eugen folgend - die Zählroutine von polling auf Interrupt umgestellt. Zwar noch ohne jegliche Optimierung, aber man kann jetzt mindestens die zehnfache Eingangsfrequenz fahren, ohne daß der Zähler etwas verliert.
Hallo Jürgen,
ja ich hab sogar den geplanten Wiffi-logger mit drei Zählern für Gas, Wasser, Strom mit Interrupts realisiert. Läuft "eigentlich" wunderbar, aber...

Beim Langzeittest hatte ich immer etwas zu geringe Zählergebnisse. Hatte gedacht, daß liegt irgendwie an der Signalaufbereitung. Hab gesucht und gesucht!

Jetzt "glaube" ich zu wissen:
Wenn das WLAN beim ESP8266 nicht aktiv ist bzw. nicht verwendet wird, dann läuft der Interrupt wunderbar und fehlerfrei. Aber wenn das WLAN aktiv ist, dann wird vermutlich ein NMI (non maskable Interrupt) regelmäßig für die WLAN-Routinen ausgelöst, währenddessen der normale Interrupt wirkungslos ist. Das führt dann zu den fehlenden Zählimpulsen.
Sehr, sehr ärgerlich das Ganze, weil das beim ESP8266 nicht dokumentiert ist. So kann ich meinen geplanten Wiffi-logger in der Form erst mal beiseite legen.
Hab auch keine Idee, wie man das Problem lösen kann :shock:
.. außer mit zwei ESP8266, wobei einer nur für's Zählen ohne WLAN werkelt. :mrgreen:
Viele Gruesse
Eugen
________________________________________________
SmartHome-Eintopf mit feinem Homeduino-Gemüse
... und für Feinschmecker gibt´s den WIFFI, den WEATHERMAN-2, den PULSECOUNTER und den AIRSNIFFER
mit vielen Kochrezepten für den ambitionierten Homematiker

klassisch
Beiträge: 3974
Registriert: 24.03.2011, 04:32
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 110 Mal
Danksagung erhalten: 70 Mal

Re: Wasserzähler erfassen - hochauflösend - Leckagekontrolle

Beitrag von klassisch » 14.03.2017, 20:57

Vielen Dank für die Hinweise, Eugen!
Drei langsame Zähler könnte auch noch ohne Interrupts mit Polling gehen.
Irgendwo habe ich Messungen auf der Versorgung gesehen, denke fake WeMos mit schlecherem Spannungsregler, wo man die WLAN-Aktivitäten recht deutlich sah. Das war recht häufig, auch in "Ruhezeiten".
Polling ist natürlich robuster als die flankengetriggerten Interrupts. Wenn da einer fehlt ist weg. Beim Polling hat man meist noch eine Chance. Ohne WLAN-Ausgabe erreiche ich 2 bis 3 kHz mit Polling. Mit WLAN-Ausgabe, Seitenaufbau etc. fehlen schon deutlich früher Impulse.
Deshalb bin ich sehr rasch auf die Zweiprozessorlösung gegangen. Erst mal 2 WeMos; die waren da und sind bezahlbar. Ein ESP32 wäre auch was Gutes, wenn die IDE mal liefe. Derzeit lasse ich beide WLANs mitlaufen, mache die Kommunikation nur über den zweiten Prozessor, der die Zählergebnisse vom esten über HW-Serial erhält. Das läuft so weit. Das WLAN des Zählprozessors nutze ich für updates zum debuggen oder gelegentliche Anfragen. Dabei kann ich dies auf Zeiten ohne Wasserdurchfluß legen. Das ist natürlich keine allgemeingültige Lösung.
Man könnte die aber erweitern: Die HW-seriell bidirektional machen und so auf Kommando des Prozessors 2 (bei mir B genannt) wird das WLAN des ersten (A, Zählprozessor) ein- oder ausschalten. Dann kann man diesen auch per OTA updaten und dann wieder WLAN aus.

Werde als nächstes mal meine Dauererprobung verschärfen und mir mit fsommer1968 Webdebug die einzelnen Abweichungen von der Sollfrequenz aufzeichnen lassen. Wobei natürlich auch ein mangelnder Synchronismus zwischen WeMos und Funktionsgenerator für den einen oder anderen "Verzähler" verantwortlich sein kann.

mfahs
Beiträge: 280
Registriert: 18.01.2011, 00:06

Re: Wasserzähler erfassen - hochauflösend - Leckagekontrolle

Beitrag von mfahs » 14.03.2017, 21:45

Ich lausche Euch schon lange hochinteressiert - komme aber leider nicht mehr ganz mit, das übersteigt meine Wemos-Fähigkeiten bei weitem.
Dennoch: da ich auch schon länger an einer Beobachtungsmöglichkeit für den Wasserzähler suche, werde ich weiter lauschen! [emoji4]
Ich habe nur eine Bitte: wenn es ein gutes und (halbwegs) endgültiges Ergebnis gibt, würde ich um eine möglichst genaue Beschreibung bitten [emoji6]
Vielen Dank schon mal dafür vorab!

Grüße
Martin

klassisch
Beiträge: 3974
Registriert: 24.03.2011, 04:32
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 110 Mal
Danksagung erhalten: 70 Mal

Re: Wasserzähler erfassen - hochauflösend - Leckagekontrolle

Beitrag von klassisch » 14.03.2017, 21:50

Der Post #1 ist die Beschreibung. Das System arbeitet bei mir im Produktiveinsatz. Das oben sind lediglich Spielereien mit einem Entwicklungssystem.

Gesendet von meinem ZTE A2016 mit Tapatalk

klassisch
Beiträge: 3974
Registriert: 24.03.2011, 04:32
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 110 Mal
Danksagung erhalten: 70 Mal

Re: Wasserzähler erfassen - hochauflösend - Leckagekontrolle

Beitrag von klassisch » 15.03.2017, 04:58

@Eugen: Du nutzt doch auch NTP.
Bei Stoffregen
https://github.com/PaulStoffregen/Time
steht
The default interval for re-syncing the time is 5 minutes but can be changed by calling the
setSyncInterval( interval) method to set the number of seconds between re-sync attempts.
Ich habe definiert

Code: Alles auswählen

unsigned int ntpSyncInterval = 10000;
was so etwa alle 3h bedeutet und mir bisher für meine Anwendungen völlig ausreichend schien. Könnte man für den Zählerprozessor noch erweitern, der lebt ja von millis() und damit vom internen Oszillator.
Außerdem hole ich ntp vom Router und nicht vom Internet, was aber auch noch nicht allgemeingültig ist. Meine alte Fritzbox 7170 am Zweitstandort kann das noch nicht, weshalb ich dort via VPN auf eine andere Fritzbox gehe. Aber die Tage der 7170 sind gezählt, Annex J steht an.

Apropos Oszillator: Was für einen Oszillator hat denn der WeMos? Da gibt es einen 12MHz Quarz, aber der gehört wohl eher zum serial-USB Wandler. Esperssif empfiehlt einen Quarz für den ESP12F.

Benutzeravatar
funkleuchtturm
Beiträge: 2362
Registriert: 13.06.2011, 16:42
Hat sich bedankt: 23 Mal
Danksagung erhalten: 355 Mal
Kontaktdaten:

Re: Wasserzähler erfassen - hochauflösend - Leckagekontrolle

Beitrag von funkleuchtturm » 15.03.2017, 07:37

klassisch hat geschrieben:@Eugen: Du nutzt doch auch NTP.
Ich nutze das Beispiel UdpNtpClient bei Beispielen unter Ethernet.

Zum Thema Oscillator kenne ich nur das: http://www.esp8266.com/viewtopic.php?f=13&t=3273
Viele Gruesse
Eugen
________________________________________________
SmartHome-Eintopf mit feinem Homeduino-Gemüse
... und für Feinschmecker gibt´s den WIFFI, den WEATHERMAN-2, den PULSECOUNTER und den AIRSNIFFER
mit vielen Kochrezepten für den ambitionierten Homematiker

cmjay
Beiträge: 2373
Registriert: 19.09.2012, 10:53
System: CCU
Wohnort: Jottweedee
Hat sich bedankt: 250 Mal
Danksagung erhalten: 348 Mal

Re: Handy-Sensor VL53L0 ungeeignet

Beitrag von cmjay » 15.03.2017, 11:04

OT:
klassisch hat geschrieben: Habe mir für fast 6,30 EUR den VL53l0 von ST gleistet. Klingt schön, duck's guts, alles was im Lidar-Bereich derzeit hoch gehandelt wird: VCSEL-Laser und SPAD-Array als Empfänger. Bei mäßiger Umgebungshelligkeit kann man bis etwa 2m den Objektabstand messen.
Danke für den Hinweis!! Höchst interessantes Teil - auch für den professionellen Einsatz. Ich habe beruflich mit Lidar und absoluter Abstandsmessung zu tun und kannte diesen Sensor bisher nicht. Ok, bei uns geht es i.d.R. um deutlich grössere Abstände, einen höheren dynamischen Bereich und höhere Auflösung... Aber ich kann mir viele Anwendungsmöglichkeiten in der Robotik vorstellen.
Das Ding ist faszinierend, weil es auf dem Time-of-flight Messprinzip beruht und die es tatsächlich schaffen, die ganze dafür notwendige HighTech auf einen 4mm x 3mm Chip für weniger als 10€ zu packen. Mit welchen Tricks die es unter diesen Umständen hinkriegen eine Auflösung im Zentimeterbereich zu erzielen ist mir (und meinen Kollegen) bisher noch ziemlich unklar.
Bestellung für ein paar VL53L0X Breakouts "zum Spielen" geht heute noch raus ...
Es kann leider nicht ganz ausgeschlossen werden, dass ich mich irre.
HmIP muss leider draussen bleiben. in Ausnahmefällen erlaubt
ACHTUNG! Per Portweiterleitung aus dem Internet erreichbare CCU-WebUI ist unsicher! AUCH MIT PASSWORTSCHUTZ! Daher: Portweiterleitung deaktivieren!

Antworten

Zurück zu „HomeMatic Tipps & Tricks - keine Fragen!“