Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[oxident]

@sushibomba Das habe ich auch noch nicht herausgefunden. Bei mir ändert sich aber (fast) ausschließlich immer nur der 1er Wert.

Ich glaube, größere Anlagen haben zwei getrennte "Tanks"?

[Sushibomba]

@oxident

Ok. Dann beobachte ich das mal.

[oxident]

Seit ein paar Tagen kommen bei mir keine Werte mehr bei gruenbeck.0.softliQ.DBSxxx.Stream.mflow1 an.

Der Rest scheint zu klappen. Hat das sonst noch jemand?

[martin_s]

@oxident
Hallo, ja das Problem habe ich auch. Seit 20.8. ca. 4:00 Uhr.
Hab schon die Anlage neu gestartet. Zeigt auch die Cloud-Verbindung als OK an.
Habe aber weder Daten in der App noch im IO-Broker.

Viele Grüße
Martin

[oxident]

@martin_s Jetzt scheint es wieder zu klappen. Habe jedoch den Adapter jetzt auf regelmäßigen Neustart nachts eingestellt.

Prinzipiell finde ich die Durchflussanzeige schon recht wichtig für diverse Smarthome-Funktionen.

[ostseeskipper]

Bekomme leider auch keine Werte mehr.
Gab ja so ein paar Meldungen zu einem Sicherheitsbruch zu MS Azure.

[martin_s]

Ich habe dazu mal ein Ticket bei Grünbeck aufgemacht, da es ja auch die App betrifftt. Das Problem ist bekannt.

Zitat:
Derzeit besteht ein Problem mit der Grünbeck-App.
Die Abteilung arbeitet mit Hochdruck an der Behebung des Fehlers.
Ich würde Sie darum bitten, Ende nächster Woche nochmals die Verbrauchsdaten in Ihrer App zu prüfen. (ggf. auf Updates)

[Presl]

@martin_s ...

habt ihr eine Idee - ich bekomm gar keine Werte.
Die App am Handy geht...

Folgendes steht im Protokoll:

gruenbeck.0
2023-09-15 21:41:47.952	error	Failed enter SD

gruenbeck.0
2023-09-15 21:41:47.951	error	AxiosError: Request failed with status code 404

gruenbeck.0
2023-09-15 21:41:47.950	error	https://prod-eu-gruenbeck-api.azurewebsites.net/api/devices/softliQ.C/BSxxx/realtime/enter?api-version=2020-08-03

gruenbeck.0
2023-09-15 21:35:47.977	error	Failed enter SD

gruenbeck.0
2023-09-15 21:35:47.975	error	AxiosError: Request failed with status code 404

gruenbeck.0
2023-09-15 21:35:47.975	error	https://prod-eu-gruenbeck-api.azurewebsites.net/api/devices/softliQ.C/BSxxx/realtime/enter?api-version=2020-08-03

gruenbeck.0
2023-09-15 21:35:47.965	error	AxiosError: Request failed with status code 404

gruenbeck.0
2023-09-15 21:35:47.959	error	AxiosError: Request failed with status code 404

gruenbeck.0
2023-09-15 21:35:47.947	error	AxiosError: Request failed with status code 404

gruenbeck.0
2023-09-15 21:35:47.930	error	AxiosError: Request failed with status code 404

[mading]

@presl 404 heisst nicht erreichbar/ verfügbar. Hast di pihole oä laufen? Kannst du https://prod-eu-gruenbeck-api.azurewebsites.net/ erfolgreich öffnen?

[ArnoD]

@presl
Was hast du den für einen Typ SD oder SC ?

[oxident]

Sagt mal, könnt ihr mir erklären, warum die verfügbare Restmenge an aufbereitetem Wasser (gruenbeck.0.softliQ.DBSxxx.Stream.mrescapa1) nach dem automatischen Regenerieren immer unterschiedlich ist?

Wenn ich morgens mal reinschaue, dann sind es mal ca. 500l, manchmal aber auch >800l.

Beim manuellen Regenerieren sind es eigentlich immer ca. 1200l.

Könnte es sein, dass der Algorithmus von Grünbeck "schätzt", wieviel Wasser ich über den Tag verbrauchen werden und demnach mehr oder weniger regeneriert?

Habe eine SD15.

[ArnoD]

@oxident
Bei der SC18 wird im Eco Betrieb der Verbrauch der letzten drei Tage verwendet, um zu berechnen, wie viel aufbereitetes Wasser benötigt wird, um auch nur diese Menge zu regenerieren.
Vermute das es bei der SD15 auch so ist, kann es aber nicht mit Sicherheit sagen.
Eventuell meldet sich noch jemand mit einer SD15 der das bestätigen kann.

[oxident]

@arnod Ahh, ok. Das macht ja Sinn. Nur, dass meine Anlage am WE eigentlich im "Power"-Modus läuft. Aber das heißt vermutlich auch nur "letzte 3 Tage + x".

Gut, dass wir ja dank des Adapters da ganz gut nachregeln können ;-)

[ArnoD]

@oxident
Im Power Modus ist es eigentlich das gleiche, nur dass mit einer anderen Kapazitätszahl gerechnet wird.

Als Beispiel: von 18 °dH auf 8°dH
Angenommene Kapazität: gestern 7 m³ x °dH , vorgestern: 10 m³ x °dH, vorvorgestern 7 m³ x °dH
Durchschnitt 8 m³ x °dH geteilt durch 10 (18-8) , entspricht 800 l 8°dH Weichwasser
Die Anlage ist werksseitig im Eco-Modus eingestellt (energie- und ressourcensparend), mit einer Kapazitätsreserve von 30 %. (1,3)

Beispiel:

• 1,3 x 8 m³x°dH = 10,4 m³ x °dH Anlage läuft mit 10,4er Kapazität. 10,4 geteilt durch 10 → entspricht 1.000 l 8°dH Weichwasser
• Bei größeren Schwankungen im Wasserverbrauch kann in den Power Modus (80 % Kapazitätsreserve) gewechselt werden. (1,8)

Beispiel:

• 1,8 x 8 m³x°dH =14,4 m³x°dH Anlage läuft mit 14,0er Kapazität. 14,0 geteilt durch 10 → entspricht 1.400 l 8°dH Weichwasser

[oxident]

@arnod Wow, sehr gut und verständlich erklärt!

Aber das betrifft generell ja nur die automatische Regenerierung, oder?
Will sagen, wenn ich manuell (bzw. per ioBroker) regeneriere, dann wird immer die komplette Kapazität bereitgestellt.

Ich frage deshalb so penetrant nach da ich jetzt schon öfters die Situation hatte, dass der Wasserverbrauch der Familie sich nicht wirklich in solche Algorithmen pressen ließ. Da würde ich der Anlage halt gerne das "Denken" ersparen und selber, z. B. bei erkannter Abwesenheit aller, die manuelle Regenerierung starten wenn die Kapazität z. B. unter 100l fällt.

[ArnoD]

@oxident
Ja richtig, bei manueller Regenerierung wird immer 100% verwendet.

[lamahgra]

..nach Rücksprache mit Grünbeck 22.04.24 sind auch die letzte Hoffnung auf eine "cloud-freie" Lösung gestorben.
MQTT wird nicht weiter verfolgt - nur der weg über die cloud :angry:

[da_Woody]

@lamahgra war nicht anders zu erwarten...

[oxident]

@lamahgra Aber verstehen tue ich es trotzdem nicht.

Nicht nur, dass sich die Anlage damit zum Liebling der Smarthome-Community entwickeln könnte, es würde auch die permanenten Zugriffe auf Azure verringern ubd Grünbeck damit bares Geld sparen.

Man sieht ja gerade bei den Mitsubishi-Klimaanlagen sehr gut, wozu der Cloudzwang führt: Erst bastelt man irgendwelche Sperren um die User von iobroker oder HA fernzuhalten, paar Wochen später ist doch wieder ein Weg gefunden worden und einige Monate später ranzt der Cloudzugriff für alle User komplett ab.

Ein lokaler MQTT-/REST-Zugang hätte das vermieden.

[lamahgra]

@oxident sagte in Test Adapter Grünbeck v0.0.x:

@lamahgra Aber verstehen tue ich es trotzdem nicht.

Nicht nur, dass sich die Anlage damit zum Liebling der Smarthome-Community entwickeln könnte, es würde auch die permanenten Zugriffe auf Azure verringern ubd Grünbeck damit bares Geld sparen.

Man sieht ja gerade bei den Mitsubishi-Klimaanlagen sehr gut, wozu der Cloudzwang führt: Erst bastelt man irgendwelche Sperren um die User von iobroker oder HA fernzuhalten, paar Wochen später ist doch wieder ein Weg gefunden worden und einige Monate später ranzt der Cloudzugriff für alle User komplett ab.

Ein lokaler MQTT-/REST-Zugang hätte das vermieden.

..genau so sehe ich das auch...
theoretisch könnte man versuchen via "fake" DNS Host Eintrag den dns name der azur.cloud - lokal aufzulösen - und zu probieren die mqtt Pakete dort abzufangen.... ist aber nur eine Theorie :-)