DDF for Ikea Device: BADRING Water Leakage Senor

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.

1 Like

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”

Hi,

I hope that somebody can help me out as aI am obviously incapable getting the Badring sensor to work with my conbee2 stick.
Initially I thought that the BAdring sensor might not be supported by the Conbee2 stick but @niklerus is stating that he was successful pairing the Badring with the Conbee2.

I was following the steps mentioned from @gma507 to connect the Badring but I don’t get the device displayed in deconz?

Any suggestions what can I try to make it work?

Thanks

Did you restart deCONZ after adding the file? I added the sensor a few days ago. I just downloaded deconz-rest-plugin/devices/ikea/badring_water_leak_sensor.json at master · dresden-elektronik/deconz-rest-plugin · GitHub and put it into /home/pi/.local/share/dresden-elektronik/deCONZ/devices/ikea, restarted deCONZ and I was able to pair it without problems

Hallo elrollo,

It seems that you can also add the device from the Phoscon App and this seemed to work better for niklerus (please rever to his post from the 25th of March 2024) as per below:

[niklerus] Mar 25

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.

For Reference: I currently use deCONZ Version v2.26.2-beta on a Raspberry Pi.

Sorry for not beeing able to help you better. During my tests, I deleted the different IKEA devices for several times including the Badring Sensor completely from the Setup and did not experiance any trouble to bind it again.

ok, there are 2 things which are confusing me.
1.) I have decent running in in docker. so I am struggling with where I have to put the DDF into as the home/pi/.local/share/dresden-elektronik/deCONZ/devices/ikea is not existing for me neither locally on the nor within the docker itself?
2.) according to the binding procedure its that you need to press the pairing button 4 times, then the LED should flash shortly and then the LED should start again flashing to indicate connection attempt but mine does not do this. It only flashes after pressing the pair button 4 times but after the LED stays dark. Can it be that there is an issue with the sensor?

The path depends on your setup. See DDF cheat sheet · dresden-elektronik/deconz-rest-plugin Wiki · GitHub. I dont know about docker

I don’t remember mine flashed. Maybe I tried keeping it pressed and/or press it 4 times.

thanks a lot guys - it works now …
The issue I was is somehow embarrassing but it looks like as the battery I was using was an old one. After replacing it works :smiley:

Thanks again!

Hi. I am trying to add a “IKEA Badring” to my setup, but I fail.
My setup:

  • iobroker on Raspberry Pi 4, 64bit OS, all up-to-date; the Raspi is has no monitor, so I access it via SSH only
  • I use a Conbee II, pluged into the Raspi
  • using deCONZ adapter v1.41; this adapter reports deConz Version: 2.26.3 and API Version: 1.16.0
  • using sudo nano I have manually created a file called “badring_water_leak_sensor.json” in the two locations mentioned above in this thread:
    /usr/share/deCONZ/devices/ikea
    ~/.local/share/dresden-elektronik/deCONZ/devices
  • into this file I pasted the content from deconz-rest-plugin/devices/ikea/badring_water_leak_sensor.json at master · dresden-elektronik/deconz-rest-plugin · GitHub
  • adapter has been restarted and Phoscon app via webfrontend has been restarted

Neither the Phoscon app under sensors nor the deCONZ adapter is recognizing the Badring device.

Questions:

  1. Any advice how I can connect the device?
  2. I was surprised that in the folders mentioned above there was no ddf file for this device as the software from my side seems as much up-to-date as possible. Why would that be?
  3. I am wondering if there is one more file location for the deCONZ adapter where there should be this ddf file. Maybe the adapter is not looking into /usr/share/deCONZ/devices/ikea but somehwere else?

1 - Recent version have native support, but actual one can just refuse to reconise ikea device, so I think yes you are doing the good thing, what is a “deconz adapatater” ?
2 - the second folder is a “user” folder, so if it’s your first DDF, this one is empty, the first one NEED to have DDF.

Stupid question, but iobroker don’t use virtual machine ?