Wasserzähler mit HM-ES-TX-WM

[MathiasZ]

Das Thema ist sehr spannend. Danke für's Teilen!!!
Sagt mal, geht das auch mit einem Arduino nano?
Ich habe da noch einige davon herumfliegen.
ich dachte, bevor ich mir jetzt einen Uno bestelle, frage ich erst mal nach, ob es auch mit einem Nano möglich ist.
danke schon im voraus,
Mathias

[klassisch]

Ein paar Posts oben hat Sven ausgerechnet, daß bei seiner Wasseruhr mit max. 5000l/h zu rechen ist, was beim Liter-Zeiger (1 Umdrehung=1l) ca. 1,4Hz bedeutet.
Meine Wasseruhr ist im Grunde anders spezifiziert mit Dauerdurchfluß Q3 mit 4m^3/h. Steht so auf der Wasseruhr. Aber der Überlastungsdurchfluß Q4 ist ebenfalls mit 5m^3/h spezifiziert (steht im Datenblatt). Wenn man also annimmt, daß die Uhr nicht schneller drehen könnte, käme man auf die 1,4Hz. Wahrscheinlich wird sie aber schneller drehen, aber nicht mehr im Rahmen ihrer spezifizierten Genauigkeit messen.
Ich möchte die Flanken des Sternrades zählen. Das hat bei mir 6 Zacken und damit 12 Flanken. Falls sich das Rad ebenfalls einmal pro Umdrehung des Literzählers dreht (was ich allderings noch nicht weiß) Wären das dann ca. 17 Hz.
Das Thema Ermittlung, Weiterleitung und Archivierung ist etwas schwieriger. Hier möchte ich einen WeMos nutzen oder zwischenschalten.
Einfach ist es dennoch nicht.

Edit: habe eben versucht zu zählen: Beim Sternrad habe ich wahrscheinlich 44Zacken /Liter, wenn ich Flanken Zähle muß ich also 88 Flanken pro Liter Zählen, also mind. 122Hz.

[Sven_A]

@Matthias: Ich hatte selber noch nie einen Nano in der Hand (leider), sehe aber kein Problem. Der original Nano läuft auch mit 5V, insofern passen auch die Widerstände. Nur bei einem 3V Clon müsste man mit den LEDs aufpassen.

@klassisch: Die Frequenz wird nicht das Problem sein, das genaue fokussieren wird “spannend“.

Gruß,
Sven

[MathiasZ]

Ich habe nur Clones zuhause. Die laufen alle auf 5V.
Nun zu den Systemvariablen.
Da ich die Daten direkt per WLAN loggen will, (dann spare ich mir die 4 Aktoren) könnte mir jemand einen Tip beim Script und den 4 Sysvar geben? Ich habe leider 1 Wasseruhr warm und 1 Wasseruhr kalt JEWEILS in der Küche und in der Toilette. Macht zusammen 4 Wasseruhren. WLAN-Module (ESP8266-12E) müssten auch bald eintreffen.
Gruß,
Mathias

[klassisch]

Ich plane auch ESP8266 in der Ausführung WeMos zu verwenden. Habe aber noch nichts programmiert und weiß auch nicht, ob der mit der Eingangsfrequenz bei gleichzeitiger WLAN-Übertragung zurecht kommt. Bei Literzähler und <2Hz eher als in meinem Fall mit eher 130 Hz.
Bei max 1,3Hz gibt es meiner Meinung nach folgende einfache Möglichkeiten:
- Frequenzmessung und Akkumulation im WeMos und Übertragung alle z.B. 30 Sekunden oder 60 Sekunden an 2 CUxD Transform-devices (Wrapper 90,1)
-- 1 Transformdevice für die Summe, die im WeMos akkumuliert wird
-- 1 zweites Transform device für den Durchfluß der letzten 30 oder 50 Sekunden
- Übertragung Jedes Impulses an ein CUxD State Monitor Device (Wrapper 90,2). Alles andere macht das CUxD Device
Für die Übetragung via WLAN an ein CUxD Device siehe Anleitung des CUxD und den WeMos-Thread hier im Forum und http://www.renmet.com/wiki/index.php?title=Hauptseite

Die zweite Lösung macht amwenigsten Arbeit, aber ich weiß nicht, ob die CCU mit der Frequenz zurecht kommt. Ich verwende das CUxD State Monitor Device (Wrapper 90,2) zur Überwachung der Brennerbetriebszeiten, allerdings nicht mit einem WeMos.
Transform-Devices verwende ich zusammen mit WeMos für Luftdruck und auch für Tankfüllung.

Edit: Übertragung an Systemvariablem würde auch gehen. Aber die lassen sich keinem Raum und keinem Gewerk zuordnen, weshalb ich die nicht mehr so gerne als Eingangsvariable für WeMos -> CCU verwende. Wie das geht, steht auch im renmet-Wiki und im WeMos Thread.

[klassisch]

@klassisch: Die Frequenz wird nicht das Problem sein, das genaue fokussieren wird “spannend“.

Ja, und deshalb habe ich eine völlig unwirtschftliche Summe von mindesten 45USD als Spielgeld deklariert und in einen Panasonic SunX EX-26A investiert. Laut dessen Datenblatt soll der 0,1mm fokussieren können. Leider hat der Händler noch nichts weggeschickt. Wird noch ein paar Wochen dauern

[Sven_A]

Ich hab mich mit Absicht für den HM-ES-TX-WM entschieden.Bei Netzwerk müsst ihr auf korrekte Übertragung, Erreichbarkeit der CCU und gleichzeitige weite Erfassung der Zähler achten... Das Fehlerhandling ist nicht ohne.
Das war als Netzwerker meine erste Idee, war mir am Arduino dann aber zu aufwändig.

Das nimmt einem der HM-Sender ab. Ich plane im Moment noch das neue 8Bit Sendemodul für eine 2 Zähler Erfassung zu integrieren, da bin ich aber noch nicht so weit. Erstmal muss ich das löten (einfach) und in Bezug auf Duty Cycle testen (aufwändiger).

Gruß,
Sven

[klassisch]

Bin kein Netzwerker, vielleicht gehe bin ich deshalb zu naiv an die Sache ran. Meine WeMos- T-H-Luftdrucksensoren und der sonstige WeMos Kram gehen jedenfalls gut, aber eben nicht in der Taktrate. Deshalb brauche ich eine Vorverarbeitung im WeMos. Wenn man z.B. alle 60 Sekunden einen Wert für den Durchfluß schicken würde, dann wäre der u.U. ca. 60 Sekunden falsch, da verzögert. Wenn man statt in konstanten Abständen bei Niedrigdurchfluß auf Flanken triggert stünde der falsche Wert noch länger an. Wenn man die Flanken in realtime direkt an die CCU, ein CUxD State-Monitor-Device bekommt, hätte man gewonnen. Bei 2Hz via WLAN/LAN könntedas noch klappen, über Bidcos treibt man die Funklast ordentlich hoch. Bin gespannt, was Deine Ergebnisse da bringen. Vielleicht klappt es noch mit dem Literzeiger; fürs Sternrad mache ich mir keine Hoffnung.
Schön wäre es auch, eine Reihe Werte im WeMos zwischenzuspeichern und dann als großes Paket an die CCU ioBroker o.ä. zu übergeben. Aber ich weiß nicht, wie man an diese Geräte neben dem Meßwert auch noch die korrespondierende Zeit schickt, so daß diese Geräte die Wertepaare dann in die Vergangeheit richtig einsortieren.

[Sven_A]

@klassisch: 0,1mm ist ja nett. Bei meinem Hauszähler ist aber das Deckglass 2cm dick, da nützt das nichts. Bei den Warm-/Kaltzählern im Bad ist das aber i.d.R. anders.

Bei Temperatur, Druck usw ist ja nicht schlimm wenn ein Wert nicht an kommt. Bei Zählen hast du dann aber eine Abweichung drin, dass ist mind. unschön. Also muss die Übertragung auf Erfolg geprüft werden, und im Fehlerfall gepuffert und erneut übertragen werden...

@Matthias: Ich weiß aber das es sich 3V Clones gibt, daher hab ich das erwähnt.

[klassisch]

Ja, bei der Variante mit dem CUxD StateMonitor kann das zu Fehlern führen. Ob die gravierend sind, weiß ich nicht. Meine Brennerkurven sehen jedenfalls plausibel aus. Aber eben nicht diese Geschwindigkeit.
Deshalb möchte ich die Kumulation unbedingt auch auf dem WeMos machen. Das scheint mir robuster, wenn auch nicht komplett fehlerfrei.
Da schleichen sich Fehler ein wenn:
- Der WeMos resetiert und verliert die Summe. Das kann man aber vielleicht mitigieren, wenn man nach einem Reset den kumulierten Wert von der CCU wieder rückliest, oder manuell korrigert und mit der Wasseruhr abgleicht.
- Der WeMos beim WLAN-Senden Impulse verliert.