Closed name-lake closed 1 month ago
Hi @name-lake, thank you for your enhancement request. We are happy to extend the binding to support water detectors :+1:
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
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.
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.
Sorry, I have no water detector - I'm still using my several years old roller shutter, (floor heating) thermostats, twin guards and window contacts.
I have a first implementation ready for the water detector 😎
Before we start testing, I need some additional infos @name-lake:
openhab-cli console
, default password is habopen
)boschshc deviceInfo
WaterLeakageSensor
and WaterLeakageSensorTilt
Thank you 🙂
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!
Thanks @name-lake :+1:
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:
openhab-cli console
la -s | grep boschshc
bundle:update [bundle ID from previous step] /path/to/JAR.jar
(sometimes openHAB needs to be restarted)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:
Thanks for the implementation, I really appreciate it. :+1: 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:
...
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. :+1:
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:
The channel WaterLeakageSensor
appears to be working, the water alarm signal is transferred correctly. This is great because this is the most important channel. :+1:
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"}
boschshc:push-notifications
and boschshc:acoustic-signals
are not transferred at all, maybe due to the communication error related to the WaterLeakageSensorTilt
channel problem.Thank you for your detailed test report :+1:
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?
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:
WaterLeakageSensorTilt
service. This should enable the push-notifications-on-move
and acoustic-signals-on-move
channelsbattery-level
and low-battery
channelssignal-strength
channel for the CommunicationQuality
service (in line with the other devices supporting this service)Please let me know if the channels work as expected and if you are fine with the names and descriptions.
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. :+1:
I created things and items. :+1:
In my opinion, the channels name and descriptions are OK, thank you for the modification.
All channels:
The battery-levels channel shows the correct value (100%) for the sensor/battery is new. :+1:
The low-battery channel does not report an alarm, this is OK. :+1:
The water leakage channel still works properly. :+1:
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. :+1:
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?
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.
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:
!UNSUPPORTED!
outputs when running the boschshc deviceInfo
commandwater-leakage-sensor-check
that should give you a result of the last check as stringCurrently it looks like I cannot provide a channel like sensor-moved
or similar. In the JSON messages you provided the only information provided is:
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 :+1:
Hello @david-pace, Thanks for the software. :+1: 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: :+1:
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
. :+1:
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
)?
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
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:
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.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 👍
Hello @david-pace, Thanks again for the software. :+1: 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; :+1:
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. :+1:
Thanks for the report @name-lake :+1:
@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?
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.
Thanks for the hint, I was not aware of these kind of channels. I will enhance the code as soon as possible 👍
Hi @name-lake, I uploaded a new JAR :+1: 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?
Hello @david-pace, Thanks again for the software. :+1: 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. :+1:
==> /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.
Thank you all for the great teamwork in the scope of this enhancement ❤️ @name-lake @jlaur @mherwege @GerdZanker
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.