Updates for Ubisys H1

[SwoopX]

Puh, totally valid while yet so difficult. The "problem" with the PR is that it would screw any device with firmware 1.40 🤔 Could you please share a screenshot of the basic cluster with read attributes?

@manup we definitively need a way to use different DDFs per firmware version. For this device, the attributes change quite a bit between the versions. And while we're at it, we also should enable per device DDFs (based on MAC?) 😄

[jan666]

Will do the screenshots tomorrow.

It will not really screw those with 1.4, offset will just not work. Like it was the other way from 1.4 to 1.5. Plus deCONZ stable with 1.4 DDF was not yet released.

...and everyone should update anyways:

[jan666]

Could you please share a screenshot of the basic cluster with read attributes?

[manup]

@manup we definitively need a way to use different DDFs per firmware version. For this device, the attributes change quite a bit between the versions.

Yes absolutely, I'm currently doing a larger refactor of the DDF loader to support DDF bundles and here also extend the capabilities for DDF matching. Basic idea is to query and store more Basic Cluster attributes from the device before the actual DDF is matched. Then let the optional "matchexpr" do its thing.

The trickier part will be that after OTA updates this also needs to be refreshed and we need to be careful not to check for specific versions (?), imagine update a device from version 2 to 3 and only 2 has a DDF :D

And while we're at it, we also should enable per device DDFs (based on MAC?) 😄

This is part of the whole DDF bundle thing — I hope we can schedule a demo soon to shed some light on that topic. There a lot which needs to be figured out but this very topic is party discussed here: https://github.com/dresden-elektronik/deconz-rest-doc/pull/48

The idea is to pin DDFs (bundles / aka one file) to a device. No magic update all or nothing, although that can be a button but not be the default.

[SwoopX]

Well, purely from a change perspective, everything looks ok to me. The last 3 (new) attributes are r/w, but I guess nobody touches them anyway so it shouldn't really matter.

@manup Just saying: a distinction based on the first basic cluster attributes wouldn't work here as it seems, so a version check would also need to allow SW Build ID in this case. What's your opinion on merging this one here?

Is an update after OTA really tricky? I thought the device would reboot and thereby issue a device announce? Based on that, the state machine could do its thing (again)?

[jan666]

Can you do this with https://github.com/dresden-elektronik/deconz-rest-plugin/pull/7642 now?

[SwoopX]

Can you do this with #7642 now?

@jan666 yes, indeed. Do you want to make the necessary amendments?

[jan666]

you want to make the necessary amendments?

@SwoopX I dont really know how... maybe it's better you do it?

[SwoopX]

@jan666 Sorry, I can't. It's not my PR and I don't have the device, hence cannot test it.

However, it should be as easy as the PR description says. Add attr/otaversion to the DDF and place below line under "status": "gold"with an appropriate value being equal or greater than your value (OTA cluster attribute 0x0002, see PR 7643).

"matchexpr": "var v = R.item('attr/otaversion').val; (v != 0 && v < 0x23079631);"

[github-actions[bot]]

Hey @jan666, thanks for your pull request!

[!TIP] Modified bundles can be downloaded here.

DDB changes

Modified

• ubisys/h1.json : H1 :heavy_check_mark:

Validation

[!TIP] Everything is fine !

_{:clock6: Updated for commit 5711f86b61504c5eeaf5576aa58213b1b0111fac}

[jan666]

Not needed anymore. New pull request for new version 1.7: https://github.com/dresden-elektronik/deconz-rest-plugin/pull/7841