[funktioniert] Wasserzähler mit Batteriebetrieb, ursprüngl. mit Solaranlage

Begonnen von andies, 23 Juli 2018, 22:17:40

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: andies am 25 Juli 2018, 22:03:09Wenn ich MySensors nachlesen, dann heißt das doch, dass ich ein weiteres Gateway brauche.

Lohnt sich das? Ich muss ja dann einen dritten (mit WLAN eigentlich vierten und weil Homematic auch im LAN eigentlich fünften) Empfänger an meinen FHEM-Server (ist übrigens ein RPi 3) anschließen. Wäre nicht ein Umweg über 433 MHz besser?
Korrekt: man braucht für jede Transceivertechnik ein eigenes GW. Ob das für dich "lohnt", mußt du letztendlich selber entscheiden. Für FHEM an sich ist das kein großes Ding: Bei mir sind derzeit 7 USB-Interfaces belegt, dazu kommt noch der MapleCUN (4 Funk-Schnittstellen, + 2 Optionen für serielle Interfaces via Netz). Dazu dann noch ein sidoh-GW für MiLight... Von den 7@USB sind 4 MySensors-GW's (nRF24, RS485, RFM69 und RFM95 (LoRa)), wobei die RFM's derzeit vorrangig zu Testzwecken dienen.
Kann halt sein, dass du für den PI einen aktiven Hub brauchst.

Aber wenn du das Prinzip mal verstanden hast, kannst du mit MySensors praktisch beliebigen Arduino-Code verwenden und Daten mit FHEM austauschen. Ist zwar etwas mehr Aufwand als z.B. ESPEasy (in dem, wie ich das verstanden habe bereits viele Standard-Sensor-libs drin sind, die man dann nur aktivieren muß), aber man kann sich da auch als interessierter Laie einarbeiten (ist mir jedenfalls halbwegs gelungen). Der Vorteil von USB-GW's ist halt, dass die Daten ohne Umweg in FHEM landen (und auch wieder rausgehen); WLAN ist z.B. was, was ich vermeide, wo es geht.
Zitat von: andies am 26 Juli 2018, 09:07:50
Na dann überlegen wir beide mal laut weiter. Ich habe inzwischen genug gelesen, dass ich das vermutlich mit einem attiny85 machen kann, der scheint den geringsten Stromverbrauch zu haben. Die ableseeinheit sollte dann der tcrt werden, wobei mir nicht klar ist, wie viel dauerstrom so ein Ding verbraucht. Und dann fehlt noch die Übertragung zu FHEM, da habe ich einen signalduino, dem ich gern ein bereits existierendes Protokoll vorgaukeln würde. Da frage ich gleich mal nach.
OK, das Prinzip ist dir ja jetzt klar. Ich würde aber auch für den Software-Teil nochmal das wiederholen, was ich schon zur Frage der Auswahl des Microcontrollers gesagt habe: Es ist für Einsteiger einfacher, sich (erst mal) aus einem bestehenden Baukasten zu bedienen, als alles mögliche selber machen zu wollen. Und die Optimierung von Code für einen ATTiny dürfte auch so eine Sache sein, die etwas Übung erfordert.

Von daher wäre m.E. nur noch der Weg über AskSin++ (Eigenbau-HM-BidCoS) tendenziell noch einsteigerfreundlich (da kenne ich mich aber nicht aus, gehe aber davon aus, dass sich da die lib auch z.B. darum kümmert, dass der Tranceiver ausgeschaltet wird, wenn er nicht gebraucht wird usw.). Kann aber sein, dass es auch Lösungen für den Signalduino gibt (für Jeelink gibt es einige keyValueProtocol-Lösungen).

Du darfst auch als Arbeitshypothese erst mal davon ausgehen, dass ein für den Batteriebetrieb optimierter Pro Mini mit einem TCRT5000 eine halbwegs vernünftige Batterielaufzeit ermöglicht, von daher: warum nicht einfach mal testen? Optimieren (oder mit Solarstrom versorgen) kann man immer noch, als Anregung: https://forum.mysensors.org/topic/4820/water-meter-pulse-sensor/13. Vom Verbrauch her wäre m.E. allerdings ein "nackiger" Reed am besten, aber es ist eben immer ein Kompromiss...

Und nochmal: 80m sind keine Entfernung, über die man sich zu große Gedanken machen sollte. Das ist - neben der Wahl des Senders/Transceivers - eher eine Frage der Antenne. Bei youtube gibt es z.B. ein Video, da hat jemand mit nRF-Bausteinen eine Verbindung über 13km (oder so) hinbekommen, ich habe einen kürzeren Test gemacht, da waren es ohne Optimierung mit pa+lna-Modellen ca. 100m (kein Freifeld!) mit MySensors als Datenprotokoll... 25m sollten auch für einen CC1101 (AskSin++/HM) zu schaffen sein, die Dinger sind im Freifeld für 100m spezifiziert. Mit MySensors kann man auch einen/mehrere Repeater dazwischenschalten, um so eine größere Abdeckung zu bekommen.

Für Fortgeschrittene, die auch eine Zeitkomponente realisiert haben wollen: Was ggf. auch geht, wäre einen Uhrenbaustein mit Zähleroption zu verwenden, z.B. https://www.nxp.com/docs/en/data-sheet/PCF8583.pdf. Das ermöglicht z.B. auch sofortige Alarmierungsmodi, wenn bestimmte Zählerwerte innerhalb eines Zeitraums überschritten werden (der Baustein kann das bei geringem Stromverbrauch überwachen und dann ggf. einen Interrupt auslösen). Ich habe z.B. vor, so einen für einen MySensors-Windmesser zu verwenden (ihr ahnt es: Solarbetrieben mit einem Supercap...). Das muß aber erst mal noch warten, wenn's fertig ist, bekommt ihr Bescheid ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

andies

Ich habe mal bei voll aufgedrehtem Gartenschlauch den Zähler gefilmt um zu sehen, wie lange eigentlich die IR-Diode an sein muss, damit sie das sich drehende Metallteil entdeckt (wenn ich das richtig sehe, zieht die Diode wohl locker 500mA und kann also nicht durchgehend eingeschaltet sein, ohne die Batterie leerzusaugen). Film hängt an.

Daraus entnehme ich, dass die Metallscheibe bei voller Last (bei mir) in etwa 4,5 Sekunden benötigt, um eine volle Umdrehung vorzunehmen. Langsamer geht immer, schneller wohl eher nicht. Wenn ich also alle 3-4 Sekunden für 0,5s anschalte, könnte das ausreichen.

Was deep sleep angeht, ist dieses Video hier sehr gut: https://www.youtube.com/watch?v=urLSDi7SD8M. Langsam entsteht ein Plan.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Beta-User

 ??? Das ist nicht so toll, dass das TCRT-Modul soviel Strom zieht - Pulsen ist daher wohl schon sinnvoll (wenn andere Optionen nicht gehen - ein Test mit einem Reed wäre m.E. noch sinnvoll).

Allerdings weiß ich nicht so recht, ob der voll aufgedrehte Gartenschlauch das Maß der Dinge ist: Wenn du einen massiven Wasserschaden hast, kann da auch deutlich mehr durchgehen, oder?

Was vielleicht auch eine Option wäre: Eine kleinere mcu zum Pulsen und ggf. messen (z.B. 1/Sec) mit einem nackten TCRT oä, +analoges Messen), die dann bei einer Drehung den interrupt an der Haupt-mcu triggert. Aber keine Idee, ob das den Strombedarf soweit senkt, dass das passt.

Oder den TCRT nackt betreiben und ggf. auf die konktete Anwendung hin angepaßtem Design drumrum (Vorwiderstand und Verstärkerschaltung?). Aber da gibt es sicher Experten, die wissen, wie das geht.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

andies

Ich habe mal nachgemessen (Lenin sagte schon, wenn der das wirklich war, "Vertrauen ist gut, Kontrolle ist besser"): Also mein TCRT5000 zieht 33mA Strom bzw, wenn er nichts vor sich hat, 29mA. Die eine Diode, die Spannung anzeigt, kann man sicher auch auslöten und so weiter senken.

Wenn ich "normale" Batterien nehme, haben die ca 2000 mAh (wobei das mW schon hoch ist, da muss man etwas mehr Geld ausgeben). Wenn die sechs Monate halten sollen, darf pro Tag nicht mehr als 11,1 mAh oder ein durchschnittlicher Dauerstrom von höchstens 0,463 mA (aus 11,11/24) über den ganzen Tag gemittelt verbraucht werden. Damit kann ich jetzt ausrechnen, wie lange und wie oft der Sensor an sein soll.

Ich gehe aus von einer Messung alle drei Sekunden. D.h. drei Sekunden ist der Sensor aus (halt: Wie kann ich denn die Stromversorgung beim Sensor unterbrechen? Ich habe ja nur einen arduino da unten? Die Pinouts liefern nur 3,3V und ein Relais habe ich nicht, das wäre auch zu viel Strom. Eventuell einen Transistor dazwischenschalten? Ist mir momentan nicht klar.), dazu kommt x ms Messzeit. Das ergibt einen durchschnittlichen Stromverbrauch von

(3000ms*0 + x ms*33mA) / (3000 ms + x ms) = 0,4636 mA.

Das ergibt ein x von 42,75 Millisekunden. (Bei einer Ablesefrequenz alle 4 Sekunden kommt da 57 ms heraus. Wenn ich jede Sekunde ablese, ergeben sich 14ms).

Also bleiben zwei Fragen.

  • Wie kann ich den Sensor komplett vom Strom nehmen?
  • Reichen 42ms oder im Idealfall sogar nur 14ms aus, um den Wasserzähler korrekt auszulesen?
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

Zitat von: Beta-User am 26 Juli 2018, 22:27:34
Allerdings weiß ich nicht so recht, ob der voll aufgedrehte Gartenschlauch das Maß der Dinge ist: Wenn du einen massiven Wasserschaden hast, kann da auch deutlich mehr durchgehen, oder?
Das kriegt man vermutlich mit einer Mustererkennung hin. Denn bei einem Wasserrohrbruch dürfte nachts der Verbrauch genau so hoch sein wie tagsüber, ohne Rohrbruch wird das wesentlich niedriger sein. Bzw es gibt nachts lange Strecken ohne Verbrauch (keine Toilette, kein Bad, keine Entkalkungsregeneration), es sei denn, es ist etwas faul.

Aber dennoch werde ich im dritten Schritt versuchen, eine Solaranlage zu installieren und permanent zu lesen. Ist einfach sicherer und gemessen an den Kosten, die hier genannt wurden, peanuts.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

Ich überlege immer noch, habe aber (bis auf zwei Bohrlöcher in der Schachtabdeckung für das Gehäuse) noch nichts umgesetzt.

Ich glaube Deep-sleep geht nicht. Das würde ja voraussetzen, dass der Interrupt jederzeit ausgelöst werden könnte. Das wiederum hieße, dass der TCRT5000 oder ein vergleichbares Gerät ständig an ist - da ist aber der Verbrauch zu hoch.

Also bleibt wohl erstmal nur: ein attiny oder was auch immer, der in einem bestimmten Takt pulst, die LED einschaltet, misst, auswertet und sich wieder schlafen legt. Bei jeder fallenden Flanke (zB) wird ein 433-Signal (oder was auch immer) abgesetzt.

Das probiere ich mal. Insbesondere ist völlig offen, wie akkurat diese Methode ist. Ich könnte parallel mal nach Sonnenkollektoren suchen, damit die Taktrate so hoch wie möglich wird.


Gesendet von iPhone mit Tapatalk Pro
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

fiedel

Ehrlich gesagt wäre mir das alles viel zu viel Aufwand und Unwägbarkeit, selbst als Elektroniker. Was sprach noch mal genau gegen das HM- Energiezählermodul? HM hast du doch.? Ob   die Reichweite passt, kannst du ggf. mit was Vorhandenem testen.
Das mit dem Pulsen und LED abschalten könntest du bei diversen HM- Bausätzen, bzw. deren Schaltplänen abgucken. Die machen ja viel mit Atmels und da siehst du auch gleich die richtigen Bauelementebezeichnungen und Werte.
FeatureLevel: 6.1 auf Wyse N03D ; Deb. 11 ; Perl: v5.14.2 ; IO: HM-MOD-RPI-PCB + VCCU|CUL 868 V 1.66|LinkUSBi |TEK603
HM: SEC-SCO|SCI-3-FM|LC-SW4-PCB|ES-PMSW1-PL|RC-4-2|SEN-MDIR-O|SEC-WDS-2
CUL: HMS100TF|FS20 S4A-2 ; OWDevice: DS18S20|DS2401|DS2406|DS2423

Beta-User

Auf die Art kommt es mir auch sehr frickelig vor, den Test mit der HM-Hardware ist vermutlich eine gute Idee.

Was Selbermachen angeht, sind da m.E. auch einige Annahmen drin, die nicht passen: Zum einen dürfte der TCRT auch mit weniger als 5V laufen (ggf. mit einem anderen Vorwiderstand), zum anderen wäre interessant, auf wessen Konto da wieviel Strom geht (eher die Leuchtdiode oder der Comparator?). Wenn möglich sollte man das Teil ohne letzeren zu betreiben, kommt halt drauf an, welchen Pegel die Photodiode liefert/liefern kann.

Jeden Puls zu versenden ist vermutlich auch keine gute Idee, da ist davon auszugehen, dass das zu viel Strom braucht. Am einfachsten wäre es immer noch, den TCRT direkt am Pro Mini zu betreiben und den Interrupt zu nutzen. Dann aber ohne pulsende Abfrage.
Wenn pulsen: Warum nicht den Teil auf einen ATTiny auslagern und das Ergebnissignal auf den Interrupt-Eingang der Haupt-MCU geben? Das düfte nicht viel Leistung kosten.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

andies

Ich war bei HM unsicher, ob die Fensterkontaktbatterie die 10.000 Öffnungen (Genauigkeit scheint beim Zähler 0,1l zu sein) über ein halbes Jahr durchhält. Und der Spieltrieb sprach dagegen, es macht einfach Spaß zu frickeln.

Aber Ihr habt Recht, das könnte unverhältnismäßig riskant sein. Den evtl höheren Verbrauch bei HM kann ich mit 4 AAs und einem step-down in den Griff kriegen. Also werde ich das mal probieren. Kann man die LEDs bei dem Homematic-Teil auslöten?


Gesendet von iPad mit Tapatalk Pro
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Beta-User

Wie kommst du wieder auf den Fensterkontakt?

Zitat von: fiedel am 29 Juli 2018, 09:57:36
Was sprach noch mal genau gegen das HM- Energiezählermodul? HM hast du doch.? Ob   die Reichweite passt, kannst du ggf. mit was Vorhandenem testen.

Ein FK ist m.E. ungeeignet, weil jeder Impuls versendet wird... Genau das macht das Energiezählerteil nicht, es zählt und sendet ggf. alle paar Minuten. Alleine die Reichweite ist die Frage bzw., ob man das Anschlußkabel für den Impulsabnehmer verlängern muß.

Wenn du weiter frickeln willst, schick' mir eine PM mit deiner Adresse, dann kann ich dir ein, zwei nackige TCRT5000 (ohne den Schnickschnack drumrum) zusenden und auch einen puren Reed (kost' nix).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

andies

Zitat von: Beta-User am 29 Juli 2018, 13:17:32
Wie kommst du wieder auf den Fensterkontakt?
Sorry, ich kenne mich mit den HM-Teilen nicht so gut aus. Ihr meint den "ELV Homematic Komplettbausatz Zählersensor-Sendeeinheit Strom/Gas inkl. Zusammenbau" mit "Zählerkonstante und Abtastempfindlichkeit"? (Wusste gar nicht, dass es so etwas gibt.)

Danke für das Angebot mit den TCRT, ich habe hier auch noch CNY72 von Vishay herumliegen, das sind nackte LED plus Diode. Also da kann ich auch spielen, aber HM wäre schon schneller und einfacher. Zumal es für das Antennenproblem auch Lösungen zu geben scheint: http://www.techwriter.de/beispiel/funkeige.htm
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Beta-User

Ja, sowas gibt es; allerdings war der Preis, den eQ-3 dafür aufruft einer der Gründe, warum HM bei mir nur noch bedingt auf der Empfehlungsliste steht: Das waren damals 75 Euro, wenn ich mich recht erinnere (eine Basis + ein Zählerkopf)...

Das hat mich zu MySensors getrieben ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

andies

Also ich kaufe jetzt auf Euren Rat hin HM, um dann zu mysensors zu wechseln [emoji41]


Gesendet von iPhone mit Tapatalk Pro
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

FHEM-User22

Moin an alle,
Zitat von: andies am 28 Juli 2018, 19:15:02
Das kriegt man vermutlich mit einer Mustererkennung hin. Denn bei einem Wasserrohrbruch dürfte nachts der Verbrauch genau so hoch sein wie tagsüber, ohne Rohrbruch wird das wesentlich niedriger sein. Bzw es gibt nachts lange Strecken ohne Verbrauch (keine Toilette, kein Bad, keine Entkalkungsregeneration), es sei denn, es ist etwas faul.
Eigentlich reicht es, wenn der Wasserzähler länger als eine gewisse Zeit (z.B. 1 Stunde) nicht "anhält" und dann Alarm gibt. Diese Idee kam mir beim lesen von Andies Nachricht.

Grüße

FHEM auf Raspberry Pi und Proxmox und... und.... und....

Beta-User

Zitat von: andies am 29 Juli 2018, 22:52:11Also ich kaufe jetzt auf Euren Rat hin HM, um dann zu mysensors zu wechseln (https://emoji.tapatalk-cdn.com/emoji41.png)
Das mit der Reichweite hast du wie empfohlen getestet, oder? (Es reicht ein Fensterkontakt oä.) Sonst brauchst du ggf. ein IO an einer weiteren Stelle usw.. einmal quer durch's Haus kann grenzwertig sein, v.a., wenn es schräg durch einen Fußboden geht oder sonst viel Metall verbaut ist.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files