Pairing not enabling RFDL-ZB-MS motion sensing, did before just fine

General
1

I have many of these Bosch RFDL-ZB-MS multi-sensors (temp, lux, motion)… and they all added quickly and worked fine on Conbee 1 and prior versions, never an issue. I even added a few to Z2M a month or two ago, they all work.

I decided to add a few more motions to Deconz and have tried 10 times to add them, same issue every time. Even when I’m pairing it 6 ft open air to the Conbee3

It pairs with Temp and Lux but never motion. When I force Deconz to ‘read’ the clusters they all readon quickly and correctly. The only difference I’ve seen in Deconz is on one cluster.
I’d attached screenshots and log link (really wish Deconz just logged to a file!)

sensors that bind to the cluster 055 IAS Zone (07), look like this…

image
image1029×1490 162 KB

sensors that do not bind to the cluster look like this…

image
image1007×1446 154 KB

image
image2785×1127 173 KB

2

Deconz can log to a file when modifying the start process > How to get logs?

What log levels are these?

Can you also share screens of the basic clusters?

3

I turns on ALL debug items since I have no idea what is needed.

When I look at all the sensors I’m seeing that even some of the ‘working’ ones dont have all the data read populated in Basic… and they have been working for 6+ months.

Hypothesis #1… Deconz is reading all cluster data on initial pairing. Even though these Bosch devices stay awake for 5mins. I’ve tested this on both Bosch and Aqara (Lumi) devices by simply clicking ‘read’ button on each Cluster after initial pairing and all the devices populate the cluster, even the not-so-easy Aqara sensors. Event the two recently added Bosch devices populate all clusters except for IAS Zone … so I suspect this is a different problem specific newer Deconz code as the other Bosch devices were added with Conbee1 and much older Deconz code (6+ months ago)

Hypothesis #2… I suspect Deconz is missing code to queue a device inspection upon next wake to gather missing data.

properly populated Basic Cluster from a not working Bosch…

image
image999×1046 185 KB

image
image1007×1072 203 KB

properly populated Basic Cluster from a working Bosch…

image
image999×1039 183 KB

image
image996×1047 199 KB

not properly populated Basic Cluster from a working Bosch…

image
image990×1038 205 KB

image
image1006×1042 221 KB

re Log Files…
Logging to file should simply be a checkbox (like 99% of all apps in the world - even poorly written ones like I make) people should not need to start/stop any app, ever, to log to a file… its literally 1 line of code to write to a file what you are writing on screen.
Same goes for Clusters… we should have a button that says, ‘Save Cluster data to file’. In Deconz you cant screenshot the entire set of cluster info in Basic (its too large); and you cant select and manually copy the tables either. I’m a crappy coder and I could write this code. Seriously, 5 mins (at most) for a good coder to put this in.

4

You can read them by clicking the button on the device and click “read” in the basic cluster.

In Linux, its quite normal to do it like this. Feel free to create a Pull request or feature request. Be the solution :wink:

On topic:

Looks like your Not working bosch sensors have a different version on Application Version.

image
Working one:
image

You need to Update them i suppose.

5

@Ltek What’s the deconz version, please?

The device is supported by legacy code only and apparently gets stuck in a loop to read attribute 0x0006 of the basic cluster upon discovery and doesn’t continue. Based on the debug log, the response seems to be a NULL byte.

I’d recommend taking the DDF drafted by deconz, share and fine tune it here and use that one from there on. That should eliminate quite some culprits, including any queries of the date code attribute.

6

I was on 2.6.3 and just installed 2.70… same problem. I thought everything was being moved to DDF?

What “DDF drafted by Deconz” are you referring to? I dont see it Supported Devices - deCONZ REST-API

I’ve never created a DDF so this is 100% new territory for me. Seems like they could have Deconz automatically create the base DDF for a given device after reading its attributes during pairing… that would save a TON of time for everyone.

7

… as I mentioned in the first post, ‘read’ doesnt help.

I dont know what ‘Application Version’ means?
These are all the same model sensor, and they all read full/properly on pairing with Z2M and work great (for a while)

so you are asking, I’m sure… “why leave Z2M if they work on it”… yeah, BUT a few hours to a few days on Z2M and newly added devices will not stay connected. All kinds (Osram, Aqara, Lumi, Bosch), when the network is larger than around 10 devices, even devices on mains (not just battery) … they work great then fall off even when LQI is over 200.

8

Hello, can try this DDF

{
  "schema": "devcap1.schema.json",
  "manufacturername": "$MF_BOSCH",
  "modelid": "RFDL-ZB-MS",
  "vendor": "Bosch",
  "product": "Motion sensor",
  "sleeper": true,
  "status": "Gold",
  "subdevices": [
    {
      "type": "$TYPE_PRESENCE_SENSOR",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x01",
        "0x0500"
      ],
      "fingerprint": {
        "profile": "0x0104",
        "device": "0x0402",
        "endpoint": "0x01",
        "in": [
          "0x0000",
          "0x0001",
          "0x0500"
        ]
      },
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/battery",
          "parse": {
            "at": "0x0021",
            "cl": "0x0001",
            "ep": 1,
            "eval": "Item.val = Attr.val / 2",
            "fn": "zcl:attr"
          }
        },
        {
          "name": "config/enrolled",
          "public": false
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/pending"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/presence",
          "awake": true
        },
        {
          "name": "state/lastupdated"
        },
        {
          "name": "state/lowbattery"
        }
      ]
    }
  ],
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0001",
      "report": [
        {
          "at": "0x0021",
          "dt": "0x20",
          "min": 600,
          "max": 43200,
          "change": "0x00000001"
        }
      ]
    },
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0500"
    }
  ]
}

To use them you can try the next deconz feature, the " DDF Bundle Support" Release v2.27.0-beta · dresden-elektronik/deconz-rest-plugin · GitHub if you are on version 27

1 Like
9

@Smanar I uploaded the DDF using Phoscon but its not being used by Deconz. I even restarted Deconz, same issue. Then I tried using Deconz ‘Edit DDF’ on a few of the devices… nothing shows loaded (I suspect because its still using legacy code)… and the tab doesn’t allow me to copy the JSON into the tab. How can I load that DDF and get it to auto-activate like the docs show?

10

You need to upload a bundle, not the json itself. that needs to be generated from a PR in github (as i’m told). @manup can explain a bit better here.

11

Ha yes, right, I m trying unsuccessfuly on my side, so it mean it’s not possible to try a personnal DDF ?

But someone have succeded Tuya Scene Switch TS0044 TZ3000_a4xycprs · Issue #7619 · dresden-elektronik/deconz-rest-plugin · GitHub

Edit:
I have confirmation from Zorimyll, not possible without PR.
What is your OS @Ltek ? if you haven’t docker just create a text file in a “devices” folder with the DDF contain, and call the file waht_you_want.json, then restart deconz.

All DDF provided directly with deCONZ typically reside in /usr/share/deCONZ/devices/on a Linux system and are loaded first. However, files residing in the home directory of the user running deCONZ (e.g./home//.local/share/dresden-elektronik/deCONZ/devices) will override the pre-packaged files to allow users to amend and keep their own files if desired.

12

@smanar I recommend you read the discord dev chat, I had a chat about it yesterday

13

Usually, deconz is able to suggest or draft a DDF for legacy devices when you right click on a device and select “edit DDF”. This typically works best if deconz is already running for some time, let’s say 30-60 mins, as then the majority of the legacy defined bindings are also available. Please also refer to the DDF cheat sheet in the wiki of the repository. However, it seems that the DDF mechanism currently has a bug and that would explain why nothing shows up (if I understood correctly). This typically saved quite some time and is pretty easy and convenient to handle.

Please do take note that the proposed DDF here is missing quite some content. Temperature and light level wouldn’t work anymore in that state.

14

@Swoop When I tried making a ‘draft ddf’ (right click on a device, “Edit DDF”) its 100% empty – I tried 5 Bosch sensors, even the ones that work / display all the properties in Deconz.

image

@Smanar running Windows 10 with Deconz installed in root of C drive
put the JSON (attached in ZIP) in 3 different places, DDF is not loading
C:\deCONZ\devices\bosch
C:\deCONZ\devices
C:\Users\LTek\AppData\Local\dresden-elektronik\deCONZ\devices

btw, uploading “Bundles” seems more work harder than simply having Deconz upload the ‘personal’ DDF… not sure why the UI doesnt just upload a DDF for us?

My hypothesis is some sort of bug in more recent versions of Deconz specific to cluster 055 IAS Zone (07)… the only diff between Bosch’s that have Motion attributes showing are some of the settings in this cluster.

15

Me neither…

16

Will be probably the next step, still beta feature.

@Ltek sorry, was my fault, have made a typo on the DDF, have corrected the previous code (miss a “,”) Pairing not enabling RFDL-ZB-MS motion sensing, did before just fine - #8 by Smanar
Your used path seem good, I don’t see the “attached zip”, but you just need to use the DDF contain in a text file called what_you_want.json.

For information deconz just use the modelID/Manufacture name to choose a DDF (it don’t take care of clusters)
And I can’t make a test on my side ATM, but strange on your side the “draft” DDF don’t have them, and more if thoses values are known by deconz for somes of your sensors.

17

I just created a DDF using a good-working RFDL-ZB-MS sensor and added it to the \devices folder.

Now Deconz has changed all the devices. Notice the little motion guy is now a siren? And the Master Bath is now a temp icon? Huh?

From this…

image
image2908×1138 179 KB

To this…

image
image2859×763 115 KB

18

Can you share the used DDF ?

19

JSON…

{
  "schema": "devcap1.schema.json",
  "manufacturername": "Bosch",
  "modelid": "RFDL-ZB-MS",
  "vendor": "Bosch",
  "product": "Motion sensor",
  "sleeper": true,
  "status": "Gold",
  "subdevices": [
    {
      "type": "$TYPE_PRESENCE_SENSOR",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x01",
        "0x0500"
      ],
      "fingerprint": {
        "profile": "0x0104",
        "device": "0x0402",
        "endpoint": "0x01",
        "in": [
          "0x0000",
          "0x0001",
          "0x0500"
        ]
      },
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/battery",
          "parse": {
            "at": "0x0021",
            "cl": "0x0001",
            "ep": 1,
            "eval": "Item.val = Attr.val / 2",
            "fn": "zcl:attr"
          }
        },
        {
          "name": "config/enrolled",
          "public": false
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/pending"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/presence",
          "awake": true
        }
        {
          "name": "state/lastupdated"
        },
        {
          "name": "state/lowbattery"
        }
      ]
    }
  ],
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0001",
      "report": [
        {
          "at": "0x0021",
          "dt": "0x20",
          "min": 600,
          "max": 43200,
          "change": "0x00000001"
        }
      ]
    },
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0500"
    }
  ]
}
20

So yes, IDK why Phoscon display this sensor, nothing in DDf can explain that.

But you can take a look direcly in the API using Phoscon/help/API Information/sensors