New Integration: Grünbeck softliQ

Here is also a SD21 for testing :slight_smile:

I have a SD32 and would also like to test the integration. :wink:

Same here → SD18 would also like to test / help testing :slight_smile:

Told Grünbeck some time ago that I’m really not happy about the fact that it has an RJ45 which ONLY is being used to connect to the internet. Having a local web interface is crucial and I would never have bought a SD21 if I had known that all functionality is only to be accessed via internet (only other manufacturer represented in my house behaving in such a bad way is Miele).

Would be happy also to have a slim Grünbeck integration in HA.

2 Likes

There are also rumors around that Grünbeck implements an MQTT-client, so that you can configure where to send all the data.
The last info I got from Grünbeck-Service in June 2023 was:
“Aufgrund der aktuellen Marktsituation und den damit verbundenen Ressourcen sehen wir uns leider gezwungen, das Vorhaben auf unbestimmte Zeit zu verschieben. Ob und wann wir weitere Entwicklungsaktivitäten hinsichtlich einer offenen Schnittstelle fokussieren, können wir zum aktuellen Stand leider nicht sagen.”

Google Translate:
Due to the current market situation and the associated resources, we are unfortunately forced to postpone the project indefinitely. Unfortunately, we cannot say at the current status whether and when we will focus further development activities on an open interface.

So the cloud-solution seems to be the only possibility indefinitely. :frowning:

1 Like

Same here. I’m not sure, but the info with “MQTT-implementation is planned/already in test” was 2020 or 2021. Last time I got the same message as you posted :frowning:

I know, it was my fault… SC had the local api and I thought, the SD would have it also. Had the choice between Judo and Grünbeck → lessons learned…

I will write them again regarding the MQTT implementation. Maybe the more are giving that feedback the higher the chance is, that they will implement it soon?

1 Like

Sure, I think you’re right. I’ll do the same…

Ask also about REST or alternative APIs

Here is the first working version:

Feel free to test it, but it can still contain bugs.

Currently it’s only providing sensor entities, I’m working to add more entities and services for changing options, like the current operating mode.

If you add the soft_water_quantity to the energy dashboard, it could display an error saying, that it’s not providing statistics, this will be gone as soon as the entity has collected some data.

The icon for the integration is also missing, I will create a pull request at Home Assistant Brands repository for that in the next days.

12 Likes

Thank you so much for your integration :+1: the setup was smooth and easy.

Installation went smooth for SD18 and I receive data, which are the same like the data from iobroker :slight_smile:
Checking now for some time and report back

Thanks so much

Installation done and it’s working. Great Work! :+1:
SD21

Thank you so much for this integration works great with SC21 and was a smooth installation!

Thank you, really nice!

Thank you very much!
I have it working with my SD21, but how often does it refresh the flow rate? I tried it during showering, but nothing happend. In my history I have some points from yesterday evending. I will see and check.
For first version it is really nice!

Best,
Stefan

It’s working so well! Thank you very much!

The flow rate is being pushed automatically via WebSocket connection, every 3-5 seconds there is new data.

I realized, that there is some delay between opening a tap and getting an update of the current flow rate.

I think, it’s because the data is sent from the Water Softener to the cloud, processed in some way and then sent to the open WebSocket connection.

This is the flow rate I got yesterday after having the dishwasher running.

This is what it’s to be expected if some manufacturer manages the data. It fulfils the expectations of the manufacturer and of some users. It makes the customer more dependant of the manufacturer and I’m afraid that this is it’s purpose. It’s not intended to be helpful to the customer. It is intended as a marketing tool. The manufacturer has services which the customers may want and if they want to keep it, they may need to pay for at a later time. It is more effort for the manufacturer and a customer is not able to manage any data about the product he bought without consent of the manufacturer. After 3 years it may be possible to take money to keep the services available. Something that should be integrated in the product, not an external service somewhere in the internet. The customer should never depend on the reliability of some Grünbeck server. When they excused for the outage of the service, I got angry that this dependency exists.

Of course it is not easy to manage for thousands of devices the data in real time. Without the Grünbeck server as “Flaschenhals”, directly in the local intranet, this would be a different story.

Long story short, I contacted Judo (hint in this thread was nice) and may replace the Grünbeck at a later time. The approach of Grünbeck is just wrong in so many ways. I don’t want to be dependant in this way.

I don’t expect Grünbeck to cooperate in the near future. They removed the web interface and if they wanted, they’d provide a local MQTT interface. They removed the functionality on the local machine which they had and are happy with this. They don’t provide any date for progress on a local interface and tell they are currently not working on it. You may prove me wrong by convincing Grünbeck and then I’ll be happy.

Again, thank you for the wonderful integration in Home Assistant. For the moment it is the best we can get.

2 Likes