<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8">Hallo zusammen, <div><br></div><div>nach dem hier viel geantwortet wurde (auch von mir), noch einmal der Versuch etwas einfacher zur Lösung zu kommen.</div><div>Immer hilft </div><div>1. Eine EMV-, Fachgerechte Installation. Spulen um andere Bauteile zu wickeln ist keines. </div><div>2. Eine direkte Verbindung zwischen Zähler und pi sollte man vermeiden.</div><div><br></div><div>Beim 1. haben leider viele keine Erfahrung. Auch Fachleute machen hier bewusst oder unbewusst Fehler. </div><div>Beim 2. Punkt sind die erwähnten Erweiterungen ein sehr gute Lösung. Nachteil ist die Verfügbarkeit. </div><div><br></div><div>Bei der Überlegung wie mann einen solchen Zähler einfach mit den pi verbindet, ist mir aufgefallen das hier <b>keine S0</b> Schnittstelle vorliegt. Der Zähler liefert Impulse mit einer bestimmten Wertigkeit, hier sind es Liter/Impulse. Hier hören die Gemeinsamkeiten mit einer S0 Schnittstelle auf. Funktionieren dieser Zähler vermutlich wunderbar in einer Relais Steuerung. Die Lösung könnten also Relais sein. Zum Glück arbeiten die Erweiterung für Arduino mit 5V. Diese Spannung liefert der pi, und jeder Reed-Kontakt sollte damit arbeiten. Meine Idee, ich nehme ein Relaismodul , hier wurden die Sensoren wahrscheinlich schon seit Tesla und Edison eingesetzt.</div><div>Meine 2. Idee: Das Relais wird vom Zähler angesteuert, an den Kontakten (Ausgang) hängen die GPIO. Kein bestimmungsgemäßer gebrauch, aber nicht Verboten.</div><div>Wichtig ist meiner Meinung nach nur das mechanische Relais verwendet werden.</div><div>Hier arbeiten die massen und Trägheit der Kontakte als Filter für die Störungen. Für das Prellen hat vzlogger ja Lösungen.</div><div>Leider kann ich selbst nicht teseten.</div><div><br></div><div><br><div dir="ltr"><div>Thomas</div><div><br></div></div><div dir="ltr"><blockquote type="cite">Am 06.02.2022 um 21:53 schrieb Christian Lange <brlnr23@gmail.com>:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<p>Hallo zusammen, <br>
</p>
<p>nach mittlerweile vielen Versuchen den S0-Impulsgeber von unserer
Sensus Wasseruhr präzise zum Laufen zu kriegen und nach etlichen
Tests und Datenabgleichen, stehe ich nun vor dem - für mich
derzeit - unüberwindbarem Problem, dass der vzlogger Impulse
erfasst, die nicht mit dem Wasserverbrauch zusammenhängen.
Mitunter ist 30 min vor und nach dem Impuls keine Wasserentnahme
geschehen und trotzdem wird ein Impuls (= 1l) geloggt. Momentan
kann ich mir das nur mit Störsignalen auf dem Weg zwischen
Raspberry und Impulsgeber erklären. Ansonsten stimmen die Impulse
ziemlich genau mit dem Wasserverbrauch überein. Selbst, wenn ich
den Impulsgeber abklemme erhalte ich von Zeit zu Zeit Impulse :( <br>
</p>
<p>Zum Aufbau:</p>
<p>* Raspi V1 bzw. Raspi V3 (habs mit beiden versucht)<br>
* Zuleitung zwischen Steckverbindung und Impulsgeber ca. 1m (von
dem Installationbetrieb verlegt und elegant um die Wasseruhr
gewickelt)<br>
* Kabel zum Raspberry sind die klassischen Jumper Kabel
(male/female) bzw. in einem anderen Versuchsaufbau ein ca. 7m
langes 4-adriges Telefonkabel<br>
* Wagoklemmen um die Kabel zum Rasberry <font size="2">mit den
beiden Kabeln des Impulsgebers zu verbinden<br>
* angeschlossen sind GND und GPIO 23 (Stromversorgung des Sensus
Impulsgebers erfolgt über eine Batterie)<br>
* eine eigene Middleware - der Abgleich zwischen dieser und dem
Debug-Log vom VZLogger ist jedoch 1:1 - es liegt also nicht an
irgendeinem Software-Fehler<br>
</font></p>
<p><font size="2">Aus der Config (zum Debuggen ohne Aggregation etc)</font></p>
<pre><font size="2"> "meters": [
{
"enabled": true,
"allowskip": false,
"interval": -1,
"aggtime": -1,
"aggfixedinterval": false,
"channels": [
{
"uuid": "b6570056-8730-11ec-a8a3-0242ac120002",
"identifier": "Impulse",
"api": "volkszaehler",
"middleware": <a class="moz-txt-link-rfc2396E" href="http://path.to.my.middleware">"http://path.to.my.middleware"</a>,
"aggmode": "none",
"duplicates": 0,
"gpio_dir": -1,
}
],
"protocol": "s0",
"gpio": 23,
"configureGPIO": false,
"send_zero": false,
"debounce_delay": 150
}
]
}
</font></pre>
<p><font size="2">aus der rc.local</font></p>
<pre><font size="2">echo 23 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio23/direction
echo falling > /sys/class/gpio/gpio23/edge
echo 0 > /sys/class/gpio/gpio23/active_low
raspi-gpio set 23 ip pu</font></pre>
<p><font size="2"><br>
</font></p>
<p>Hat jemand von euch mit dieser Art von Messfehler Erfahrungen und
Ideen, ob das Phänomen wirklich an Störsignalen liegt und es mit
besserer Abschirmung (wie?) gelöst werden kann? <br>
</p>
<p>Vielen Dank schon mal!</p>
Chris
</div></blockquote></div></div></div></div></div></div></body></html>