[boschshc] Initial contribution - Bindings for Bosch Smart Home devices #8629

coeing · 2020-10-01T19:40:19Z

Hi there,

@stefan-kaestle started a fork of your repository in November 2019 to implement the bindings for Bosch Smart Home devices which are pretty popular in Germany. @GerdZanker and I joined earlier this year.

Together we managed to built a good base for a first release, which already has the base structure to setup and communicate with the Bosch Smart Home controller and supports a lot of devices:

Bosch In-Wall switches
Bosch Smart Plugs (use "in-wall-switch" thing too).
Bosch TwinGuard smoke detector
Bosch Window/Door contacts
Bosch Motion Detector
Bosch Shutter Control in-wall
Bosch Thermostat
Bosch Climate Control

Before we continue our development we'd like to do a first public release to gather user feedback and your feedback as openHAB maintainers :)

We already found some fellow openHAB users who tested pre-release versions and apart from some minor issues which we fixed, they were already quite content with the result (and had some ideas for enhancements for the next version of course :) ).

We tried to get some upfront feedback about our code base from one of your maintainers, but got no answer, so we thought we just create a pull request to discuss any further issues here: https://community.openhab.org/t/towards-merging-the-new-bosch-shc-binding/101952

You can find the fork here: https://github.com/stefan-kaestle/openhab2-addons We already tried to sign-off each commit and follow your coding guidelines (https://www.openhab.org/docs/developer/development/guidelines.html), but might have missed some points as it is our first contribution to your project.

We have a thread in the community forum: https://community.openhab.org/t/will-there-be-a-bosch-smart-home-binding

The last pre-release is up-to-date apart from some file moving: https://github.com/stefan-kaestle/openhab2-addons/releases/tag/v1.0-beta.1

Feel free to ask any questions and let us know what work needs to be done before our work can be merged. Thanks for your help and for your great open-source Smart Home platform!

This pull request continues the first merge of our binding from the previous pull request #8371 Due to openHAB 3 we rebased our binding on the new code base.

TravisBuddy · 2020-10-01T19:45:52Z

Travis tests were successful

Hey @coeing,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

cpmeister

I wasn't able to review the entire thing, but I found a few issues to get you started.

...hshc/src/main/java/org/openhab/binding/boschshc/internal/devices/BoschSHCHandlerFactory.java

...hshc/src/main/java/org/openhab/binding/boschshc/internal/devices/bridge/BoschHttpClient.java

...rc/main/java/org/openhab/binding/boschshc/internal/devices/bridge/BoschSHCBridgeHandler.java

...oschshc/src/main/java/org/openhab/binding/boschshc/internal/devices/bridge/BoschSslUtil.java

...chshc/src/main/java/org/openhab/binding/boschshc/internal/devices/bridge/JsonRpcRequest.java

coeing · 2020-10-26T08:40:22Z

I wasn't able to review the entire thing, but I found a few issues to get you started.

Thanks @cpmeister for your review! I will try to fix the issues you found this week :)

cpmeister

Second review pass

...ng.boschshc/src/main/java/org/openhab/binding/boschshc/internal/devices/BoschSHCHandler.java

...chshc/src/main/java/org/openhab/binding/boschshc/internal/devices/BoschSHCConfiguration.java

...rc/main/java/org/openhab/binding/boschshc/internal/devices/bridge/BoschSHCBridgeHandler.java

...oschshc/src/main/java/org/openhab/binding/boschshc/internal/devices/bridge/BoschSslUtil.java

....boschshc/src/main/java/org/openhab/binding/boschshc/internal/devices/bridge/dto/Device.java

...ava/org/openhab/binding/boschshc/internal/devices/inwallswitch/BoschInWallSwitchHandler.java

...java/org/openhab/binding/boschshc/internal/devices/shuttercontrol/ShutterControlHandler.java

...ng.boschshc/src/main/java/org/openhab/binding/boschshc/internal/devices/BoschSHCHandler.java

...rc/main/java/org/openhab/binding/boschshc/internal/devices/bridge/BoschSHCBridgeHandler.java

...boschshc/src/main/java/org/openhab/binding/boschshc/internal/devices/bridge/LongPolling.java

...main/java/org/openhab/binding/boschshc/internal/devices/twinguard/BoschTwinguardHandler.java

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

bundles/org.openhab.binding.boschshc/src/main/resources/OH-INF/thing/thing-types.xml

...boschshc/src/main/java/org/openhab/binding/boschshc/internal/devices/bridge/LongPolling.java

cpmeister · 2020-11-17T19:48:06Z

...main/java/org/openhab/binding/boschshc/internal/devices/twinguard/BoschTwinguardHandler.java

+        updateState(CHANNEL_TEMPERATURE, new DecimalType(state.temperature));
+        updateState(CHANNEL_TEMPERATURE_RATING, new StringType(state.temperatureRating));
+        updateState(CHANNEL_HUMIDITY, new DecimalType(state.humidity));
+        updateState(CHANNEL_HUMIDITY_RATING, new StringType(state.humidityRating));
+        updateState(CHANNEL_PURITY, new DecimalType(state.purity));


Temperature, humidity, and purity should be QuantityType instead of DecimalType.

Changed it :) Hope the QuantityType<Dimensionless> is okay for humidity and purity as the channels are of type Number:Dimensionless?

@cpmeister Are the current types okay?

cpmeister · 2020-11-17T19:49:35Z

Oh, also your build is failing.

bundles/org.openhab.binding.boschshc/DEVELOPERS.md

fwolter

This is pretty good code, you made a really good job!

I receive compiler errors. E.g.

BoschSHCBridgeHandler.java:[355,19] Null type mismatch (type annotations): required 'T extends org.openhab.binding.boschshc.internal.services.dto.@NonNull BoschSHCServiceState' but this expression has type '@Nullable T extends org.openhab.binding.boschshc.internal.services.dto.@NonNull BoschSHCServiceState'

bundles/org.openhab.binding.boschshc/.classpath

bundles/org.openhab.binding.boschshc/.project

bundles/org.openhab.binding.boschshc/DEVELOPERS.md

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

...oschshc/src/main/java/org/openhab/binding/boschshc/internal/devices/bridge/BoschSslUtil.java

...boschshc/src/main/java/org/openhab/binding/boschshc/internal/devices/bridge/LongPolling.java

...main/java/org/openhab/binding/boschshc/internal/devices/twinguard/BoschTwinguardHandler.java

bundles/org.openhab.binding.boschshc/src/main/resources/OH-INF/thing/thing-types.xml

...oschshc/src/main/java/org/openhab/binding/boschshc/internal/devices/bridge/BoschSslUtil.java

bundles/org.openhab.binding.boschshc/.gitignore

bundles/org.openhab.binding.boschshc/src/main/resources/OH-INF/thing/thing-types.xml

...hshc/src/main/java/org/openhab/binding/boschshc/internal/devices/BoschSHCHandlerFactory.java

cpmeister

I think these are the last changes I'll request, other than these it looks good to me.

...ava/org/openhab/binding/boschshc/internal/devices/inwallswitch/BoschInWallSwitchHandler.java

...hshc/src/main/java/org/openhab/binding/boschshc/internal/devices/bridge/BoschHttpClient.java

...rc/main/java/org/openhab/binding/boschshc/internal/devices/bridge/BoschSHCBridgeHandler.java

fwolter · 2020-12-10T17:34:49Z

SmartHomeUnits has been renamed to Units. That needs to be adapted in your code.

coeing · 2020-12-10T17:51:12Z

SmartHomeUnits has been renamed to Units. That needs to be adapted in your code.

Found this issue while you wrote your comment :) Changed it in my last commit.

cpmeister

Almost done from me I think.

...hshc/src/main/java/org/openhab/binding/boschshc/internal/devices/bridge/BoschHttpClient.java

...main/java/org/openhab/binding/boschshc/internal/devices/twinguard/BoschTwinguardHandler.java

...hshc/src/main/java/org/openhab/binding/boschshc/internal/devices/bridge/BoschHttpClient.java

...boschshc/src/main/java/org/openhab/binding/boschshc/internal/devices/bridge/LongPolling.java

added back the removed @nullable annotation in sendRequest() replaced deprecated SslContextFactory constructor call Signed-off-by: Gerd Zanker <gerd.zanker@web.de>

cpmeister · 2021-01-08T02:34:10Z

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

+  <dependencies>
+    <dependency>
+      <groupId>org.bouncycastle</groupId>
+      <artifactId>bcpkix-jdk15on</artifactId>
+      <version>1.54</version>
+      <scope>compile</scope>
+    </dependency>
+    <dependency>
+      <groupId>org.bouncycastle</groupId>
+      <artifactId>bcprov-jdk15on</artifactId>
+      <version>1.54</version>
+      <scope>compile</scope>
+    </dependency>
+  </dependencies>


Is there a documentation which information of the dependencies should go into the NOTICE file?

Not that I'm aware of, but you can look at other bindings as an example.

Hilbrand · 2021-01-08T08:50:20Z

There is no documentation on format of additional licenses in NOTICE. It's something like this:

## Third-party Content

bcpkix-jdk15on
bcprov-jdk15on
* License: Bouncy Castle License
* Project https://www.bouncycastle.org
* Source: https://github.com/bcgit/bc-java

One other thing. It looks like the library bcpkix-jdk15on is also available repackaged in core, but only at runtime. This is version 1.52. If that is indeed the case than this library could be added in this binding with scope provided. It may be worth testing this to reduce the download size of the jar (this would mean the version number here needs to be changed match the version in openhab-core).

coeing · 2021-01-08T19:28:11Z

There is no documentation on format of additional licenses in NOTICE. It's something like this:
## Third-party Content

bcpkix-jdk15on
bcprov-jdk15on
* License: Bouncy Castle License
* Project https://www.bouncycastle.org
* Source: https://github.com/bcgit/bc-java
One other thing. It looks like the library bcpkix-jdk15on is also available repackaged in core, but only at runtime. This is version 1.52. If that is indeed the case than this library could be added in this binding with scope provided. It may be worth testing this to reduce the download size of the jar (this would mean the version number here needs to be changed match the version in openhab-core).

@GerdZanker Could you try this out? Would be nice to have no additional dependency for our binding :) I am currently working on the Long Polling cancelation after 24 hours (stefan-kaestle#62)

Signed-off-by: Gerd Zanker <gerd.zanker@web.de>

…g.openhab.core.io.jetty.certificate to later reduce download size Signed-off-by: Gerd Zanker <gerd.zanker@web.de>

GerdZanker · 2021-01-09T17:35:54Z

@GerdZanker Could you try this out?

I'm on the way. The NOTICE is updated and I downgraded the Bouncy Castle version to 1.52 and certificate can still be created.

GerdZanker · 2021-01-09T17:49:35Z

this library could be added in this binding with scope provided. It may be worth testing this to reduce the download size of the jar (this would mean the version number here needs to be changed match the version in openhab-core)

The version number 1.52 now matches to the version used in org.openhab.io.jetty.certificate, see dc03646.
I changed locally the scope of the <artifactId>bcpkix-jdk15on</artifactId> dependency to <scope>provided</scope>, but I get errors during mvn install:

[ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.2.7:verify (karaf-feature-verification) on project org.openhab.binding.boschshc: Feature resolution failed for [openhab-binding-boschshc/3.1.0.SNAPSHOT]
[ERROR] Message: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=openhab-binding-boschshc; type=karaf.feature; version=3.1.0.SNAPSHOT; filter:="(&(osgi.identity=openhab-binding-boschshc)(type=karaf.feature)(version>=3.1.0.SNAPSHOT))" [caused by: Unable to resolve openhab-binding-boschshc/3.1.0.SNAPSHOT: missing requirement [openhab-binding-boschshc/3.1.0.SNAPSHOT] osgi.identity; osgi.identity=org.openhab.binding.boschshc; type=osgi.bundle; version="[3.1.0.202101091740,3.1.0.202101091740]"; resolution:=mandatory [caused by: Unable to resolve org.openhab.binding.boschshc/3.1.0.202101091740: missing requirement [org.openhab.binding.boschshc/3.1.0.202101091740] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.bouncycastle.cert)(version>=1.52.0)(!(version>=2.0.0)))"]]
[ERROR] Repositories: {
[ERROR]         file:...\openhab-addons\bundles\org.openhab.binding.boschshc\target/feature/feature.xml
[ERROR]         mvn:org.apache.karaf.features/framework/4.2.7/xml/features
[ERROR]         mvn:org.apache.karaf.features/standard/4.2.7/xml/features
[ERROR]         mvn:org.openhab.core.features.karaf/org.openhab.core.features.karaf.openhab-core/3.1.0-SNAPSHOT/xml/features
[ERROR]         mvn:org.openhab.core.features.karaf/org.openhab.core.features.karaf.openhab-tp/3.1.0-SNAPSHOT/xml/features
[ERROR]         mvn:org.ops4j.pax.web/pax-web-features/7.2.11/xml/features
[ERROR] }
[ERROR] Resources: {
...
[ERROR]         mvn:org.apache.xbean/xbean-reflect/4.14
[ERROR]         mvn:org.bitbucket.b_c/jose4j/0.7.0
[ERROR]         mvn:org.eclipse.emf/org.eclipse.emf.common/2.17.0
...
[ERROR]         mvn:org.openhab.addons.bundles/org.openhab.binding.boschshc/3.1.0-SNAPSHOT
...
[ERROR]         mvn:org.openhab.core.bundles/org.openhab.core.io.jetty.certificate/3.1.0-SNAPSHOT
...
[ERROR] }

Can you @Hilbrand support us, because I'm not a maven expert and know how to solve this? It would be great if you can suggest necessary pom.xml changes to fix this, because I have now idea what the problem is.

GSON will not return null if there is no "result" field, but will just set the "result" member to null. Signed-off-by: Christian Oeing <christian.oeing@slashgames.org>

…method name Signed-off-by: Christian Oeing <christian.oeing@slashgames.org>

cpmeister · 2021-01-13T20:49:12Z

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

+		<feature>openhab-runtime-base</feature>
+		<bundle start-level="80">mvn:org.openhab.addons.bundles/org.openhab.binding.boschshc/${project.version}</bundle>


After switch the dependencies to provided you would then need to update your feature.xml to let the osgi system know where it can find those dependencies. This should solve the error your are seeing in the build.

Suggested change

<feature>openhab-runtime-base</feature>

<bundle start-level="80">mvn:org.openhab.addons.bundles/org.openhab.binding.boschshc/${project.version}</bundle>

<feature>openhab-runtime-base</feature>

<bundle dependency="true">mvn:org.bouncycastle/bcpkix-jdk15on/1.52</bundle>

<bundle dependency="true">mvn:org.bouncycastle/bcprov-jdk15on/1.52</bundle>

<bundle start-level="80">mvn:org.openhab.addons.bundles/org.openhab.binding.boschshc/${project.version}</bundle>

Thanks a lot @cpmeister! Your suggestion solves the error on my machine.

This means that the maven pom.xml contains the "compile time" dependencies and the feature.xml defines the runtime OSGi environment.

I will tests the new binding jar - now only 88Kb big - and commit the changes afterwards.

88kb?! 🎆

Oh no 😧. During runtime I get now problems: Not all used class from org.bouncycastle.* are contained in org.openhab.io.jetty.certificate and this binding code uses of cause missing classes.

I will evaluate the following option:
a) rewrite the binding certificate code to only use available classes
b) use the maven-shade-plugin as in the org.openhab.io.jetty.certificate bundle pom.xml to reduce the jar size

From what I can tell, org.openhab.io.jetty.certificate doesn't export any of the org.bouncycastle.* classes that it has shaded internally. This means that you can't rely on org.openhab.io.jetty.certificate as a dependency to get those classes from.

Are you having any trouble getting the binding to install? Or does it install and just throw errors?

The trouble started after a successful compilation and bundle installation. It seems to me that all dependencies inside the OSGi container were resolved, because I was able to start the Bosch SHC Bridge Thing. But during the very first initialization I got exceptions during the keystore and the self signed certificate creation.

I will write unit tests to have a defined environment and reproduce steps for keystore and self signed certificate creation. Then I can evaluate different dependencies and code combinations.

FYI: A first "copy & paste" of the maven-shade-plugin settings from the org.openhab.io.jetty.certificate pom.xml to this binding pom resulted in the error

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:3.2.1:shade (default) on project org.openhab.binding.boschshc: Error creating shaded jar: Invalid signature file digest for Manifest main attributes -> [Help 1]

Since you are going to shade the bouncycastle libraries into you binding anyway, the easiest way to do that would be to give those dependencies a compile scope in your pom file. Doing so would automatically get those dependencies shaded into your final binding jar. You also wouldn't need to list the dependencies in your feature.xml file either in that case.

The current PR content has the compile scope for the bouncycastle dependencies and the shading results in a 3.4MB big jar which is working.
It was requested to reduce the jar size and up to now I found no feasible way, because
a) the org.openhab.io.jetty.certificate jar doesn't provide necessary classes currently used in the BoschSslUtil class during runtime
b) I have no working maven pom to shade and reduce the jar size during compile time

When @Hilbrand made his suggestion I don't think he was aware that the org.openhab.io.jetty.certificate doesn't export the bouncycastle packages. So depending on the core to provide those dependencies isn't an option at the moment. For now I suggest leaving the dependencies embedded for now and once the core exposes the bouncycastle packages we can try to readdress the sizing issue.

Signed-off-by: Gerd Zanker <gerd.zanker@web.de>

The changeable SHC system password for the keystore is replaced by a static string in the code. The keyStore name is now based on SHC ipAddress to support multiple SmartHomeControllers. Signed-off-by: Gerd Zanker <gerd.zanker@web.de>

cpmeister

The code looks good to me right now. Is there anything else you want to add before this gets merged? I'd suggest leaving new features for later PRs.

GerdZanker · 2021-01-17T17:11:36Z

Is there anything else you want to add before this gets merged?

Hello @coeing, I know you currently in progress with this issue.
Do you want to add modifications before a merge?

I'm done: The JAR size is OK and the initial setup is improved, because an internal password is used for the keystore.

coeing · 2021-01-17T20:05:22Z

@cpmeister @GerdZanker I am fine with the current state of the binding. As Gerd mentioned, our binding disconnects after 24 hours (stefan-kaestle#62), but I need some time to investigate the issue as it is not easy to reproduce (having to wait 24 hours each time...). Having some more people test the binding will help with finding the issue.

So from my side: Ready to merge! 👍

…es (openhab#8629) * Initial code from create_openhab_binding_skeleton.sh Co-authored-by: Stefan Kaestle <stefan@mad-kow.de> Co-authored-by: Gerd Zanker <gerd.zanker@web.de> Co-authored-by: Christian Oeing <christian.oeing@scalamat.de> Co-authored-by: Hilbrand Bouwkamp <hilbrand@h72.nl> Co-authored-by: Fabian Wolter <github@fabian-wolter.de> Co-authored-by: Connor Petty <mistercpp2000+gitsignoff@gmail.com>

…es (openhab#8629) * Initial code from create_openhab_binding_skeleton.sh Signed-off-by: Stefan Kaestle <stefan@mad-kow.de> Signed-off-by: Christian Oeing <christian.oeing@slashgames.org> Signed-off-by: Gerd Zanker <gerd.zanker@web.de> Co-authored-by: Stefan Kaestle <stefan@mad-kow.de> Co-authored-by: Gerd Zanker <gerd.zanker@web.de> Co-authored-by: Christian Oeing <christian.oeing@scalamat.de> Co-authored-by: Hilbrand Bouwkamp <hilbrand@h72.nl> Co-authored-by: Fabian Wolter <github@fabian-wolter.de> Co-authored-by: Connor Petty <mistercpp2000+gitsignoff@gmail.com> Signed-off-by: John Marshall <john.marshall.au@gmail.com>

…es (openhab#8629) * Initial code from create_openhab_binding_skeleton.sh Signed-off-by: Stefan Kaestle <stefan@mad-kow.de> Signed-off-by: Christian Oeing <christian.oeing@slashgames.org> Signed-off-by: Gerd Zanker <gerd.zanker@web.de> Co-authored-by: Stefan Kaestle <stefan@mad-kow.de> Co-authored-by: Gerd Zanker <gerd.zanker@web.de> Co-authored-by: Christian Oeing <christian.oeing@scalamat.de> Co-authored-by: Hilbrand Bouwkamp <hilbrand@h72.nl> Co-authored-by: Fabian Wolter <github@fabian-wolter.de> Co-authored-by: Connor Petty <mistercpp2000+gitsignoff@gmail.com>

coeing mentioned this pull request Oct 1, 2020

[boschshc] Initial contribution - Bindings for Bosch Smart Home devices #8371

Closed

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

coeing mentioned this pull request Oct 18, 2020

Version 1.0 Discussion stefan-kaestle/openhab2-addons#14

Closed

coeing marked this pull request as ready for review October 18, 2020 19:27

coeing force-pushed the bosch-shc-3.0 branch from c19df48 to d2389b2 Compare October 22, 2020 18:59

cpmeister requested changes Oct 25, 2020

View reviewed changes

coeing force-pushed the bosch-shc-3.0 branch 2 times, most recently from a251db1 to 83a86f5 Compare October 26, 2020 19:54

cpmeister requested changes Oct 27, 2020

View reviewed changes

coeing requested a review from cpmeister November 2, 2020 20:13

cpmeister requested changes Nov 3, 2020

View reviewed changes

cpmeister reviewed Nov 9, 2020

View reviewed changes

...boschshc/src/main/java/org/openhab/binding/boschshc/internal/devices/bridge/LongPolling.java Outdated Show resolved Hide resolved

coeing requested a review from cpmeister November 13, 2020 14:27

kaikreuzer added rebuild Triggers Jenkins PR build and removed rebuild Triggers Jenkins PR build labels Nov 17, 2020

cpmeister requested changes Nov 17, 2020

View reviewed changes

JohannesPtaszyk reviewed Nov 17, 2020

View reviewed changes

bundles/org.openhab.binding.boschshc/DEVELOPERS.md Outdated Show resolved Hide resolved

coeing force-pushed the bosch-shc-3.0 branch from 242909b to 01a607a Compare November 18, 2020 10:21

fwolter requested changes Nov 20, 2020

View reviewed changes

fwolter reviewed Nov 20, 2020

View reviewed changes

...oschshc/src/main/java/org/openhab/binding/boschshc/internal/devices/bridge/BoschSslUtil.java Outdated Show resolved Hide resolved

coeing requested a review from a team as a code owner December 3, 2020 11:15

fwolter requested changes Dec 4, 2020

View reviewed changes

cpmeister requested changes Dec 7, 2020

View reviewed changes

cpmeister requested changes Dec 11, 2020

View reviewed changes

coeing requested a review from fwolter December 15, 2020 14:38

GerdZanker force-pushed the bosch-shc-3.0 branch from 1b7cc8e to 0664874 Compare January 7, 2021 18:53

fixed last two pending warnings

dfbf982

added back the removed @nullable annotation in sendRequest() replaced deprecated SslContextFactory constructor call Signed-off-by: Gerd Zanker <gerd.zanker@web.de>

cpmeister added rebuild Triggers Jenkins PR build and removed rebuild Triggers Jenkins PR build labels Jan 7, 2021

cpmeister requested changes Jan 8, 2021

View reviewed changes

GerdZanker added 2 commits January 9, 2021 18:14

added Bouncy Castle third-party license info into NOTICE

5b6baae

Signed-off-by: Gerd Zanker <gerd.zanker@web.de>

changed Bouncy Castle version to same version as currently used in or…

dc03646

…g.openhab.core.io.jetty.certificate to later reduce download size Signed-off-by: Gerd Zanker <gerd.zanker@web.de>

coeing added 2 commits January 10, 2021 23:54

#62 Correctly check if long poll response is valid

a29068d

GSON will not return null if there is no "result" field, but will just set the "result" member to null. Signed-off-by: Christian Oeing <christian.oeing@slashgames.org>

Add @NonNullByDefault annotation to LongPollResultTest class and fix …

ed36092

…method name Signed-off-by: Christian Oeing <christian.oeing@slashgames.org>

GerdZanker mentioned this pull request Jan 13, 2021

Handle change of Home Controller system password correctly stefan-kaestle/openhab2-addons#55

Closed

cpmeister requested changes Jan 13, 2021

View reviewed changes

GerdZanker added 3 commits January 16, 2021 19:53

added first unittests for BoschSslUtil class

de75994

Signed-off-by: Gerd Zanker <gerd.zanker@web.de>

added next unittests for BoschHttpClient class

ab17362

Signed-off-by: Gerd Zanker <gerd.zanker@web.de>

#55 replaced the password with a fixed one

0136cf0

The changeable SHC system password for the keystore is replaced by a static string in the code. The keyStore name is now based on SHC ipAddress to support multiple SmartHomeControllers. Signed-off-by: Gerd Zanker <gerd.zanker@web.de>

cpmeister approved these changes Jan 16, 2021

View reviewed changes

cpmeister added rebuild Triggers Jenkins PR build and removed rebuild Triggers Jenkins PR build labels Jan 17, 2021

cpmeister merged commit 2a5bdf3 into openhab:main Jan 17, 2021

cpmeister added this to the 3.1 milestone Jan 17, 2021

coeing deleted the bosch-shc-3.0 branch February 7, 2021 20:07

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[boschshc] Initial contribution - Bindings for Bosch Smart Home devices #8629

[boschshc] Initial contribution - Bindings for Bosch Smart Home devices #8629

coeing commented Oct 1, 2020 •

edited

Loading

TravisBuddy commented Oct 1, 2020 •

edited

Loading

cpmeister left a comment

coeing commented Oct 26, 2020

cpmeister left a comment

cpmeister Nov 17, 2020

coeing Nov 18, 2020 •

edited

Loading

coeing Dec 10, 2020

cpmeister commented Nov 17, 2020

fwolter left a comment

cpmeister left a comment

fwolter commented Dec 10, 2020

coeing commented Dec 10, 2020

cpmeister left a comment

cpmeister Jan 8, 2021

Hilbrand commented Jan 8, 2021

coeing commented Jan 8, 2021

GerdZanker commented Jan 9, 2021 •

edited

Loading

GerdZanker commented Jan 9, 2021

cpmeister Jan 13, 2021

GerdZanker Jan 14, 2021

coeing Jan 14, 2021

GerdZanker Jan 14, 2021

cpmeister Jan 14, 2021

GerdZanker Jan 15, 2021

GerdZanker Jan 15, 2021

cpmeister Jan 15, 2021

GerdZanker Jan 16, 2021

cpmeister Jan 16, 2021

cpmeister left a comment

GerdZanker commented Jan 17, 2021

coeing commented Jan 17, 2021

		<feature>openhab-runtime-base</feature>
		<bundle start-level="80">mvn:org.openhab.addons.bundles/org.openhab.binding.boschshc/${project.version}</bundle>

[boschshc] Initial contribution - Bindings for Bosch Smart Home devices #8629

[boschshc] Initial contribution - Bindings for Bosch Smart Home devices #8629

Conversation

coeing commented Oct 1, 2020 • edited Loading

TravisBuddy commented Oct 1, 2020 • edited Loading

Travis tests were successful

cpmeister left a comment

Choose a reason for hiding this comment

coeing commented Oct 26, 2020

cpmeister left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

coeing Nov 18, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cpmeister commented Nov 17, 2020

fwolter left a comment

Choose a reason for hiding this comment

cpmeister left a comment

Choose a reason for hiding this comment

fwolter commented Dec 10, 2020

coeing commented Dec 10, 2020

cpmeister left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Hilbrand commented Jan 8, 2021

coeing commented Jan 8, 2021

GerdZanker commented Jan 9, 2021 • edited Loading

GerdZanker commented Jan 9, 2021

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

cpmeister left a comment

Choose a reason for hiding this comment

GerdZanker commented Jan 17, 2021

coeing commented Jan 17, 2021

coeing commented Oct 1, 2020 •

edited

Loading

TravisBuddy commented Oct 1, 2020 •

edited

Loading

coeing Nov 18, 2020 •

edited

Loading

GerdZanker commented Jan 9, 2021 •

edited

Loading