Miele Cloud-binding

Just for my understanding. Is it possible to change values with this cloud-binding?

I have a miele dishwasher with powerdisk function. So it would be greate to choos the right program, set a start or end time and etc… Is this possible?

I managed to install the binding and it works fine.

First of all, a big thank you to everyone who tried out the binding and reported back over the weekend! We appreciate your feedback and are happy that most things are working smoothly (Friday deployments tend to blow things up :wink:).

A general hint: Please note that we currently recommend to not use things-files for configuration for reasons outlined in the account configuration section in the documentation.

Now to your questions:

With the Miele Cloud Binding it is only possible to communicate with appliances via the Miele cloud and a cloud account is required (see also @BertP’s first post). Local communication with appliances with Wi-Fi (and ZigBee) requires the XGW3000 gateway which can be controlled locally with the Miele@home Binding. If you are looking for a purely local solution, you should opt for this one. For further information about the supported devices and supported functionality, have a look at the corresponding binding documentation.

The Miele 3rd party API is limited in terms of available control mechanisms. All channels thus support reading and only some can be set (see the list of available channels in the documentation for a complete overview).

Selecting a program is currently only supported for robotic vacuum cleaners and planned for warming drawers. It is possible to start dishwashers, washing machines and dryers via the program_start_stop channel under some conditions:

  • appliance is turned on
  • program (including all additional options) is selected
  • countdown timer is already started
  • remote control is enabled

You could do the following: Manually select the program you want to run, set the countdown to the maximum value, enable remote control and then start the dishwasher earlier via the channel. We are aware that this is only a small subset of what you want to achieve.

Setting a start time is currently not implemented in the binding. Please submit separate feature requests for these functionalities but be aware that I cannot promise they will be implemented. Even if we implement setting the start time in the binding, a workflow like power on the appliance, select a program and start it will not be possible with the current feature set of the 3rd party API.

Good point, maybe this should be changed or an additional switch channel should be introduced. Please open a bug report. For now, you can simulate a switch by defining an additional item and some rules that synchronize the status.

What model of tumble dryer do you have? Which kind of communication module is used? Are the firmwares up-to-date?

Thanks a lot Miele team for all the extensive answers! It is great to get so much support from the producer. Please keep this going!

For the ZigBee devices I technically understand why a gateway is needed. But is there a reason for the WiFi connected devices to require yet another gateway? This seems unnecessary complex and expensive.

Hello. I set up this binding yesterday, and today, finally, the dishwasher was running, so I coud adjust my custom widgets to use the new binding.

However, the dishwasher thing reports: The Miele webservice cannot be accessed over the bridge. Check the bridge configuration.. I have checked the bridge, and even re-paired the bridge (which show as “Online”. Yesterday, a few hours after setting it up, I verified that it worked by turning the dishwaser on and of, seeing how the status changed in Paper UI. The data is visible in the iPhone App and within my MQTT script.

Hi @oklona, please open a bug report on GitHub and attach logs of the time when the thing went OFFLINE if you have them. As a workaround, try to restart your openHAB instance to force a re-initialization and let me know if that fixed the problem. Please record the logs provided after the reboot if it does not work. Make sure to remove any confidential information from the logs and strip all output from other bindings. Please also state in the bug report whether you configured your things via things-file or management UI.

I rechecked and the dryer is actually from late 2015. Apologies. Seemed like less. Still, it would have been nice if there was a way to upgrade a dryer from 2015. I’ve been in contact with Miele and unfortunately for our TKG 650 WP there is no such option.

I was wondering why one of my rules had failed and noticed, that on 30 September the API suddenly seemed to return language specific properties in English although “de” is specified in the binding configuration and I hadn’t touched that setting. I can see the exact point in time when the switch happened for me by looking at the logs:

2020-09-30 07:34:09.328 [vent.ItemStateChangedEvent] - WEGOperationState changed from Aus to Off

The channel this item is connected to is an “operation_state” of a “washing_mashine” device.

Has anyone else noticed this? I realise it is generally not a good idea to base a rule on language dependent channels. However I had my reasons in this case and the behaviour should still be well-defined. Thanks! :slight_smile:

Hi all

I have a WTF115 WCS washer dryer with wifi module XKM3100W
Could I use the binding to monitor the energy consumption and the status of the washing process??

thanks
Ale

Just a quick “me, too”.

For me this began around the time the API started sending all language dependent Strings in english. (See above.) I noticed that a notification I had set up (which is based on the “finish_state” cannel with ON/OFF value) continued to work. But others like estimated times etc. no longer got updated. I also saw the message you mentioned in PaperUI on the washing machine thing while the bridge thing was still reported as online. I had to remove the washing machine thing and add it again via auto discovery. Right after that all washing machine items were receiving updates again. But still in english.

Thanks. I have only used English, but didn’t bother to delete and re-add yet. I guess I will set up log options for debugging into a separate file, and follow Björn’s recommendation.

Thanks. I will :slight_smile: I will just need to adjust my log settings and restart OpenHAB.

/Ole Kristian

I opened an issue regarding the Thing problem The Miele webservice cannot be accessed over the bridge. Check the bridge configuration. We already have an idea why that happens and how to fix it but any feedback on how to reproduce this behavior would be appreciated. Please post all additional information there.

A new cloud version went live on September 30th. As stated in the documentation we were actually waiting for this. More details can be found here. We plan to implement the new behavior with the binding version beta.2.

It is currently not possible to monitor energy consumption, see this feature request. The status of the washing process can be monitored using the finish_state, program_remaining_time, program_elapsed_time and program_progress channels. Please be aware that there are some issues with these at the moment, which we plan to fix with the binding version beta.2.

2 Likes

Thank you. I turned on debugging, but at the same time updated my OpenHAB container to version 2.5.9 (from 2.5.7), and after the process/restart, the Dishwasher seems to work again.

Out of curiosity, the API documentation does not cover how to use a refresh_token to retrieve a new token, and I haven’t found a way to do that myself yet. (I have just tried normal OAuth2 methods via Postman.) Is there such an option, so that we won’t have to refresh our tokens every few months with the new binding?

Using the beta binding for 20 days now, generally seems to be stable and working fine, besides the known bugs reported at GitHub. So it’s a good start into the beta.

@BjoernLange, still I’m wondering what is the goal/vision that Miele wants to fulfill with the binding. For a Smart Home that wants to include such devices, in my opinion the main value comes with the following general functionality:

  1. Being able to see the status / activity of the devices (is it on, which program is running, when will it finish, etc.)
  2. Being able to see the status of consumables related to the devices (e.g. AutoDos/PowerDisk, is it active, what is the remaining capacity, when do I have to buy new consumables, etc.)
  3. Being able to trigger events around the Smart Home based on the status / activity of the devices (signaling when a program is finished, etc.)
  4. Being able to control the devices based on the status of the Smart Home (e.g. start the washing machine if the solar panels produce a lot of energy)

Point 1 is currently available in the beta1 binding. Point 3 is partly available, what is missing is e.g. full text messages around status and error (not just a flag saying that there’s a message, I want to trigger actions depending on what kind of message/error it is). Points 2 and 4 are currently missing.

I opened feature requests for the missing parts on GitHub (except for point 4, which for me personally has the lowest priority of all points).

Please don’t get me wrong. I highly appreciate the decision of Miele to provide an OpenHAB binding, it is a great commitment of Miele for Smart Home automation. I also understand we are only at beta1, although you mentioned earlier that it is nearly feature complete, which worries me a bit. I do hope that you folks will enhance the functionality according to the points 1-4 otherwise you potentially spend a lot of time and effort for a binding that has limited value in a Smart Home only. This would be a pity because the binding looks really promising and has the potential to be of great value. As far as I understand, the Miele Cloud API supports all of the mentioned 4 points so it is “only” a matter of bringing it into the binding as well.

Thanks again, and please keep up the great work, looking forward to beta2 and the new Cloud API version around the end of the year!

There is no need for a manual token refresh. The binding is performing the token handling, and will refresh the access token if necessary. As described in the documentation, the accessToken parameter will be removed in future versions of the binding for the reasons stated there. During the beta phase, it helps us for debugging purposes though.

Please note: If you are also using the Miele 3rd party API yourself, i.e. not in the context of the binding, and invalidate the refresh token that is used by the binding, you have to re-pair the bridge using the configuration UI.

We are happy about the positive feedback for the beta so far.

In the first announcement post, we outlined the motivation together with the planned feature set for the binding. The feature set of the binding depends on the capabilities of the Miele 3rd party API, which you can check in the documentation. Some of the points that you assume to be “only” a matter of implementing it in the binding, are actually not supported by the Miele 3rd party API at the moment and can thus not be realized. Maybe you assume that everything that the Miele App supports is also supported by the Miele 3rd party API, but this is not the case. The Miele 3rd party API is, however, under active development, which also enabled us to provide actually more features than we initially planned. The binding can be extended to support new features once they are available on the Miele 3rd party API. After we make the binding available and open-source, everyone can contribute these extensions.

Thank you for sharing your thoughts on what features would bring you further value in your smart home. Concerning the device control that you mentioned in point 4, please also have a look on the list of available channels in the documentation to see what can already be controlled. You can, for instance, start the washing machine by manually selecting the program you want to run, set the countdown to the maximum value, enable remote control and then start the washing machine remotely when you want to. We are aware that the current possibilities might be only a subset of what you want to achieve.

Status information about consumables, which you mentioned in point 2, are currently discussed as an extension for the Miele 3rd party API, but there is no schedule when they will be available, yet.

Just switched from Ole’s fantastic script to the binding. Only using one washer but so far everything is running as expected.

I did need to setup a rule to convert the Number “Time remaining” into a better legible Hours:Minutes String. I believe the former script pulled a legible text version directly from the API.

I mainly use it to catch current running phases and update the status information in my (Basic UI) home screen and act upon those status changes, ie. sending broadcasts once the machine is finished.

Thank you very much @BjoernLange for the detailed response.
Glad to hear that providing information about consumables in the binding is under discussion, especially as this information is currently not available in a satisfying way neither directly on the device itself nor in the Miele App.

Quick info:
I manually maintain my things files because I like to be in control of what happens on my OpenHAB instance and it’s easier to backup and rebuild if necessary. Some days ago the access token expired, as documented and expected. For the beta period, I now wanted to switch to the automatically generated / maintained way you recommend and re-paired successfully (after I removed my own things file first, of course). The things then appeared in the Inbox and, after being added, appeared online in the Things list in PaperUI. Unfortunately, the items didn’t map any more to the things, it seemed, although the config was correct (i.e. I didn’t get any data for the Items any more).

I had to remove the things in PaperUI again, restored my manual things file, used the new access token in the manual things file, and everything works fine again.

Not sure if this a glitch in the binding or it could also be a caching issue of OpenHAB (I’ve seen it before that removing / adding objects like this can create unexpected effects in OpenHAB). I don’t want to restart my OpenHAB instance unnecessarily and also do not really have the time for further investigations at the moment. Mentioning it here just in case someone has the same issues in the same situation, offering a resolution with the fallback to the manual things file.

Yeah, I was actually looking for a hint for how to refresh the token outside of this binding. In my script, I try to use the refresh_token to refresh the token once it has expired, but it looks like the API doesn’t provide a method for refreshing tokens. Some people still use my script for other home automation software than OpenHAB, so I feel I cannot abandon the script just yet.

However on the bright side, it looks like your binding is working in my environment again, after a reboot.

Today, we release the second beta version of the binding. Analogue to the first version, it can be downloaded from the release page of the GitHub repo. We also updated the documentation to reflect the changes we made to the channel configuration. As we changed the channel composition it might be necessary to remove channels that do not exist anymore and add new ones. Apart from that, no migration steps are necessary when switching from beta.1 to beta.2, just replace the .jar file.

With this release we primary focus on adding planned features and validating the lists of channels associated with the device categories. We also addressed some of the problems that were reported, primarily devices switching to OFFLINE although the bridge is ONLINE. We hope this is fixed now. Additionally, localization now works as intended. A detailed changelog can be found on the releases page.

Here are some answers to the questions that popped up during the last weeks:

I totally second that working with .things files is more convenient in the long run, therefore we want to support both ways. The problem you observed is related to how the PaperUI and the .things file parser create thing UIDs. The PaperUI always uses the schema binding:thing-type:thing-id while in .things files it depends on how the file is structured. If you use hierarchical declarations for bridge connections (as the template provided by the configuration UI does) then the bridge ID will be part of the thing UID following the schema binding:thing-type:bridge-id:thing-id. Thus, your items will no longer map to the channels. You can circumvent this by using the alternative syntax and following the naming convention of the PaperUI:

Bridge mielecloud:account:mybridge [ accessToken="...", locale="..." ]
Thing mielecloud:hob:000160123456 "My Device" (mielecloud:account:mybridge) [ ]

Details on this can be found in the official documentation for things.

This is actually pretty well documented on the Miele 3rd Party API Swagger. When your access token expires, you send a request to https://api.mcs3.miele.com/thirdparty/token with the parameters client_id, client_secret, refresh_token and grant_type. client_id and client_secret need to be provided by the user (as in the binding). refresh_token is the current refresh token obtained either from the initial authorization or from the last token refresh. grant_type has the fixed value refresh_token. As response you should receive a set of new access and refresh tokens. Note that the parameters need to be sent in the request body. Thus, a curl request would look like this:

curl --location --request POST 'https://api.mcs3.miele.com/thirdparty/token/' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'client_id=<client ID>' \
  --data-urlencode 'client_secret=<client secret>' \
  --data-urlencode 'grant_type=refresh_token' \
  --data-urlencode 'refresh_token=<old refresh token>'

Hope this helps you.

I also spoke with Miele about your dryer, but can unfortunately only confirm that your dryer is incompatible.

2 Likes