Miele Cloud-binding

Add-ons Bindings
, ,
41

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

42

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.

43

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.

44

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

/Ole Kristian

45

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
46

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?

47

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!

48

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.

49

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.

50

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.

51

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.

52

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.

53

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
54

Quick question:

I know this binding is still in beta phase and OH 3 is as well. Having said that: What are your plans towards OH 3 compatibility? Will there be a beta that is compatible? Will there be a parallel final release? Or will OH 3 compatibility be added at a later point? Just curious about the roadmap. (Just out of curiosity I quickly threw the beta 1 in the OH 3 addons directory to see what happens but naturally it wouldn’t start.)

As usual, thank you very much for all the effort!

Jens

55

Hi,

Curious to try this new binding, but ran into dumb problem very early in the process. Went here:
https://www.miele.com/f/com/en/register_api.aspx

I see:
Enter your application name
Enter your email address

But no input fields? Tried different browsers, but no luck. Does this page work?

Best regards,
Jacob Laursen

56

Hey Jacob,

this API registration process can indeed be a bit confusing. For me the blinking cursor appears if I tap on app name or email address respectively (iPad / Safari). The label then moves aside and gives way to the "input field“ which is just empty space with the cursor. If that‘s not the case then maybe the page was temporarily broken. (It is working for me at the time of this writing.)

Hope that helps

Jens

1 Like
57

This is actually pretty well documented on the Miele 3rd Party API Swagger.

Thanks! Somehow, I have missed this section of the swagger. I was probably too focused on the “Authorization” documentation. Thanks a lot for your help!

58

Hi Jens,

Thanks. I still couldn’t get any input fields to appear, but suddenly yesterday it started working. I got registered, and binding is now working.

I read somewhere about limitations when using XGW3000 with this binding. What kind of limitations can be expected? I have three devices currently configured with ZigBee modules and one device with built-in Wi-Fi (dishwasher). My dishwasher transfers a lot of data, but I haven’t analyzed it yet, so I don’t know if it only communicates with Miele Cloud through the gateway, or directly through the Internet and keeping the gateway updated at the same time?

/Jacob

59

Hi all,
sorry for the dump question, but the bridge creation is still confusing for me.

I have tocreate a new thing file with the content (Thing Configuration):

Bridge mielecloud:account:home [ accessToken=“DE_1234567890abcdefghijklmnopqrstuv”, locale=“en” ]

But where does the accessToken comes from?

mielecloud:account:home

This is the BridgeID, right?

BR
Tobias

Edit: Ok got it. Just any BridgeID

60

hello and thanks for this binding

I noticed that drying_target is not available on the washer-dryer Waschtrockner WTH730

greetings
Mario