[boschshc] Add command to list SHC device mappings

[GerdZanker]

Added command to list SHC devices and mapping to openhab devices and related services.

The new console command lists Bosch SHC devices and openhab support.
Uses the SHC API to get all SHC devices and SHC services and tries to lookup openhab devices and implemented service classes.

The command should help to get an overview what devices are supported, see #14672.
The implementation uses pull request #13615 as example to start.

[GerdZanker]

Hello @david-pace,
I tried to use an algorithm to get an overview what devices are support and what is missing in our boschshc implementation.
This is just a draft for discussion if the output can help for future development.
Currently is only the commandline code without tests or further cleanup.
But I'm interested about what you think and if it can help to get check for missing services.

[GerdZanker]

Example output of my openhab installation

openhab> boschshc showIds
thing: Bosch Smart Home Controller (192.168.x.x)
  thingHandler: org.openhab.binding.boschshc.internal.devices.bridge.BridgeHandler
bridge access possible: true
devices (61):
  device: hdm:Cameras:4b6e...
	type: CAMERA_EYES -> security-camera-eyes
		  services: CameraLight -> !UNSUPPORTED!
		  services: CameraNotification -> cameranotification
  device: roomClimateContr...
	type: ROOM_CLIMATE_CONTROL -> climate-control
		  services: TemperatureLevelConfiguration -> !UNSUPPORTED!
		  services: ThermostatSupportedControlMode -> !UNSUPPORTED!
		  services: RoomClimateControl -> roomclimatecontrol
		  services: TemperatureLevel -> temperaturelevel

[mike-bike]

I'd love to see that command available in open hab - maybe 4.0.0M4?
I do have the Lightswitch/Shuttercontrol II relais. I do see Unknown deviceModel MICROMODULE_LIGHT_CONTROL, 2 x MICROMODULE_LIGHT_ATTACHED during rnal.discovery.ThingDiscoveryService.
I'd assume the device behaves either like 2 Wall Switches or 1 Shutter Control. You need to define the function during training. Let me know were I could download a trial version of the binding and I am happy to test.
Keep up with the great work. Happy sunny weekend!

[david-pace]

Hi @GerdZanker, thank you for implementing this very useful command 👍 I tested it successfully and I have the following questions and ideas:

• What is the background that the device IDs are abbreviated? Is this for security purposes? If so, I guess the well-known system services such as smokeDetectionSystem do not have to be abbreviated (it shows smokeDetectionSy..., same for roomClimateContr... in your example). Furthermore, in most cases users need the complete ID, e.g. for copying it to a thing configuration. In this case it might not be useful to abbreviate them.
• Would it make sense to change services: to service:?
• Could we change device: to device ID:, or indicate that a device ID follows in some other way?
• Since the command does not show only IDs but also device types, names and services, maybe another command name would be better. Maybe something in the direction listDevices or listDeviceServices or listServices? Are there any conventions in openHAB already? Do we know other bindings that provide such a command? Which command name do the others use?

[GerdZanker]

Hi @GerdZanker, thank you for implementing this very useful command 👍 I tested it successfully ...

Thanks for this positive feedback!
Then I will continue and bring this first code into a merge-able state.

• What is the background that the device IDs are abbreviated? Is this for security purposes? If so, I guess the well-known system services such as smokeDetectionSystem do not have to be abbreviated (it shows smokeDetectionSy..., same for roomClimateContr... in your example). Furthermore, in most cases users need the complete ID, e.g. for copying it to a thing configuration. In this case it might not be useful to abbreviate them.

Yes, I tried to only share anonimized data in my example. Of cause this must not be part of final code and is removed now.

• Would it make sense to change services: to service:?

done

• Could we change device: to device ID:, or indicate that a device ID follows in some other way?

changed

• Since the command does not show only IDs but also device types, names and services, maybe another command name would be better. Maybe something in the direction listDevices or listDeviceServices or listServices? Are there any conventions in openHAB already? Do we know other bindings that provide such a command? Which command name do the others use?

Command names changed and new commands added.
I will also look if I can find a naming pattern in other bindings.

[GerdZanker]

Hello @mike-bike,

I'm happy to read your comment and your feedback and details about the new relais is welcome.

Let me know were I could download a trial version of the binding and I am happy to test. Keep up with the great work. Happy sunny weekend!

I attach a built and zipped jar from commit [3df4994] based on the openhab 4.0.0-SNAPSHOT sources.

It would be great if you can test the command and also report the device ID of the new relais hardware and the reported services it supports. Then I get feedback about the commands and we can immediately use the output to support new devices.

[mike-bike]

Hi Gerd, many thanks for the jar. I will try it tomorrow as time permits. I am currently using M3. Hope I am not breaking my installation. I am not that firm with karaf and loading / unloading new bindings. Better take a backup before. However, no risk, no fun :-) I will let you now the results soon. Kind regards Michael

…

Am 12.06.2023 um 21:37 schrieb Gerd Zanker ***@***.***>: Hello @mike-bike <https://github.com/mike-bike>, I'm happy to read your comment and your feedback and details about the new relais is welcome. Let me know were I could download a trial version of the binding and I am happy to test. Keep up with the great work. Happy sunny weekend! I attach a built and zipped jar <https://github.com/openhab/openhab-addons/files/11727599/org.openhab.binding.boschshc-4.0.0-SNAPSHOT-20230612.jar.zip> from commit [3df4994 <3df4994>] based on the openhab 4.0.0-SNAPSHOT sources. It would be great if you can test the command and also report the device ID of the new relais hardware and the reported services it supports. Then I get feedback about the commands and we can immediately use the output to support new devices. — Reply to this email directly, view it on GitHub <#15060 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHVH7GA6AFNLAIWENR3MTHTXK5VYPANCNFSM6AAAAAAY7O3F7Y>. You are receiving this because you were mentioned.

[mike-bike]

Hi Gerd,

I managed to load the snapshot version of the boschshc binding.

openhab> list -s | grep bosch
236 │ Active │  80 │ 4.0.0.202306121923     │ org.openhab.binding.boschshc

boschshc deviceInfo shows below for the Switch/Shutter Control II (defined as light switches) below:

# Light Switch II Device - not visible as Thing in Paper UI
  deviceID: hdm:ZigBee:70ac08fffefead2d
      type: MICROMODULE_LIGHT_CONTROL -> !UNSUPPORTED!
            service: CommunicationQuality -> !UNSUPPORTED!
            service: PowerMeter -> powermeter
            service: ElectricalFaults -> !UNSUPPORTED!
            service: SwitchConfiguration -> !UNSUPPORTED!

# Light Switch II (2) - configured as a Thing
  deviceID: hdm:ZigBee:70ac08fffefead2d#3
      type: MICROMODULE_LIGHT_ATTACHED -> !UNSUPPORTED!
            service: PowerSwitch -> powerswitch
            service: ChildProtection -> !UNSUPPORTED!
            service: PowerSwitchProgram -> !UNSUPPORTED!

# Light Switch II (1) - configured as a Thing
  deviceID: hdm:ZigBee:70ac08fffefead2d#2
      type: MICROMODULE_LIGHT_ATTACHED -> !UNSUPPORTED!
            service: PowerSwitch -> powerswitch
            service: ChildProtection -> !UNSUPPORTED!
            service: PowerSwitchProgram -> !UNSUPPORTED!

I have created 2 Things with type Wall-Switch. PowerSwitch seem to work partially, but not reliably. Please note, that the Bosch App shows PowerMeter data for both switches separately. I'd assume data to be available.

For reference, see below a classic Bosch Wall-Switch

  deviceID: hdm:HomeMaticIP:3014F711A000191BB8596C35
      type: BSM -> in-wall-switch
            service: PowerMeter -> powermeter
            service: PowerSwitch -> powerswitch
            service: PowerSwitchProgram -> !UNSUPPORTED!

Unfortunately, a garden light has grilled the second device which I planned to configure as Shutter Control. I am waiting for a replacement to do the same.

Some other observations I’d like to share:

1. I do have two bridges defined. boschshc deviceInfo enumerates all devices by bridge. However, boschshc bridgeInfo only returns one (the first?) bridge. Is there a way to get info of the other bridge?
2. What is the use case of boschshc supporting HUE lights? There is a native HUE binding available for HUE devices. I’d appreciate boschshc supporting Bosch Smarthome Rooms and Scenes (Bosch bridge will then connect to HUE/others as needed), but HUE support in boschshc I am not seeing the benefit.

Please advise if you want me to perform further analysis.

Regards,
Michael

[GerdZanker]

Hello @mike-bike ,

wow what a detailed test result. Thanks a lot Michael!
I'm sorry that I can not answer within a day, because my openhab time limited and usually limited to Monday evenings for about one or two hours.

I'm happy that you were able to use the binding and execute the commands and the output seems to fulfill the idea of #14672:
You got enough details to create alternative devices and I can create a new issue with all needed information to support the new relay with a future pull request.
More analysis or data is not need from my current point of view.

My next steps is to enhance the commands and write tests to prepare a good pull requests content for a merge.

Regarding 1: This PR will include the support of more than one defined bridge, because my simple code just takes the first bridge instance it gets to print details about it.

Regarding 2: Bosch SHC can connect to the HUE bridge and can use HUE lights in combination with its own hardware. I assume the Bosch Multi Switch can trigger HUE lights. I use the Bosch TwinGuard and the "Air Quality Check" and report the status with a HUE color light.

Bye, bye
Gerd

[mike-bike]

Hi Gerd, many thanks for your response. No need to feel sorry. I am really happy that there is someone spending free time to support that binding. I'd probably need to feel „guilty" as I am only a consumer benefitting from the effort the numerous people around the world put into the development of that great piece of software. The code lists all devices, so I’d assume to enhance the command to enumerate all bridges would be straight forward. I am looking forward to your enhancement for the new Light/Shutter Control devices. Let me know if you do have a version available to test. A working switch would be nice to start, power measurement the cream on the ice (too warm for cake) :-) Too sad, that one has blown by the garden light. I am going to put in some fuses in front of the relay. 500mA should do. There are only a handful LED garden lights and a fountain pump. Unfortunately one LED broke due to water leakage and blowed the 16A main fuse. Too much for the small relay :-( I need to wait for a replacement before I could try the shutter control. In regards to HUE support of the Bosch binding: I still don’t get the use case for boschshc to support HUE. Within Bosch App you could use the scenes and triggers controlling HUEs. Got it! However, within the OpenHAB eco-system you do have the HUE binding. If you have rules monitoring air quality of your TwinGuard you could use the native HUE binding to trigger your light show reporting the air quality status. In my mind it would only make sense if you would have HUE lights directly connected to the Bosch bridge without the HUE bridge (Is that even possible?). Anyhow, the HUE support does not harm. It is only the redundancy... Wishing you a nice evening and a wonderful week. Many greetings from sunny Cologne Michael

…

Am 19.06.2023 um 21:23 schrieb Gerd Zanker ***@***.***>: Hello @mike-bike <https://github.com/mike-bike> , wow what a detailed test result. Thanks a lot Michael! I'm sorry that I can not answer within a day, because my openhab time limited and usually limited to Monday evenings for about one or two hours. I'm happy that you were able to use the binding and execute the commands and the output seems to fulfill the idea of #14672 <#14672>: You got enough details to create alternative devices and I can create a new issue with all needed information to support the new relay with a future pull request. More analysis or data is not need from my current point of view. My next steps is to enhance the commands and write tests to prepare a good pull requests content for a merge. Regarding 1: This PR will include the support of more than one defined bridge, because my simple code just takes the first bridge instance it gets to print details about it. Regarding 2: Bosch SHC can connect to the HUE bridge and can use HUE lights in combination with its own hardware. I assume the Bosch Multi Switch can trigger HUE lights. I use the Bosch TwinGuard and the "Air Quality Check" and report the status with a HUE color light. Bye, bye Gerd — Reply to this email directly, view it on GitHub <#15060 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHVH7GGAXPWB3GM6ZJF27UDXMCRJTANCNFSM6AAAAAAY7O3F7Y>. You are receiving this because you were mentioned.

[lolodomo]

@GerdZanker : did you see review comments from @david-pace ?

[GerdZanker]

@GerdZanker : did you see review comments from @david-pace ?

Yes, most of the review comments are already improved locally. My time is currently very, very limited and I struggle with a good way to collect all possible services. I tested already four different way to collect the service names, but failed.

Perhaps I need to stop this and do not implement the possible services. Instead we can finish this pull request and later I improve the command.

[GerdZanker]

Hello @david-pace,
now when days are short and nights are longer, I'm able to code a bit further on this PR.

All your comments should be improved. But I wasn't able to improve the way how all services are known to the command. I already tried several different ideas and most of the time I struggle during runtime, because creating an object from our SHC classes is not enough. The object needs also other references from openhab to not fail with exceptions and here I'm stuck.

Please give me a bit more time over the Christmas time to hopefully solve the last pending task.

Thanks you all for your support here and I wish you nice 🎄 Holidays ⛄.

[GerdZanker]

The CommandExtension code is done.

The extension needs a list of all services. This list is now a static list checked with a unit tests.
I wasn't able to build the list during runtime - refection and creating thinks to access all services did not work for me.

Here an example of the output to see which devices and services are already support or which ones we could add in the future

  deviceID: hdm:HomeMaticIP:3014F711A000...
	  type: PSM -> smart-plug-compact
			service: PowerMeter -> powermeter
			service: PowerSwitch -> powerswitch
			service: PowerSwitchConfiguration -> !UNSUPPORTED!
			service: PowerSwitchProgram -> !UNSUPPORTED!
			service: Routing -> !UNSUPPORTED!
			service: Linking -> !UNSUPPORTED!

  deviceID: hdm:HomeMaticIP:3014F711A000...
	  type: BWTH -> wall-thermostat
			service: CommunicationQuality -> communicationquality
			service: Thermostat -> !UNSUPPORTED!
			service: TemperatureLevel -> temperaturelevel
			service: HumidityLevel -> humiditylevel
			service: WallThermostatConfiguration -> !UNSUPPORTED!
			service: TemperatureOffset -> !UNSUPPORTED!

[david-pace]

Looks good in general, left a few comments / questions.

[lsiepel]

Left a small comment. otherwise LGTM

[lsiepel]

Thanks LGTM