stefan-kaestle/openhab2-addons

Add-ons for openHAB 2.x

openhab2-addons's Issues

Bosch Smart Home Controller Vs Easy Control Smart Thermostat

Hi, I've been checking in with your binding for a little while now and have been very excited to try it out.

I'm not sure if this is a question or a feature request really.

Essentially I have the Bosch Easy Control Smart Thermostat that seems to do the job of the Smart Home Controller. I think this as I have the Easy Control Smart Thermostat and several Radiator Valves that connect through this thermostat, which is connected to my network and is pingable.

I can connect to the EasyConnect via IFTTT, but would really prefer to access it through OpenHab.

I've installed your latest OpenHab 2 binding but it asks for me to press the pairing button which I don't have.

Is the Smart Thermostat supported by your binding?

Would be happy to try and fix this myself although I'm completely new to the world of Binding development so am not sure where to start.

Exception during keystore creation

Expected Behavior

Keystore is created after entering IP and PW into bridge handler.

Current Behavior

No *.jks file is created. After setting log to trace I get this info:

2020-12-25 13:27:51.526 [INFO ] [internal.devices.bridge.BoschSslUtil] - Creating new keystore /Users/jensflorian/Downloads/openhab-RC1/userdata/etc/oss_openhab_binding_2eae8ca1-754d-41aa-a1e2-87d3dec7faa6.jks because it doesn't exist.
2020-12-25 13:27:51.527 [DEBUG] [internal.devices.bridge.BoschSslUtil] - Creating new keypair
2020-12-25 13:27:51.672 [DEBUG] [internal.devices.bridge.BoschSslUtil] - Creating a new self signed certificate: CN=oss_openhab_binding_2eae8ca1-754d-41aa-a1e2-87d3dec7faa6, O=openHAB, L=None, ST=None, C=None
2020-12-25 13:27:51.677 [DEBUG] [internal.devices.bridge.BoschSslUtil] - Adding keypair and self signed certificate to keystore
2020-12-25 13:27:51.678 [DEBUG] [internal.devices.bridge.BoschSslUtil] - Adding Issuing CA to keystore
2020-12-25 13:27:51.678 [DEBUG] [internal.devices.bridge.BoschSslUtil] - Exception during keystore creation Could not parse certificate: java.io.IOException: Stream closed

Possible Solution

Create jks file manually (how?)

Steps to Reproduce (for Bugs)

Reproducible. I assume creation of jks file in OsX shell may be different from RaspberryPI.

Your Environment

• OH3.0.0 final release
• Safari macOS Catalina
• OSX 10.15.17, The default interactive shell is zsh.

RoomClimateControl exception

I am getting for the Room Climate Control thing the following error when reading through the looks.

2020-08-15 15:02:33.676 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.Error: State request for service RoomClimateControl of device hdm:HomeMaticIP:3014F711A000239A18595A2C failed with status code 404 and error code ENTITY_NOT_FOUND
at org.openhab.binding.boschshc.internal.BoschSHCBridgeHandler.getState(BoschSHCBridgeHandler.java:495) ~[?:?]
at org.openhab.binding.boschshc.internal.services.BoschSHCService.refreshState(BoschSHCService.java:108) ~[?:?]
at org.openhab.binding.boschshc.internal.BoschSHCHandler.handleCommand(BoschSHCHandler.java:124) ~[?:?]
at org.openhab.binding.boschshc.internal.devices.climatecontrol.ClimateControlHandler.handleCommand(ClimateControlHandler.java:64) ~[?:?]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.channelLinked(BaseThingHandler.java:191) ~[?:?]
at org.eclipse.smarthome.core.thing.link.ThingLinkManager.lambda$0(ThingLinkManager.java:267) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_252]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]

The thing configuration looks as follows:
//Fussbodenheizungs Thermostat
Thing thermostat flur "Thermostat Flur" @ "Flur" [ id="hdm:HomeMaticIP:3014F711A000239A18595A2C"]
Thing climate-control flur "Thermostat Flur" @ "Flur" [ id="hdm:HomeMaticIP:3014F711A000239A18595A2C"]

The climate-control previously properly showed the "To be temperature" now it show -NaN as an exception occurs.

Add support for Home Connect washing machines

It would be great if Home Connect washing machines like the BOSCH-WAYH2840 would be supported.

2021-01-01 10:31:53.046 [INFO ] [devices.bridge.BoschSHCBridgeHandler] - Found device: name=Waschmaschine id=hdm:homeconnect:BOSCH-WAYH2840-68A40EXXXXXX

Add handler for "Wall thermostat" (temperature + humidity)

The Bosch Thermostat for floor heating system does also measure the relative air moisture and shares this with the controller.

As a second iteration obtaining this value together with the temperature would be good to use for analytics and graphing.

Please support the smoke detector for fire detection and siren

It would be nice to get the Information (event) if the smoke detector detect a fire. This information could be important for existing devices in OpenHAB like open the shutters or push notifications to the mobile phone or external gong in the garden.

In addition to that I wish a switch to start the alarm siren. For example if a burglar enters the house, I would like to start the siren.

Device: https://www.bosch-smarthome.com/uk/en/shop?url=products/smart-system-solutions/smoke-detector

BoschSHCBindingConstants.java - Auto-generated code

BoschSHCBindingConstants.java tells me about auto-generated code, but I can't see how to trigger the auto-generation.

Would be nice to have a hint there or in the Readme.md how to trigger the auto-generation because I always edited the code myself for the last changes.

Fix code analysis warnings

Right now we have a lot of code analysis warnings popping up during a Maven build:

mvn install

The code analysis report can be found at openhab-addons/bundles/org.openhab.binding.boschshc/target/code-analysis/report.html afterwards.

We have probably all skipped the code analysis during our work, so the warnings piled up. In the future we should run a normal build each time we merge a pull request.

For now we should fix those as soon as possible to avoid code smells.

Support for RoomClimateControls

Once the thermostats are in, it would be great to have a way to set the desired temperature for a room.

This happens via virtual devices of the type "RoomClimateControl": BoschSmartHome/bosch-shc-api-docs#35

The API documentation can be found here: https://apidocs.bosch-smarthome.com/local/ -> Climate Control

The service is called RoomClimateControl as well and can receive a state for the setpointTemperature to set the desired temperature.

Please support Bosch's radiator thermostat

Please consider to support Bosch's radiator thermostats in the Bosch Smart Home Binding.

https://www.bosch-smarthome.com/de/de/produkte/smart-system-solutions/heizkoerperthermostat

Parental controls on ash thermostats

it would be great to activate / deactivate the bsh thermostats parental controls via openhab (see Kindersicherung unter BSH APP --> Verwaltung --> Geräte --> Heizkörper-Thermostate --> Zimmer --> Kindersicherung)

P.S: Great performance, the binding works perfectly

MINOR - Power consumption in-wall switch reports NULL as WH consumption

A configured in-wall switch reports back state (ON/OFF) and the current (W) however the power consumption over time (Wh) does report NULL.

Issue is not minor, only relevant for reporting/graphing

Send alarm system to BSH via openhab (use integrated alarm ton in BSH APP)

Adding of virtual Thing / Item for activation and deactivation of the alarm system / ton in the BSH APP via OepnHab.

Version 1.0 Discussion

As we talked about in several issues, we'd like to publish a first version to openHAB soon. We can use this issue to discuss what needs to be done and how the publishing progresses.

@stefan-kaestle As you are the initiator of the plugin, you should approach the devs from openHAB to ask for a roadmap for publishing a plugin. It might just be a pull request of a branch of our fork to their main repository, but maybe there is more to it.

Remove hard-coded Gateway-ID in BoschSHCBridgeHandler

It might not be necessary at all (some requests are made without it already). If it should be necessary we have to get the correct Gateway-ID instead of using one hard-coded one :)

Documentation - Which things exist, which channels do they have and which item type a channel requires

We should probably put some information somewhere which channels exists and which item type they require. This missing information was the problem in issue #26.

@GerdZanker @stefan-kaestle Is there a general way in openHAB to do this? Or is openHAB able to create this information automatically? Basically this information is already in our thing-types.xml

Key/Cert Generation and Pairing during first setup

During the first setup of teh Bosch SHC binding a KeyStore with the necessary key, cert and Bosch certs shall be created and the pairing between the Bosch SHC client and the SHC shall be executed.

If the hardware button is pressed, the Bosch SHC things are ready for usage. All manual key generation, registration, etc is done via Java code. Compare with the command line calls.

Bosch Thermostat valve nullpointer exception

I have a thermostat for my heating system configured. This is currently in summerpause, hence it is expected to be off. I am reading the current temperature and the valve position. However currently the valve is in NULL according to the paper UI, in the logs I can see the following null pointer.

2020-08-09 10:17:39.479 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - refreshState: Request complete: [{"@type":"JsonRestExceptionResponseEntity","errorCode":"ENTITY_NOT_FOUND","statusCode":404}] - return code: 404
2020-08-09 10:17:39.481 [ERROR] [ome.core.thing.link.ThingLinkManager] - Exception occurred while informing handler: null
java.lang.NullPointerException: null
at org.openhab.binding.boschshc.internal.services.valvetappet.ValveTappetServiceState.getPositionState(ValveTappetServiceState.java:33) ~[?:?]
at org.openhab.binding.boschshc.internal.thermostat.ThermostatHandler.updateChannels(ThermostatHandler.java:60) ~[?:?]
at org.openhab.binding.boschshc.internal.services.BoschSHCService.onStateUpdate(BoschSHCService.java:150) ~[?:?]
at org.openhab.binding.boschshc.internal.services.BoschSHCService.refreshState(BoschSHCService.java:108) ~[?:?]
at org.openhab.binding.boschshc.internal.BoschSHCHandler.handleCommand(BoschSHCHandler.java:122) ~[?:?]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.channelLinked(BaseThingHandler.java:191) ~[?:?]
at org.eclipse.smarthome.core.thing.link.ThingLinkManager.lambda$0(ThingLinkManager.java:267) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_252]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]

Window Contact does not show its status

@coeing Thanks! Of corse we are still interested :)

I deleted the old Beta1-.jar file (this worked fine) and insert the new beta2 file in openhab folder and reboot the complete System (RP3 with OH 2.5.9 - hope this is compatible with your 3.0 binding). I do not created a new key (pushed NOT the button on the BSH gateway again)

I got this WARN Message in the log file:
[WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.boschshc-3.0.0-SNAPSHOT.jar

I noticed an issue with the window-contact. In the log I can see when the status change, but in the "control" view (/paperui/index.html#/control) there is no status for all window-contacts. I don't know why.

here is my config:

things

Bridge boschshc:shc:1 [ ipAddress=„x.xx.x, password=„xxxxx ] {

Thing motion-detector  motion-corridor "Bewegungsmelder"      [ id="hdm:ZigBee:xxxxxxxxx“ ]

Thing twinguard tg-Wohnzimmer  "Twinguard Smoke Detector" [ id="hdm:ZigBee:xxxxxxx“ ]

Thing window-contact BSHtuer "BSH Tuer" [ id="hdm:HomeMaticIP:xxxxxxxxxxx“ ]

Thing window-contact BSHWZrechts "BSH Wohnzimmer rechts" [ id="hdm:HomeMaticIP:xxxxxxxxx7" ]

}

items:

Number TemperaturWZ "Temperatur Wohnzimmer" (gTemp){ channel="boschshc:twinguard:1:tg-Wohnzimmer:temperature" }

Contact BSHtuer "BSH Haustuer" {channel="boschshc:window-contact:1:BSHtuer:contact"}

Contact BSHWZrechts "BSH Wohnzimmertuer rechts" {channel="boschshc:window-contact:1:BSHWZrechts:contact"}

EDIT: I also found an issue with my time. Can not remember if it works fine with the old version. My motion sensor has not the same time like Openhab. There is a difference of exactly two hours. This could also be an issue because of the timezone plus summer/winter time.

2020-10-21 22:54:29.430 [vent.ItemStateChangedEvent] - Bewegungsmelder_LatestMotion changed from 2020-10-21T19:40:22.638+0000 to 2020-10-21T20:54:29.320+0000

Originally posted by @VL2019 in #14 (comment)

Create common "Service" classes that can be reused

As I already mentioned I developed some functions inside the ShutterControlHandler that might be useful for other handlers as well.

As far as I see it, the Bosch developers separated their API by "services" instead of devices, so we should probably use the same separation to have an easy time to access the API.

For example there is a service "TemperatureLevel" which is the same for the devices "Thermostat", "Wall Thermostat" and "Climate Control". It would be bad coding to duplicate the logic in multiple handlers. So I would suggest to have one handler per device/thing and those handlers access the services the device supports. The state getting and setting happens inside the services.

As I am starting with the handler for the Thermostat, I would like to try this architecture if you support the idea. If it works out well we can use this architecture for the other handlers as well :)

Put each device in an own subfolder

I already did it for the Shutter Control (shuttercontrol) and I think it would make the bundle cleaner now and when new devices arrive. I would do the refactoring but would like to hear your feedback first! :) Maybe there could be even a common parent folder "devices" to separate them from other areas, but that could also be another step later if we see that it's necessary.

Sign-off all incorrect commits

Hi there,

Creating a pull request for openHAB runs an automatic check for unsigned or incorrectly signed-off commits: https://github.com/openhab/openhab-addons/pull/8371/checks?check_run_id=1048335445

We have to fix them before our work can be merged :)

add "doHttpRequest" function to wrap the Bosch SHC Request code at one single place

Add a new request function into BoschHttpClient to make simple calls like doHttpRequest("smarthome/devices") possible.
We have at least three places in BoschSHCBridgeHandler'' where we create http requests with duplicated code parts which can be replaced by the `´doHttpRequest function.

Here an example

public ContentResponse doHttpRequest(String restData) throws InterruptedException, TimeoutException, ExecutionException {
return GET("https://" + m_ipAddress + ":8444/" + restData)
.header("Content-Type", "application/json").header("Accept", "application/json")
.send();
}

Add support for Home Connect dryers

It would be great if Home Connect dryers like the BOSCH-WTYH7701 would be supported.

2021-01-01 10:31:53.026 [INFO ] [devices.bridge.BoschSHCBridgeHandler] - Found device: name=Trockner id=hdm:homeconnect:BOSCH-WTYH7701-68A40EXXXXXX

Exception logged when device is initialized

Every time the binding is initialized (and with it the devices), I get an error inside the openhab.log:

2020-06-15 18:33:57.635 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - refreshState: HTTP request failed: {}
java.util.concurrent.ExecutionException: java.net.SocketTimeoutException: Concurrent Connect Timeout
	at org.eclipse.jetty.client.util.FutureResponseListener.getResult(FutureResponseListener.java:118) ~[?:?]
	at org.eclipse.jetty.client.util.FutureResponseListener.get(FutureResponseListener.java:101) ~[?:?]
	at org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:685) ~[?:?]
	at org.openhab.binding.boschshc.internal.BoschSHCBridgeHandler.refreshState(BoschSHCBridgeHandler.java:525) ~[?:?]
	at org.openhab.binding.boschshc.internal.shuttercontrol.ShutterControlHandler.getDeviceState(ShutterControlHandler.java:106) ~[?:?]
	at org.openhab.binding.boschshc.internal.shuttercontrol.ShutterControlHandler.handleCommand(ShutterControlHandler.java:53) ~[?:?]
	at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.channelLinked(BaseThingHandler.java:191) ~[?:?]
	at org.eclipse.smarthome.core.thing.link.ThingLinkManager.lambda$0(ThingLinkManager.java:267) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_232]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_232]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_232]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:1.8.0_232]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_232]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_232]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_232]
Caused by: java.net.SocketTimeoutException: Concurrent Connect Timeout
	at org.eclipse.jetty.io.ManagedSelector.processConnect(ManagedSelector.java:235) ~[?:?]
	at org.eclipse.jetty.io.ManagedSelector.access$1500(ManagedSelector.java:61) ~[?:?]
	at org.eclipse.jetty.io.ManagedSelector$SelectorProducer.processSelected(ManagedSelector.java:533) ~[?:?]
	at org.eclipse.jetty.io.ManagedSelector$SelectorProducer.produce(ManagedSelector.java:395) ~[?:?]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produceTask(EatWhatYouKill.java:360) ~[?:?]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:184) ~[?:?]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) ~[?:?]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:135) ~[?:?]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:782) ~[?:?]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:918) ~[?:?]
	... 1 more

First question would be: Does it only happen for my Shutter Control device due to my ShutterControlHandler? Or is it a general problem?

Where to initially set IP, PW and Keystore

Where is the configuration required for the initial connection between Addon and Bosch Smart Home controller?

The readme outlines, that the IP, PW and KeyStore File location needs to be set. However the UI remains empty when clicking on the binding and I dont see a config file - template - in the services folder in openhab.

From the readme I take this has to be in the thing file, however at least there is no reference to a password that needs to be entered.

Enhance robustness of TwinGuard measurment handling on weak wireless connections

I have a SHC with 5 TwinGuards connected. One of the TwinGuards has better and worse days in regards of the wireless connection to the gateway. In the official Bosch Smart Home app the reading during a wacky connection will look like this:

In OpenHAB it will look like this:

The good: There seems to be more valid data than the Bosch Smart Home app shows.

The bad: OpenHAB receives bad data the Bosch Smart Home app is able to filter out.

It would be great if the binding could also filter out the bad data.

Only use one Gson instance per object instead of creating new ones for each call

Due to the official GSON user guide, the object does not store any state and can be used for multiple serializations/deserializations: https://sites.google.com/site/gson/gson-user-guide#TOC-Using-Gson

Discover Bosch SHC devices automatically

As discussed in #5 we should aim for an auto discovery of the devices, so our users don't have to dig for the device IDs inside the openHAB logs.

Readme.md - Outdated paragraph "Binding Configuration"

From the Readme.md:

Bosch IDs for devices are displayed in the OpenHab log on bootup.

Bridge boschshc:shc:1 [ ipAddress="192.168.x.y" ] {
  Thing in-wall-switch bathroom "Bathroom" [ id="hdm:HomeMaticIP:3014F711A000XXXXXXXXXXXX" ]
  Thing in-wall-switch bedroom "Bedroom" [ id="hdm:HomeMaticIP:3014F711A000XXXXXXXXXXXX" ]
  Thing in-wall-switch kitchen "Kitchen" [ id="hdm:HomeMaticIP:3014F711A000XXXXXXXXXXXX" ]
  Thing in-wall-switch corridor "Corridor" [ id="hdm:HomeMaticIP:3014F711A000XXXXXXXXXXXX" ]
  Thing in-wall-switch livingroom "Living Room" [ id="hdm:HomeMaticIP:3014F711A000XXXXXXXXXXXX" ]

  Thing in-wall-switch coffeemachine "Coffee Machine" [ id="hdm:HomeMaticIP:3014F711A0000XXXXXXXXXXXX" ]

  Thing twinguard      tg-corridor    "Twinguard Smoke Detector" [ id="hdm:ZigBee:000d6f000XXXXXXX" ]
  Thing window-contact window-kitchen "Window Kitchen"           [ id="hdm:HomeMaticIP:3014F711A00000XXXXXXXXXX" ]
  Thing window-contact entrance       "Entrance door"            [ id="hdm:HomeMaticIP:3014F711A00000XXXXXXXXXX" ]

  Thing motion-detector  motion-corridor "Bewegungsmelder"      [ id="hdm:ZigBee:000d6f000XXXXXXX" ]
}

Not sure about this, but in my openHAB log the logs look like this:

2020-06-15 18:18:39.788 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - Found device: name=Rollladen id=hdm:HomeMaticIP:3014F711A00018D6D859A52C
2020-06-15 18:18:39.790 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - Found device: name=-RoomClimateControl- id=roomClimateControl_hz_6
2020-06-15 18:18:39.791 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - Found device: name=Rollladen id=hdm:HomeMaticIP:3014F711A00018D6D859A3C4
2020-06-15 18:18:39.792 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - Found device: name=Central Heating id=hdm:ICom:819410185

run.sh still required?

I just stumbled upon the "run.sh" file in the root folder of our bundle. Is that script still required? If not we should throw it out :)

Prevent creation of Thing without assigning a parent bridge

Right now (v1.0-beta.5) it is possible to create a Thing (e.g. TwinGuard) without assigning a parent bridge.

It would be great if there was no parent bridge selected and the user presses the Create Thing button an error text would be shown and the Parent Bridge field would be highlighted.

I systematically forgot to assign the parent bridge to most of my five TwinGuards when setting them up. For most I quickly found the problem because the Thing went from online to offline quickly. But one stayed online (for unknown reasons) but did not receive measurements. Finally I realized that the bridge was missing.

Additional information for README.md

Hi, @coeing
if you want to you can add samples from my configuration with two thermostats, a twinguard and the window contact to the samples. Covers a few things not yet included in the Readme, all available channels for each item linked to items

They belong all to the same room in the Controller configuration and thus only have one climate control. The items belong to groups to store data in the influxdb and visualization in Grafana

Things

  Thing window-contact  balkontuer       "Balkontuer"            [ id="hdm:HomeMaticIP:3014F711A000009A185AB854" ]
  Thing thermostat      heizung1         "Heizung WZ 1" [id="hdm:HomeMaticIP:3014F711A000005A185BB182" ]
  Thing thermostat      heizungwz2       "Heizung WZ 2" [id="hdm:HomeMaticIP:3014F711A000005A185B5576"]
  Thing twinguard       twinguardWZ      "Twinguard WZ" [id="hdm:ZigBee:000d6f000efb849f" ]
  Thing climate-control ccwohnzimmer     "CC Wohnzimmer" [id="roomClimateControl_hz_6" ]

Items

Group gSHC
Group gSHCSet
Group Wohnung
Group Wohnzimmer ( Wohnung)
Contact SHC_Balkontuer       "Balkontür [MAP(SHCKontakt.map):%s]"  ( gSHC )      { channel="boschshc:window-contact:65561fa0:balkontuer:contact" }
Number SHC_TempWZ1			"[%.1f] °C" <temperature>  (Wohnzimmer,gSHC) { channel="boschshc:thermostat:65561fa0:heizung1:temperature" }
Number SHC_ValvWZ1          "Valv Pos WZ1" (Wohnzimmer,gSHC) { channel="boschshc:thermostat:65561fa0:heizung1:valve-tappet-position" }
Number SHC_TempWZ2          "[%.1f] °C" <temperature>  (Wohnzimmer,gSHC) {channel="boschshc:thermostat:65561fa0:heizungwz2:temperature"}
Number SHC_ValvWZ2          "Valv Pos WZ2" (Wohnzimmer,gSHC) { channel="boschshc:thermostat:65561fa0:heizungwz2:valve-tappet-position" }
Number SHC_TempWZTG1        "[%.1f] °C" <temperature> (Wohnzimmer,gSHC) { channel="boschshc:twinguard:65561fa0:twinguardWZ:temperature" }
String SHC_TempRating       "Rating [%s]" (Wohnzimmer,gSHC) { channel="boschshc:twinguard:65561fa0:twinguardWZ:temperature-rating" }
Number SHC_Humidity         "[%.1f] %%" (Wohnzimmer,gSHC) { channel="boschshc:twinguard:65561fa0:twinguardWZ:humidity"}   
String SHC_HumRating        "Rating [%s]" (Wohnzimmer,gSHC) { channel="boschshc:twinguard:65561fa0:twinguardWZ:humidity-rating" }
Number SHC_Purity           "[%d] ppm" (Wohnzimmer,gSHC) {  channel="boschshc:twinguard:65561fa0:twinguardWZ:purity"}
String SHC_AirDescripton    "Desc [%s]" ( Wohnzimmer,gSHC) { channel="boschshc:twinguard:65561fa0:twinguardWZ:air-description" }
String SHC_PurRating        "Rating [%s]" ( Wohnzimmer,gSHC) { channel="boschshc:twinguard:65561fa0:twinguardWZ:purity-rating" }
String SHC_CombRating       "Rating [%s]" (Wohnzimmer,gSHC) { channel="boschshc:twinguard:65561fa0:twinguardWZ:combined-rating" }
Number SHC_CCWZ1Set         "[%.1f] °C" <temperature> (Wohnzimmer,gSHCSet) { channel="boschshc:climate-control:65561fa0:ccwohnzimmer:setpoint-temperature"}
Number SHC_CCWZ1Now         "[%.1f] °C" <temperature> (Wohnzimmer) { channel="boschshc:climate-control:65561fa0:ccwohnzimmer:temperature"}

Originally posted by @armin-gh in https://github.com/stefan-kaestle/openhab2-addons/issue_comments/704507191

Use without bridge but only with Thermostat and some Valves

Hi,

I need to connect to openHAB my Thermostat and some Bosch Valves. The Thermostat is connected to home wlan and has an IP address.
There is a possibility to use it without the bridge?

Thanks a lot

After 24h no Temprature update with Climate Control

Hello,

i have the Beta 5 release addon running.
My BSH Gateway thing says it is online and my five ClimateControl things are online.
After i add the BSH Thing all works fine.
The setpoint_temprature and temprature Item become a automatics updates. After i change the value in the Bosch App the setpoint item in OH change his value under one second.
After 24h i can change a value and wait for temprature updates but nothing happen.

When i pause the BSH Thing and start it again i can change the values in the Bosch app and all works fine for 24 hours.
I made this yesterday and today. In my Log is no error. Yesterday i made the resart at 13:00 today at 14:00. I thing tomorrow at 14:00 i will get no updates.

I am from north of Hamburg. I can describe this better in German when you want.

Jörg

POM error during Travis build

https://travis-ci.com/github/openhab/openhab-addons/jobs/379252414

@GerdZanker Maybe you can have a look at this? You seemed to be the most experienced of us for that file :) You can probably ask for help in the pull request if you don't see the issue immediately.

Refactor code to follow official openHAB guidelines

The guidelines are here: https://www.openhab.org/docs/developer/guidelines.html

We should follow them as closely as possible.

Here are some first TODOs:

• Add correct Null Annotations (https://www.openhab.org/docs/developer/guidelines.html#null-annotations)
• Check logger usages (https://www.openhab.org/docs/developer/guidelines.html#f-logging)
• Add documentation for all classes & methods (https://www.openhab.org/docs/developer/guidelines.html#c-documentation)
• Run Spotless Maven Plugin to format code (https://www.openhab.org/docs/developer/guidelines.html#code-format)
• Format XML files correctly (https://www.openhab.org/docs/developer/guidelines.html#xml-files)
• Every Java file must have a license header. You can run mvn license:format on the root of the repo to automatically add missing headers.

Support for Thermostats

As I have two at home, I'd like to add a handler for them to the binding.

The Bosch API can be found here:
https://apidocs.bosch-smarthome.com/local/index.html (Select a definition: Thermostat)

As the official API doesn't have endpoints to change the state of the device, the first version of the handler will contain:

• Providing the temperature measured at the device
• Providing the valve tappet position of the device

I will also open an issue in the official Bosch API repository https://github.com/BoschSmartHome/bosch-shc-api-docs to ask for the current state of the Thermostat API. Maybe there are more functions which are not documented yet or they are coming soon. As the devices can be controlled by other apps, chances are that they have all the functionality already.

OFFLINE COMMUNICATION_ERROR - Bosch Window/Door Contact

Hi guys,

after paring of BSH Controller, i tried to add the window/door contacts. I get the following error message: OFFLINE COMMUNICATION_ERROR

Item definition:
Contact Sensor_Eingangstuer_Status "Sensor Eingangstür" (Flur) {channel="boschshc:window-contact:851459af:contact"}

Log (despite error message):
2020-08-09 00:23:25.778 [INFO ] [chshc.internal.BoschSHCBridgeHandler] - Got update for hdm:HomeMaticIP:3014F711A000009A18592258
2020-08-09 00:23:25.779 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - longPoll: child handler for null does not implement Bosch SHC handler

Result:
no status is transferred

Do you have any idea how to fix this?
Thanks in advance.

boschshc: Add support for roomLightControl in 2.0

Currently in-wall-switches are already supported. I would like to see in future versions as an enhancement also support for its parent: The roomLightControl service controls all light items assigned to a given room in Bosch SHC. There is only one channel for operation.

The device is already successfully detected in the current version.

[INFO ] [devices.bridge.BoschSHCBridgeHandler] - Found device: name=RoomLightControl id=roomLightControl_hz_5

The relevant device path is (for example in room hz_5 as above):
/devices/roomLightControl_hz_5/services/BinarySwitch/state

Output in REST API (when all lights are off):

{
    "@type": "binarySwitchState",
    "on": false
}

"true" turns all lights on.

Pre-Release for external testers

As we are working on the first release it might be a good time to invite some external testers to check out our binding so we might get some reports for bugs we haven't found yet.

One interested person already ask to test it: https://community.openhab.org/t/will-there-be-a-bosch-smart-home-binding/8910/81

Could we add a binary as a GitHub release in this repository? I don't see the tab here yet, but maybe it just has to be activated in the settings by the repository owner @stefan-kaestle ? :) I remember that the issue tracker was also off by default.

Add shutter control write

Currently the shutter control offers the read function of the current position in numeric value that I convert into %.

If shutters shall be controller a corresponding set function is required. At least querying the interface did not lead to a successful movement for my shutters.

Unify names of handlers by removing Bosch prefix

Control of the BSH radiator thermostats

Hi Bosch heroes :-)

for some reason I can't chenge the radiator controls and for my radiator in living room (its look so that)i received 2 IDs.

Hire my customizing:
Things:

       Thing thermostat Thermostat_W "Heizkörper Wohnzimmer"   [ id="roomClimateControl_hz_1" ]
       Thing thermostat Thermostat_X "Heizkörper X"   [ id="hdm:HomeMaticIP:3014F711A00000XXXXXXXXXX" ] // double Entrie, implemented for testing

Items:

       Number      Thermostat_W_Ist       "Ist Termperatur"   <temperature>      (Wohnzimmer)        {channel="boschshc:thermostat:1:Thermostat_W:temperature"}
       Number      Thermostat_W_Soll      "Soll Temperatur"   <radiator>         (Wohnzimmer)        {channel="boschshc:thermostat:1:Thermostat_W:valve-tappet-position"}

        Number      Thermostat_X_Ist       "Ist Termperatur"   <temperature>      (Wohnzimmer)        {channel="boschshc:thermostat:1:Thermostat_X:temperature"}
        Number      Thermostat_X_Soll      "Soll Temperatur"   <radiator>         (Wohnzimmer)        {channel="boschshc:thermostat:1:Thermostat_X:valve-tappet-position"}

Sitemap:

         Text item=Thermostat_W_Ist label="Ist Temperatur" icon="radiator"
         Slider item=Thermostat_W_Soll label="Soll Temperatur" icon="radiator"
                        
         Text item=Thermostat_X_Ist label="Ist TemperaturX" icon="radiator"
         Slider item=Thermostat_X_Soll label="Soll TemperaturX" icon="radiator"

By change of temperature in sideman recipe following Log:

         2020-08-13 15:03:20.769 [ome.event.ItemCommandEvent] - Item 'Thermostat_W_Soll' received command 23
         2020-08-13 15:03:20.776 [nt.ItemStatePredictedEvent] - Thermostat_W_Soll predicted to become 23
         2020-08-13 15:03:20.806 [vent.ItemStateChangedEvent] - Thermostat_W_Soll changed from 24 to 23

          2020-08-13 15:03:58.634 [ome.event.ItemCommandEvent] - Item 'Thermostat_X_Soll' received command 12
          2020-08-13 15:03:58.637 [nt.ItemStatePredictedEvent] - Thermostat_X_Soll predicted to become 12
          2020-08-13 15:03:58.656 [vent.ItemStateChangedEvent] - Thermostat_X_Soll changed from 13 to 12

This does not change the thermostat values.

In case of change of values in BSH APP I receive following log:

           2020-08-13 15:06:43.630 [INFO ] [chshc.internal.BoschSHCBridgeHandler] - Got update for roomClimateControl_hz_1
           2020-08-13 15:06:43.633 [INFO ] [chshc.internal.BoschSHCBridgeHandler] - Found child: org.openhab.binding.boschshc.internal.thermostat.ThermostatHandler@1973e55 - calling processUpdate with {"schedule":{"profiles":[{"switchPoints":[{"startTimeMinutes":0,"value":{"@type":"temperatureLevelSwitchPointValue","temperatureLevel":"COMFORT"}},{"startTimeMinutes":1390,"value":{"@type":"temperatureLevelSwitchPointValue","temperatureLevel":"ECO"}}],"day":"MONDAY"},{"switchPoints":[{"startTimeMinutes":0,"value":{"@type":"temperatureLevelSwitchPointValue","temperatureLevel":"COMFORT"}},{"startTimeMinutes":1390,"value":{"@type":"temperatureLevelSwitchPointValue","temperatureLevel":"ECO"}}],"day":"TUESDAY"},{"switchPoints":[{"startTimeMinutes":0,"value":{"@type":"temperatureLevelSwitchPointValue","temperatureLevel":"COMFORT"}},{"startTimeMinutes":1390,"value":{"@type":"temperatureLevelSwitchPointValue","temperatureLevel":"ECO"}}],"day":"WEDNESDAY"},{"switchPoints":[{"startTimeMinutes":0,"value":{"@type":"temperatureLevelSwitchPointValue","temperatureLevel":"COMFORT"}},{"startTimeMinutes":1390,"value":{"@type":"temperatureLevelSwitchPointValue","temperatureLevel":"ECO"}}],"day":"THURSDAY"},{"switchPoints":[{"startTimeMinutes":0,"value":{"@type":"temperatureLevelSwitchPointValue","temperatureLevel":"COMFORT"}},{"startTimeMinutes":1390,"value":{"@type":"temperatureLevelSwitchPointValue","temperatureLevel":"ECO"}}],"day":"FRIDAY"},{"switchPoints":[{"startTimeMinutes":0,"value":{"@type":"temperatureLevelSwitchPointValue","temperatureLevel":"COMFORT"}},{"startTimeMinutes":1390,"value":{"@type":"temperatureLevelSwitchPointValue","temperatureLevel":"ECO"}}],"day":"SATURDAY"},{"switchPoints":[{"startTimeMinutes":0,"value":{"@type":"temperatureLevelSwitchPointValue","temperatureLevel":"COMFORT"}},{"startTimeMinutes":1390,"value":{"@type":"temperatureLevelSwitchPointValue","temperatureLevel":"ECO"}}],"day":"SUNDAY"}]},"operationMode":"MANUAL","summerMode":false,"showSetpointTemperature":false,"low":false,"@type":"climateControlState","setpointTemperature":5.5,"setpointTemperatureForLevelEco":5,"setpointTemperatureForLevelComfort":21,"ventilationMode":false,"boostMode":false,"supportsBoostMode":true}
           2020-08-13 15:06:43.631 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - longPoll: child handler for org.openhab.binding.boschshc.internal.WindowContactHandler@18be3df does not implement Bosch SHC handler
           2020-08-13 15:06:43.635 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - longPoll: child handler for org.openhab.binding.boschshc.internal.WindowContactHandler@a09ea8 does not implement Bosch SHC handler
           2020-08-13 15:06:43.636 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - longPoll: child handler for org.openhab.binding.boschshc.internal.WindowContactHandler@14ea307 does not implement Bosch SHC handler
           2020-08-13 15:06:43.637 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - longPoll: child handler for org.openhab.binding.boschshc.internal.thermostat.ThermostatHandler@1973e55 does not implement Bosch SHC handler
           2020-08-13 15:06:43.639 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - longPoll: child handler for org.openhab.binding.boschshc.internal.thermostat.ThermostatHandler@8c6d61 does not implement Bosch SHC handler
           2020-08-13 15:06:43.640 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - longPoll: child handler for org.openhab.binding.boschshc.internal.thermostat.ThermostatHandler@15a6677 does not implement Bosch SHC handler
           2020-08-13 15:06:43.641 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - longPoll: child handler for org.openhab.binding.boschshc.internal.thermostat.ThermostatHandler@143d113 does not implement Bosch SHC handler
           2020-08-13 15:06:43.642 [INFO ] [chshc.internal.BoschSHCBridgeHandler] - Could not find a thing for device ID: roomClimateControl_hz_1
           2020-08-13 15:06:45.120 [INFO ] [chshc.internal.BoschSHCBridgeHandler] - Got update for hdm:HomeMaticIP: 3014F711A00000XXXXXXXXXX
           2020-08-13 15:06:45.121 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - longPoll: child handler for org.openhab.binding.boschshc.internal.WindowContactHandler@10c7ed9 does not implement Bosch SHC handler
           2020-08-13 15:06:45.122 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - longPoll: child handler for org.openhab.binding.boschshc.internal.WindowContactHandler@18be3df does not implement Bosch SHC handler
           2020-08-13 15:06:45.123 [INFO ] [chshc.internal.BoschSHCBridgeHandler] - Got update for hdm:HomeMaticIP: 3014F711A00000XXXXXXXXXX
           2020-08-13 15:06:45.124 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - longPoll: child handler for org.openhab.binding.boschshc.internal.WindowContactHandler@a09ea8 does not implement Bosch SHC handler
           2020-08-13 15:06:45.124 [INFO ] [chshc.internal.BoschSHCBridgeHandler] - Found child: org.openhab.binding.boschshc.internal.thermostat.ThermostatHandler@143d113 - calling processUpdate with {"@type":"childLockState","childLock":"ON"}
           2020-08-13 15:06:45.125 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - longPoll: child handler for org.openhab.binding.boschshc.internal.WindowContactHandler@14ea307 does not implement Bosch SHC handler
           2020-08-13 15:06:45.126 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - longPoll: child handler for org.openhab.binding.boschshc.internal.thermostat.ThermostatHandler@1973e55 does not implement Bosch SHC handler
           2020-08-13 15:06:45.127 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - longPoll: child handler for org.openhab.binding.boschshc.internal.thermostat.ThermostatHandler@8c6d61 does not implement Bosch SHC handler
           2020-08-13 15:06:45.129 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - longPoll: child handler for org.openhab.binding.boschshc.internal.thermostat.ThermostatHandler@15a6677 does not implement Bosch SHC handler
           2020-08-13 15:06:45.130 [WARN ] [chshc.internal.BoschSHCBridgeHandler] - longPoll: child handler for org.openhab.binding.boschshc.internal.thermostat.ThermostatHandler@143d113 does not implement Bosch SHC handler
           2020-08-13 15:06:45.131 [INFO ] [chshc.internal.BoschSHCBridgeHandler] - Could not find a thing for device ID: hdm:HomeMaticIP: 3014F711A00000XXXXXXXXXX

Changes will't be replicated to openhab...
I'm definitely doing something wrong :-(

Thanks in advance!

Use new service architecture in all device handlers

As some devices share the same functionality, we introduced service classes which implement setting and getting the state of a specific service of a device (e.g. temperature level, room climate control, valve tappet,...).

This architecture should be used by all device handlers that derive from BoschSHCHandler. The existing handlers should be refactored to reflect this architecture.

These handlers already use the new architecture:

• ClimateControlHandler
• ThermostatHandler
• WindowContactHandler
• ShutterControlHandler
• InWallSwitchHandler (in part)

Handle change of Home Controller system password correctly

A change of SHC "system password" is an issue and happening also during initial setup of the binding e.g. if the wrong password was used instead of the App password.

See also comments in openhabCommunity.

The current solution is to delete the /etc/oss_openhab_binding_*.jks file in your openhab installation because the binding will recreate the jks file.

TODO from BoschSslUtil.java:

                // TODO if SHC system password is changed the keystore can't be loaded and an IOException "... password
                // was incorrect" is thrown
                // Either use a different secret instead of the system password (e.g. openHAB UUID?)
                // or recreate a new keystore with the different system password again (needs pairing)

---

In the meantime the initial pull request is discussed and from comments we can use "reference" code from openhab core how certificate handling is done there.
See CertificateGenerator.java and the generateCertificate() function how the password, and self singed cert creation is done.

With this reference we should get rid of password problems, by using a single fixed password ins the code and avoid at least the bcprov-jdk15on bundle dependency, which increases the jar size a lot.

Set Thermostat Value

Hi Guys,

some question to be a sure, that my settings are right (or wrong) :-):

BSH Thermostate Thing:

//Heizregler
    Thing thermostat Thermostat_W       "Heizkörper Wohnzimmer"           [ id="hdm:HomeMaticIP:3014F711A0000056D85895E8" ]
    Thing climate-control Climate_W     "Temperaturregelung Wohnzimmer"   [ id="roomClimateControl_hz_1" ]

BSH Thermostate Items:

//Heizregler
Number      Thermostat_W_Ist       "Ist Termperatur Wohnzimmer"     <temperature>      (Wohnzimmer)             {channel="boschshc:thermostat:1:Thermostat_W:temperature"}
Number      Thermostat_W_Soll      "Soll Temperatur Wohnzimmer"     <radiator>         (Wohnzimmer)             {channel="boschshc:thermostat:1:Thermostat_W:valve-tappet-position"}
Number      Climate_W_Ist          "Ist Termperatur Wohnzimmer"     <temperature>      (Wohnzimmer)             {channel="boschshc:climate-control:1:Climate_W:temperature"}
Number      Climate_W_Soll         "Soll Temperatur Wohnzimmer"     <radiator>         (Wohnzimmer)             {channel="boschshc:climate-control:1:Climate_W:setpoint-temperature"}

BSH Thermostate Rules:

rule "Heizungsregelung Wohnzimmer Temperaturabhängig"
when
    Item Heizugsregelung_rolle changed or 
    Item Sommerpause changed or 
    Item Abwesenheit changed or 
    Item Contact_W changed or 
    Item W_Temperature changed or
    Item Climate_W_Soll changed or
    Time cron "0 0 6,10,14,23 ? * * *" 
then
//logInfo("Bedingungen für die Rolle werden überprüft")
        // Abwesenheitsstatus ist deaktiviert, Sommerpause für Heizungssteuerung ist deaktiviert, Heizungsregelungsrolle ist aktiviert, Balkontür im Wohnzimmer ist zu
    if (Heizugsregelung_rolle.state == ON && Sommerpause.state == OFF && Abwesenheit.state == OFF && Contact_W.state == CLOSED) {
        if ((day <= 7) && (((hour >= 6) && (hour <= 14)) || ((hour <=14) && (hour <= 23)))) {
            **Climate_W_Soll.sendCommand("21.5")**
        }
        else {
            **Climate_W_Soll.sendCommand("17")**
        }
    }
    else {
        **Climate_W_Soll.sendCommand("5")**
    }
end

do I manage right the temperature Value, or I need to add some additional BSH Items (Thermostat_W_Soll) to set and hold the right value at my thermostat?
Sorry for beginner question :-)
Thanks in advance

Fix code analysis errors

https://travis-ci.com/github/openhab/openhab-addons/jobs/379580919

Detect incorrect device ID instead of showing the thing as "Online"

Right now any configured thing that has a bridge is shown as "Online", even if the specified device id is invalid (any string possible). We should do a test request to the controller on initialization to check if a device with this ID exists. It might be enough to do this only when the device ID was first set or changed, but as a first step I would do it on each initialization. This can be implemented in the base class BoschSHCBridgeHandler

Discover Bosch Home Controller Bridge automatically

Would it be possible to discover the IP address automatically? If not we could add a link to the official Bosch support page which describes how to find out the IP: https://www.bosch-smarthome.com/de/de/service/bei-der-erstinstallation-werde-ich-nach-der-ip-adresse-des-shc-gefragt

We could ask in the Bosch GitHub repository (https://github.com/BoschSmartHome/bosch-shc-api-docs) how an automatic discovery could be done. The official Bosch Smart Home app does it as well, so it might be possible: https://tt-smarthome.resource.bosch.com/documents/Manual/UK/System_Solutions/Controller_EN_161109_web.pdf

Feedback from @GerdZanker :

The SHC returns public information without pairing.
If we assume that both - SHC and OpenHAB - have IPs in the same network it should be possible find with a simple try & error approach.
I suggest to add/implement this later, after this PR, via a SHC bridge discovery service.