Gaszähler BK-G4 auslesen mit Zigbee-Fensterkontakt
-
@ralfth Der Abnehmer ist ein originaler vom Hersteller. Nichts selbst gebasteltes.
-
Zum Thema Entprellen: Könnte man das nicht über den Zeitstempel zuverlässig realisieren...? Ich würde es zumindest so versuchen...
-
@cino Das sollte die nicht davon abhalten diesen Abnehmer einmal zu testen. Am besten nimmst du dazu verschieden starke Magnete und näherst dich dem Kontakt bis er schaltet. Das kannst du mit einem Messgerät prüfen, oder mit der ganzen Schaltung im ioBroker. Wenn du mit Influxdb oder History aufzeichnest siehst du auch gleich, ob die Schaltung/Meldung erfolgt oder nicht, ob es zu mehrfach "true" oder "false" kommt. Das sollte sowieso für den Datenpunkt des Aqara-Sensors aktiviert sein, wenn man solche Probleme hat. Ich glaube der heißt deconz.0.Sensors."X".open. Bei mir sieht das so aus:
-
Jetzt habe ich aber auch ein Verständnisproblem:
Ich habe einen Sensor (Aqara), der bei "is open" true oder false liefert. Diese Änderung bzw. der Wert false triggert mein Skript, bei dem der Wert in einen Datenpunkt geschrieben wird. Soweit alles gut.
Wenn ich diesen Datenpunkt dann per history oder influxdb logge, ist doch an dieser Stelle die Einstellung der Entprellzeit falsch?! Der Datenpunkt wird ja per Skript geschrieben... das Loggen ist doch dann nachgelagert.
-
@deejaydave mit der Entprellzeit im Historyadapter verfälscht du doch nur alles. Was in der History steht muss ja nicht das sein was der Skript verarbeitet. Im Skript sind die 500 ms Entprellzeit vom Historyadapter doch uninteressant.
Zudem ich mittlerweile der Meinung bin, das prellenede Schalter nur ein Problem sind wenn dahinter Zähler hängen. Die easyesp firmware hat ja counter devices, da müsste es dann auffallen wenn der Schalter prellt.
Ich habe das Teil nur als Schalter definiert und schicke den Wert über MQTT. -
@cino
Yo hab ich gemacht. kann ich den genau wie den reed kontakt an den nodemcu anschließen? -
@jmeister79 ja kannst du, gpio mit pullup auswählen und dann gegen Masse schalten. Noch einen debounce von 100 ms auswählen. Das alles als switch und per mqtt senden.
-
@cino also eine Seite an n gpio und die andere an g? Hans gerade Mal mit dem normalen counter probiert bevor du geantwortet hattest.
-
@jmeister79 Der Counter gibt eine Zahl ab. Dieser Skript hier rechnet mit true/false.
-
@deejaydave Mal was zur Klärung der Fragen.
Meine Konfiguration ist folgende:- ioBroker auf Raspberry
- ConbeeII-Stick für Zigbee-Geräte
- Aquara Fensterkontakt
Wenn ich den Sensor in der App anmelde (in meinem Fall deconz) dann wird in der Instanz deconz_0 ein Objekt mit den folgenden Datenpunkten angelegt:
Wenn sich jetzt der Zustand des Sensors ändert wird dies im Datenpunkt .....open registriert, angezeigt und erfasst. So weit ich das verstanden habe, kann sehr wohl mit dem Entprellen festgelegt werden, ob das Signal mehrfach erscheint, da für die angegebene Zeit Zustandsänderungen ignoriert werden.
Das Skript liest diesen Datenpunkt, berechnet und schreibt die Informationen in weitere, selbst angelegte Datenpunkte ab. Ich habe meine Datenpunkte unter 0_userdata angelegt:
Ob und wie häufig jetzt das Skript angestoßen wird hängt davon ab, ob der Datenpunkt ....open sich ändert und im weiteren Verlauf entprellt wurde. Das Entprellen ist ggf. eine Probierarbeit.Letztlich ist es egal, ob das Skript dabei auf den Zustand "true" oder "false" reagiert und rechnet.
Hat das geholfen?
-
@ralfth Danke für die Erklärung. Meine Kombi ist recht ähnlich, außer dass ich den Zigbee-Adapter (CC2538) nutze. Trotzdessen, dass ich im Skript einen Entpreller von 5 Sekunden eingebaut habe, werden minimal falsche Werte nach einer gewissen Zeit angezeigt. Dem muss ich noch näher nachgehen.
-
@deejaydave Falls du Erkenntnisse zu dem Fehler gewinnst bin ich dankbarer Abnehmer.
Meine Vermutung ist die, wenn der Zählerstand nahe der Position mit dem Magnet stehen bleibt, dann kommt es ggf. zu falschen Zählungen. Bei mir ist die Abweichung in den Sommermonaten etwas höher als zu Heizperiode, was diese Theorie stützt. -
@ralfth Sobald ich was rausgefunden habe, mache ich selbstverständlich Meldung
-
Ich werde die Sache anders angehen, und zwar habe ich ja eine Kombitherme. Die höchste Leistung hat das Teil bei Heißwassererzeugung. Ich gucke mir dann an wie lange es dauert für einen Impuls. Dementsprechend setze ich mir dann eine Sperrzeit. Flankenerkennung gehört auch dazu. Sonst würde wie hier geschrieben es zu Problemen kommen wenn der Kontakt ständig geschlossen ist.
Ich glaube aber mir ist eher das Problem das über MQTT die Werte verloren gehen. Es müsste sowas wie ein ACK Flag geben.
-
@deejaydave Mal ein Update zu der Fehlzählung.
Bei mir ging es vor zwei Tagen los mit erheblicheren Abweichungen trotz unveränderter Konfiguration.
Jetzt hat es Aqara nicht so genau mit dem Batteriestatus. Zunächst war ich etwas ratlos, habe aber dann für mich ermittelt, dass die Verbindung zum Conbee II nicht stabil zu sein scheint. Was soll es auch anderes sein?!
Jetzt habe ich das Kabel zwischen Reedkontakt und Aqara-Sensor verlängert und diesen näher in die Reichweite des Conbee II gebracht.
Bis jetzt sind keine Abweichungen mehr aufgetreten.
Keine Ahnung woran das jetzt im Einzelnen liegt, aber ich gehe mal davon aus, dass bei 100% Batterie die Verbindungsqualität schon grenzwertig ist und sobald der Batteriestand sinkt es zu den Ausfällen kommt.
Ich berichte weiter über dieses Experiment.UPDATE:
Die Signalstärke war es nicht, oder nicht allein. Der Sensor war zwar mit der Phoscon-App verbunden, trotzdem kam es zu Fehlern. Erst nachdem ich den Sensor erneut mit der App verbunden habe läuft alles super. Dabei ist es bei der Phoscon-App nicht erforderlich den Sensor vorher zu löschen. Ma muss nur auf "Sensor anmelden" klicken und beim Sensor ebenfalls das Pairing starten. Danach lief alles wieder einwandfrei.Vielleicht hilft es jemanden.
Update: 08.11.2021
Bisher läuft alles perfekt.... Keine Abweichungen zum Zählerstand des Gaszählers -
Ich bin gerade mit espeasy was anderes am versuchen.
Ich habe einen eigenen Datenpunkt erstellt, den ich mit ESPeasy und send to http steuere.
Hintergrund ist das ich bei send to http einen ACK habe. Ich erhoffe mir dadurch keine Impulse mehr zu verlieren. -
ESP Easy:
Rules
on Gasimp00#State=1 do
SendToHTTP 192.168.0.254,8087,/set/0_userdata.0.Gasimp?value=true
endonon Gasimp00#State=0 do
SendToHTTP 192.168.0.254,8087,/set/0_userdata.0.Gasimp?value=false
endonLogs
1049597480: SW : GPIO=12 State=0 Output value=0
1049597489: EVENT: Gasimp00#State=0
1049597505: ACT : SendToHTTP 192.168.0.254,8087,/set/0_userdata.0.Gasimp?value=false
1049597941: EVENT: Clock#Time=Wed,04:01
1049605864: SW : GPIO=12 State=1 Output value=1
1049605870: EVENT: Gasimp00#State=1
1049605880: ACT : SendToHTTP 192.168.0.254,8087,/set/0_userdata.0.Gasimp?value=trueIOBroker Log
javascript.0 2021-11-10 04:01:08.608 info (25390) script.js.gaszz: 8259.5
javascript.0 2021-11-10 04:01:08.608 info (25390) script.js.gaszz: gasimpuls gekriegt -
@cino
In den Controller Settings kann man doch ACK für MQTT aktivieren?!
Sollte dies nicht reichen?
Und wird bei den "send to http" Requests eine Queue aufgebaut, falls das Ziel mal nicht erreicht werden kann?
-
Puh ich wusste nicht das es sowas gibt.
-
@cino Macht doch nix. So ein Forum ist für den Austausch gedacht.
