Wasserzähler auslesen mit Näherungssensor

Begonnen von Matscher, 24 November 2015, 14:44:10

Vorheriges Thema - Nächstes Thema

cortezz

Das FSS12 sendet eltako-typisch im enOcean format. Empfangen wollte ich die Funktelegramme (868MHz) dann über einen enOcean USB-Stick (TCM310). Einrichten würde ich das Teil dann wie unter: https://wiki.fhem.de/wiki/EnOcean_Starter_Guide beschrieben.

Und dann sollte Fhem ja an die Daten kommen wenn der FSS12 mit dem USB Stick gekoppelt ist oder nicht?






Informationen zu unserem Hausbau mit der Hauscompagnie findet ihr unter www.lupgblog.wordpress.com

andies

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

Homalix99

Hallo,
ich habe das mit einem Näherungssensor für 8 mm realisiert (4 mm Sensor hat nicht angesprochen). Funktioniert, jedoch, wenn das Metallrad (Halbmond, des Wasserzählers) ungünstig steht, kommt es leider oft zu einem Toggeln und somit zu viel zu hoch angezeigten Verbrauchswerten. Ich habe den Näherungssensor auch schon anders positioniert, aber wenn der Halbmond ungünstig zum Stehen kommt, zählt der Näherungssensor solange weiter, bis wieder Wasser durch den Zähler fließt.
Weiß jemand Abhilfe?

VG

Alex
- RPI 4 fhem in Docker, 2 x Arduino Uno, HM-GW, HM-Dev. (Fensterkontakte, HK-Thermostate, div. Aktoren), JeeLink,
- GPIOs, HM-LAN, ESPs (MQTT2)
-Überwachung Fenster/Türen/Licht, HK-Thermostatregelung, Rollosteuerung, Überw. Betriebstemperaturen Heizung, Erfassung Gas/Wasser, PV-Anl., Wetter (WS1600)

andies

Du musst die Flanke auslesen, also Anstieg von 0 zu 1 oder Abfall von 1 zu 0. Da gibt es dann kein toggeln, oder doch?
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

Homalix99

Das bringt nichts, da die Impulse vom Näherungssensor kommen.
- RPI 4 fhem in Docker, 2 x Arduino Uno, HM-GW, HM-Dev. (Fensterkontakte, HK-Thermostate, div. Aktoren), JeeLink,
- GPIOs, HM-LAN, ESPs (MQTT2)
-Überwachung Fenster/Türen/Licht, HK-Thermostatregelung, Rollosteuerung, Überw. Betriebstemperaturen Heizung, Erfassung Gas/Wasser, PV-Anl., Wetter (WS1600)

andies

du musst den aufbau genauer erklären, sonst kapiert keiner, was los ist


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

herrmannj

er meint sicher prellen. Da wird sich aber nicht viel machen lassen. Den Sensor anders anbauen hilft evtl ein wenig

Wzut

Zitat von: Homalix99 am 13 März 2019, 20:12:23
aber wenn der Halbmond ungünstig zum Stehen kommt, zählt der Näherungssensor solange weiter, bis wieder Wasser durch den Zähler fließt.
War bei mir am Anfang auch so. Wenn man den Halbmond genau beobachtet hat bewegte der sich ständig ganz sanft ein kleines Stückchen vor und wieder zurück.
Und das machte er immer egal wo er gerade stand. Ich war damals der Meinng das sind Druckschwankungen im Netz, hatte aber auch keine Idee wie ich diese abstellen könnte. Die Lösung kam ein paar Monate später als ich wegen eines anderen Projektes meine Wasseruhr und die Zuleitung ein Stück versetzen lassen musste. Mein damaliger Handwerker meinte ganz entsetzt "Sie haben ja gar keinen Filter und Druckminderer in ihrem System !" Nein hatte ich nicht, war auch damals 1965 beim Neubau kein Thema. Lange Rede kurzer Sinn, der Druckminderer kam rein und seit diesem Tag "zappelt" der Halbmond nicht mehr. Ergo entweder hast du auch keinen oder aber er ist defekt ? 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Homalix99

Hallo,
vielen Dank für die Antwort.
Genau, der Halbmond zappelt etwas. Allerdings
war der Druckminderer vor 4 Jahren defekt und wurde
ausgetauscht. Filter wurde vor einem Jahr gewechselt.
Komm da echt nicht weiter.

VG
Alex
- RPI 4 fhem in Docker, 2 x Arduino Uno, HM-GW, HM-Dev. (Fensterkontakte, HK-Thermostate, div. Aktoren), JeeLink,
- GPIOs, HM-LAN, ESPs (MQTT2)
-Überwachung Fenster/Türen/Licht, HK-Thermostatregelung, Rollosteuerung, Überw. Betriebstemperaturen Heizung, Erfassung Gas/Wasser, PV-Anl., Wetter (WS1600)

Wzut

IMHO hat meine jetzige Einheit aus Filter & Druckminderer auch ein internes Rückschlagventil und das müsste jetzt dafür sorgen das sich das Wasser in dem kurzen Stück Leitung nicht mehr vor und zurück bewegt. Wobei ich es eh erstaunlich finde das das Zählwerk der Wasseruhr keine mechanische Rücklauf Sperre hat ( ist vllt auch vom Typ/Hersteller der WU anhängig oder auch ein Defekt ? )
Frag doch mal deinen Gas-Wasser-Sch... Guru ob dein System kein Rückschlagventil hat oder wieso die Uhr so unruhig ist ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Homalix99

- RPI 4 fhem in Docker, 2 x Arduino Uno, HM-GW, HM-Dev. (Fensterkontakte, HK-Thermostate, div. Aktoren), JeeLink,
- GPIOs, HM-LAN, ESPs (MQTT2)
-Überwachung Fenster/Türen/Licht, HK-Thermostatregelung, Rollosteuerung, Überw. Betriebstemperaturen Heizung, Erfassung Gas/Wasser, PV-Anl., Wetter (WS1600)

Schotty

Hi,
auch wenn dieser Thread nun schon recht alt ist, grabe ich ihn trotzdem nochmal aus - falls hier niemand mehr mitliest (@Matscher?), dann erstelle ich sonst einen neuen..

Ich habe im Grunde das gleiche vor wie du @Matscher, daher an dieser Stelle erstmal ein 'Danke' für deine Projektbeschreibung.
Für Interessierte:
Es gibt von dem Näherungssensor mittlerweile eine 5V-Version, die man folglich direkt an einen Ardu (bzw mittels Spannungsteiler auch an einen ESP/nodeMCU/Wemos) anschließen kann: https://www.amazon.de/Taiss-induktiver-N%C3%A4herungsschalter-Arbeitsspannung-LJ18A3-8-Z/dp/B07XMNF843/

Abgesehen davon, dass ich es noch nicht hinbekommen habe, den Code für einen Ardu + MQTT umzustricken (Programmier-n00b halt :( ), ist bei mir folgende Frage aufgetaucht:
Was passiert, wenn das Metallplättchen im Erfassungsbereich des Näherungssensors (und dann auch noch für etliche Stunden, bspw nachts) zum Stehen kommt und das Signal dauerhaft auf den Ardu gegeben wird..?
Kann mir hier jemand bei der Klärung der Frage behilflich sein?

Danke & Gruß
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

andies

Da wird doch die Flanke ausgewertet, also High zu Low und umgekehrt. Diese Flanke bleibt ja nachts nicht bestehen.
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

Schotty

Danke andies. Aber die Flanke(?) bleibt doch auf bspw HIGH, wenn der Sensor das Signal dauerhaft durchschaltet und fällt erst wieder ab, wenn er abschaltet, oder? Als visuelle Kontrolle leuchtet an dem besagten Sensor ja eine LED, wenn das Metall erfasst wird. Beim langsamen Drehen des Plättchens erlischt sie dann irgendwann, wenn das Metall nicht mehr im Erfassungsbereich ist. Logischerweise leuchtet sie aber ja erstmal dauerhaft so lange weiter, wie sich das Metallplättchen im Erfassungsbereich befindet - also über Nacht dann ggf ein paar Stunden.
Fazit: Verstehe ich das richtig, dass es also kein Problem ist, wenn das Signal über einen längeren Zeitraum anliegt und die Flanke somit nicht 'abgeschlossen' ist, es also nicht als 'ein Impuls' gewertet wird? Sorry für meine laienhafte Ausdrucksweise, ich weiß es gerade nicht besser zu formulieren.. ;)
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

andies

Zitat von: Schotty am 28 Februar 2020, 11:45:06
Aber die Flanke(?) bleibt doch auf bspw HIGH
Das Signal bleibt High. Flanke meint den Signalwechsel. Der findet nur statt, wenn das Metall erfasst wird.

Zitat von: Schotty am 28 Februar 2020, 11:45:06
Als visuelle Kontrolle leuchtet an dem besagten Sensor ja eine LED, wenn das Metall erfasst wird...Logischerweise leuchtet sie aber ja erstmal dauerhaft so lange weiter, wie sich das Metallplättchen im Erfassungsbereich befindet - also über Nacht dann ggf ein paar Stunden.
Ja, und die LED zieht dann die ganze Zeit Strom. Also nix mit Batteriebetrieb, es sei denn, die LED wird nur pulsierend geschaltet. Der Homematic-Wasserzähler macht das so.

Zitat von: Schotty am 28 Februar 2020, 11:45:06
Verstehe ich das richtig, dass es also kein Problem ist, wenn das Signal über einen längeren Zeitraum anliegt und die Flanke somit nicht 'abgeschlossen' ist
Kein Problem, wobei die Flanke ja gerade abgeschlossen ist: Das Signal ist definitiv von LOW nach HIGH gewechselt. Du hast ja bei so einem Metalldurchgang normalerweise zwei Flanken:

ZitatLOW (noch kein Metall) -> HIGH (Metall!) -> LOW (kein Metall mehr)

Die Meldung über den Durchgang machst du dann entweder beim ersten L->H Wechsel oder eben beim zweiten H->L Wechsel. Wenn das über nacht im Metall stehen bleibt, wird im ersten Fall am Abend der Durchgang vermeldet, im zweiten Fall erst am frühen Morgen. In der Sache ist das am Ende beides auswertbar und die Unterschiede sind nicht so gravierend.
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