Wasseruhr anbinden

Begonnen von Edi77, 01 Mai 2017, 03:21:53

Vorheriges Thema - Nächstes Thema

flipse

Zitat von: Beta-User am 04 Juli 2019, 07:19:39
Das ist etwas mißverständlich...  Eigentlich sollte meine Antwort in den anderen Threadrein, ich brauchte nur das Zitat von hier...

Dort ging es um die Frage, wie man viele Tür- und Fensterkontakte, die kabelmäßig heute schon an einer Stelle zusammenlaufen, aber über einen Fibaro angebunden sind, denn nicht einfacher "an den Server" anbinden kann, der direkt da steht, wo die Kabelenden zusammenlaufen. Hier hatte ich dann gesehene, dass _auch_ ein Zähler darunter ist.
Und wenn dann >10 Kontakte zu überwachen sind + 1 (oder mehr) Zähler, "rechtfertigt" das ggf. auch einen Nano, oder?

@flipse: Es wäre ggf. sinnvoller, die Diskussion über einen eventuellen Sketch in dem anderen Thread weiterzuführen. Dann müssen hier nicht alle mitlesen.

ja das stimmt. wir verlagern die diskussion mal dahin.
ihr habt mir schon gut weitergeholfen.
der nano ist bestellt. ich werde dann erstmal die türkontakte / fensterkontakte testen.

im nachgang dann das Thema mit der Wasseruhr.
Ich möchte dies insbesondere auch zur Leckageüberwachung nutzen.

Prof. Dr. Peter Henning

In der Anlage zwei Abschnitte aus den SmartHome Hacks. Erstens darüber wie man einen S0-Ausgang an einen Raspberry Pi bzw. über 1-Wire an einen beliebigen Computer anschließt, und zweitens über den Anschluss von bis zu 100 Fenstersensoren an _einen_Arduino Nano.

LG

pah

CQuadrat

Hallo Zusammen,

ich habe zur Verbrauchsermittlung durch Zählen von Impulsen mal eine prinzipielle Frage (falls Off-Topic, bitte nicht schlagen :) ):

  • Wie zuverlässig ist das eigentlich?
  • Wird da auch mal ein Impuls "übersehen"?
  • Was ist, wenn FHEM und/oder der Impulszähler mal aus ist? Was passiert dann, mit den zwischenzeitlich stattgefundenen Impulsen?
  • Wenn Impulse "durchrutschen", wie korrigiert ihr das?


Danke und Gruß

Christoph
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), KM271 (per ser2net), SONOS (div. Gimmicks), OneWire, Hue

Prof. Dr. Peter Henning

ZitatWie zuverlässig ist das eigentlich?
Sehr zuverlässig - läuft seit 7 Jahren bei mir ohne ein einziges Problem (1-Wire). Wasser z.B. 1 Impuls pro Liter.
Beim Anschluss auf GPIO-Pins ist das eher fraglich, da können bei mehreren Pins erhebliche Latenzen auftreten.

ZitatWird da auch mal ein Impuls "übersehen"?
Nö. Maximale Zählrate meiner DS2423 liegt jenseits der 100 kHz.

ZitatWas ist, wenn FHEM und/oder der Impulszähler mal aus ist? Was passiert dann, mit den zwischenzeitlich stattgefundenen Impulsen?
Wenn FHEM "aus" ist, passiert gar nichts - denn der Zähler DS2423 zählt autonom. Und FHEM fragt mit dem Modul OWCOUNT den jeweiligen Zählerstand ab.
Wenn die Netzspannung fehlt (und somit die Versorgungsspannung der DS2423), gehen diese natürlich in den Reset, dann stimmt der Zählerstand nicht mehr. Dazu müsste man den 1-Wire Bus mit einer USV absichern (das diskutieren wir gerade in einem anderen Forum).


ZitatWenn Impulse "durchrutschen", wie korrigiert ihr das?
Das OWCOUNT-Modul hat einen "set <...> counter A|B <wert>" Befehl.

LG

pah

CQuadrat

Vielen Dank! Das hilft mir weiter.
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), KM271 (per ser2net), SONOS (div. Gimmicks), OneWire, Hue

Beta-User

Zitat von: Prof. Dr. Peter Henning am 04 Juli 2019, 12:31:35
Beim Anschluss auf GPIO-Pins ist das eher fraglich, da können bei mehreren Pins erhebliche Latenzen auftreten.
Das bezieht sich vorrangig auf PI-GPIOs?

(Von deren Nutzung zu was anderem als RTC und dem Anschluß von UART-Funkmodulen würde ich auch eher abraten).

Was Arduino-GPIO angeht: evtl. sollte man - abhängig vom jeweiligen Impulsgeber (wenn der sauber arbeitet: kein Problem...) - darauf achten, dass man das softwaremäßig entprellt (lib: bounce2()), was tatsächlich zu kleinen Latenzen führen _kann_. Nutzt man alle PINs eines Nano, kommt man z.B. bei 5ms/Eingang auf ca. 100ms/Durchlauf => auch das sollte in der Praxis deutlich weniger Probleme machen wie die Frage, wie man überhaupt an einen Puls kommt...
Aber anders als Pi&Co. ist ein Arduino u.a. dafür gemacht, PINs zu überwachen. (Man kann das natürlich durch schlechte firmware konterkarieren, und für MCU's, die "nebenbei" noch WLAN machen, mag das auch anders sein, aber prinzipiell: Don't worry...)
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

Prof. Dr. Peter Henning

ZitatDas bezieht sich vorrangig auf PI-GPIOs?

Ja, die sind gemeint. Wir haben beim Test der seriellen Schnittstelle (die hier auch nur emuliert wird...) mit dem EBUS Verzögerungen von bis zu 90 Minuten (!) produziert...

LG

pah

flipse

Hallo zusammen,

ich habe auch einen Sensus 620.
Ich versuche gerade den Wasserzähler mit einem TCRT5000 auszulesen.
Angebunden ist der Sensor an einem Arduino mit MySensors.
Der Sketch, den ich als Basis genommen habe, kommt von build@mysensors.

Ich glaube aber, er ist darauf ausgelegt, das Rädchen, das sich sehr schnell dreht mit den vielen Ärmchen auszulesen.
Ich versuche beim Sensor das große 2geteilte Rädchen (eine Hälfte Metall, eine Hälfte Kunststoff) zu lesen.
Der TCRT5000 zeigt auch durch die kleine LED an, dass das Rädchen ordentlich erkannt wird.

Leider schaffe ich es nicht, den Sketch dementsprechend zu modifizieren.
Hat das schon jemand gemacht und kann mir mal ein Beispiel geben?

Danke Euch.

Beta-User

Hmm, so wie du das schilderst, sollte der Sketch ohne weiteres funktionieren (wenn das TCRT5000-Modul ordentliche Pulse liefert). Wie schnell sich das Rad dreht, ist dem Basis-Sketch von MySensors.org herzlich egal, es muß eben die Mengenkonstante entsprechend angepaßt werden, dass jeder Puls der richtigen Wassermenge zugeordnet wird (1 Puls kann 1l, 10l, 100l ... sein). Diese eine Angabe mußt du im Sketch anpassen.
(Oder die Auswertung in FHEM machen und einfach nur die Zahl der Pulse seit der letzten Übermittlung mitteilen; da du die Node sowieso direkt an den Server anschließt, sollte praktisch auch nichts verloren gehen, anders wäre das, wenn z.B. eine schlechte Funkstrecke dazwischen läge...)
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

flipse

Habe das mal umgestellt und warte auf Ergebnisse.
Ich habe gestern zum Spaß mal alle if Abfragen, die auf unsinnige Werte prüfen, herausgenommen. dann kamen auch werte an. Diese konnte ich aber nicht validieren, da ich den Sensor auf dem Schreibtisch liegen hatte.

Ich habe aber noch eine Frage zum Verständnis des Moduls.
Ich habe nun

#define PULSE_FACTOR 1    // Number of blinks per m3 of your meter (one rotation/liter)

auf 1 gesetzt, da eine Umdrehung scheinbar einem Liter entspricht.


was passiert in diesen Zeilen:

#define MAX_FLOW 40            // Max flow (l/min) value to reported

Ich vermute, dass alles was größer ist als 40 Liter/Min. wird nicht reported???


Und in dieser Methode

void onWaterMeterPulse() {
   
    if (!SLEEP_MODE) {
        uint32_t newBlink = micros();
        uint32_t interval = newBlink - lastBlink;
       
        if(interval!=0) {
            lastPulse = millis();
            if (interval<500000) {
                // Sometimes we get interrupt on RISING, 500000=0.5second debounce (max 120L/m)
                return;
            }
            flow = (60000000.0/interval) / ppl;
        }
        lastBlink = newBlink;
    }
    pulseCount++;
}


Verstehe ich den statischen Wert von 60000000.0 nicht.
Kann mir das jemand erklären?

Beta-User

Hmm,

irgendwie finde ich die Frage hier in diesem Thread in der Nähe von OT (der TE war ja jemand anderes!). Bitte daher ggf. entweder direkt bei MySensors.org einen Thread aufmachen, oder wenigstens hier im MySensors-Bereich (alternativ, da sich die Frage vermutlich im wesentlichen an mich richtet: in deinem eigenen "direkt-anbinden-Thread). Das folgende bleibt daher das einzige, was ich konkret darauf aufworte:

Such mal nach Arduino und micros() (darauf beziehen sich alle Variablen in der ISR):
ZitatNote: there are 1,000 microseconds in a millisecond and 1,000,000 microseconds in a second.
Damit ist diese ominöse hohe Zahl eine Minute, oder...?

Was den PULSE_FACTOR angeht, steht im Original:
#define PULSE_FACTOR 1000                       // Number of blinks per m3 of your meter (One rotation/liter)Was da ursprünglich stand, bedeutete also: "ein Blink ist ein Liter". Du hast jetzt "ein Blink ist ein m³" draus gemacht, was tatsächlich vom Sketch als "too much" verworfen wird...
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

flipse

Zitat von: Beta-User am 10 Juli 2019, 10:02:40
Hmm,

irgendwie finde ich die Frage hier in diesem Thread in der Nähe von OT (der TE war ja jemand anderes!). Bitte daher ggf. entweder direkt bei MySensors.org einen Thread aufmachen, oder wenigstens hier im MySensors-Bereich (alternativ, da sich die Frage vermutlich im wesentlichen an mich richtet: in deinem eigenen "direkt-anbinden-Thread). Das folgende bleibt daher das einzige, was ich konkret darauf aufworte:

Such mal nach Arduino und micros() (darauf beziehen sich alle Variablen in der ISR):Damit ist diese ominöse hohe Zahl eine Minute, oder...?

Was den PULSE_FACTOR angeht, steht im Original:
#define PULSE_FACTOR 1000                       // Number of blinks per m3 of your meter (One rotation/liter)Was da ursprünglich stand, bedeutete also: "ein Blink ist ein Liter". Du hast jetzt "ein Blink ist ein m³" draus gemacht, was tatsächlich vom Sketch als "too much" verworfen wird...

ok, das habe ich angepasst und wieder rückgängig gemacht.
wo kann ich denn definieren, ab wann ich in FHEM eine Rückmeldung bekomme.
möchte das am Anfang recht häufig haben zum testen.
derzeit tauchen nicht mal die readings auf.

Führe die Konversation im anderen Thread fort:

https://forum.fhem.de/index.php/topic,101967.msg956837.html#msg956837

Frank_Huber

Zitat von: roedert am 24 Oktober 2017, 13:04:00
Anbei für die die es interessiert die 3D-Datei für den "Abnehmer"

Hi,

Sorry dass ich das alte Thema hier aufwärme,
aber könntest Du mir sagen womit Du die Datei erstellt/bearbeitet hast?
Ich müsste sie für meinen Zähler etwas anpassen, scheitere aber daran.

Danke & Grüße
Frank

PeMue

Zitat von: Frank_Huber am 08 Januar 2020, 16:03:00
... aber könntest Du mir sagen womit Du die Datei erstellt/bearbeitet hast?
Ich müsste sie für meinen Zähler etwas anpassen, scheitere aber daran.
Da solltest Du am besten die Originaldatei bekommen, mit einer STL Datei wirst Du nicht viel Freude haben  :(.

Gruß Peter
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

Frank_Huber

Zitat von: PeMue am 08 Januar 2020, 17:18:53
Da solltest Du am besten die Originaldatei bekommen, mit einer STL Datei wirst Du nicht viel Freude haben  :(.

Danke Peter!
Bin noch ganz neu im 3D Thema. Dachte stl wäre das "original" weil ja zum Drucken erst gesliced wird.
Wieder was gelernt. :-)