@schmid_no1 said in [Aufruf] ioBroker Grünbeck Adapter:
. Das problem sind die letzten Zahlen die ändern sich jede Stunde + 1)
Hi Danke für den Hinweis, es ist also der Fehlercode _ Anzahl der vergangenen Stunden seit dem Fehler.
Ich würde es jetzt so einfügen, dass man die Fehlercodes zurücksetzen muss damit der new Error state korrekt funktioniert. Denn ich kann sonst nich feststellen ob es ein neuer Code oder ein alter identischer Code ist.
Ich habe mal eine Version 0.0.4 released.
Bugfixes
Restkapazität Austauscher zu den refresh Werten hinzugefügt
berechneter Salzstand und Salzverbrauch Reset hinzugefügt
Fehlerspeicher zurücksetzen hinzugefügt
am besten unter Objekte wieder alle das objekt gruenbeck.0 löschen und die Instanz neustarten
@tombox 0.0.4 läuft, cool gelöst mit dem Fehlerspeicher.
Wäre es eine Idee wenn du auch eine JSON Tabelle für die Fehler+ Datum und Uhrzeit erzeugen könntest?
Was macht das Projekt schleichwasser Warnung...hat Jemand schon mal getestet mit welchen Parametern man das erfassen könnte? Eventuell eine Formel aus durchfluss und restkapazitaet.. Habe bei mir festgestellt das die restkapazitaet etwas abnimmt auch ohne wasserentnahme... Habt ihr das auch bemerkt? Wenn nicht waere das ein Ansatz...
@smartboart das könnte ich nicht feststellen
Aber tombox wird das sicher auch bald angehen
Ich habe mal Version 0.0.5 hinzugefügt. Diese enhält eine Fehlercodehistory. Das bedeutet, dass man nicht mehr den Fehlerspeicher zurücksetzen muss damit der neue Fehler State korrekt funktioniert. Es muss nur der neue Fehler State manuell zurückgesetzt werden.
Schleichwasser halte ich für nicht sehr realistisch. Ich habe mal eingebaut dass der aktuelle Durchfluss alle 4sec abgerufen wird. Aber ich bin nicht sicher ob das genau genug ist und wir werden sehen wie viele Fehler kommen.
Über eine Formel für da Schleichwasser mit dem aktuellen Durchfluss würde ich mich freuen.
Habe gerade den neuen Adapter installiert und bei mir kommt fogende Fehlermeldung:
@ArnoD Bitte installier nochmal
Ok jetzt läuft er 
@tombox kann es sein das zu viele Abfragen in zu kurzer Zeit an die Grünbeck gesendet werden. Der Fehler "socket hang up" deutet jedenfalls darauf hin. Das hatte ich nur wenn der Webserver der Grünbeck alle weiteren anfragen blockiert.
Die Abfrage vom aktuellen Durchfluss ist hier anscheinend die Ursache.
@ArnoD Das stimmt ich habe jetzt auch mehr dieser Überlastungen drin. Ich habe mal auf 5sek erhöht mal sehen wie er so die nächsten Stunden zurecht kommt.
Gibt es schon ein Formel für das Schleichwasser? Denn der aktuelle Durchfluss ist doch das gesamte Wasser nicht nur das Weichwasser?
Ja, es ist dieselbe Formel wie beim Wasserverbrauch. Aber das Problem ist der Durchflusszähler der Grünbeck Anlage.
Der Durchflusszähler kann nur das Weichwasser messen und das auch erst ab einer gewissen Menge.
Ich war gerade dabei zu testen, was hier möglich ist.
Der Durchflusszähler hat eine Messtoleranz von 0,02 m³/h, was somit eine sichere Detektierung ab 0,03 m³/h möglich macht.
Zusammengefasst ist bei 0,03 m³ Weichwasser reden wir bei mir (22°dH auf 5°dH) von ca. 39 l/h Verschnittwasser, da kann man von Schleichwasser nicht mehr reden.
Es würde aber meiner Meinung nach trotzdem Sinn machen, da eine Warnung immer besser ist als gar keine Anzeige.
Es muss nur jedem klar sein das die die Warnung erst bei Wasserverlusten über 40 l/h sicher angezeigt werden kann und das ist eine Menge Wasser.
@ArnoD Ich denke bei 40l/h baut man vielleicht eine falsche Sicherheit auf. Da macht es sicher mehr Sinn Wasserdetektoren zu verteilen. Weil 40l/h bemerkt man auch ohne ioBroker.
Ich würde bei der Abfragerate nicht unter 15 sek. gehen. Habe da einige Zeit mit Tests verbracht und erst mit 15 sek. konnte ich sicher sein, dass der Fehler nicht mehr auftritt.
Es gibt auch keinen wirklichen Grund um einen Wert schneller zu aktualisieren, da die Durchflussmessung eigentlich nicht wirklich aussagekräftig ist.
@ArnoD Ich weiß wäre aber trotzdem nett wenn man sieht wann wasser verbraucht wird und wenn nur ein Wert alle 5 sek abgerufene wird ist es was anderes als 20. Ich habe mal auf 5 sek kannst ja auch nochmal neu installieren wie er sich so über Nacht verhält
Ich muss meinen Satz oben etwas korrigieren, der Durchflusszähler hat natürlich eine geringere Messtoleranz, was ich meinte, war die Anzeigetoleranz über die Schnittstelle, da schwankt der Wert um 0,02 m³/h.
@tombox der State newError ist jetzt ein String, was eigentlich auch kein Problem wäre. Wie kann man in Vis das abfragen?? Wenn der State 0 ist, geht das noch, aber wenn er einen Fehler anzeigt, wird er ja nicht 1 oder true so das ich es mit meinem Widget ValueList HTML Style nicht mehr farblich anzeigen kann.
@schmid_no1 OK, also wenn du abends ins Bett gehst und hast z. B frisch regeneriert mit 100 % Verfügbarkeit hast du morgens nicht 99?
Hast du dann immer noch 100%? Muss mir mal abends den Wasserverbrauch und restkapazitaet notieren und morgens mal checken...
Dumm nur das meine Frau immer vor mir wach ist...@ArnoD
@tombox
Meine idee war, wenn die restkapazitaet abnimmtumm nur das meine Frau immer vor mir wach ist... ohne registrierten wasserverbrauch... Dann könnte es sich um schleichwasser handeln
@smartboart bei mir wir zuerst 100% und dann auch die 99% ohne Wasserverbrauch angezeigt.
@ArnoD OK dann ist das keine Option... Aber beruhigt bin ich trotzdem... Dachte schon da lläuft was weg... Werde morgen meine vis auf den Adapter umstellen, damit ich vernünftig mit testen kann...
@tombox kann es sein das zu viele Abfragen in zu kurzer Zeit an die Grünbeck gesendet werden. Der Fehler "socket hang up" deutet jedenfalls darauf hin. Das hatte ich nur wenn der Webserver der Grünbeck alle weiteren anfragen blockiert.
Die Abfrage vom aktuellen Durchfluss ist hier anscheinend die Ursache.
