UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[w00dst0ck]

@deejaydave könnte auch an einem schlecht platziertem Reed-Kontakt liegen. Hast du die Möglichkeit vor dem Zähler zu sitzen und parallel zu gucken was im iobroker ankommt?

[DeeJayDave]

@w00dst0ck Ich habe mir ja extra den "Metrix Impulsnehmer NI-3" dafür gekauft, der einen Reedkontakt hat und das Signal (grün/orange) an den Aqara sendet (angelötet).

Muss mich tatsächlich mal davor setzen und beobachten was passiert.....

[RalfTh]

@deejaydave bei mir sind es mal 0,2 m³ in 2 Wochen. Das passiert interessanterweise in den Sommermonaten vermehrt, als zur Heizperiode. Erklärung habe ich dafür keine.

[Cino]

uii. Bei mir sind es in 24 Stunden 5 Kubik. Ich hatte gestern geguckt und gerade nochmal.

Ich setze heute abend mal einen syslog server auf und in dem skript debugging. Irgendwo geht mir ja was verloren.

[RalfTh]

@cino Das hat vermutlich nichts mehr mit entprellen zu tun. Entweder ist dein Kontakt nicht einwandfrei am Gaszähler montiert, oder der Kontakt selbst ist zu unempfindlich. Der Magnet auf dem Rad des Gaszählers ist schließlich kein Schwergewicht.
Probiere deine Schaltung mal auf dem Tisch in einer Trockenübung. Nähere dich dem Kontakt mit einem kleinen Magnet und ermittle mal, ab wann dein Kontakt reagiert und so weiter.

[Cino]

@ralfth Der Abnehmer ist ein originaler vom Hersteller. Nichts selbst gebasteltes.

[JoergH]

@cino

Zum Thema Entprellen: Könnte man das nicht über den Zeitstempel zuverlässig realisieren...? Ich würde es zumindest so versuchen...

[RalfTh]

@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:

[DeeJayDave]

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.

[Cino]

@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.

[jmeister79]

@cino
Yo hab ich gemacht. kann ich den genau wie den reed kontakt an den nodemcu anschließen?

[Cino]

@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.

[jmeister79]

@cino also eine Seite an n gpio und die andere an g? Hans gerade Mal mit dem normalen counter probiert bevor du geantwortet hattest.

[Cino]

@jmeister79 Der Counter gibt eine Zahl ab. Dieser Skript hier rechnet mit true/false.

[RalfTh]

@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?

[DeeJayDave]

@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.

[RalfTh]

@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.

[DeeJayDave]

@ralfth Sobald ich was rausgefunden habe, mache ich selbstverständlich Meldung :)

[Cino]

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.

[RalfTh]

@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