NEWS
Gaszählerstand mittels ESP8266 erfassen
-
Hey Leute,
ich bin im Moment dabei, meine Zähler smart zu machen und ich dachte mir, dass ich mit dem Gaszähler anfange. Ich nutze als Basis ein Wemos D1 Mini mit einem Reedkontakt und einem 10k als Pullup Widerstand. Der Wemos übersendet mir mittels mqtt eine 1 oder 0, worauf mein Script reagiert und einen Datenpunkt, der mittels mqtt auf 1 bzw. 0 gesetzt wird. Je nachdem ob der Reedkonakt am Wemos geschlossen oder offen ist.
Soweit läuft auch erstmal alles an sich, lediglich nach ein paar Tagen ändern sich die Stellen nach dem Komma und er verliert plötzlich Impulse, wodurch der Zählerstand an der Gasuhr nicht mehr mit dem im ioBroker übereinstimmt. Ich kann es mir irgendwie nicht erklären, aber ich Poste mal mein Blockly Code, vielleicht hab ich da irgendwo ein Bock drin.
Der Datenpunkt "ESP/Keller/Gaszaehler" ist der Wert der vom Wemos kommt und entweder 1 oder 0 ist und wenn der Wert 1 ist soll er den Wert aus dem Datenpunkt "Zaehlerstand" holen, diesen um 0.01 erhöhen und wieder in den Datenpunkt schreiben. Zumindest so die Theorie, das läuft auch ca. 7 Tage ohne Probleme doch plötzlich steht im Datenpunkt "Zaehlerstand" nicht mehr ein Wert mit lediglich 2 Stellen nach dem Komma, sondern mit 8 oder 9 Stellen (wobei die letzten 5 Stellen alles 9 sind). Hat da jemand von euch eine Idee?
-
@raspido sagte: 8 oder 9 Stellen (wobei die letzten 5 Stellen alles 9 sind). Hat da jemand von euch eine Idee?
Das kann durch Zählen von Integer-Werten verhindert werden, etwa so:
-
Ich hatte auch mal Ärger mit so seltsamen Kommastellen, weiß aber leider nicht mehr woran es lag.
Ggf. kannst du den Datenpunkt auf zwei Kommastellen begrenzen.
Davon abgesehen könntest du das Skript etwas vereinfachen:
EDIT: zu spät
-
@paul53 Die Frage ist, wie kann das sein, wenn ich immer nur Wert + 0.01 rechne, dass sich plötzlich mehr Stellen nach dem Komma bilden? Bei * und / wäre es klar. Aber bei + oder auch - mit einem Festen Wert sollten die Stellen nach dem Komma normal gleich bleiben und nicht mehr werden. Zumindest war das im Matheunterricht so gewesen in der Schule.
Klar, wenn die letzten Ziffern x.000 wird, kann sein dass eine 0 weg fällt die am Ende steht. Aber sonst.
Ich hoffe man versteht, was mich zum irritieren bringt.
Ich habe Testweise das Script mal geändert und muss aber nun 7 Tage warten ob sich was tut. Also ich habe von Wert + 0.01 auf Wert + 1 umgestellt. Das heißt zwar wenn ich den irgendwo verwenden möchte den Wert, ich / 100 Teilen muss, damit das mit den Stellen nach dem Komma passt. Weil wie gesagt, das Programm läuft über ca. 7 Tage ohne Probleme doch plötzlich kommt sowas. Ich konnte noch keine Regelmäßigkeit oder so feststellen.
-
@cinimod Klar vereinfachen ist immer gut. Nur wie gesagt das Script läuft über Tage sauber und erst nach paar Tagen kommt das Ereignis zum Tragen, wo plötzlich sowas passiert.
In der Nacht wartet der Wemos in der Regel auch bis zu 8 Stunden. Da die Heizung zwischen 22 und 6 Uhr nicht heizt. Somit kein Gas verbraucht, außer jemand zapft Warmes Wasser. Aber das nur als Randinfo, was ja eigentlich egal ist.
-
Wenn du das Skript von Paul GANZ übernimmst, da teilt er doch schon dein Ergebnis… Dann hast den richtigen Wert im Datenpunkt.
-
@raspido said in Gaszählerstand mittels ESP8266 erfassen:
Der Datenpunkt "ESP/Keller/Gaszaehler" ist der Wert der vom Wemos kommt und entweder 1 oder 0 ist und wenn der Wert 1 ist soll er den Wert aus dem Datenpunkt "Zaehlerstand" holen, diesen um 0.01 erhöhen und wieder in den Datenpunkt schreiben. Zumindest so die Theorie, das läuft auch ca. 7 Tage ohne Probleme doch plötzlich steht im Datenpunkt "Zaehlerstand" nicht mehr ein Wert mit lediglich 2 Stellen nach dem Komma, sondern mit 8 oder 9 Stellen (wobei die letzten 5 Stellen alles 9 sind). Hat da jemand von euch eine Idee?
Nur einmal so eine Idee:
Warum nicht die Auswertung im Wemos machen und den Wert an ioBroker übermitteln.
Wenn Du die Flankenauswertung im ioBroker machst, ist da immer eine Unsicherheit drin, zum Einen die Datenstrecke und zum Zweiten verlierst Du Impulse, wenn ioBroker nicht Online ist. -
Ich bringe hier noch eine Idee ein:
https://forum.iobroker.net/topic/36622/wasserzähler-version-2-all-in-device
Funktioniert super am Gas- und Stromzähler. Sendet den aktuellen Stand per MQTT.
Am Wasserzähler zickt er im Moment weil der neue Digitale so ein schlechtes Display hat. Aber da bin ich dran.
Kosten etwa 15 Euro plus Gehäuse, wer aus China bestellt kriegt es auch für 5 Euro hin. -
@andreas-5 Ich hatte mich bei der Auswertung und so auf den ioBroker eigentlich gestützt, da es so am einfachsten war den aktuellen Zählerstand einzupflegen, vor allem wenn mal der Wemos Probleme macht. Und wie gesagt, was mich ja an der ganzen Nummer wundert ist, es läuft 7 Tage ca. ohne Probleme. Also nachdem es einmal passiert war gucke ich immer mal wieder rein und konnte so feststellen, dass es wirklich über Tage sauber läuft.
Aber ggf. werde ich mir vielleicht nochmal Gedanken machen müssen.
Und das mit der Auswertung im ioBroker habe ich gemacht bedingt eines Videos eines Youtubers, der das ganz professionel macht. Link zum Video. Ob es bei Ihm sauber läuft weiß ich nicht, hab aber zumindest keine negativen Eindrücke mit bekommen. Er nutzt ein Raspberry Pi zum auswerten der Signale. Und naja wenn der ioBroker mal ausfallen sollte, ist möglich aber eher unwahrscheinlich. Dieser läuft als LXC Container (ähnlich Virtualle Maschine auf einem Server mit 2 Festplatten im Raidverbund zur Datensicherheit.
Michael
-
@cinimod Ja nur die Frage ist, woher kommen mehr Kommastellen? Weil solange ich in der Schule richtig aufgepasst habe, wenn ich einen Festen Wert (in meinem Fall +0.01) rechne, kann es normal nie mehr Kommastellen geben als 2 Stellen die vorhanden sind, eigentlich zumindest.
-
Ja ist schon klar, keiner weiß wieso das so ist.
Paul hat dir bereits ne Lösung dafür angeboten, wo ist denn das Problem jetzt ? mach es doch so und dann ist es Sauber -
@raspido sagte: wenn ich einen Festen Wert (in meinem Fall +0.01) rechne,
Der Dezimalwert 0,01 kann nicht beliebig genau als Binärwert dargestellt werden, sondern ist als Binärwert gerundet. Deshalb kommt es zu Abweichungen. Beispiel:
-
@paul53 Okay weiß ich bescheid. Ich habe um das Dezimalproblem zu beseitigen abgeändert. Also er Addiert immer +1 statt 0.01. Bedeutet ich muss den Wert jedesmal durch 100 rechnen, wenn ich es irgendwo anzeigen will. Aber das ist kein Problem.
@Cinimod Die Lösung von Paul mit dem Runden ist super. Nur das Problem war, sobald die Ungenauigkeit eingetreten war an Tag 7 oder so etwa, gingen auch Impulse verloren. Habe es die letzten Tage etwas intensiver im Auge behalten, bevor der "Fehler" das 2te mal aufgetreten war. Also denke ich, ich teste die Abänderung von mir, aber werde später parallel dazu die Lösung von Paul in einem Zweiten Datenpunkt wirken lassen. Macht zwar grundsätzlich wenig Sinn, den gleichen Wert parallel x fach zu loggen / bearbeiten. Aber so kann ich verschiedene Wege zum Ziel gleichzeitig testen und mus nicht jedes Verfahren mindestens 7 Tage laufen lassen.
-
Paul teil doch den Wert jedesmal schon durch 100 bevor er in den Datenpunkt geschrieben wird.
Dann ist er doch korrekt im Datenpunkt geschrieben -
@cinimod Stimmt, ist auch eine Möglichkeit