[boschshc] Support for Light/Shutter Control II

openhab / openhab-addons

Add-ons for openHAB

https://www.openhab.org/

Eclipse Public License 2.0

1.86k stars 3.56k forks source link

[boschshc] Support for Light/Shutter Control II #14562

Closed mike-bike closed 3 months ago

mike-bike commented 1 year ago

Hi,

I just purchased 2 Bosch Light/Shutter Control II devices (https://www.bosch-smarthome.com/uk/en/products/devices/light-control/). Based on configuration they behave like a shutter control or 2 wall switches. I have tried to add them as switches to OpenHAB but unfortunately they don't work. Neither switch states nor power consumption are recognized. Looking at the log, they are reporting different services than switches:

Found device: name=Brunnen id=hdm:ZigBee:xyz .... service: PowerSwitch .... service: ChildProtection .... service: PowerSwitchProgram

Are there any concrete plans enhancing the functionality of the binding?

Many thanks for your great effort and support.

Regards, Michael

Your Environment

openhabian on RPi4, HUE, Bosch Smart Home Controller

openhab-bot commented 1 year ago

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

https://community.openhab.org/t/problem-connection-bosch-smarthome-light-shutter-control-unit-ii/146281/2

david-pace commented 6 months ago

This was also requested by @wwinandy in #16203.

I can implement support for the Light/Shutter Control II, but as I don't own this specific device myself I would need your help to test it. This would involve downloading JARs, installing JARs via the openHAB console, and testing the new thing and its channels. This can potentially make the binding unusable temporarily, but everything should be revertable to the original state. A backup would be in order anyway just in case. @mike-bike already offered to help us testing, which is great :heart:

If you guys need support for other devices, please create separate Github enhancement requests for each device. Thank you :+1:

mike-bike commented 6 months ago

Hi @david-pace, let me know where to download a test version of the JAR and I am happy to test. I could offer:

Door Contact II (installed) - dev in progress
Light/Shutter Control II configured as double Light Switch (installed)
Light/Shutter Control II configured as Roller Shutter (need to grab screw driver to install device)
Dimmer (sitting in the box waiting for screw driver) - request #16241 raised

Cheers

mike-bike commented 6 months ago

Hi @david-pace, let me know where to download a test version of the JAR and I am happy to test. I could offer:

Door Contact II (installed)
Light/Shutter Control II configured as double Light Switch (installed)
Light/Shutter Control II configured as Roller Shutter (need to grab screw driver to install device)
Dimmer (sitting in the box waiting for screw driver)

Cheers

mike-bike commented 6 months ago

Hi @david-pace, let me know where to download a test version of the JAR and I am happy to test. I could offer:

Door Contact II (installed)
Light/Shutter Control II configured as double Light Switch (installed)
Light/Shutter Control II configured as Roller Shutter (need to grab screw driver to install device)
Dimmer (sitting in the box waiting for screw driver)

Cheers

wwinandy commented 6 months ago

Hi @david-pace, where can i get the test JARs for testing? Is there any instruction for installing the JARs?

I also use a smoke alarm II - request ( #16243) and a Universal Switch II - request (#16244)

Regards

david-pace commented 6 months ago

Hi, I first have to implement the necessary services and devices before I can provide JARs. Once I have a first version I will also provide instructions how to install the JARs. I hope I will find some free time soon and that it won't be too long but I can't promise anything.

Thank you in advance for volunteering to help with the testing, this already motivates me to start coding because without your help this would not be possible 👍

david-pace commented 6 months ago

Hi @mike-bike, I need some information regarding the device IDs. The Light/Shutter Control II works with so called child devices. I think there should be one main device and two child devices. The child device IDs should contain # or %23.

Could you please check whether you see the main device and the child device IDs in the listing when openHAB is started? If so, can you please post them here or send them via email? I need the main device ID, both child device IDs and the associated services. Thank you 🙂

mike-bike commented 6 months ago

Hi Davi, I have extracted the info from the log file after a restart with your snapshot binding:

openhab> list | grep Bosch 250 │ Active │ 80 │ 4.2.0.202401032334 │ openHAB Add-ons :: Bundles :: Bosch Smart Home Binding

You should find a Dimmer, Roller Shutter II, and Light Control II. Hope that is the information you are looking for. If anything is missing, just let me know.

`BOSCH Dimmer

2024-01-13 18:22:22.578 [DEBUG] [rnal.discovery.ThingDiscoveryService] - Found device: name=Dimmertest id=hdm:ZigBee:60b647fffe14a1e1 2024-01-13 18:22:22.580 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: CommunicationQuality 2024-01-13 18:22:22.582 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: PowerSwitch 2024-01-13 18:22:22.584 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: ChildProtection 2024-01-13 18:22:22.587 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: ElectricalFaults 2024-01-13 18:22:22.589 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: MultiLevelSwitch 2024-01-13 18:22:22.592 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: DimmerConfiguration 2024-01-13 18:22:22.594 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: SwitchConfiguration

{
    "@type": "device",
    "childDeviceIds": [
    ],
    "deviceModel": "MICROMODULE_DIMMER",
    "deviceServiceIds": [
        "CommunicationQuality",
        "PowerSwitch",
        "ChildProtection",
        "ElectricalFaults",
        "MultiLevelSwitch",
        "DimmerConfiguration",
        "SwitchConfiguration"
    ],
    "iconId": "ip_lamp_bulb_1",
    "id": "hdm:ZigBee:60b647fffe14a1e1",
    "manufacturer": "BOSCH",
    "name": "Dimmertest",
    "profile": "GENERIC",
    "roomId": "hz_16",
    "rootDeviceId": "64-da-a0-10-83-a7",
    "serial": "60B647FFFE14A1E1",
    "status": "AVAILABLE",
    "supportedProfiles": [
    ]
},

BOSCH Shutter Control II

2024-01-13 18:22:22.427 [DEBUG] [rnal.discovery.ThingDiscoveryService] - Found device: name=Treppenhaus Rollo id=hdm:ZigBee:b43a31fffeffae5d 2024-01-13 18:22:22.429 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: PowerMeter 2024-01-13 18:22:22.432 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: ShutterControl 2024-01-13 18:22:22.434 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: CommunicationQuality 2024-01-13 18:22:22.437 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: ChildProtection 2024-01-13 18:22:22.440 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: SwitchConfiguration

{
    "@type": "device",
    "childDeviceIds": [
    ],
    "deviceModel": "MICROMODULE_SHUTTER",
    "deviceServiceIds": [
        "PowerMeter",
        "ShutterControl",
        "CommunicationQuality",
        "ChildProtection",
        "SwitchConfiguration"
    ],
    "id": "hdm:ZigBee:b43a31fffeffae5d",
    "manufacturer": "BOSCH",
    "name": "Treppenhaus Rollo",
    "profile": "GENERIC",
    "roomId": "hz_6",
    "rootDeviceId": "64-da-a0-10-83-a7",
    "serial": "B43A31FFFEFFAE5D",
    "status": "AVAILABLE",
    "supportedProfiles": [
    ]
},

BOSCH Light Control II configured as 2 Light Switches (Brunnen, Olivenbaum)

2024-01-13 18:22:22.824 [DEBUG] [rnal.discovery.ThingDiscoveryService] - Found device: name=Brunnen id=hdm:ZigBee:70ac08fffefead2d#3 2024-01-13 18:22:22.826 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: PowerSwitch 2024-01-13 18:22:22.828 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: ChildProtection 2024-01-13 18:22:22.831 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: PowerSwitchProgram 2024-01-13 18:22:22.833 [DEBUG] [rnal.discovery.ThingDiscoveryService] - Found device: name=Olivenbaum id=hdm:ZigBee:70ac08fffefead2d#2 2024-01-13 18:22:22.835 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: PowerSwitch 2024-01-13 18:22:22.837 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: ChildProtection 2024-01-13 18:22:22.840 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: PowerSwitchProgram

{
    "@type": "device",
    "childDeviceIds": [
        "hdm:ZigBee:70ac08fffefead2d#3",
        "hdm:ZigBee:70ac08fffefead2d#2"
    ],
    "deviceModel": "MICROMODULE_LIGHT_CONTROL",
    "deviceServiceIds": [
        "CommunicationQuality",
        "PowerMeter",
        "ElectricalFaults",
        "SwitchConfiguration"
    ],
    "id": "hdm:ZigBee:70ac08fffefead2d",
    "manufacturer": "BOSCH",
    "name": "LightMM_70ac08fffefead2d",
    "profile": "GENERIC",
    "rootDeviceId": "64-da-a0-10-83-a7",
    "serial": "70AC08FFFEFEAD2D",
    "status": "AVAILABLE",
    "supportedProfiles": [
    ]
},

{
    "@type": "device",
    "childDeviceIds": [
    ],
    "deviceModel": "MICROMODULE_LIGHT_ATTACHED",
    "deviceServiceIds": [
        "PowerSwitch",
        "ChildProtection",
        "PowerSwitchProgram"
    ],
    "iconId": "icon_mm_light_lantern",
    "id": "hdm:ZigBee:70ac08fffefead2d#3",
    "manufacturer": "BOSCH",
    "name": "Brunnen",
    "parentDeviceId": "hdm:ZigBee:70ac08fffefead2d",
    "profile": "GENERIC",
    "roomId": "hz_8",
    "rootDeviceId": "64-da-a0-10-83-a7",
    "serial": "70AC08FFFEFEAD2D",
    "status": "AVAILABLE",
    "supportedProfiles": [
    ]
},
{
    "@type": "device",
    "childDeviceIds": [
    ],
    "deviceModel": "MICROMODULE_LIGHT_ATTACHED",
    "deviceServiceIds": [
        "PowerSwitch",
        "ChildProtection",
        "PowerSwitchProgram"
    ],
    "iconId": "icon_mm_light_spot_br30",
    "id": "hdm:ZigBee:70ac08fffefead2d#2",
    "manufacturer": "BOSCH",
    "name": "Olivenbaum",
    "parentDeviceId": "hdm:ZigBee:70ac08fffefead2d",
    "profile": "GENERIC",
    "roomId": "hz_8",
    "rootDeviceId": "64-da-a0-10-83-a7",
    "serial": "70AC08FFFEFEAD2D",
    "status": "AVAILABLE",
    "supportedProfiles": [
    ]
},

Regards, Michael

Am 12.01.2024 um 22:59 schrieb David Pace @.***>:

Hi @mike-bike https://github.com/mike-bike, I need some information regarding the device IDs. The Light/Shutter Control II works with so called child devices. I think there should be one main device and two child devices. The child device IDs should contain # or %23.

Could you please check whether you see the main device and the child device IDs in the listing when openHAB is started? If so, can you please post them here or send them via email? I need the main device ID, both child device IDs and the associated services. Thank you 🙂

— Reply to this email directly, view it on GitHub https://github.com/openhab/openhab-addons/issues/14562#issuecomment-1890014929, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVH7GHYBCYQ5Z3ACIV4VV3YOGW3VAVCNFSM6AAAAAAVVSVT4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJQGAYTIOJSHE. You are receiving this because you were mentioned.

mike-bike commented 6 months ago

Some long poll responses from the version II devices. Might help identifying the appropriate channels.

Response from Shutter Control II

2024-01-13 19:58:23.696 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"path":"/devices/hdm:ZigBee:b43a31fffeffae5d/services/PowerMeter","@type":"DeviceServiceData","id":"PowerMeter","state":{"energyConsumption":0,"powerConsumption":93,"@type":"powerMeterState"},"deviceId":"hdm:ZigBee:b43a31fffeffae5d"}],"jsonrpc":"2.0"}
2024-01-13 19:58:23.904 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"path":"/devices/hdm:ZigBee:b43a31fffeffae5d/services/ShutterControl","operations":["decrementOpenLevel","incrementOpenLevel"],"@type":"DeviceServiceData","id":"ShutterControl","state":{"delayCompensationTime":0.2,"referenceMovingTimes":{"movingTimeBottomToTopInMillis":17800,"movingTimeTopToBottomInMillis":17000},"endPositionAutoDetect":true,"delayCompensationSupported":true,"level":0.61,"@type":"shutterControlState","operationState":"STOPPED","endPositionSupported":true,"automaticDelayCompensation":true,"calibrated":true},"deviceId":"hdm:ZigBee:b43a31fffeffae5d"}],"jsonrpc":"2.0"}
2024-01-13 19:58:24.044 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"path":"/devices/hdm:ZigBee:b43a31fffeffae5d/services/ShutterControl","operations":["decrementOpenLevel","incrementOpenLevel"],"@type":"DeviceServiceData","id":"ShutterControl","state":{"delayCompensationTime":0.2,"referenceMovingTimes":{"movingTimeBottomToTopInMillis":17800,"movingTimeTopToBottomInMillis":17000},"endPositionAutoDetect":true,"delayCompensationSupported":true,"level":0.61,"@type":"shutterControlState","operationState":"MOVING","endPositionSupported":true,"automaticDelayCompensation":true,"calibrated":true},"deviceId":"hdm:ZigBee:b43a31fffeffae5d"}],"jsonrpc":"2.0"}

Response from Dimmer

2024-01-13 20:00:39.104 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"path":"/devices/hdm:ZigBee:60b647fffe14a1e1/services/MultiLevelSwitch","@type":"DeviceServiceData","id":"MultiLevelSwitch","state":{"level":50,"@type":"multiLevelSwitchState"},"deviceId":"hdm:ZigBee:60b647fffe14a1e1"}],"jsonrpc":"2.0"}
2024-01-13 20:00:51.514 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"path":"/devices/hdm:ZigBee:60b647fffe14a1e1/services/MultiLevelSwitch","@type":"DeviceServiceData","id":"MultiLevelSwitch","state":{"level":30,"@type":"multiLevelSwitchState"},"deviceId":"hdm:ZigBee:60b647fffe14a1e1"}],"jsonrpc":"2.0"}
2024-01-13 20:01:50.724 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"path":"/devices/hdm:ZigBee:60b647fffe14a1e1/services/PowerSwitch","@type":"DeviceServiceData","id":"PowerSwitch","state":{"@type":"powerSwitchState","automaticPowerOffTime":0,"switchState":"OFF"},"deviceId":"hdm:ZigBee:60b647fffe14a1e1"}],"jsonrpc":"2.0"}

Response from Light Control II

2024-01-13 20:03:12.414 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"path":"/devices/hdm:ZigBee:70ac08fffefead2d#2/services/PowerSwitch","@type":"DeviceServiceData","id":"PowerSwitch","state":{"@type":"powerSwitchState","automaticPowerOffTime":0,"switchState":"OFF"},"deviceId":"hdm:ZigBee:70ac08fffefead2d#2"}],"jsonrpc":"2.0"}
2024-01-13 20:03:14.084 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"path":"/devices/hdm:ZigBee:70ac08fffefead2d/services/PowerMeter","@type":"DeviceServiceData","id":"PowerMeter","state":{"energyConsumption":18600,"powerConsumption":0,"@type":"powerMeterState"},"deviceId":"hdm:ZigBee:70ac08fffefead2d"}],"jsonrpc":"2.0"}

david-pace commented 5 months ago

Hi @mike-bike and @wwinandy,

I implemented support for Shutter Control II and uploaded a JAR that you can use for testing :+1: Note that this does not support Light Control II yet.

Here are step by step instructions how you can test:

if you have a dedicated second openHAB system just for testing it would be optimal just to be sure your productive system is not affected during testing
- please make a backup of your system to be safe (I don't expect that exchanging the JAR can destroy the system but just in case...)
start an openHAB console with openhab-cli console
find out the bundle ID of the boschshc binding: la -s | grep boschshc
replace the JAR with bundle:update [bundle ID from previous step] /path/to/JAR.jar (sometimes openHAB needs to be restarted)
check if the discovery works
add a corresponding thing
add items to all channels
change states on the device and check if all channels are updated correctly
when you're finished with testing, delete & unlink all created items and delete the thing you created (in case there are updates/enhancements later, they would become incompatible)
finally, replace the bundle JAR with the original JAR of your release. JARs for all releases can be found here

Let me know if anything does not work. Once Shutter Control II works, I will continue with support for Light Control II.

david-pace commented 5 months ago

I just fixed two issues:

child protection state was not settable
device was not registered properly in the factory

If you have already downloaded the JAR, please download again.

mike-bike commented 5 months ago

Hi David,

downloaded JAR. Could not get it working on my test box with openhab 4.1.0. Upgrade to 4.1.1.-1 seems to somewhat resolve that issue. SNAPSHOT binding could be loaded but errors with:

Caused by: java.lang.ClassNotFoundException: org.openhab.core.config.discovery.AbstractThingHandlerDiscoveryService cannot be found by org.openhab.binding.boschshc_4.2.0.202401311653

Existing things does not switch online and discovery does not bring any new.

When I revert back to org.openhab.binding.boschshc-4.2.0-SNAPSHOT-discovery-disabled.jar it seems to be working ok again.

Any advice?

Regards, Michael

Am 31.01.2024 um 16:52 schrieb David Pace @.***>:

Hi @mike-bike https://github.com/mike-bike and @wwinandy https://github.com/wwinandy,

I implemented support for Shutter Control II and uploaded a JAR http://davidpace.de/openhab/org.openhab.binding.boschshc-4.2.0-SNAPSHOT-shutter-control-2.jar that you can use for testing 👍 Note that this does not support Light Control II yet.

Here are step by step instructions how you can test:

if you have a dedicated second openHAB system just for testing it would be optimal just to be sure your productive system is not affected during testing please make a backup of your system to be safe (I don't expect that exchanging the JAR can destroy the system but just in case...) start an openHAB console with openhab-cli console find out the bundle ID of the boschshc binding: la -s | grep boschshc replace the JAR with `bundle:update [bundle ID from previous step] /path/to/JAR.jar (sometimes openHAB needs to be restarted) check if the discovery works add a corresponding thing add items to all channels change states on the device and check if all channels are updated correctly when you're finished with testing, delete & unlink all created items and to delete the thing (in case there are updates/enhancements later, they would become incompatible) finally, replace the bundle JAR with the original JAR of your release. JARs for all releases can be found here https://openhab.jfrog.io/ui/repos/tree/General/libs-release-local/org/openhab/addons/bundles/org.openhab.binding.boschshc Let me know if anything does not work. Once Shutter Control II works, I will continue with support for Light Control II.

— Reply to this email directly, view it on GitHub https://github.com/openhab/openhab-addons/issues/14562#issuecomment-1919389870, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVH7GHH4ERYEEFI5JCJRV3YRJSENAVCNFSM6AAAAAAVVSVT4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJZGM4DSOBXGA. You are receiving this because you were mentioned.

david-pace commented 5 months ago

I suppose it does not work because in the mean time there were some changes in the openHAB core discovery framework, so my JAR only works with the latest state.

Since you have a dedicated test system you could switch to the latest SNAPSHOT state by using the following apt repository:

deb https://openhab.jfrog.io/artifactory/openhab-linuxpkg unstable main

For milestone releases, you can use testing instead of unstable. See also https://community.openhab.org/t/guide-installing-and-testing-oh3-snapshots-milestones-using-apt-and-yum/104572

Once you have the latest snapshot version of openHAB, my JAR should be compatible.

mike-bike commented 5 months ago

That’s what I thought. Just wanted to doublecheck my understanding.

I have upgraded to latest 4.2 Snapshot and upgraded the binding without any issues.

Roller Shutter II has been detected and I have added as a new thing.

All linked items working. Child Protection also flips status in the other devices correctly. All commands and updates working correctly and in both directions changes in Bosch Controller App reflected in OpenHAB changes in OpenHAB reflected in Controller App

Power- and Energy Meters showing realistic values.

Just one observation: Connection Strenghts / Signalstärke seem to be overly optimistic. Value in log is GOOD but you show Ausgezeichnet which I’d translate as „VERY GOOD“ or „EXCELLENT“ - probably the mapping is not yet correct.

Let me know if I shall check anything else.

In summary: Very well done. Many thanks.

Looking forward to testing even more new devices :-)

Best regards, Michael

Am 02.02.2024 um 12:49 schrieb David Pace @.***>:

I suppose it does not work because in the mean time there were some changes in the openHAB core discovery framework, so my JAR only works with the latest state.

Since you have a dedicated test system you could switch to the latest SNAPSHOT state by using the following apt repository:

deb https://openhab.jfrog.io/artifactory/openhab-linuxpkg unstable main For milestone releases, you can use testing instead of unstable. See also https://community.openhab.org/t/guide-installing-and-testing-oh3-snapshots-milestones-using-apt-and-yum/104572

Once you have the latest snapshot version of openHAB, my JAR should be compatible.

— Reply to this email directly, view it on GitHub https://github.com/openhab/openhab-addons/issues/14562#issuecomment-1923651337, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVH7GH6CATH5ROGXOJGAN3YRTHFNAVCNFSM6AAAAAAVVSVT4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRTGY2TCMZTG4. You are receiving this because you were mentioned.

david-pace commented 5 months ago

Wow this is great news 😎 I wouldn't have thought that everything works directly in the first test iteration 😉

About the signal strength mapping: interestingly the exact same question was asked in https://github.com/openhab/openhab-addons/pull/16357#issuecomment-1925205687. We use an openHAB system channel and translate the Bosch-specific communication quality to an openHAB-specific signal strength as discussed here: https://github.com/openhab/openhab-addons/pull/16093#discussion_r1434107400

The mapping is:

UNKNOWN -> 0
BAD -> 1
MEDIUM -> 2
NORMAL -> 3
GOOD -> 4

As you can see, GOOD is the best Bosch communication quality, so it is translated to the best openHAB signal strength 4 which is "excellent". In my opinion this is the best mapping but if you have a better idea feel free to propose a different mapping.

mike-bike commented 5 months ago

Yes, I think that was a great work. I Have not done rough testing, but what else should be tested? Channels are updating inline with the BOSCH app values and the items receive a timely refresh. Let me know if I could test any other specific scenarios.

It would be worth to note (probably in the channel configuration comment): power consumption update is 5-10 secs delayed; ie when motor stops it takes a while until the item reflects 0W signal strengths is only updated, when Signal Test is pushed in BOSCH App

Though, these might be system driven and honestly not an issue for me at all.

Thanks for the explanation with the signal strength values. I am perfectly fine to align with the OpenHAB model. 5 states nicely mapped. I was just confused by the Bosch response GOOD in the log and the EXCELLENT mapping in OpenHAB. However, if BOSCH’s highest value is GOOD, then it matches perfectly.

Looking forward to seeing the support for the same device configured as two light switches (probably with just one combined Energy/Power meter).

Regards, Michael

Am 03.02.2024 um 17:49 schrieb David Pace @.***>:

Wow this is great news 😎 I wouldn't have thought that everything works directly in the first test iteration 😉

About the signal strength mapping: interestingly the exact same question was asked in #16357 (comment) https://github.com/openhab/openhab-addons/pull/16357#issuecomment-1925205687. We use an openHAB system channel and translate the Bosch-specific communication quality to an openHAB-specific signal strength as discussed here: #16093 (comment) https://github.com/openhab/openhab-addons/pull/16093#discussion_r1434107400 The mapping is:

UNKNOWN -> 0 BAD -> 1 MEDIUM -> 2 NORMAL -> 3 GOOD -> 4 As you can see, GOOD is the best Bosch communication quality, so it is translated to the best openHAB signal strength 4 which is "excellent". In my opinion this is the best mapping but if you have a better idea feel free to propose a different mapping.

— Reply to this email directly, view it on GitHub https://github.com/openhab/openhab-addons/issues/14562#issuecomment-1925393049, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVH7GBDCWOKSOHM7DY4YPDYRZTDNAVCNFSM6AAAAAAVVSVT4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRVGM4TGMBUHE. You are receiving this because you were mentioned.

david-pace commented 5 months ago

Hi @mike-bike, I just implemented a first version that also supports the light switch configuration. Please download the JAR again from the same location I already provided.

The implementation for the light switches is a bit more complex because we see a parent device and two child devices for the two light switch circuits. I modeled it the same way in openHAB - one thing type for the parent device and another thing type for the light switch circuits.

Please test if this works in the first place. Then we can discuss whether we should stay with this model or change it. I thought about representing it only as one device in openHAB which would be more user-friendly, but this has significant drawbacks regarding the channel names and scalability for possible future Bosch devices that might have logical child devices. But we can discuss this later. Now let's first see whether it even works with the different thing types ;)

mike-bike commented 5 months ago

Hi David,

new JAR downloaded wget http://davidpace.de/openhab/org.openhab.binding.boschshc-4.2.0-SNAPSHOT-shutter-control-2.jar

and renamed to -3.jar 7063221 Feb 11 17:54 org.openhab.binding.boschshc-4.2.0-SNAPSHOT-shutter-control-3.jar

Then updated in openHAB: openhab> list | grep Bosch 265 │ Active │ 80 │ 4.2.0.202402111653 │ openHAB Add-ons :: Bundles :: Bosch Smart Home Binding openhab> bundle:update 265 file:///home/openhabian/addons/org.openhab.binding.boschshc-4.2.0-SNAPSHOT-shutter-control-3.jar

So far so good… :-) Then, there seems to be an issue with the new code. Binding loads but discovery ends with exception. Binding state turns to „UNKNOWN“ - see error below:

2024-02-11 23:30:11.062 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: java.lang.IllegalArgumentException: ID segment 'hdm_ZigBee_70ac08fffefead2d#3' contains invalid characters. Each segment of the ID must match the pattern [\w-]*.

Please note, that I do have some BOSCH Devices with Umlauts in the name. This has never caused any issues...

Let me know how I could help any further.

Regards Michael

New Devices Recognized: 2024-02-11 23:30:10.500 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: BinarySwitch 2024-02-11 23:30:10.502 [DEBUG] [rnal.discovery.ThingDiscoveryService] - Found device: name=Brunnen id=hdm:ZigBee:70ac08fffefead2d#3 2024-02-11 23:30:10.503 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: PowerSwitch 2024-02-11 23:30:10.504 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: ChildProtection 2024-02-11 23:30:10.505 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: PowerSwitchProgram 2024-02-11 23:30:10.507 [DEBUG] [rnal.discovery.ThingDiscoveryService] - Found device: name=RoomLightControl id=roomLightControl_hz_2 2024-02-11 23:30:10.508 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: BinarySwitch 2024-02-11 23:30:10.509 [DEBUG] [rnal.discovery.ThingDiscoveryService] - Found device: name=Olivenbaum id=hdm:ZigBee:70ac08fffefead2d#2 2024-02-11 23:30:10.511 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: PowerSwitch 2024-02-11 23:30:10.512 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: ChildProtection 2024-02-11 23:30:10.513 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: PowerSwitchProgram

2024-02-11 23:30:10.595 [DEBUG] [rnal.discovery.ThingDiscoveryService] - Found device: name=LightMM_70ac08fffefead2d id=hdm:ZigBee:70ac08fffefead2d 2024-02-11 23:30:10.597 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: PowerMeter 2024-02-11 23:30:10.598 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: CommunicationQuality 2024-02-11 23:30:10.599 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: ElectricalFaults 2024-02-11 23:30:10.601 [DEBUG] [rnal.discovery.ThingDiscoveryService] - .... service: SwitchConfiguration

Binding crashes with following error: 2024-02-11 23:30:11.062 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: java.lang.IllegalArgumentException: ID segment 'hdm_ZigBee_70ac08fffefead2d#3' contains invalid characters. Each segment of the ID m ust match the pattern [\w-]*. at org.openhab.core.common.AbstractUID.validateSegment(AbstractUID.java:105) ~[?:?] at org.openhab.core.common.AbstractUID.(AbstractUID.java:76) ~[?:?] at org.openhab.core.common.AbstractUID.(AbstractUID.java:59) ~[?:?] at org.openhab.core.thing.UID.(UID.java:57) ~[?:?] at org.openhab.core.thing.ThingUID.(ThingUID.java:58) ~[?:?] at org.openhab.binding.boschshc.internal.discovery.ThingDiscoveryService.addDevice(ThingDiscoveryService.java:226) ~[?:?] at org.openhab.binding.boschshc.internal.discovery.ThingDiscoveryService.addDevices(ThingDiscoveryService.java:206) ~[?:?] at org.openhab.binding.boschshc.internal.discovery.ThingDiscoveryService.doScan(ThingDiscoveryService.java:169) ~[?:?] at org.openhab.binding.boschshc.internal.devices.bridge.BridgeHandler.initialAccess(BridgeHandler.java:274) ~[?:?] at org.openhab.binding.boschshc.internal.devices.bridge.BridgeHandler.lambda$2(BridgeHandler.java:221) ~[?:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?] at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?] at java.lang.Thread.run(Thread.java:840) [?:?]

Am 11.02.2024 um 17:59 schrieb David Pace @.***>:

Hi @mike-bike https://github.com/mike-bike, I just implemented a first version that also supports the light switch configuration. Please download the JAR again from the same location I already provided.

The implementation for the light switches is a bit more complex because we see a parent device and two child devices for the two light switch circuits. I modeled it the same way in openHAB - one thing type for the parent device and another thing type for the light switch circuits.

Please test if this works in the first place. Then we can discuss whether we should stay with this model or change it. I thought about representing it only as one device in openHAB which would be more user-friendly, but this has significant drawbacks regarding the channel names and scalability for possible future Bosch devices that might have logical child devices. But we can discuss this later. Now let's first see whether it even works with the different thing types ;)

— Reply to this email directly, view it on GitHub https://github.com/openhab/openhab-addons/issues/14562#issuecomment-1937808730, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVH7GG6O7BIP6HJ46PXZ7LYTD2GLAVCNFSM6AAAAAAVVSVT4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZXHAYDQNZTGA. You are receiving this because you were mentioned.

david-pace commented 5 months ago

Thanks for the report :+1: There is an issue because the child devices contain hash characters in their IDs (for example the second to last character in hdm_ZigBee_70ac08fffefead2d#3). This is translated 1:1 into a thing ID in which this character is not allowed. I have an idea for a fix that I will provide soon.

david-pace commented 5 months ago

I uploaded a new JAR, please test again 👍

mike-bike commented 5 months ago

Hi @david-pace, I have loaded the new JAR and done some quick tests:

Device has been quickly discovered and the light-switch things placed in Inbox
Things instantiated and items created
Switch changes in Bosch App are immediately reflected in corresponding openHAB item state
Switch (On/Off) in OpenHAB does not trigger any change to the device itself. Item state in openHAB flips On/Off but does not actually switch the device.

We are getting closer...

mike-bike commented 5 months ago

Quick follow up - I missed to create the "base device" with power consumption and signal strength

Power consumption (W) and Energy (W/h) is showing same values as Bosch App
I have tricked Bosch App to perform another signal test (by changing to Roller Shutter mode)--> Item state shows correct value

In short: Things/Items picks up correct status but cannot control the device from OpenHAB

Re multiple things: I personally would find 1 thing with two sets of channels for the switch and child-protection more intuitive. It is one physical devices with a power meter and two switches. They cannot be separated. Implementing them as 3 things does not make logical sense to me. However, implementation model challenges or technical design thinking may lead to a different opinion. I have placed all items of all 3 things into the same equipment in the model keeping them together. That works for me.

david-pace commented 5 months ago

Thanks for testing the current development state @mike-bike :+1:

Could you please check your logs and look for:

any errors that relate to an unsuccessful HTTP PUT request
look for a log entry that looks like create request for {some URL} and content {some JSON code}. The URL has to contain one of the child device IDs in the middle. This entry can only be seen on TRACE level.

I have an idea what could be the problem. The child device ID in the URL has to be escaped and I suspect that this does not happen correctly.

Example: https://host:port/devices/hdm:ZigBee:70ac08fffe5294ea#3/services/PowerSwitch/state Here the hash tag before 3 would have to be escaped using %23.

david-pace commented 5 months ago

I just uploaded a new JAR that addresses the URL escaping issue. Please try again 🙂

mike-bike commented 5 months ago

While I was composing my response to your second last note, you came up with an update to the JAR...

2024-02-12 16:02:10.509 [TRACE] [ernal.devices.bridge.BoschHttpClient] - Create request for http client BoschHttpClient@4be2b7{STARTED} 2024-02-12 16:02:10.512 [TRACE] [ernal.devices.bridge.BoschHttpClient] - create request for https://192.168.2.61:8444/smarthome/devices/hdm:ZigBee:70ac08fffefead2d%232/services/PowerSwitch/state and content {"switchState":"ON","stateType":"powerSwitchState","@type ":"powerSwitchState"}

Escaping # has resolved the issue. Switching in openHAB now triggers the device.

mike-bike commented 5 months ago

Hi @david-pace, I have checked on/off and child-protection switches and all seem to be working fine. As I do not have any physical switches attached to the device, I am relying on corresponding status changes in the Bosch app. Though I'd expect the physics will work as expected if the app shows the changes.

It works like a charm - well done! Many thanks!

david-pace commented 5 months ago

Nice 😎

I will provide a PR soon, in which we can also discuss the thing/channel model :+1: