DDF for Ikea Device: BADRING Water Leakage Senor

DDF for Ikea Device: BADRING Water Leakage Senor

This is a working DDF for the recently released BRADING Water Leakage Sensor from IKEA:

  • The Device checks for water leakage in an interval of 1 minute. (it updates its status if it detects wet = true or dry = false once every minute).
  • I used the same settings for the battery status like other IKEA devices use, and it seems to be okay.
  • Basic testing was performed and the BRADING sensor changes it’s state accordingly and it is visible in the deCON Rest-API.

It would be great if someone performs some additional testing and I would be delighted to get some feedback and/or recommendations for improvements.

{
  "schema": "devcap1.schema.json",
  "manufacturername": "$MF_IKEA",
  "modelid": "BADRING Water Leakage Sensor",
  "vendor": "IKEA",
  "product": "BADRING Water Leakage Sensor",
  "sleeper": true,
  "status": "Silver",
  "path": "/devices/badring_water_leakage_sensor.json",
  "subdevices": [
    {
      "type": "$TYPE_WATER_LEAK_SENSOR",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x01",
        "0x0500"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/productid",
          "refresh.interval": 86400
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/alert",
          "default": "none"
        },
        {
          "name": "config/battery",
          "awake": true,
          "refresh.interval": 86400,
          "read": {
            "at": "0x0021",
            "cl": "0x0001",
            "ep": 1,
            "fn": "zcl:attr"
          },
          "parse": {
            "at": "0x0021",
            "cl": "0x0001",
            "ep": 1,
            "eval": "Item.val = Math.round(Attr.val / 2)",
            "fn": "zcl:attr"
          },
          "default": 0
        },
        {
          "name": "config/group"
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/lastupdated"
        },
        {
          "name": "state/water",
          "awake": true,
          "refresh.interval": 30,
          "read": {
            "at": "0x0002",
            "cl": "0x0500",
            "fn": "zcl:attr"
          },
          "parse": {
            "fn": "ias:zonestatus",
            "mask": "alarm1,alarm2"
          },
          "default": false
        }
      ]
    }
  ]
}

I am buying one online now and I’ll be able to test next week probably. Thanks for developing the DDF!

Ah! I wish I could! Not available in Ikea in my country yet.

Hi

This is exactly what I am looking for. I Just bought two Ikea Badring sensors, and has been trying to figure out how to make them accessable.

I am struggling figuring out how to edit the DDF. If I right click on the device in deConz and choose edit DDF I do not get anywhere I can edit the .json file directly.

I can click file and open. But I am not sure how I add a .json file with your configuration above, that can be accessed in that open file directory.

I hope you can help.

I am using a raspberry pi (linux based system), if you have a similar setup, you just can copy the json file in the /usr/share/deCONZ/devices/ikea directory. You should find there already other ddf files for most of the Ikea devices.

I had to restart deCONZ, then it associated the badring_water_leakage_sensor.json ddf file with the device. Note, the file permissions and ownership should be same as the other already existing files.

(I also tried to edit the ddf file on the GUI without much luck (maybe it is because I do not have much experiance with deCONZ and only use it since 2 weeks - and of course I didn’t read the manual yet).
It also stores the user modified ddf file in your user directory:
~/.local/share/dresden-elektronik/deCONZ/devices
in my case, it was not picked up, or I was just too impatient. For sure, you can also put a copy of the file in this directory, then it should according the manual not be overwritten by a regular update, and the device remains operating as is.

I hope this is of any help for you.
best regards and good luck to get it working ;O)

Cool that you got Badring working!
I’m not having any sucess though, running a supervised installation of HA.
Copied your json file to both file locations and made sure ownership and persmissions were the same as the other IKEA json files.
I try adding the device through Phoscon as a sensor but it never pops up there. I can see it is present in deconz but not with a correct name, it’s just a hex code number.
If I check cluster info it actually shows BADRING Water Leakage Sensor (but I think that was present before I addes your file).
Right clicking the node and choosing Edit DDF does show your code under the Preview tab.
I have restarted deconz several times but still no success.
Did you add the device in Phoscon and it showed up there as a new sensor?
Any help would be appreciated.

EDIT: Actually just got it working a few minutes ago, noticed your file had a path specified which the other json files did not have. Removed the path line and also changed status to Gold for the same reason.
My guess is that the path edit was the solution in my case.

Thanks a lot for your reply. I think there is something more fundamentally that I still have not understood.

I am also running Home Assistant on a Raspberry Pi. I have tried to access the file directory both through my computer through a SSH connection and through the “Advanced SSH & Web Terminal” ad-on directly in the browser-access to Home Assistant (again from my laptop).

image

In both cases it looks like I get access to a different file directory than showed through the DDF editor in DeConz.

I can not figure out how those two file directories are connected and if they have any folders in common? Or alternatively how which terminal/setup I need to access the directory that you screen-dumped above.

Great job, as you can see below I had some trouble getting it to pair properly but now it does and here’s some feedback:
Seems there’s an issue returning to “dry” state after “wet”. After it triggered as wet and I dried the sensor feet it still is at “wet” an hour later.

##deCONZ - Ikea Brading water leakage Sensor - Note 2024-03-24T17.03.09

  1. Copy the badring_water_leakage_sensor.json
    into the following directories:
    /usr/share/deCONZ/devices/ikea

    gma507@IOTMGW02:~ $ cd /usr/share/deCONZ/devices/ikea
    gma507@IOTMGW02:/usr/share/deCONZ/devices/ikea $ ls -l
    total 240
    -rw-r--r-- 1 root root   196 Feb 11 20:14 0006_presence.js
    -rw-r--r-- 1 root root   497 Feb 11 20:14 0008_rotaryevent.js
    -rw-r--r-- 1 root root   362 Feb 11 20:14 0400_lightlevel.js
    -rw-r--r-- 1 root root  2555 Mar 19 10:37 badring_water_leakage_sensor.json
    -rw-r--r-- 1 root root  4437 Feb 11 20:14 blind.json
    -rw-r--r-- 1 root root   934 Feb 11 20:14 e14_ws_opal_400lm_light.json
    

    and also into:
    ~/.local/share/dresden-elektronik/deCONZ/devices
    gma507@IOTMGW02:/usr/share/deCONZ/devices/ikea $ cd ~/.local/share/dresden-elektronik/deCONZ/devices
    gma507@IOTMGW02:~/.local/share/dresden-elektronik/deCONZ/devices $ ls -l
    total 4
    -rw-r--r-- 1 gma507 gma507 2328 Mar 14 11:11 badring_water_leakage_sensor.json
    gma507@IOTMGW02:~/.local/share/dresden-elektronik/deCONZ/devices $ 
    
  2. I deleted the existing Badring Sensor Device in my setup:


  1. Go into Control on the DDF folder and check if you have the Basic Mode activated, also tik at least Silver and Gold for the DDF status:

  1. Then go to Pairing and perform the joining procedure of the device:

the Badring Device was recoginzed within a couple of seconds and poped up as  0xAA21.
  1. After about 30 seconds, without any interaction from my side, it changed the name and also showed a battery state.

  1. Checking the Node List, the device is now also listed with the available information.
    I then clicked on the + sign on the device to show the cluster information.
    Then I right clicked and opened the Edit DDF:

  1. Now also the correct DDF file appears in the deCONZ setup:
    I did not adjust anything and went to the Preview folder:

  1. Here you should now see the uploaded ddf json file content:
    Note: I marked the status “Silver” in the json file, which means that you have to tick at least Silver under point 3, in order that the ddf file will be loaded in deCONZ.

  1. Now I went back to the Basic Cluster Information and we try to make them appear by first clicking on Basic and then press the read button under point 2. Important: As this kind of device is not always active, you can just wake it by simulating a leakage (I used a fork to shorten the 2 water detectors of the device). After max 1 minute the information should appear on the screen (marked by the green box):

  1. Now we repeat the same with the Power Configuration. Then press the read button and make sure y your device is beeping ;O)
    The information in the marked green box should be updated and it will also affect the battery state of the device in the right window (marked with an arrow on the screenshot):

  1. I then went on the Phoscon App, where I was able to rename the device.

  1. At last, I checked the API (which I am most interested in) and I marked the interesting values in green:
    the battery level is actually 84 % and water leakage is false:

  1. now I shorten the 2 water detectors of the device again and it starts beebing, within the following 60 seconds, the state should change to true (in my case this jus worked fine):

Done

I hope this is some kind of better help than last time.
Unfortunately I am not able to assist on Home Assistant related subjects, I do not have such a setup, sorry.

Hallo niklerus,

Thanks a lot for your feedback. To be honnest, I did not test my sensor with some water yet. I performed my testing by shortening the 2 sensor water detectors of the device with a metal fork (as I don’t want to play on my desk with water - already my desperatly needed coffee cup is a danger threat on my desk ;O)

Anyhow - testing with my fork worked well, but I obmit, that this afternoon I had a hickup too, after reconfiguring and documenting the hole setup process, deCONZ did not change the state to true, while testing it (the device was beeping - but the API always showed false). I had to shutdown the raspberry pi and to make sure also the raspbee II hat is poperly reset - I unplugged the powersupply for 15 seconds.

Just after completing the other reply, I performed another quick test and now it works well and within 60 seconds the state will change forth and back as expected:

true - at 18h45:22 ----> (see “lastupdated”: in API response)
As soon as I saw true in the API response, I lifted the fork from the sensor.
false again at 18h46:19 ---->(see “lastupdated”: “2024-03-24T18:46:19Z”, in API response)

In the ddf file I marked the relevant settings in below screenshot:

  1. at awake it will set the value true,

  2. I set the refresh.interval to 30 seconds (deCONZ will poll the value after 30 seconds past again - roughly (please refer to the manual for details). I set it to 30 seconds as the device will check its sensors every minute, and as soon as it has no contact (is dry) again, it should fall back to the default
    value which is set to false.

  3. the default value is set to false

you can plas with the refresh.interval, if you like. During my tests before publishing the ddf 10 days ago, I set it also to 10 and 15 seconds, but it will not differ much to the 30 seconds as the sensor checks its
own state only once within a minute. I also payed with values of 300 and 600 seconds (5 + 10 minutes), but then I took to long to switch back and the beeping was quiet anoying, so I aymed for 30 seconds, and within the next reading cycle it should switch off again.

So much to the theorie, and you have a good point. As now after reconfiguring and dry (fork) testing all is back to normal, and working as expected. I will now perform some tests with water…

I will come back once I have some feedback
Thanks and best regards

Great write up!
Unfortunately I’m going backwards in my progress, can’t get it to trigger for wet at all.
Removed badring from deconz and started over.
First time i followed your guide and paired it from within deconz, worked to some extent, added device “Water 109” or something and I could view the json preview and and all the cluster info and it was also present in Phoscon app.
However, it didn’t show up in the Node list and it didn’t send “wet” signal when I checked in the rest api.
Removed it again and added it from phoscon (as I usually do) and now it showed up in the node list in deconz also. So everything looked OK in deconz.
Still no response though in the rest api when shorting the sensor tabs (the fork thing you did was much smarter than using water…).
Have tried rebooting the system, powercycled conbee ii and so on.
I’m out of ideas really.

PS. do you need to short the sensor tabs for long for it to trigger? I tried for like a minute but no luck. The beeper does sound.

Hallo Niklerus,

Thanks for your reply and patience. I guess you know that testing will take some time ;O).
You had a good point and playing around for a while, I also recognized that if it beeps for a little longer, then it does not switch back from true to false again.

For on your reply of today, I guess you got it just working fine, and do not have to uninstall the device from your configuration (I just wrote this for the user b2cis as he mentioned in his post, that he couldn’t find the directories…)

Coming back to the issue you raised, yes it seems if the device goes back to sleep while the water leakeage is true, then it will not switch back the value on deCONZ and stays true while the device is already dry again. So I adjusted the ddf file a little and did some further testing, now it will switch back within some seconds (the most after 5 minutes) - while testing mine never took that long.

please find the new ddf file below - and copy it to ~/.local/share/dresden-elektronik/deCONZ/devices
directory for testing:

{
  "schema": "devcap1.schema.json",
  "manufacturername": "$MF_IKEA",
  "modelid": "BADRING Water Leakage Sensor",
  "vendor": "IKEA",
  "product": "BADRING Water Leakage Sensor",
  "sleeper": true,
  "status": "Silver",
  "path": "/devices/ikea/badring_water_leakage_sensor.json",
  "subdevices": [
    {
      "type": "$TYPE_WATER_LEAK_SENSOR",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x01",
        "0x0500"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/productid",
          "refresh.interval": 86400
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/alert",
          "default": "none"
        },
        {
          "name": "config/battery",
          "awake": true,
          "refresh.interval": 86400,
          "read": {
            "at": "0x0021",
            "cl": "0x0001",
            "ep": 1,
            "fn": "zcl:attr"
          },
          "parse": {
            "at": "0x0021",
            "cl": "0x0001",
            "ep": 1,
            "eval": "Item.val = Math.round(Attr.val / 2)",
            "fn": "zcl:attr"
          },
          "default": 0
        },
        {
          "name": "config/group"
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/lastupdated"
        },
        {
          "name": "state/water",
          "awake": true,
          "refresh.interval": 30,
          "read": {
            "ep": 2,
            "at": "0x0002",
            "cl": "0x0500",
            "fn": "zcl:attr"
          },
          "parse": {
            "fn": "ias:zonestatus",
            "mask": "alarm1"
          },
          "default": false
        }
      ]
    }
  ],
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0500",
      "report": [
        {
          "at": "0x0002",
          "dt": "0x19",
          "min": 10,
          "max": 300,
          "change": "0x0000"
        }
      ]
    }
  ]
}

As I had some time today - and now using the new ddf version, the Badring sensor reacts much more responsive. ( I also added it as Sensor Control to a group in order to switch on a light, when the Leakage Alarm is true) so I have a visual confirmation from deCONZ directly without the need of refreshing the API or GUI.

Now within 1 max 2 seconds, after shortening the senor (and beeping), the lights switches on. API and GUI show also after refreshing, immediatley the true. And after removing the fork, it will usualy take also 1 to 3 seconds to go back to false, bare in mind - for now I only have tiny setup with 4 switches 1 light, 1 motion sensor and 1 Badring; (here I do not have visual confirmation with the light, as it takes the light 2 to 4 seconds to switch off after the Badring sensor value got updated to false.

Thanks to your help, we have now a pretty responsive sensor setup.
I hope you also get it working fine within a short time.

Many thanks and greetings

Great! Got it to work and it is really responsive!
A bit strange that it was more or less “dead” before your edit, only got it to send wet signal once yesterday.
Thank you for your help!

Hello, I haven’t read all the post, so I can miss something, but using “refresh.interval” is not a good idea for battery device.
We use generaly a bind+report, for the device send itself value when it want.

  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0500",
      "report": [
        {
          "at": "0x0002",
          "dt": "0x19",
          "min": 10,
          "max": 300,
          "change": "0x0000"
        }
      ]
    }

This part is not enought to have return ? and the value 0x0000 is strange for me, it’s from the editor ? (for me you can remove this line)

This cluster géneraly don’t need bind, and if we set a bind, we don’t set a report.

Hallo Smanar,

Thanks for your input, so I adapted the ddf file and

  1. cleanded (removed) the refresh.interval which was part of the previous version and seemed not to work that well.
  2. I also removed the “change”: to “0x0000” completley (It did not came from the editor - sorry I did not use the editor)

To be honnest, I only use deCONZ since the 13th of march and I am not that familiar with it, so I do not know how to use the bindings in an efficiant / correct way. But I can tell, that with the former version which had no bindings, we had some issue to get the value back to “false”, and now it seems to work (somehow).

Maybe, you can enlighten me and give me some hints or let me know where to look at or read it up.

Please find the new adapted ddf file below, I also tested it quickly through and it all is still working and also has no decrease of it’s responsivness:

{
  "schema": "devcap1.schema.json",
  "manufacturername": "$MF_IKEA",
  "modelid": "BADRING Water Leakage Sensor",
  "vendor": "IKEA",
  "product": "BADRING Water Leakage Sensor",
  "sleeper": true,
  "status": "Silver",
  "path": "/devices/ikea/badring_water_leakage_sensor.json",
  "subdevices": [
    {
      "type": "$TYPE_WATER_LEAK_SENSOR",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x01",
        "0x0500"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/productid",
          "refresh.interval": 86400
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/alert",
          "default": "none"
        },
        {
          "name": "config/battery",
          "awake": true,
          "refresh.interval": 86400,
          "read": {
            "at": "0x0021",
            "cl": "0x0001",
            "ep": 1,
            "fn": "zcl:attr"
          },
          "parse": {
            "at": "0x0021",
            "cl": "0x0001",
            "ep": 1,
            "eval": "Item.val = Math.round(Attr.val / 2)",
            "fn": "zcl:attr"
          },
          "default": 0
        },
        {
          "name": "config/group"
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/lastupdated"
        },
        {
          "name": "state/water",
          "awake": true,
          "read": {
            "ep": 2,
            "at": "0x0002",
            "cl": "0x0500",
            "fn": "zcl:attr"
          },
          "parse": {
            "fn": "ias:zonestatus",
            "mask": "alarm1"
          },
          "default": false
        }
      ]
    }
  ],
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0500",
      "report": [
        {
          "at": "0x0002",
          "dt": "0x19",
          "min": 10,
          "max": 300
        }
      ]
    }
  ]
}

Thanks a lot for your imput, and let me kwnow your suggestions - I will try them out.
Greetings

The better way is using a good bind+report, like that the device make itself report when it want, some device have native bind/report (tuya or Xioami), and some of them have it for some clusters (generaly the 0x0500 don’t need report, but need bind)

If the report fail, or if the device don’t support it, deconz will detect it and make a poll.
Problem, it’s hard to make a poll on a sleeper device and realy bad for the battery.
Deconz look at value “min” and “max” to see if the report is working, if not, it look at “refresh.interval” and make a poll using the “read” value.

It’s for that “refresh.interval” NEED to be > “max” value.
And if you set a “read” part for a field, you NEED to set a “refresh.interval”, can use a 24h timer

"refresh.interval": 86400,

Else you can remove the “Read” part.

On your DDF, I think you can improve the “parse” part for the “state/water”, because without information deconz will use defaut value, and I m seing you need to use the EP=0x02, deconz by defaut can use the 0x01

Edit:
^^ ok, so your device have only one endpoint, it’s the number on top/left title node. So you can use defaut value (don’t add more information) but this part can’t work

"ep": 2,

For me you can remove all the “read” part for the “state/water”