DDF for Sonoff ZBMini R2 Extreme (ZBMINIR2)

[duffbeer2000]

Product name: Sonoff ZBMini R2 Extreme
Manufacturer: Sonoff
Model identifier: ZBMINIR2
Device Type: Smart Switch

Fixes Issue #8020 with help of @Smanar

[Smanar]

But you miss the c++ part ?

The validator don't reconise "range" here

          "write": {
            "fn": "zcl:attr",
            "ep": 1,
            "cl": "0xfc11",
            "at": "0x0015",
            "dt": "0x21",
            "eval": "Item.val",
	          "range": [
              1,
              3600
            ]
          },

[github-actions]

Hey @duffbeer2000, thanks for your pull request!

Tip

Modified bundles can be downloaded here.

DDB changes

Modified

• sonoff/zbminir2_relay.json : Sonoff ZBMINI R2 Extreme ✔️

Validation

Tip

Everything is fine !

_{🕐 Updated for commit dad115b}

[duffbeer2000]

But you miss the c++ part ? --> Like I mentioned in my commit "add zbminir2 to button_maps, needs changes from smanars pull request …" and discord chat ;) but I made a pull from your fork now.

The validator don't reconise "range" here" --> corrected that one

[manup]

The PR adds a new item config/on/delayedpoweron.
@ebaauw @SwoopX I think it's ok, what are your opinions, shall we include it as such?

{
  "schema": "resourceitem1.schema.json",
  "id": "config/on/delayedpoweron",
  "datatype": "Bool",
  "access": "RW",
  "public": true,
  "description": "Delays On/Off state on device startup (power on)."
}

[SwoopX]

@manup I'm afraid following the line of argumentation of the manup from the past, that would be a no. The item at hand would be a prime example of such a response.

However, that brings me once again to the topic of not having any guidance when we might want to expose a resource item and when not. If new ones are exposed, documentation is often lacking or incomplete.

I would personally like to introduce additional 5-10 items but haven't done so, as they do not necessarily match to the requirement(s) discussed.

[ebaauw]

I don't understand why we need two items, config.delay and config.on.delayedpoweron. Also a very non-standard use of config.delay (i.e. different from how it's used on ZHAPresence resources). I would propose to make a single numeric config.on.poweron_delay, and use value 0 to disable it. Since the configuration concerns the output wire, it should be on the lights resource (as should config.on.poweron).
I suppose, functionally it makes sense, after an outage, to delay the power on of appliances that consume a lot of power, not to cause the circuit breaker to overload. For a wired lights switch I fail to see a use case.

Also not happy about the myriad of modes taking device-specific values: config.clickmode, config.devicemode, config.mode. I think most of these should be on the lights resource as well, not on the ZHASwitch sensors resource.

I agree with @SwoopX that we need more guidance on when and how to introduce resource items. Ideally, the API would become self-describing, so API clients don't need to rely on (outdated or missing) documentation. It would definitely like to see capabilities resources describing the values for config.clickmode, config.devicemode and config.mode.