[boschshc] Add support for water detector #16593

name-lake · 2024-03-30T17:24:02Z

Since I'm afraid of water and moisture in the basement, I use Bosch water detectors. They work pretty well. However, I couldn't connect them to my openHAB because they are missing from the boschshc binding.
I use openHAB version 4.1.2 (Build) and Bosch Smart Home Controller II.
I would be very happy about an extension of the boschshc binding to use the water detector.

david-pace · 2024-03-31T12:53:50Z

Hi @name-lake, thank you for your enhancement request. We are happy to extend the binding to support water detectors 👍

Please note that in order to test the code, we need the actual hardware devices to confirm that everything is working. I don't have any water detector myself. Before we can start developing the binding code, we need someone who can test it with the real hardware. Do you have a water detector, @GerdZanker or @mike-bike? If not, would you be willing to perform the tests with your hardware @name-lake?

This would involve stuff like

downloading JAR files
replacing JARs on your system using the openHAB client console
creating a thing and creating items for all channels
and in the end removing all items and the thing

As soon as we found someone who has a water detector and is willing to test, we can theoretically start 😎 Please also note that there are other enhancement requests for the boschshc binding that we have to prioritize against each other.

name-lake · 2024-04-02T20:53:45Z

Like I said, I have water detectors. However, I have to say that I have never done this before (updating and testing a single binding). So yes, I'm ready.

GerdZanker · 2024-04-03T16:29:15Z

Sorry, I have no water detector - I'm still using my several years old roller shutter, (floor heating) thermostats, twin guards and window contacts.

david-pace · 2024-04-11T05:42:45Z

I have a first implementation ready for the water detector 😎

Before we start testing, I need some additional infos @name-lake:

Which openHAB version are you currently using? It would be good if you could update to openHAB 4.2.0.M2, which was released 4 days ago.
If you are on a fairly new version, there is a console command to list Bosch Smart Home devices and services. It would be good if you could execute this for me:
- Start an openhab console (on Linux installations this can be done with openhab-cli console, default password is habopen)
- Execute the command boschshc deviceInfo
- Find your water detector. Its services should include WaterLeakageSensor and WaterLeakageSensorTilt
- Copy the type information and the services and paste them here

Thank you 🙂

name-lake · 2024-04-11T18:56:21Z

As requsted I installed the version 4.2.0.M2. It works.
The console command boschshc deviceInfo returns (as I have 2 water detectors):


    ...
    deviceID: hdm:ZigBee:c...
        type: WLS -> !UNSUPPORTED!
             service: CommunicationQuality -> communicationquality
             service: BatteryLevel -> batterylevel
             service: WaterLeakageSensorTilt -> !UNSUPPORTED!
             service: WaterLeakageSensorCheck -> !UNSUPPORTED!
             service: WaterLeakageSensor -> !UNSUPPORTED!
    deviceID: hdm:ZigBee:5...
         type: WLS -> !UNSUPPORTED!
             service: CommunicationQuality -> communicationquality
             service: BatteryLevel -> batterylevel
             service: WaterLeakageSensorTilt -> !UNSUPPORTED!
             service: WaterLeakageSensorCheck -> !UNSUPPORTED!
             service: WaterLeakageSensor -> !UNSUPPORTED!

david-pace · 2024-04-12T04:46:38Z

Thanks @name-lake 👍

I implemented all services except WaterLeakageSensorCheck now. Here is a download link to the test JAR.

Here are step by step instructions how you can test:

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 (in both directions if channels are writable)

Then you can report back here what worked and what did not work. We might go through a few development iterations.

When we are done, these are the final steps:

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

name-lake · 2024-04-15T14:10:29Z

Thanks for the implementation, I really appreciate it. 👍
After updating the bundle (& rebooting - maybe not necessary?) I could test it.
These are the results.

The console command boschshc showBindingInfo returns:


Bosch SHC Binding
  SymbolicName org.openhab.binding.boschshc
  Version 4.2.0.202404120439

The command boschshc showDevices returns:


...
 - WLS = boschshc:water-detector

The console command boschshc deviceInfo returns:


  deviceID: hdm:ZigBee:c...
      type: WLS -> water-detector
            service: CommunicationQuality -> communicationquality
            service: BatteryLevel -> batterylevel
            service: WaterLeakageSensorTilt -> !UNSUPPORTED!
            service: WaterLeakageSensorCheck -> !UNSUPPORTED!
            service: WaterLeakageSensor -> !UNSUPPORTED!
  deviceID: hdm:ZigBee:5...
      type: WLS -> water-detector
            service: CommunicationQuality -> communicationquality
            service: BatteryLevel -> batterylevel
            service: WaterLeakageSensorTilt -> !UNSUPPORTED!
            service: WaterLeakageSensorCheck -> !UNSUPPORTED!
            service: WaterLeakageSensor -> !UNSUPPORTED!

After rebooting, both of my water detectors are in the thing INBOX - discovery works. 👍
The code of a water detector is as follows:


Channel UID
            boschshc:water-detector:BC1:hdm_ZigBee_5...:water-leakage
Label       Water Leakage
Description Indicates whether a water leakage was detected.
Channel UID
            boschshc:water-detector:BC1:hdm_ZigBee_5...:push-notifications
Label       Push Notification
Description Indicates whether push notifications are enabled.
Channel UID
            boschshc:water-detector:BC1:hdm_ZigBee_5...:acoustic-signals
Label       Acoustic Signal
Description Indicates whether acoustic signals are enabled.
UID: boschshc:water-detector:BC1:hdm_ZigBee_5...
label: Bosch_Wassermelder_1
thingTypeUID: boschshc:water-detector
configuration:
  id: hdm:ZigBee:5...
bridgeUID: boschshc:shc:BC1
channels:
  - id: water-leakage
    channelTypeUID: boschshc:water-leakage
    label: Water Leakage
    description: Indicates whether a water leakage was detected.
    configuration: {}
  - id: push-notifications
    channelTypeUID: boschshc:push-notifications
    label: Push Notification
    description: Indicates whether push notifications are enabled.
    configuration: {}
  - id: acoustic-signals
    channelTypeUID: boschshc:acoustic-signals
    label: Acoustic Signal
    description: Indicates whether acoustic signals are enabled.
    configuration: {}

The channel WaterLeakageSensor appears to be working, the water alarm signal is transferred correctly. This is great because this is the most important channel. 👍
The channels:


             service: CommunicationQuality -> communicationquality
             service: BatteryLevel -> batterylevel
             service: WaterLeakageSensorTilt -> !UNSUPPORTED!
             service: WaterLeakageSensorCheck -> !UNSUPPORTED!

are missing.

No need to implement the channel communicationquality.
However, I think, the remaining 3 missing channels, special WaterLeakageSensorTilt & batterylevel would be very useful.
Although, the channel WaterLeakageSensorCheck enables the sound check of the water sensor, which I placed in the base under the dishwasher, so maybe???

The switcheses boschshc:push-notifications and boschshc:acoustic-signals are related only to the service WaterLeakageSensorTilt.
I tested it on the Bosch app, it really works that way.
Therefore may I make some suggestions regarding the names of the channels push-notifications and acoustic-signals?

push-notifications
I have a german version of the Bosch Smart Home app, the corresponding app text is
Erhalten Sie eine Benachrichtigung auf diesem Mobilgerät, wenn der Wassermelder bewegt wird.
Free translation:
Receive a notification on this mobile device when the water detector is moved.
Suggestion:
id: push-notifications-onTamper (or push-notifications-onMove)
channelTypeUID: boschshc:push-notifications-onTamper (or push-notifications-onMove)
label: Push Notification When Moved
description: Indicates whether push notifications, when sensor moved, are enabled
acoustic-signals
The app german text:
Wenn Ihr Bosch SmartHome Wassermelder bewegt wird, ertönt ein Signalton.
Free translation:
If your Bosch SmartHome water detector is moved, it will beep.
Suggestion:
id: beep-onTamper (or beep-onMove)
channelTypeUID: boschshc:beep-onTamper (or beep-onMove)
label: Acoustic Signal When Moved
description: Indicates whether, when moved, acoustic signals are enabled.

The service WaterLeakageSensorTilt seems to cause some troubles.
See the log:
openhab> log:display | grep boschshc 11:24:00.317 [DEBUG] [internal.devices.bridge.BridgeHandler] - Found handler org.openhab.binding.boschshc.internal.devices.waterleakage.WaterLeakageSensorHandler@15808be, calling processUpdate() for service WaterLeakageSensorTilt with state {"pushNotificationState":"ENABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"ENABLED"} 11:24:00.318 [DEBUG] [to.WaterLeakageSensorTiltServiceState] - Expected state type waterLeakageSensorTilt for state class org.openhab.binding.boschshc.internal.services.waterleakage.dto.WaterLeakageSensorTiltServiceState, received waterLeakageSensorTiltState 11:24:00.318 [WARN ] [shc.internal.services.BoschSHCService] - Received invalid, expected type org.openhab.binding.boschshc.internal.services.waterleakage.dto.WaterLeakageSensorTiltServiceState 11:24:00.319 [DEBUG] [to.WaterLeakageSensorTiltServiceState] - Expected state type waterLeakageSensorTilt for state class org.openhab.binding.boschshc.internal.services.waterleakage.dto.WaterLeakageSensorTiltServiceState, received waterLeakageSensorTiltState 11:24:00.319 [WARN ] [shc.internal.services.BoschSHCService] - Received invalid, expected type org.openhab.binding.boschshc.internal.services.waterleakage.dto.WaterLeakageSensorTiltServiceState 11:24:00.320 [DEBUG] [to.WaterLeakageSensorTiltServiceState] - Expected state type waterLeakageSensorTilt for state class org.openhab.binding.boschshc.internal.services.waterleakage.dto.WaterLeakageSensorTiltServiceState, received waterLeakageSensorTiltState 11:24:00.320 [WARN ] [shc.internal.services.BoschSHCService] - Received invalid, expected type org.openhab.binding.boschshc.internal.services.waterleakage.dto.WaterLeakageSensorTiltServiceState 11:24:00.662 [DEBUG] [internal.devices.bridge.BridgeHandler] - Found handler org.openhab.binding.boschshc.internal.devices.waterleakage.WaterLeakageSensorHandler@15808be, calling processUpdate() for service WaterLeakageSensor with state {"@type":"waterLeakageSensorState","state":"LEAKAGE_DETECTED"} 11:24:09.789 [DEBUG] [internal.devices.bridge.BridgeHandler] - Found handler org.openhab.binding.boschshc.internal.devices.waterleakage.WaterLeakageSensorHandler@15808be, calling processUpdate() for service WaterLeakageSensor with state {"@type":"waterLeakageSensorState","state":"NO_LEAKAGE"}

The data of the channels boschshc:push-notifications and boschshc:acoustic-signals are not transferred at all, maybe due to the communication error related to the WaterLeakageSensorTilt channel problem.

david-pace · 2024-04-15T18:23:57Z

Thank you for your detailed test report 👍

Apparently there is a typo in my implementation, the internal type name in the requests/responses should be waterLeakageSensorTiltState instead of just waterLeakageSensorTilt. I will fix this soon and provide a new version. Then the push-notification and acoustic-signal transfers will hopefully work.

Also thank you for the explanations regarding in which specific cases the push notifications and the acoustic signals are activated. I will enhance the channel names and the descriptions accordingly.

And one last question: do you think it makes sense to put efforts into supporting the WaterLeakageSensorCheck service? Should this be controllable from openHAB or is this not really required? Do you know what it does exactly? Is this some kind of sensor self-check?

david-pace · 2024-04-16T05:40:06Z

Hi @name-lake, I just uploaded a new JAR (just use the same link as before). Please unlink and/or delete your items and delete the water detector things before updating the JAR, then re-create the things and then re-link the items or create new items.

Changes:

Fixed the state type name of the WaterLeakageSensorTilt service. This should enable the push-notifications-on-move and acoustic-signals-on-move channels
Added battery-level and low-battery channels
Added signal-strength channel for the CommunicationQuality service (in line with the other devices supporting this service)
Enhanced channel names and descriptions

Please let me know if the channels work as expected and if you are fine with the names and descriptions.

name-lake · 2024-04-18T21:19:09Z

Hello @david-pace,
thank you for the new version.

These are the test results at 18.04.2024.

The binding version is:

Bosch SHC Binding
  SymbolicName org.openhab.binding.boschshc
  Version 4.2.0.202404160530

The console command boschshc deviceInfo returns:

  deviceID: hdm:ZigBee:c...
      type: WLS -> water-detector
            service: CommunicationQuality -> communicationquality
            service: BatteryLevel -> batterylevel
            service: WaterLeakageSensorTilt -> !UNSUPPORTED!
            service: WaterLeakageSensorCheck -> !UNSUPPORTED!
            service: WaterLeakageSensor -> !UNSUPPORTED!

After rebooting, both of my water detectors are in the thing INBOX - discovery works. 👍
I created things and items. 👍
In my opinion, the channels name and descriptions are OK, thank you for the modification.
All channels:

Items:

The battery-levels channel shows the correct value (100%) for the sensor/battery is new. 👍

The low-battery channel does not report an alarm, this is OK. 👍

The water leakage channel still works properly. 👍

The signal-strength works also OK. 👍

Both switches push-notifications-on-move and acoustic-signals-on-move work properly, both reading and writing work correctly. 👍
There is a problem with refresh on the Bosch app, but I think, it is not a binding problem.

However, it seems, the channel for sensor tilt state (WaterLeakageSensorTiltState?) is missing.
The log after moving the water detector (both switches push-notifications-on-move and acoustic-signals-on-move on the Bosch app are enabled):

openhab> log:display |  grep '[Bb]osch'
11:00:41.010 [DEBUG] [internal.devices.bridge.BridgeHandler] - Found handler org.openhab.binding.boschshc.internal.devices.waterleakage.WaterLeakageSensorHandler@13045a6, calling processUpdate() for service WaterLeakageSensorTilt with state {"pushNotificationState":"ENABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"ENABLED"}
11:00:41.015 [INFO ] [openhab.event.ItemStateUpdatedEvent  ] - Item 'Bosch_water_detector_1_Push_Notifications_When_Moved' updated to ON
11:00:41.016 [INFO ] [openhab.event.ItemStateUpdatedEvent  ] - Item 'Bosch_water_detector_1_Acoustic_Signals_When_Moved' updated to ON
11:01:41.593 [DEBUG] [internal.devices.bridge.BridgeHandler] - Found handler org.openhab.binding.boschshc.internal.devices.waterleakage.WaterLeakageSensorHandler@13045a6, calling processUpdate() for service WaterLeakageSensorTilt with state {"pushNotificationState":"ENABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"ENABLED"}
11:01:41.596 [INFO ] [openhab.event.ItemStateUpdatedEvent  ] - Item 'Bosch_water_detector_1_Push_Notifications_When_Moved' updated to ON
11:01:41.596 [INFO ] [openhab.event.ItemStateUpdatedEvent  ] - Item 'Bosch_water_detector_1_Acoustic_Signals_When_Moved' updated to ON
openhab>

I think the line 11:00:41.010 shows the tilt state after sensor moving (some sort of active?),
the line 11:01:41.593 -> probably the tilt state goes automatically after some time (60 sec?) to some sort of deactivated?

The channel WaterLeakageSensorCheck activates a sensor sound check.
The Bosch app german description is:

Um den Alarmton des Wassermelders zu testen, tippen Sie auf "Test starten". Bitte beachten Sie, dass der Alarmton sehr laut ist.
Achten Sie auch auf das Blinken der Alarm LED.

Free translation:
To test the water detector alarm sound, touch the button “Start Test”. Please, note that the alarm sound very loud is.
Also notice the flashing of the alarm LED.

Support of that channel? - a question of the effort, in my opinion it makes sense.

david-pace · 2024-04-27T06:46:08Z

Hi @name-lake, I just uploaded a new JAR (at the same location as before). Please unlink or delete your items and delete the thing before testing again.

Changes:

Renamed some packages internally. This should mitigate the !UNSUPPORTED! outputs when running the boschshc deviceInfo command
Added a new channel water-leakage-sensor-check that should give you a result of the last check as string

Currently it looks like I cannot provide a channel like sensor-moved or similar. In the JSON messages you provided the only information provided is:

the type (this is required for all messages)
whether push notifications are enabled
whether acoustic notifications are enabled

From this information we cannot conclude whether only the notification settings changed or whether the sensor was actually moved.

Unfortunately, there is no API documentation about the sensor check service, so you have to help me by sending me the log messages about the events that are sent and received when starting the check from the Bosch App. The only thing I could find out is that there is a result field in the JSON messages with a string value.

With the current JAR you can theoretically also set the result field and send it to the controller, but this is only for experimental testing and I might remove this later. It is only to test whether the check can be initiated by setting the result field to some specific value. But I assume that there must be other fields in the JSON messages of this service to start a sensor check.

It would be great if you could provide log entries about what happens if you initiate such a check in the Bosch app 👍

name-lake · 2024-05-06T20:59:48Z

Hello @david-pace,
Thanks for the software. 👍
I tested it, these are the results.

The binding version is:

Bosch SHC Binding
  SymbolicName org.openhab.binding.boschshc
  Version 4.2.0.202404270629

The console command boschshc deviceInfo returns: 👍

  deviceID: hdm:ZigBee:c...
      type: WLS -> water-detector
            service: CommunicationQuality -> communicationquality
            service: BatteryLevel -> batterylevel
            service: WaterLeakageSensorTilt -> waterleakagesensortilt
            service: WaterLeakageSensorCheck -> waterleakagesensorcheck
            service: WaterLeakageSensor -> waterleakagesensor

The new channel water-leakage-sensor-check is working, I got the value SUCCESS. 👍

2024-04-29 21:49:33.919 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"path":"/devices/hdm:ZigBee:5cc7c1fffe1373ba/services/WaterLeakageSensorCheck","operations":["triggerCheck"],"@type":"DeviceServiceData","id":"WaterLeakageSensorCheck","state":{"result":"SUCCESS","@type":"waterLeakageSensorCheckState"},"deviceId":"hdm:ZigBee:5cc7c1fffe1373ba"}],"jsonrpc":"2.0"}

A channel sensor-moved or similar.
Evntually I found out, how this channel is working. You are right, actual there is no channel containing the info about moving the water detection sensor.
The event information about the tilt detection is sent in a controller message.

Some examples for TILT_DETECTED:

openhabian@openhabian:~ $ tail -n 1000 -f /var/log/openhab/openhab.log /var/log/openhab/events.log | grep -i TILT
2024-04-29 09:25:56.479 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"path":"/devices/hdm:ZigBee:5cc7c1fffe1373ba/services/WaterLeakageSensorTilt","@type":"DeviceServiceData","id":"WaterLeakageSensorTilt","state":{"pushNotificationState":"DISABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"DISABLED"},"deviceId":"hdm:ZigBee:5cc7c1fffe1373ba"}],"jsonrpc":"2.0"}
2024-04-29 09:25:56.480 [DEBUG] [nternal.devices.bridge.BridgeHandler] - Got update for service WaterLeakageSensorTilt of type DeviceServiceData: {"pushNotificationState":"DISABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"DISABLED"}
2024-04-29 09:25:56.482 [DEBUG] [nternal.devices.bridge.BridgeHandler] - Found handler org.openhab.binding.boschshc.internal.devices.waterleakage.WaterLeakageSensorHandler@15624c2, calling processUpdate() for service WaterLeakageSensorTilt with state {"pushNotificationState":"DISABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"DISABLED"}
2024-04-29 09:25:56.539 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"sourceId":"hdm:ZigBee:5cc7c1fffe1373ba","sourceType":"DEVICE","@type":"message","flags":[],"messageCode":{"name":"TILT_DETECTED","category":"WARNING"},"location":"Küche ","arguments":{"deviceModel":"WLS"},"id":"3499a60e-45b5-4c29-ae1a-202c2182970c","sourceName":"Bosch_water_detector_1","timestamp":1714375556426}],"jsonrpc":"2.0"}
2024-04-29 09:27:05.342 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"path":"/devices/hdm:ZigBee:5cc7c1fffe1373ba/services/WaterLeakageSensorTilt","@type":"DeviceServiceData","id":"WaterLeakageSensorTilt","state":{"pushNotificationState":"DISABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"DISABLED"},"deviceId":"hdm:ZigBee:5cc7c1fffe1373ba"}],"jsonrpc":"2.0"}
2024-04-29 09:27:05.343 [DEBUG] [nternal.devices.bridge.BridgeHandler] - Got update for service WaterLeakageSensorTilt of type DeviceServiceData: {"pushNotificationState":"DISABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"DISABLED"}
2024-04-29 09:27:05.343 [DEBUG] [nternal.devices.bridge.BridgeHandler] - Found handler org.openhab.binding.boschshc.internal.devices.waterleakage.WaterLeakageSensorHandler@15624c2, calling processUpdate() for service WaterLeakageSensorTilt with state {"pushNotificationState":"DISABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"DISABLED"}
2024-04-29 09:27:34.198 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"sourceId":"hdm:ZigBee:5cc7c1fffe1373ba","sourceType":"DEVICE","@type":"message","flags":[],"messageCode":{"name":"TILT_DETECTED","category":"WARNING"},"location":"Küche ","arguments":{"deviceModel":"WLS"},"id":"da58cb28-3f18-4fa5-9b2e-b022d3e052a1","sourceName":"Bosch_water_detector_1","timestamp":1714375654146}],"jsonrpc":"2.0"}
2024-04-29 09:28:34.794 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"path":"/devices/hdm:ZigBee:5cc7c1fffe1373ba/services/WaterLeakageSensorTilt","@type":"DeviceServiceData","id":"WaterLeakageSensorTilt","state":{"pushNotificationState":"DISABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"DISABLED"},"deviceId":"hdm:ZigBee:5cc7c1fffe1373ba"}],"jsonrpc":"2.0"}
2024-04-29 09:28:34.795 [DEBUG] [nternal.devices.bridge.BridgeHandler] - Got update for service WaterLeakageSensorTilt of type DeviceServiceData: {"pushNotificationState":"DISABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"DISABLED"}
2024-04-29 09:28:34.796 [DEBUG] [nternal.devices.bridge.BridgeHandler] - Found handler org.openhab.binding.boschshc.internal.devices.waterleakage.WaterLeakageSensorHandler@15624c2, calling processUpdate() for service WaterLeakageSensorTilt with state {"pushNotificationState":"DISABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"DISABLED"}
2024-04-29 10:05:05.786 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"path":"/devices/hdm:ZigBee:5cc7c1fffe1373ba/services/WaterLeakageSensorTilt","@type":"DeviceServiceData","id":"WaterLeakageSensorTilt","state":{"pushNotificationState":"DISABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"DISABLED"},"deviceId":"hdm:ZigBee:5cc7c1fffe1373ba"}],"jsonrpc":"2.0"}
2024-04-29 10:05:05.787 [DEBUG] [nternal.devices.bridge.BridgeHandler] - Got update for service WaterLeakageSensorTilt of type DeviceServiceData: {"pushNotificationState":"DISABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"DISABLED"}
2024-04-29 10:05:05.788 [DEBUG] [nternal.devices.bridge.BridgeHandler] - Found handler org.openhab.binding.boschshc.internal.devices.waterleakage.WaterLeakageSensorHandler@15624c2, calling processUpdate() for service WaterLeakageSensorTilt with state {"pushNotificationState":"DISABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"DISABLED"}
2024-04-29 10:05:05.842 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"sourceId":"hdm:ZigBee:5cc7c1fffe1373ba","sourceType":"DEVICE","@type":"message","flags":[],"messageCode":{"name":"TILT_DETECTED","category":"WARNING"},"location":"Küche ","arguments":{"deviceModel":"WLS"},"id":"efa0dc34-c962-4ae6-a084-2ef065a7afd8","sourceName":"Bosch_water_detector_1","timestamp":1714377905734},{"deleted":true,"@type":"message","flags":[],"arguments":{},"id":"da58cb28-3f18-4fa5-9b2e-b022d3e052a1","timestamp":0}],"jsonrpc":"2.0"}
2024-04-29 10:06:07.107 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"path":"/devices/hdm:ZigBee:5cc7c1fffe1373ba/services/WaterLeakageSensorTilt","@type":"DeviceServiceData","id":"WaterLeakageSensorTilt","state":{"pushNotificationState":"DISABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"DISABLED"},"deviceId":"hdm:ZigBee:5cc7c1fffe1373ba"}],"jsonrpc":"2.0"}
2024-04-29 10:06:07.109 [DEBUG] [nternal.devices.bridge.BridgeHandler] - Got update for service WaterLeakageSensorTilt of type DeviceServiceData: {"pushNotificationState":"DISABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"DISABLED"}
2024-04-29 10:06:07.110 [DEBUG] [nternal.devices.bridge.BridgeHandler] - Found handler org.openhab.binding.boschshc.internal.devices.waterleakage.WaterLeakageSensorHandler@15624c2, calling processUpdate() for service WaterLeakageSensorTilt with state {"pushNotificationState":"DISABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"DISABLED"}

The next TILT_DETECTED message could be generated only if the sensor is not moved for a minute (since the last TILT_DETECTED message).

However there are more message codes than TILT_DETECTED.

Message for water alarm comming:

2024-05-06 10:50:35.495 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"firstIncident":{"@type":"waterAlarmIncident","deviceId":"hdm:ZigBee:5cc7c1fffe1373ba","roomName":"Küche ","timestamp":1714985435372},"deleted":false,"@type":"waterAlarmSystemState","available":true,"videoActuatorsAvailable":false,"state":"WATER_ALARM","visualActuatorsAvailable":false},{"sourceId":"waterDetectionSystem","sourceType":"SERVICE","@type":"message","flags":["USER_ACTION_REQUIRED"],"messageCode":{"name":"WATER_ALARM","category":"ALARM"},"location":"Küche ","arguments":{"surveillanceEvents":"[{\"timestamp\":1714985435372,\"deviceName\":\"Bosch_water_detector_1\",\"location\":\"Küche \",\"type\":\"WATER_ALARM\",\"triggerId\":\"hdm:ZigBee:5cc7c1fffe1373ba\"}]"},"id":"7c942b97-f132-4b08-9c83-db9233ddee33","timestamp":1714985435373}],"jsonrpc":"2.0"}
2024-05-06 10:55:14.923 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"sourceId":"waterDetectionSystem","sourceType":"SERVICE","@type":"message","flags":["USER_ACTION_REQUIRED"],"messageCode":{"name":"WATER_ALARM","category":"ALARM"},"location":"Küche ","arguments":{"surveillanceEvents":"[{\"timestamp\":1714985714811,\"deviceName\":\"Bosch_water_detector_1\",\"location\":\"Küche \",\"type\":\"WATER_ALARM\",\"triggerId\":\"hdm:ZigBee:5cc7c1fffe1373ba\"}]"},"id":"08048e4f-ec5b-402a-9a05-5e792a3b64d7","timestamp":1714985714814},{"firstIncident":{"@type":"waterAlarmIncident","deviceId":"hdm:ZigBee:5cc7c1fffe1373ba","roomName":"Küche ","timestamp":1714985714811},"deleted":false,"@type":"waterAlarmSystemState","available":true,"videoActuatorsAvailable":false,"state":"WATER_ALARM","visualActuatorsAvailable":false}],"jsonrpc":"2.0"}

Message for water alarm going:

2024-05-06 10:50:41.386 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"deleted":false,"@type":"waterAlarmSystemState","available":true,"videoActuatorsAvailable":false,"state":"ALARM_OFF","visualActuatorsAvailable":false},{"sourceId":"waterDetectionSystem","sourceType":"SERVICE","@type":"message","flags":[],"messageCode":{"name":"WATER_ALARM","category":"ALARM"},"location":"Küche ","arguments":{"surveillanceEvents":"[{\"timestamp\":1714985435372,\"deviceName\":\"Bosch_water_detector_1\",\"location\":\"Küche \",\"type\":\"WATER_ALARM\",\"triggerId\":\"hdm:ZigBee:5cc7c1fffe1373ba\"},{\"timestamp\":1714985441281,\"deviceName\":\"Bosch_water_detector_1\",\"location\":\"Küche \",\"type\":\"ALARM_OFF\",\"triggerId\":\"hdm:ZigBee:5cc7c1fffe1373ba\"}]"},"id":"7c942b97-f132-4b08-9c83-db9233ddee33","timestamp":1714985441281}],"jsonrpc":"2.0"}
2024-05-06 10:55:20.303 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"sourceId":"waterDetectionSystem","sourceType":"SERVICE","@type":"message","flags":[],"messageCode":{"name":"WATER_ALARM","category":"ALARM"},"location":"Küche ","arguments":{"surveillanceEvents":"[{\"timestamp\":1714985714811,\"deviceName\":\"Bosch_water_detector_1\",\"location\":\"Küche \",\"type\":\"WATER_ALARM\",\"triggerId\":\"hdm:ZigBee:5cc7c1fffe1373ba\"},{\"timestamp\":1714985720194,\"deviceName\":\"Bosch_water_detector_1\",\"location\":\"Küche \",\"type\":\"ALARM_OFF\",\"triggerId\":\"hdm:ZigBee:5cc7c1fffe1373ba\"}]"},"id":"08048e4f-ec5b-402a-9a05-5e792a3b64d7","timestamp":1714985720194},{"deleted":false,"@type":"waterAlarmSystemState","available":true,"videoActuatorsAvailable":false,"state":"ALARM_OFF","visualActuatorsAvailable":false}],"jsonrpc":"2.0"}

Intrusion alarm coming

2024-05-06 11:53:24.170 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"deleted":false,"@type":"alarmState","incidents":[{"metaData":{"@type":"armingControlIncidentMetaData","profileId":"0"},"@type":"incident","id":"0","time":1714989159514,"type":"SYSTEM_ARMED"},{"metaData":{"alarmTrigger":{"deleted":false,"@type":"alarmTrigger","groupId":"intrusion:shuttercontact","id":"hdm:ZigBee:18fc260000097664"},"@type":"intrusionIncidentMetaData"},"triggerName":"Tür-/Fensterkontakt II Pl","@type":"incident","locationId":"hz_4","location":"Wohnzimmer","id":"hdm:ZigBee:18fc260000097664","time":1714989165663,"type":"INTRUSION_DETECTED"},{"metaData":{"alarmTrigger":{"deleted":false,"@type":"alarmTrigger","groupId":"intrusion:vibration","id":"hdm:ZigBee:18fc260000097664"},"@type":"intrusionIncidentMetaData"},"triggerName":"Tür-/Fensterkontakt II Pl","@type":"incident","locationId":"hz_4","location":"Wohnzimmer","id":"hdm:ZigBee:18fc260000097664","time":1714989204062,"type":"INTRUSION_DETECTED"}],"value":"ALARM_ON"},{"path":"/devices/intrusionDetectionSystem/services/SurveillanceAlarm","@type":"DeviceServiceData","id":"SurveillanceAlarm","state":{"@type":"surveillanceAlarmState","incidents":[{"triggerName":"Tür-/Fensterkontakt II Pl","locationId":"hz_4","location":"Wohnzimmer","id":"hdm:ZigBee:18fc260000097664","time":1714989204062,"type":"INTRUSION"},{"triggerName":"Tür-/Fensterkontakt II Pl","locationId":"hz_4","location":"Wohnzimmer","id":"hdm:ZigBee:18fc260000097664","time":1714989165663,"type":"INTRUSION"}],"value":"ALARM_ON"},"deviceId":"intrusionDetectionSystem"},{"sourceId":"intrusionDetectionSystem","sourceType":"SERVICE","@type":"message","flags":["USER_ACTION_REQUIRED"],"messageCode":{"name":"INTRUSION_ALARM","category":"ALARM"},"arguments":{"surveillanceEvents":"[{\"timestamp\":1714989165663,\"deviceName\":\"Tür-/Fensterkontakt II Pl\",\"location\":\"Wohnzimmer\",\"type\":\"INTRUSION_SHUTTER_CONTACT\",\"triggerId\":\"hdm:ZigBee:18fc260000097664\"},{\"timestamp\":1714989204062,\"deviceName\":\"Tür-/Fensterkontakt II Pl\",\"location\":\"Wohnzimmer\",\"type\":\"INTRUSION_VIBRATION_DETECTION\",\"triggerId\":\"hdm:ZigBee:18fc260000097664\"}]"},"id":"581205ca-7dd9-4ebb-ae8b-8d129dd7b155","timestamp":1714989204062}],"jsonrpc":"2.0"}

Intrusion alarm going

2024-05-06 11:53:36.058 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"path":"/devices/intrusionDetectionSystem/services/SurveillanceAlarm","@type":"DeviceServiceData","id":"SurveillanceAlarm","state":{"@type":"surveillanceAlarmState","incidents":[{"triggerName":"Tür-/Fensterkontakt II Pl","locationId":"hz_4","location":"Wohnzimmer","id":"hdm:ZigBee:18fc260000097664","time":1714989204062,"type":"INTRUSION"},{"triggerName":"Tür-/Fensterkontakt II Pl","locationId":"hz_4","location":"Wohnzimmer","id":"hdm:ZigBee:18fc260000097664","time":1714989165663,"type":"INTRUSION"}],"value":"ALARM_OFF"},"deviceId":"intrusionDetectionSystem"},{"deleted":false,"@type":"alarmState","incidents":[],"value":"ALARM_OFF"},{"deleted":false,"@type":"armingState","state":"SYSTEM_DISARMED"},{"sourceId":"intrusionDetectionSystem","sourceType":"SERVICE","@type":"message","flags":[],"messageCode":{"name":"INTRUSION_ALARM","category":"ALARM"},"arguments":{"surveillanceEvents":"[{\"timestamp\":1714989165663,\"deviceName\":\"Tür-/Fensterkontakt II Pl\",\"location\":\"Wohnzimmer\",\"type\":\"INTRUSION_SHUTTER_CONTACT\",\"triggerId\":\"hdm:ZigBee:18fc260000097664\"},{\"timestamp\":1714989204062,\"deviceName\":\"Tür-/Fensterkontakt II Pl\",\"location\":\"Wohnzimmer\",\"type\":\"INTRUSION_VIBRATION_DETECTION\",\"triggerId\":\"hdm:ZigBee:18fc260000097664\"},{\"timestamp\":1714989215949,\"type\":\"ALARM_OFF\"}]"},"id":"581205ca-7dd9-4ebb-ae8b-8d129dd7b155","timestamp":1714989215949},{"path":"/devices/intrusionDetectionSystem/services/SurveillanceAlarm","@type":"DeviceServiceData","id":"SurveillanceAlarm","state":{"@type":"surveillanceAlarmState","incidents":[],"value":"ALARM_OFF"},"deviceId":"intrusionDetectionSystem"},{"path":"/devices/intrusionDetectionSystem/services/IntrusionDetectionControl","@type":"DeviceServiceData","id":"IntrusionDetectionControl","state":{"activeProfile":"0","alarmActivationDelayTime":30,"actuators":[],"@type":"intrusionDetectionControlState","armActivationDelayTime":30,"triggers":[{"readonly":false,"active":true,"id":"hdm:ZigBee:18fc260000097664"},{"readonly":false,"active":true,"id":"hdm:ZigBee:30e8e40000d38246"},{"readonly":false,"active":true,"id":"hdm:ZigBee:30e8e40000d36404"}],"value":"SYSTEM_DISARMED"},"deviceId":"intrusionDetectionSystem"}],"jsonrpc":"2.0"}

So I identified some message codes:
"messageCode":{"name":"TILT_DETECTED","category":"WARNING"}
"messageCode":{"name":"WATER_ALARM","category":"ALARM"}...state":"WATER_ALARM"
"messageCode":{"name":"WATER_ALARM","category":"ALARM"}..."state":"ALARM_OFF"
"messageCode":{"name":"INTRUSION_ALARM","category":"ALARM"}
"messageCode":{"name":"INTRUSION_ALARM","category":"ALARM"},..."value":"SYSTEM_DISARMED"
"messageCode":{"name":"DEVICE_NOT_INITIALIZED","category":"INFO"},

Maybe we need an "event" channel so we could trigger on the event (for example on TILT_DETECTED)?

Sensor check
After starting the sensor alarm test on the Bosch app I got the log:

openhabian@openhabian:~ $ tail -n 1000 -f /var/log/openhab/openhab.log /var/log/openhab/events.log | grep -i ater
2024-05-06 14:44:10.618 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"path":"/devices/hdm:ZigBee:5cc7c1fffe1373ba/services/WaterLeakageSensorCheck","operations":["triggerCheck"],"@type":"DeviceServiceData","id":"WaterLeakageSensorCheck","state":{"result":"NONE","@type":"waterLeakageSensorCheckState"},"deviceId":"hdm:ZigBee:5cc7c1fffe1373ba"}],"jsonrpc":"2.0"}
2024-05-06 14:44:10.619 [DEBUG] [nternal.devices.bridge.BridgeHandler] - Got update for service WaterLeakageSensorCheck of type DeviceServiceData: {"result":"NONE","@type":"waterLeakageSensorCheckState"}
2024-05-06 14:44:10.619 [DEBUG] [nternal.devices.bridge.BridgeHandler] - Found handler org.openhab.binding.boschshc.internal.devices.waterleakage.WaterLeakageSensorHandler@15624c2, calling processUpdate() for service WaterLeakageSensorCheck with state {"result":"NONE","@type":"waterLeakageSensorCheckState"}
2024-05-06 14:44:10.621 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Bosch_water_det_1_Sensor_Check' updated to NONE
2024-05-06 14:44:10.623 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Bosch_water_det_1_Sensor_Check' changed from SUCCESS to NONE
2024-05-06 14:44:18.567 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"path":"/devices/hdm:ZigBee:5cc7c1fffe1373ba/services/WaterLeakageSensorCheck","operations":["triggerCheck"],"@type":"DeviceServiceData","id":"WaterLeakageSensorCheck","state":{"result":"SUCCESS","@type":"waterLeakageSensorCheckState"},"deviceId":"hdm:ZigBee:5cc7c1fffe1373ba"}],"jsonrpc":"2.0"}
2024-05-06 14:44:18.569 [DEBUG] [nternal.devices.bridge.BridgeHandler] - Got update for service WaterLeakageSensorCheck of type DeviceServiceData: {"result":"SUCCESS","@type":"waterLeakageSensorCheckState"}
2024-05-06 14:44:18.571 [DEBUG] [nternal.devices.bridge.BridgeHandler] - Found handler org.openhab.binding.boschshc.internal.devices.waterleakage.WaterLeakageSensorHandler@15624c2, calling processUpdate() for service WaterLeakageSensorCheck with state {"result":"SUCCESS","@type":"waterLeakageSensorCheckState"}
2024-05-06 14:44:18.574 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Bosch_water_det_1_Sensor_Check' updated to SUCCESS
2024-05-06 14:44:18.575 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Bosch_water_det_1_Sensor_Check' changed from NONE to SUCCESS

I could not change the sensor check item on the page, so I tried by using a rule. I was able to change the item but the item change did not trigger the sensor check.

2024-05-06 14:54:46.429 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Bosch_water_det_1_Sensor_Check' predicted to become ON
2024-05-06 14:54:46.431 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Bosch_water_det_1_Sensor_Check' updated to ON

david-pace · 2024-05-17T05:04:48Z

Hi @name-lake,

I just uploaded a new JAR 😎 Please delete the water detector thing, re-download, update, and then re-create your water detector thing.

Changes:

The water-leakage-sensor-check channel is now read-only. I would suggest we leave it like this for now because I have no idea how the check can be triggered via the REST API.
Added a new channel sensor-moved which should be triggered if the sensor is moved.

Please let me know whether the new channel works and if the system is stable. I assume you have some other Bosch things configured on your system? It would be good if you could quickly check whether they still get updates, too. Thanks for your support testing the new binding code 👍

name-lake · 2024-05-19T22:00:57Z

Hello @david-pace,
Thanks again for the software. 👍
I tested it, these are the results.

The binding version is:

Bosch SHC Binding
  SymbolicName org.openhab.binding.boschshc
  Version 4.2.0.202405170457

The new channel sensor-moved works; 👍
Each time the sensor was moved, the channel updated to the value ON.

However, there is a small issue. Once the channel has the value ON, it is always ON. So on the screen page, the channel is always ON.
I tried installing a timer, that would send the OFF command to the channel item after some seconds and... it worked. This is fine as long as the channel item is writable. 👍

david-pace · 2024-05-20T04:20:15Z

Thanks for the report @name-lake 👍

@jlaur what do you think - should we leave it as is, meaning that it is up to the user to reset the item whenever it is appropriate, for example by means of rules, or should we send a command to the sensor-moved channel in the binding code?

I would argue that the channel should only receive an ON command when we actually receive an event from the Smart Home Controller, and that any additional logics are up to the user. Do you agree?

mherwege · 2024-05-20T05:21:21Z

Why din’t you use a trigger channel instead of a switch channel for the detector? A trigger channel has no state, only sends a signal that can be interpreted by rules. Or an item can be attached using a profile. But had it has no state, it is often more useful to react in rules, e.g. send a push message when leakage detected. With a trigger channel you don’t have to worry about resetting state.

david-pace · 2024-05-20T08:36:44Z

Thanks for the hint, I was not aware of these kind of channels. I will enhance the code as soon as possible 👍

david-pace · 2024-05-24T14:00:07Z

Hi @name-lake, I uploaded a new JAR 👍 Please delete the thing again before testing the new version.

I turned the sensor-moved channel into a trigger channel now. Is the behavior now as expected? If you need it, here is the documentation on how to react on trigger events in rules.

Do you agree that we should leave the water-leakage channel as it is (with a Switch item)? Does the sensor go back to "No leakage detected" when you get it out of the water after the water alarm was activated?

name-lake · 2024-05-28T08:14:03Z

Hello @david-pace,
Thanks again for the software. 👍
These are the test results.

The binding version is:

Bosch SHC Binding
  SymbolicName org.openhab.binding.boschshc
  Version 4.2.0.202405241350

The trigger channel sensor-moved:
As you can see in the logging, after the messageCode TILT_DETECTED was received, the channel sensor-moved triggered. The trigger called then my script OnSensorMoved().
So it works very well, as expected. 👍

==> /var/log/openhab/openhab.log <==
2024-05-28 09:12:53.354 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[],"jsonrpc":"2.0"}
2024-05-28 09:12:53.355 [DEBUG] [.internal.devices.bridge.LongPolling] - Sending long poll request
2024-05-28 09:12:55.390 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"path":"/devices/hdm:ZigBee:5cc7c1fffe1373ba/services/WaterLeakageSensorTilt","@type":"DeviceServiceData","id":"WaterLeakageSensorTilt","state":{"pushNotificationState":"DISABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"DISABLED"},"deviceId":"hdm:ZigBee:5cc7c1fffe1373ba"}],"jsonrpc":"2.0"}
2024-05-28 09:12:55.392 [DEBUG] [nternal.devices.bridge.BridgeHandler] - Got update for service WaterLeakageSensorTilt of type DeviceServiceData: {"pushNotificationState":"DISABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"DISABLED"}
2024-05-28 09:12:55.393 [DEBUG] [nternal.devices.bridge.BridgeHandler] - Got update for device hdm:ZigBee:5cc7c1fffe1373ba
2024-05-28 09:12:55.394 [DEBUG] [nternal.devices.bridge.BridgeHandler] - Found handler org.openhab.binding.boschshc.internal.devices.waterleakage.WaterLeakageSensorHandler@fa9c56, calling processUpdate() for service WaterLeakageSensorTilt with state {"pushNotificationState":"DISABLED","@type":"waterLeakageSensorTiltState","acousticSignalState":"DISABLED"}
2024-05-28 09:12:55.395 [DEBUG] [.internal.devices.bridge.LongPolling] - Sending long poll request
2024-05-28 09:12:55.450 [DEBUG] [.internal.devices.bridge.LongPolling] - Long poll response: {"result":[{"sourceId":"hdm:ZigBee:5cc7c1fffe1373ba","sourceType":"DEVICE","@type":"message","flags":[],"messageCode":{"name":"TILT_DETECTED","category":"WARNING"},"location":"Küche ","arguments":{"deviceModel":"WLS"},"id":"b497a910-ddf4-48d8-abbc-92c256fe6c75","sourceName":"Bosch_water_detector_1","timestamp":1716880375322},{"deleted":true,"@type":"message","flags":[],"arguments":{},"id":"1280edc4-c693-4bed-b39f-6f31d52fc06b","timestamp":0}],"jsonrpc":"2.0"}
2024-05-28 09:12:55.452 [DEBUG] [.internal.devices.bridge.LongPolling] - Sending long poll request
2024-05-28 09:12:55.786 [INFO ] [org.openhab.rule.OnSensorMoved      ] - OnSensorMoved(), sensor moved
==> /var/log/openhab/events.log <==
2024-05-28 09:12:55.453 [INFO ] [openhab.event.ChannelTriggeredEvent ] - boschshc:water-detector:BC1:Bosch_water_detector_1:sensor-moved triggered

The channel water-leakage
The channel works as follows:
water alarm on -> the channel changes to Leakage detected
water allarm off -> the channel changes to No leakage detected
So it works well, no need to change it.

david-pace · 2024-05-30T03:26:40Z

Thank you all for the great teamwork in the scope of this enhancement ❤️ @name-lake @jlaur @mherwege @GerdZanker

name-lake added the enhancement An enhancement or new feature for an existing add-on label Mar 30, 2024

david-pace self-assigned this Apr 6, 2024

david-pace mentioned this issue May 18, 2024

[boschshc] Support for Smart Water Alarm #16770

Merged

david-pace added the PR pending There is a pull request for resolving the issue label May 18, 2024

jlaur closed this as completed in #16770 May 29, 2024

david-pace removed the PR pending There is a pull request for resolving the issue label May 30, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[boschshc] Add support for water detector #16593

[boschshc] Add support for water detector #16593

name-lake commented Mar 30, 2024

david-pace commented Mar 31, 2024

name-lake commented Apr 2, 2024

GerdZanker commented Apr 3, 2024

david-pace commented Apr 11, 2024

name-lake commented Apr 11, 2024

david-pace commented Apr 12, 2024

name-lake commented Apr 15, 2024

david-pace commented Apr 15, 2024

david-pace commented Apr 16, 2024

name-lake commented Apr 18, 2024

david-pace commented Apr 27, 2024

name-lake commented May 6, 2024

david-pace commented May 17, 2024 •

edited

name-lake commented May 19, 2024

david-pace commented May 20, 2024 •

edited

mherwege commented May 20, 2024

david-pace commented May 20, 2024

david-pace commented May 24, 2024

name-lake commented May 28, 2024

david-pace commented May 30, 2024

[boschshc] Add support for water detector #16593

[boschshc] Add support for water detector #16593

Comments

name-lake commented Mar 30, 2024

david-pace commented Mar 31, 2024

name-lake commented Apr 2, 2024

GerdZanker commented Apr 3, 2024

david-pace commented Apr 11, 2024

name-lake commented Apr 11, 2024

david-pace commented Apr 12, 2024

name-lake commented Apr 15, 2024

david-pace commented Apr 15, 2024

david-pace commented Apr 16, 2024

name-lake commented Apr 18, 2024

david-pace commented Apr 27, 2024

name-lake commented May 6, 2024

david-pace commented May 17, 2024 • edited

name-lake commented May 19, 2024

david-pace commented May 20, 2024 • edited

mherwege commented May 20, 2024

david-pace commented May 20, 2024

david-pace commented May 24, 2024

name-lake commented May 28, 2024

david-pace commented May 30, 2024

david-pace commented May 17, 2024 •

edited

david-pace commented May 20, 2024 •

edited