[mielecloud] Initial contribution of the Miele Cloud binding #9146

BjoernLange · 2020-11-27T17:23:50Z

This is the initial contribution of the Miele Cloud binding as announced in #9106.

Further resources associated with the contribution:

The binding provides openHAB with access to Miele@home appliances connected via the Miele cloud. These devices communicate over WiFi (as compared to the devices communicating via the XGW3000 gateway which is using ZigBee). A detailed description of the binding's capabilities is given in the README.

All contributors will sign-off the squashed commit once necessary changes have been made and the PR has been approved.

Please note: We tested the binding with the most recent openHAB 3.0 milestone build (3.0.0.M3) and discovered a binary incompatibility with Inbox.approve because of which we were unable to complete our tests. We still consider the binding "ready for review" and will do extensive testing once the problem is solved.

kaikreuzer · 2020-11-28T12:19:41Z

Thanks @BjoernLange! Could you please also make sure to sign-off your commits, so that the DCO check passes? See https://www.openhab.org/docs/developer/contributing.html#sign-your-work

BjoernLange · 2020-11-30T08:15:39Z

Thank you for the hint @kaikreuzer! We didn't expect sign-off to be a prerequisite for review. The commit is signed now.

fwolter

I reviewed the readme so far. The Channel descriptions don't state any units. Do you use Units of Measure for temperatures and so on?

fwolter · 2020-11-30T09:58:08Z

bundles/org.openhab.binding.mielecloud/README.md

+For a detailed walk through the account configuration, see [Account Configuration Example](#account-configuration-example).
+
+Once a Miele account is paired, all supported appliances are automatically discovered as individual things and placed in the inbox.
+They can then be paired with your favorite management UI, e.g. the PaperUI.


Can you remove the reference, as PaperUI will be removed in OH3?

fwolter · 2020-11-30T10:19:48Z

bundles/org.openhab.binding.mielecloud/README.md

+
+![Pairing Successful](doc/pairing-success.png)
+
+Once the bridge instance is `ONLINE`, you can either pair things for all appliances via your favorite management UI, e.g. the Paper UI, or use a things-file.


fwolter · 2020-11-30T10:24:36Z

bundles/org.openhab.binding.mielecloud/README.md

+| remote_control_can_be_started | Switch | Indicates if this device can be started remotely. | Yes |
+| remote_control_can_be_stopped | Switch | Indicates if this device can be stopped remotely. | Yes |
+| remote_control_can_be_paused | Switch | Indicates if this device can be paused remotely. | Yes |
+| remote_control_can_be_switched_on | Switch | Indicates if the device can be switched on remotely. | Yes |
+| remote_control_can_be_switched_off | Switch | Indicates if the device can be switched off remotely. | Yes |
+| remote_control_can_set_program_active | Switch | Indicates if the active program of the device can be set remotely. | Yes |


Some of the Channels seems to describe properties rather than changing values. You could make those properties. Same might apply for the plate present Channels.

We decided to use channels for the remote_control_* values because these are dynamically updated by the cloud based on the device state. Because of this we assumed them to be part of the "state" rather than a fixed "property". Do you think a property would be more suitable even if it is updated frequently? Our intend was to make scripting more comfortable and allow for generic rules. As far as I know properties cannot be accessed from within rules, is that still correct?

The plate_is_present channels are a different story, though. Making these properties is reasonable. What would be the preferred way in that case? Having one property plate count vs. having six boolean properties?

Channel is just right for remote_control_*, then.

If the plate count is only an information, I'd go for plate_count.

fwolter · 2020-11-30T10:28:40Z

bundles/org.openhab.binding.mielecloud/README.md

+| spinning_speed | String | The spinning speed of the active program. | Yes |
+| spinning_speed_raw | Number | The raw spinning speed of the active program. | Yes |


Did you take a look at Channel state descriptions? That might make the _raw Channels unnecessary.

I assume you are referring to the <options> tag specifically, but using this is in our opinion not reasonably possible at the moment. In order to provide a full description of the possible options the list would have to be either static or accessible via the cloud. Unfortunately, both is not the case. I will use the active program / program ID as an example but the following outline applies to all channels that we defined raw channels for.

The list of possible options for the active program depends on the kind of device (oven, washing machine, ...) and on the specific model. Additionally, for some devices custom programs can be defined. Thus, we cannot statically list all possible values in the binding.

Also, there is no endpoint in the Miele 3rd Party API that supplies a list of possible values including translations. The only supplied information is the localized value of the currently selected / active program. We considered to dynamically alter the channel with these values once they are received but found it to be rather confusing than helpful from a user's perspective.

Have other bindings had similar problems? How did they solve them? Or is our solution fine given these circumstances? If you have a good advice we will happily apply it.

If you don't have a mapping of the options, it's barely possible to use state descriptions. I don't have any better solution.

fwolter · 2020-11-30T10:30:04Z

bundles/org.openhab.binding.mielecloud/README.md

+| Channel ID | Channel Type ID |
+| ---------- | --------------- |
+| remote_control_can_be_started | remote_control_can_be_started |
+| remote_control_can_be_stopped | remote_control_can_be_stopped |
+| remote_control_can_be_switched_on | remote_control_can_be_switched_on |


The Channel Type ID column seems to be redundant. Would a list be sufficient?

You're right, it is redundant in almost all cases. The sole exception is the hob which uses multiple channels of the same type for the plate_power_step channels. So, better make a list for all other devices and leave the table for the hob?

I think that'd be better. I'm wondering why the Channel Type ID is important to the user at all?

In order to define the correct type of item in .items files the user needs to know the type of the channel which is defined by the channel type. Therefore, we included it in the documentation.

Understood. You could add the Item type to the Channels in the lists which differ from above table.

I changed everything to lists, the only special case is the hob where I used some additional text to explain.

BjoernLange · 2020-11-30T11:39:23Z

I reviewed the readme so far. The Channel descriptions don't state any units. Do you use Units of Measure for temperatures and so on?

No, we do not use units of measure at the moment.

fwolter · 2020-11-30T16:05:57Z

Can you at least make the temperature Channels make use of QuantityType?

fwolter · 2020-12-01T18:48:08Z

bundles/org.openhab.binding.mielecloud/src/main/feature/feature.xml

+<features name="org.openhab.binding.mielecloud-${project.version}" xmlns="http://karaf.apache.org/xmlns/features/v1.4.0">
+	<repository>mvn:org.openhab.core.features.karaf/org.openhab.core.features.karaf.openhab-core/${ohc.version}/xml/features</repository>
+
+	<feature name="openhab-binding-mielecloud" description="mielecloud Binding" version="${project.version}">


Is the capitalization correct?

No, that one slipped us.

fwolter · 2020-12-01T18:50:54Z

...ecloud/src/main/java/org/openhab/binding/mielecloud/internal/MieleCloudBindingConstants.java

+    /**
+     * Constants for all channels.
+     */
+    @NonNullByDefault({})


Does this annotation has any effect? Same for below.

The build for openHAB 2.5.x used to warn on internal classes that they should be annotated with @NonNullByDefault although the containing class was annotated. This was our workaround. I checked and it seems it isn't necessary any more so I will remove these annotations.

fwolter · 2020-12-01T18:51:33Z

...ng.mielecloud/src/main/java/org/openhab/binding/mielecloud/internal/auth/OAuthException.java

+ * @author Roland Edelhoff - Initial contribution
+ */
+@NonNullByDefault
+public class OAuthException extends RuntimeException {


Did you make this an unchecked exception by intention?

Yes, we actually prefer unchecked exceptions. Shall we change it to a checked one?

That would fit better to the other code in this repo, but I won't insist on it. As you're using many lambdas converting could be painful.

fwolter · 2020-12-01T18:52:09Z

...d/src/main/java/org/openhab/binding/mielecloud/internal/auth/OpenHabOAuthTokenRefresher.java

+    @Nullable
+    private OAuthFactory oauthFactory;


You could inject this via the constructor to avoid the Nullable annotation. The framework takes care, that this is not null. Same for MieleCloudConfigService.

Thank you for pointing this out! It saves a lot of trouble. Is this also possible for MieleHandlerFactory?

fwolter · 2020-12-01T18:59:03Z

...d/src/main/java/org/openhab/binding/mielecloud/internal/auth/OpenHabOAuthTokenRefresher.java

+            } else {
+                return Optional.of(tokenResponse.getAccessToken());
+            }
+        } catch (Exception e) {


What type of exception do you expect here? Can you specify the concrete type?

We expect multiple exceptions here:

org.openhab.binding.mielecloud.internal.auth.OAuthException: If the OAuthClientService is not available

IOException: If a network/IO issue occurs while getting the access token response

OAuthErrorException / OAuthResponseException: If an OAUTH error response was returned by the cloud while getting the access token response

OAuthException: For other exceptions that occurred while getting the access token response

The latter three come from OAuthClientService.getAccessTokenResponse() (btw. the documentation seems to be outdated there). We want to handle all these exceptions the same way and their common parent is, well, Exception.

In general you want to avoid catching Exception unless you are handling all cases of Exception. If you have multiple exception types and want to handle them the same way you use multi-catch:
catch (OAuthException | IOException | OAuthErrorException | OAuthResponseException( {

I agree to @boc-tothefuture . Catching Exception catches also all RuntimeExceptions

fwolter · 2020-12-01T19:00:02Z

...d/src/main/java/org/openhab/binding/mielecloud/internal/auth/OpenHabOAuthTokenRefresher.java

+                return Optional.of(tokenResponse.getAccessToken());
+            }
+        } catch (Exception e) {
+            logger.info("Cannot obtain access token from persistent storage.");


Logging to info should be used sparsely e.g. a newly started component or a user file that has been loaded. This could be debug or warn.

fwolter · 2020-12-01T19:11:50Z

...d/src/main/java/org/openhab/binding/mielecloud/internal/auth/OpenHabOAuthTokenRefresher.java

+                logger.warn("Failed to remove refresh listener: OAuth client service is unavailable.");
+                logger.debug("Exception details:", e);


This logging pattern is uncommon to OH bindings. If you have a recoverable error like a network fail, you would log a text with the exception's message to debug. If you have a persistent error you would log to warn. These are only examples. See the definitions: https://www.openhab.org/docs/developer/guidelines.html#f-logging

The stack trace should only be logged if the message on its own is not sufficient and the stack trace is crucial for debugging.

I replaced this pattern in all locations it occurred. Please check again.

fwolter

This is pretty good code (thank god 😆)

fwolter · 2020-12-02T18:08:03Z

...rc/main/java/org/openhab/binding/mielecloud/internal/config/servlet/CreateBridgeServlet.java

+        try {
+            TimeUnit.SECONDS.sleep(1);
+        } catch (InterruptedException e) {
+        }


What's the purpose of this sleep? If you want to ensure that there's some delay, you should choose a value of at least 100ms, otherwise the JVM may skip the sleep entirely.

The delay is 1s which is larger than 100ms 😉

You are right, the purpose is not that obvious here: After our bridge changed to ONLINE (see the sleep above) it might take a moment for our discovery service to initialize and discover all devices. We wait for this because the overview page which the user is redirected to shows a template for a .things file which is populated with the discovery results. If these are missing then the template is incomplete. We want to avoid confusing the user here. Obviously that is a hacky workaround and we should rather wait until a maximum delay expired or the number of discovered things in the inbox doesn't change any more. Or is there a more common / easier solution?

It seems it was a bit too late that day...

It'd be good if you solve this in a more elegant way. Unfortunately I can't come up with a solution.

We now wait until the number of discovery results from this binding doesn't change any more.

...oud/src/main/java/org/openhab/binding/mielecloud/internal/config/servlet/SuccessServlet.java

...src/main/java/org/openhab/binding/mielecloud/internal/handler/AbstractMieleThingHandler.java

...cloud/src/main/java/org/openhab/binding/mielecloud/internal/handler/MieleHandlerFactory.java

...ing.mielecloud/src/main/java/org/openhab/binding/mielecloud/internal/util/OptionalUtils.java

...rg/openhab/binding/mielecloud/internal/webservice/api/WineStorageDeviceTemperatureState.java

fwolter

There are some formatting issues. You can fix them with mvn spotless:apply.

Are the JavaScript and CSS files redundant (formatted and stripped)?

There are some checkstyle warnings left. You could take a look at target/code-analysis/report.html.

fwolter · 2020-12-06T18:35:57Z

bundles/org.openhab.binding.mielecloud/src/main/resources/OH-INF/binding/binding.xml

+
+	<name>@text/binding.mielecloud.name</name>
+	<description>@text/binding.mielecloud.description</description>
+	<author>Miele &amp; Cie. KG</author>


The author tag is deprecated and should therefore be removed. See openhab/openhab-core#1844.

We removed it. Is there any other (openHAB official) possibility for Miele to state that they kicked-off development of this binding?

You could include Miele in the author tag in each file.

We discussed this with Miele and came to the conclusion that including them as author in every file isn't reasonable. Miele would rather like to include a small section at the end of the README. Something like

Development of this binding was initiated by Miele & Cie. KG.

Can we do this?

We added a paragraph with an acknowledgement.

fwolter · 2020-12-06T18:36:42Z

bundles/org.openhab.binding.mielecloud/src/main/resources/OH-INF/config/configDescription.xml

+<config-description:config-descriptions
+	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+	xmlns:config-description="https://openhab.org/schemas/config-description/v1.0.0"
+	xsi:schemaLocation="https://openhab.org/schemas/config-description/v1.0.0 http://openhab.org/schemas/config-description-1.0.0.xsd">
+	<config-description uri="thing-type:mielecloud:device" />
+</config-description:config-descriptions>


What's the purpose of this file?

We used to have something in there, but it is not required any more. Removed it.

fwolter · 2020-12-06T18:47:10Z

bundles/org.openhab.binding.mielecloud/src/main/resources/OH-INF/i18n/mielecloud.properties

+thing-type.mielecloud.wine_storage.description=The generic thing type for all Miele wine storage devices.
+
+# Channel related texts
+channel-type.mielecloud.remote_control_can_be_started.label=Remote control can be started


Words in labels should be capitalized (except prepositions and so on). See https://www.openhab.org/docs/developer/bindings/thing-xml.html#formatting-labels-and-descriptions

Labels are expected to be as short as possible. Guideline is 2-3 words with up to 25 chars.

bundles/org.openhab.binding.mielecloud/src/main/resources/OH-INF/thing/bridge.xml

bundles/org.openhab.binding.mielecloud/src/main/resources/OH-INF/thing/channelTypes.xml

fwolter · 2020-12-06T19:00:31Z

...ecloud/src/main/resources/org/openhab/binding/mielecloud/internal/config/assets/css/main.css

@@ -0,0 +1,15023 @@
+/*! normalize.css v5.0.0 | MIT License | github.com/necolas/normalize.css */


Is this really needed today?

It is still needed to have a common initial state across all browsers.

bundles/pom.xml

BjoernLange · 2020-12-11T10:54:50Z

Are the JavaScript and CSS files redundant (formatted and stripped)?

Yes. We thought it would be reasonable to contribute both versions as otherwise it will be hard to impossible to change them in the future.

BjoernLange · 2020-12-11T12:26:36Z

Hi @fwolter! I worked through your review comments and made the appropriate changes or commented on the discussions. Hope I didn't miss anything. Will you close the discussions once you consider them "done"?

fwolter · 2020-12-16T17:18:54Z

Are the JavaScript and CSS files redundant (formatted and stripped)?

Yes. We thought it would be reasonable to contribute both versions as otherwise it will be hard to impossible to change them in the future.

I'd suggest to keep only the formatted version and use that. I don't think performance and data volume matters in this case. That would avoid at least the redundancy of this huge files.

BjoernLange · 2020-12-18T10:29:26Z

We catched up with the recent comments.

fwolter · 2020-12-18T13:37:08Z

...rc/main/java/org/openhab/binding/mielecloud/internal/config/servlet/CreateBridgeServlet.java

@@ -98,8 +98,7 @@ protected String getRedirectionDestination(HttpServletRequest request) {
        try {
            accessToken = authorizationHandler.getAccessToken(bridgeUid);
        } catch (OAuthException e) {
-            logger.warn("Failed to obtain access token");
-            logger.debug("Exception details:", e);
+            logger.warn("Failed to obtain access token.", e);


It seems a bit unreasonable to log the stack trace when the authentication failed. You could log the exception's message. The stack trace should only be logged in rare cases e.g. a bug in your code has been detected.

Sorry for the inconvenience, this part of the code should have been removed. The access token is no longer part of the bridge configuration, so accessing it here is unnecessary. I removed the code.

fwolter · 2020-12-18T13:38:50Z

bundles/org.openhab.binding.mielecloud/README.md

+The following table lists all available channels.
+See the following chapters for detailed information about which appliance supports which channels.
+Depending on the exact appliance configuration not all channels might be supported, e.g. a hob with four plates will only fill the channels for plates 1-4.
+Channe ID and channel type ID match unless noted.


Suggested change

Channe ID and channel type ID match unless noted.

Channel ID and channel type ID match unless noted.

fwolter

LGTM!

Since this is a new binding, another maintainer needs to review your code before it can be merged.

mhilbush

Thanks for your contribution. Finally now I have a reason to enable networking on my dishwasher!

I left a few review comments relating to logging at info level that should be changed to debug level in order to avoid repeatedly spamming the openhab log file.

In general, there are quite a lot of info level logging elsewhere throughout the binding that should be changed to debug level.

mhilbush · 2020-12-23T12:22:50Z

...loud/src/main/java/org/openhab/binding/mielecloud/internal/webservice/sse/SseConnection.java

+            return;
+        }
+
+        logger.info("Opening SSE connection...");


Should be debug level

...loud/src/main/java/org/openhab/binding/mielecloud/internal/webservice/sse/SseConnection.java

mhilbush · 2020-12-23T12:24:38Z

...ud/src/main/java/org/openhab/binding/mielecloud/internal/webservice/sse/SseStreamParser.java

+            }
+
+            silentlyCloseReader();
+            logger.info("SSE stream ended. Closing stream.");


Should be debug level

mhilbush · 2020-12-23T12:24:49Z

...ud/src/main/java/org/openhab/binding/mielecloud/internal/webservice/sse/SseStreamParser.java

+                onStreamClosedCallback.accept(exception.getCause());
+            }
+        }
+        logger.info("SSE stream closed.");


Should be debug level

BjoernLange · 2020-12-24T10:07:25Z

Thanks for your contribution. Finally now I have a reason to enable networking on my dishwasher!

That's great @mhilbush! I also saw your reply on the forum, thank you for trying it out!

I left a few review comments relating to logging at info level that should be changed to debug level in order to avoid repeatedly spamming the openhab log file.

In general, there are quite a lot of info level logging elsewhere throughout the binding that should be changed to debug level.

I went through the code and changed all info logs to debug or warn.

openhab-bot · 2021-01-11T10:16:28Z

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/miele-cloud-binding/93266/79

mhilbush · 2021-01-25T13:47:12Z

@BjoernLange Sorry for the delayed response. Thanks for making the changes to the log levels. I downloaded and built the latest PR. The binding is super quiet now!

I had been running the Beta 4 release. As that release is pretty old, and not everyone is comfortable building PRs, it might be a good idea to get a new beta version out there. 😉

cpmeister

I still have a bit more to go through but these are what I found so far.

itests/org.openhab.binding.mielecloud.tests/pom.xml

...a/org/openhab/binding/mielecloud/internal/webservice/exception/TooManyRequestsException.java

...src/main/java/org/openhab/binding/mielecloud/internal/webservice/DefaultMieleWebservice.java

...ecloud/src/main/java/org/openhab/binding/mielecloud/internal/handler/MieleBridgeHandler.java

...d/src/main/java/org/openhab/binding/mielecloud/internal/auth/OpenHabOAuthTokenRefresher.java

bundles/org.openhab.binding.mielecloud/pom.xml

...a/org/openhab/binding/mielecloud/internal/webservice/language/CombiningLanguageProvider.java

...ud/src/main/java/org/openhab/binding/mielecloud/internal/webservice/retry/RetryStrategy.java

...ud/src/main/java/org/openhab/binding/mielecloud/internal/webservice/sse/SseStreamParser.java

Also-by: Bert Plonus <[email protected]> Also-by: Martin Lepsy <[email protected]> Also-by: Benjamin Bolte <[email protected]> Signed-off-by: Björn Lange <[email protected]>

BjoernLange · 2021-05-21T12:45:28Z

Hi @kaikreuzer, I implemented all requested changes. Please check whether you are satisfied with the thing modeling now. If you are, I will update the documentation to reflect the new configuration parameters and do manual testing to ensure that nothing broke through the changes.

kaikreuzer · 2021-05-21T18:18:46Z

Million thanks @BjoernLange, this looks pretty good to me!
Go ahead and update the docs and we should be ready to merge!

Also-by: Bert Plonus <[email protected]> Also-by: Martin Lepsy <[email protected]> Also-by: Benjamin Bolte <[email protected]> Signed-off-by: Björn Lange <[email protected]>

BjoernLange · 2021-05-25T07:55:15Z

Good morning @kaikreuzer! Everything looks good and I updated the documentation to reflect the recent changes. From my perspective it can be merged now 😄

Also-by: Bert Plonus <[email protected]> Also-by: Martin Lepsy <[email protected]> Also-by: Benjamin Bolte <[email protected]> Signed-off-by: Björn Lange <[email protected]>

kaikreuzer

Great, thanks for the quick updates, @BjoernLange.

Lgtm and I guess it is finally time to merge. 🎉

A million thanks to you, your colleagues and the friends at Miele for creating this huge binding!

BjoernLange · 2021-05-26T17:05:17Z

I have to thank you for the kind review @kaikreuzer! Apart from that I have two further questions:

In order to implement real time updates we implemented an SSE client based on Jetty because there was (and still seems to be) no viable option declared in the default libraries documentation. Is there something ongoing in this direction or would it make sense to generalize our implementation and add it to openHAB core?
There are now multiple bindings that bring their own UI for OAuth logins (at least this one and the Spotify binding). I don't know if its possible in the general case, but wouldn't it be reasonable to add the OAuth login handling to openHAB core? Are there any efforts towards this?

kaikreuzer · 2021-06-01T20:31:26Z

The only other use of SSE within a binding that I remember is @lolodomo's work on the remote openHAB binding. He used JAX-RS for SSE, which looks pretty straight forward to me. I guess we had missed putting that to the default library documentation, but in general that makes sense. I don't really now how feature rich it is and whether it would have worked for your use case as well, though.
What is available in core is the oauth2client bundle, which was actually implemented in the context of Qivicon. This client left out any UI parts, mainly because (at least to my knowledge) there isn't really a proper general way to offer it as long as you cannot have a public url as a redirect url. If you have a good suggestion on how it could/should be done, feel free to open an issue on openhab-core for further discussion!

lolodomo · 2021-06-02T06:55:07Z

There are also the Nest binding (this was my reference to implement the remote openHAB binding) and the recently merged Home Connect binding. They all use JAX-RS for client SSE. I am not sure if they are the only bindings implementing a SSE client .

BjoernLange · 2021-06-02T09:44:30Z

Then I have another question: We had a look at JAX-RS and found it to be suitable, but it isn't part of the compact profile 2 which openHAB targets, or am I wrong here? According to the Oracle documentation JAX-WS, which JAX-RS is a part of, is only included in the full SE API. That's why we didn't use it and instead build something based on Jetty.
I'll look into whether the "proof of concept" implementation from this binding can be used in general and will then open an issue for discussion, thank you @kaikreuzer!

lolodomo · 2021-06-03T07:41:05Z

If I am not wrong, openHAB core framework is built with Apache CXF which provides an implementation of JAX-RS SSE.

kaikreuzer · 2021-06-03T19:08:01Z

it isn't part of the compact profile 2 which openHAB targets, or am I wrong here?

Hm, this was a requirement for ESH. But for openhab-core, we didn't enforce this anymore and since we are on Java 11, there isn't such thing as compact profiles anymore...

BjoernLange · 2021-06-08T07:00:58Z

Shouldn't the paragraph regarding compact profile 2 be dropped then?

kaikreuzer · 2021-06-14T19:26:20Z

Absolutely. I've created openhab/openhab-docs#1602.

…#9146) Also-by: Bert Plonus <[email protected]> Also-by: Martin Lepsy <[email protected]> Also-by: Benjamin Bolte <[email protected]> Signed-off-by: Björn Lange <[email protected]>

cpmeister added the new binding If someone has started to work on a binding. For a new binding PR. label Nov 28, 2020

BjoernLange force-pushed the 9106-miele-cloud-binding-initial-contribution branch from 1b3932d to 6582025 Compare November 30, 2020 07:59

fwolter requested changes Nov 30, 2020

View reviewed changes

fwolter self-assigned this Dec 1, 2020

fwolter requested changes Dec 1, 2020

View reviewed changes

fwolter requested changes Dec 2, 2020

View reviewed changes

BjoernLange requested a review from a team as a code owner December 3, 2020 11:38

fwolter reviewed Dec 6, 2020

View reviewed changes

...rg/openhab/binding/mielecloud/internal/webservice/api/WineStorageDeviceTemperatureState.java Outdated Show resolved Hide resolved

fwolter requested changes Dec 6, 2020

View reviewed changes

BjoernLange force-pushed the 9106-miele-cloud-binding-initial-contribution branch from 1e00ed6 to a36c6fb Compare December 9, 2020 09:32

fwolter reviewed Dec 18, 2020

View reviewed changes

fwolter approved these changes Dec 21, 2020

View reviewed changes

fwolter added the cre Coordinated Review Effort label Dec 21, 2020

mhilbush reviewed Dec 23, 2020

View reviewed changes

BjoernLange mentioned this pull request Dec 29, 2020

Feature request: Implement target temperature actions for type=21 BjoernLange/openhab-miele-cloud-binding-beta#17

Closed

BjoernLange force-pushed the 9106-miele-cloud-binding-initial-contribution branch from 8365026 to ff76f65 Compare February 3, 2021 07:07

cpmeister requested changes Feb 7, 2021

View reviewed changes

cpmeister self-assigned this Feb 9, 2021

Björn Lange added 2 commits May 21, 2021 10:09

handleConfigurationUpdate reinitializes the bridge

5198874

Also-by: Bert Plonus <[email protected]> Also-by: Martin Lepsy <[email protected]> Also-by: Benjamin Bolte <[email protected]> Signed-off-by: Björn Lange <[email protected]>

Locale parameter is not required

594c940

Also-by: Bert Plonus <[email protected]> Also-by: Martin Lepsy <[email protected]> Also-by: Benjamin Bolte <[email protected]> Signed-off-by: Björn Lange <[email protected]>

BjoernLange force-pushed the 9106-miele-cloud-binding-initial-contribution branch from d87f2b8 to 7389bf9 Compare May 21, 2021 11:13

Björn Lange added 3 commits May 21, 2021 13:14

Add required e-mail address config param

7389bf9

Also-by: Bert Plonus <[email protected]> Also-by: Martin Lepsy <[email protected]> Also-by: Benjamin Bolte <[email protected]> Signed-off-by: Björn Lange <[email protected]>

Add device identifier config param

ffcb467

Also-by: Bert Plonus <[email protected]> Also-by: Martin Lepsy <[email protected]> Also-by: Benjamin Bolte <[email protected]> Signed-off-by: Björn Lange <[email protected]>

Do not call framework methods for reinit

2bd65a6

Also-by: Bert Plonus <[email protected]> Also-by: Martin Lepsy <[email protected]> Also-by: Benjamin Bolte <[email protected]> Signed-off-by: Björn Lange <[email protected]>

Add integration test for e-mail address validity

9d52296

Also-by: Bert Plonus <[email protected]> Also-by: Martin Lepsy <[email protected]> Also-by: Benjamin Bolte <[email protected]> Signed-off-by: Björn Lange <[email protected]>

BjoernLange force-pushed the 9106-miele-cloud-binding-initial-contribution branch from 689109c to 2f3d31b Compare May 25, 2021 07:54

Update documentation

2f3d31b

Also-by: Bert Plonus <[email protected]> Also-by: Martin Lepsy <[email protected]> Also-by: Benjamin Bolte <[email protected]> Signed-off-by: Björn Lange <[email protected]>

kaikreuzer approved these changes May 25, 2021

View reviewed changes

kaikreuzer merged commit 705f5c5 into openhab:main May 25, 2021

kaikreuzer added this to the 3.1 milestone May 25, 2021

BjoernLange mentioned this pull request May 26, 2021

Add official logo for Miele Cloud binding openhab/openhab-docs#1552

Merged

BjoernLange mentioned this pull request Jul 6, 2021

Add default libraries for SSE openhab/openhab-docs#1614

Merged

BjoernLange mentioned this pull request Jul 31, 2021

[mielecloud] E-Mail check is not RFC compliant #11050

Closed


		![Pairing Successful](doc/pairing-success.png)

		Once the bridge instance is `ONLINE`, you can either pair things for all appliances via your favorite management UI, e.g. the Paper UI, or use a things-file.

		\| spinning_speed \| String \| The spinning speed of the active program. \| Yes \|
		\| spinning_speed_raw \| Number \| The raw spinning speed of the active program. \| Yes \|

		logger.warn("Failed to remove refresh listener: OAuth client service is unavailable.");
		logger.debug("Exception details:", e);

		@@ -0,0 +1,15023 @@
		/! normalize.css v5.0.0 \| MIT License \| github.com/necolas/normalize.css /

	Channe ID and channel type ID match unless noted.
	Channel ID and channel type ID match unless noted.

[mielecloud] Initial contribution of the Miele Cloud binding #9146

[mielecloud] Initial contribution of the Miele Cloud binding #9146

Conversation

BjoernLange commented Nov 27, 2020

kaikreuzer commented Nov 28, 2020

BjoernLange commented Nov 30, 2020

fwolter left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BjoernLange commented Nov 30, 2020

fwolter commented Nov 30, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fwolter left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fwolter left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BjoernLange commented Dec 11, 2020

BjoernLange commented Dec 11, 2020

fwolter commented Dec 16, 2020

BjoernLange commented Dec 18, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fwolter left a comment

Choose a reason for hiding this comment

mhilbush left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BjoernLange commented Dec 24, 2020

openhab-bot commented Jan 11, 2021

mhilbush commented Jan 25, 2021

cpmeister left a comment

Choose a reason for hiding this comment

BjoernLange commented May 21, 2021

mhilbush left a comment •

edited

Loading

lolodomo commented Jun 2, 2021 •

edited

Loading

lolodomo commented Jun 3, 2021 •

edited

Loading