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

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

Vorheriges Thema - Nächstes Thema

r00t2

#15
Zitat von: Wuppi68 am 25 Juli 2018, 12:42:22...Solarpanel an Raspi Zero mit Kamera und dann wird der PI alle 5 Minuten geweckt und schickt ein Foto vom Zähler und legt sich dann wieder schlafen...
Hatte ich auch schon gedacht aber: In der Zeit, in der der RPi gebootet hat, hat eine RF-MCU schon die Messung gemacht, sich wieder schlafen gelegt und ist bereits in die dritte Tiefschlafphase übergegangen :)

Leider kann man die RPi auch nicht wirklich "schlafen" legen, wie eine "echte" MCU und der Leistungshunger im idle des RPi ist jenseits von gut und böse (vergleichen mit einem kleinen Controller).

Grob geschätzt:
RPi: Ein paar Milliwatt Leistungsaufnahme "idle" (vermutlich < 200mW)
MCU: Ein paar Microwatt Leistungsaufnahme im Tiefschlaf (vermutlich < 1mW, je nach Hardware)
FHEM 6.0 (Raspberry Pi 2 B | Raspberry Pi OS Lite | Perl 5.28.1 | UZB Z-WAVE.Me | Hue Bridge V1 | SIGNALDuino 433 MHz | FritzBox | Kodi | Pioneer AVR | MQTT | Node-RED | Diverse Google Dienste)

Wuppi68

mit verlinktem Modul klappt es auch den Pi neu zu starten ...
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

Beta-User

Wenn du einen TCRT noch rumliegen hast (bzw. ein Modul, das optimalerweise gleich einen vernünftigen Logikpegel @3.3V liefert), würde ich den mal testen, ob der sauber unterscheidet, ob das Metallteil drunter durchläuft oder der Rest des Rades. Wenn das klappt, müßte es eigentlich mit einem Arduino im Solarbetrieb gehen, das Stichwort heißt "Interrupt":
Dabei bekommt der TCRT zwar immer Strom (braucht aber vermutlich nicht viel), und du stellst den Arduino so ein, dass er kurz aufwacht, sobald der Logikpegel von High auf Low geht, den Puls in eine Variable schreibt und wieder schlafen geht.

Des Pudels Kern ist das hier im Code: "attachInterrupt(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), onPulse, FALLING);"

Damit wird dann die Routine "void onPulse()" bei jedem Ausgehen des Pegels aufgerufen. Der Code ist nur etwas unübersichtlich, weil er zwei Betriebsarten berücksichtigt, nämlich Schlafend (was du brauchst) und Dauer-Wach. Für den FHEM-Betrieb solltest du dann nur nicht mehr ein "sleep(SEND_FREQUENCY);" am Ende verwenden, sondern "smartSleep(SEND_FREQUENCY);", wenn du zukünftig je Daten mit der Node austauschen wolltest (RSSI-Werte und so).

Als weitere Stromsparmaßnahme solltest du den Arduino dann noch "kastrieren" und nur mit 1MHz betreiben.

Was die Furcht angeht: Ich kann nicht beurteilen, ob das begründet ist, aber ich würde auch neben der Abtastung der Wasseruhr noch einen weiteren PIN des Arduino nutzen, um z.B. einen Schwimmer-oder Pegelschalter anzuschließen (oder nur einen simplen Kontakt). Der Schacht scheint ja mit die tiefste Stelle der Installation zu sein - bei Problemen läuft der also ggf. als erstes voll. Noch ein Grund, den Arduino "nach draußen" zu verlagern.

Zitat von: r00t2 am 25 Juli 2018, 12:39:08
An sowas dachte ich auch. Alternativ gibt es doch auch ESP32 Boards mit LiPo Laderegler an Bord. Könnte man die nicht auch mit einer passenden Solareinheit speisen + betreiben? Alternativ eine separate Ladeeinheit an einem "kleineren" Board (mit separatem oder integriertem RF Chip).
Damit habe ich keine Erfahrung, allerdings ist diese mcu ja noch performanter, was bedeutet, dass man ihr auch erst mal wieder den Stromhunger austreiben müßte...
Manche gehen den anderen Weg und versuchen, noch kleinere mcu's (ATTiny) für MySensors und Co. zu verwenden.

Wer mit sowas keine Erfahrung aht, ist nach meiner persönlichen Meinung besser beraten, er nimmt was Erprobtes, wo nicht mehr allzuviel an Experimenten zu machen ist. Meine ganz persönliche Erfahrung war ein ziemlich frustierender Einstieg in ESP8266 in der vor ESPEasy-Zeit, weil ich der Meinung war, das mir bekannte WLANen wäre einfacher, als Experimente mit irgendwelchen seltsamen Funkmodulen zu machen. Das Gegenteil war richtig: Simple Technik, klarer Einsatzzweck - schnelle verläßliche Ergebnisse...

Und eine mcu hat gg. einem Pi den klaren Vorteil, dass man sich _nie mehr_ um die Software darauf kümmern muß. Paßt die firmware, funktioniert das Ding. Und man hat kein Einfalltor für irgendwelche Eindringlinge ins WLAN.
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

r00t2

#18
Zitat von: Wuppi68 am 25 Juli 2018, 12:50:28
mit verlinktem Modul klappt es auch den Pi neu zu starten ...
Stimmt, das hatte ich übersehen - wirklich ein feines Teil!
Leider braucht das immer noch ein Vielfaches mehr (Zeit und Leistung), als eine MCU.

Zitat von: Beta-User am 25 Juli 2018, 12:51:29...
Als weitere Stromsparmaßnahme solltest du den Arduino dann noch "kastrieren" und nur mit 1MHz betreiben.
...
Oder gleich nur die MCU nehmen, ohne viel drumherum-Verdrahtung. Flashen kann man manche "nackigen" Chips auch mit einem ausgewachsenen Arduino-Board. Hinterher braucht man den ganzen Kram, der Strom frisst (USB, LED, etc.), ja meistens nicht mehr.

Zitat von: Beta-User am 25 Juli 2018, 12:51:29...weil ich der Meinung war, das mir bekannte WLANen wäre einfacher, als Experimente mit irgendwelchen seltsamen Funkmodulen zu machen. Das Gegenteil war richtig: Simple Technik, klarer Einsatzzweck - schnelle verläßliche Ergebnisse...
So sieht es aus :)
WLAN hat seine Einsatzgebiete, ohne Frage. Aber Schnell, performant und stromsparend geht mit RF Funkmodulen um einiges besser.
FHEM 6.0 (Raspberry Pi 2 B | Raspberry Pi OS Lite | Perl 5.28.1 | UZB Z-WAVE.Me | Hue Bridge V1 | SIGNALDuino 433 MHz | FritzBox | Kodi | Pioneer AVR | MQTT | Node-RED | Diverse Google Dienste)

Beta-User

Zitat von: r00t2 am 25 Juli 2018, 12:57:15
Oder gleich nur die MCU nehmen, ohne viel drumherum-Verdrahtung. Flashen kann man manche "nackigen" Chips auch mit einem ausgewachsenen Arduino-Board. Hinterher braucht man den ganzen Kram, der Strom frisst (USB, LED, etc.), ja meistens nicht mehr.
Na ja, für eine "nackige" MCU benötigst du dann doch wieder irgend ein Board, und die Löterei ist nicht unbedingt was für Einsteiger.
Kompromiss wäre ein Arduino Pro Mini (kein USB), da einen anderen Bootloader (1MHz) drauf und dann an Bauteilen entfernt, was nicht benötigt wird: https://www.mysensors.org/build/battery.

Man braucht dann halt einen USB-Seriell-Wandler und "was", um den BL zu flashen - kostet jeweils keine 2 Euro beim freundlichen Chinesen, aber die Sachen braucht man auch für viele Projekte insgesamt nur 1 Mal ;) .
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

r00t2

#20
Die optimierte Arduino Pro Mini Variante mit Batterieüberwachung klingt absolut vernünftig und bietet auch noch genug IOs für diverse Sensoren zum Messen und für RF.

Bliebe noch die Frage nach einer passenden Solarbeschaltung/Laderegelung oder ob man eben alle paar Monate mal die Batterien tauschen geht.

Edit: Habe gerade auf Sparkfun gelesen, dass der Pro Mini den Spannungsregler umgeht, wenn man ihn direkt mit stabilen 3V3 in Vcc betreibt - dann müsste man "nur" die Power-LED unterbrechen, um sparsamer zu werden (und hätte zukünftig immer noch die Chance den RAW Eingang für Spannungen > 3V3 zu verwenden). Klingt gut.
FHEM 6.0 (Raspberry Pi 2 B | Raspberry Pi OS Lite | Perl 5.28.1 | UZB Z-WAVE.Me | Hue Bridge V1 | SIGNALDuino 433 MHz | FritzBox | Kodi | Pioneer AVR | MQTT | Node-RED | Diverse Google Dienste)

Beta-User

Wenn es mit dem TCRT klappt, würde ich erst mal sehen wollen, wie lange z.B. zwei Baby-Zellen halten (das sollte eigentlich für den Pro Mini und das Funkmodul reichen); die Batterie-Spannung kann man ja mit der Node gleich mit erfassen.

Ist das unbefriedigend: Zwischenzeitlich so eine Solar-Lampe organisieren (<10 Euro) und den Schaltplan ansehen, da ist das notwendige drauf und man hat gleich ein für außen passendes Gehäuse ;) . Ggf. dann statt des Akkus einen Supercap dran - fertig sollte die Laube sein...
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

Beta-User

Zitat von: r00t2 am 25 Juli 2018, 12:39:08
Ich klinke mich hier mal mit ein, da das Thema auch für mich interessant ist. Habe zwar einen anderen Anwendungsfall (Briefkastenüberwachung mit Reed-Switches oder Hallsensor, etc.) - das Thema "autarke Energieversorgung" ist aber auch bei mir eine Vorgabe.
Das hatte ich bisher irgendwie überlesen, sorry.

Da würde ich ggf. mal die "universelle HM-Platine" ins Spiel bringen (wenn du HM schon im Einsatz hast). Da das Teil ja nur jeden Tag einige wenige Messungen/Sendungen machen muß, sollte da eine Batterie auch "ewig" halten. Und soweit ich mich entsinne kann man die Platine auch mit nRF-Stamps betreiben, wenn es doch MySensors sein soll.

Bitte dazu aber ggf. einen separaten Thread aufmachen, gerne im MySensors-Bereich. Dieser Thread hier gehört andies ;) .
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

FHEM-User22

Zitat von: andies am 25 Juli 2018, 12:19:29
Die Horrorgeschichte, die ich dann erzählt bekam: Leck in der Leitung, nicht bemerkt, Zack 35.000€ von den Wasserbetrieben berechnet. Nun bin ich etwas nervös.
Sowas ist keine Horrorgeschichte. Habe ich live erlebt. Ich konnte froh sein, das die Versorger wenigstens auf die Abwasserkosten verzichtet haben. Das machte aus 20.000,00 Euro dann "nur" noch ca. 10.000,00 Euro.

Mit denen ist nicht zu spaßen. Wenn ich die Möglichkeit hätte, würde ich das Wasserrohr in ein anderes, größeres Rohr einziehen, so das bei einem Leck mein Keller unter Wasser stehen würde. Dies ist definitiv der kleinere Schaden.

Grüße

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

andies

OK, danke für die vielen Tipps. Dann werde ich mich mal in deepsleep einlesen, das sollte irgendwie gehen. Damit ist klar, dass ich mit einem arduino oder einem Attiny und dem TRCT versuche das Signal auszulesen. Aber wie kommuniziert der arduino jetzt mit FHEM? WLAN scheidet aus. Ich habe derzeit Bluetooth und SIGNALduino (433 MHz) an meinem FHEM-Server. Wenn 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?
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

#25
Zitat von: andies am 25 Juli 2018, 12:19:29
Die Horrorgeschichte, die ich dann erzählt bekam: Leck in der Leitung, nicht bemerkt, Zack 35.000€ von den Wasserbetrieben berechnet. Nun bin ich etwas nervös.
Dafür gibt es doch aber Leckageschutzgeräte.
... naja - Strom bräuchten die dann schon. :-[
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

FHEM-User22

Moin,
Zitat von: fiedel am 26 Juli 2018, 04:37:54
Dafür gibt es doch aber Leckageschutzgeräte.
... naja - Strom bräuchten die dann schon. :-[
nein, sowas ist nicht verwendbar. Man kann garantiert im Übergabeschacht keine zusätzlichen Zähleinrichtungen ins Rohr einschleifen, ausserdem sind das neue Fehlerquellen. Es geht auch nicht um das Wasser, was im Haus Schaden anrichtet, sondern um das, was zwischen Zählerschacht und Haus (bei mir z.B. 80 Meter) bei einem Leck unbemerkt im Boden versickert.  Und das können unbemerkt zwischen den Jahresabrechnungen schon mal einige 100 -1000 m³ sein. Daher wäre eine Zählerfernablesung schon sehr prima. Am besten wäre es, eine Differenz zu bilden aus dem Zähler im Schacht und einem im Haus.
Aber das Problem "Fernablesen" 80 Meter vorm Haus bleibt.

Grüße FHEM-User22
FHEM auf Raspberry Pi und Proxmox und... und.... und....

andies

Zitat von: FHEM-User22 am 26 Juli 2018, 07:04:31
bei mir z.B. 80 Meter
Wie hast du denn das gelöst?


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

Zitat von: andies am 26 Juli 2018, 08:46:56
Wie hast du denn das gelöst?


Gesendet von iPhone mit Tapatalk Pro

Leider noch nicht. Ich nehme mir vor mindestens jede Woche einmal zum Schacht zu laufen und Wasserzähler ablesen. ....
FHEM auf Raspberry Pi und Proxmox und... und.... und....

andies

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.


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