Android-nRF-Mesh-Library icon indicating copy to clipboard operation
Android-nRF-Mesh-Library copied to clipboard

Any plans to support Generic Delta Set?

Open vkurkchi opened this issue 2 years ago • 3 comments

After digging into the documentation and the source code, I noticed that the current implementation does not support sending the Generic Delta (Generic Level) messages. The GenericLevelSet message sends the level with only 2 bytes(Mesh Model Spec, 3.2.2.2) without a simple way to morph the level message into delta, while delta messages require 4 bytes(Mesh Model Spec, 3.2.2.4) for the payload.

The solution seems to be pretty straightforward, we can have a class that duplicates the GenericLevelSet interface (let's say GenericLevelDeltaSet) with a different opCode (0x8209), and instead of sending the level with 2 bytes, we can have a delta field of 4 bytes.

Currently, as an alternative, I use a hack like this one:

class GenericLevelDeltaSet(
    appKey: ApplicationKey,
    delta: Int,
    tId: Int,
    transitionSteps: Int? = null,
    transitionResolution: Int? = null,
    delay: Int? = null,
) : GenericUserPropertySet(appKey,
    (delta and 0xFFFF).toShort(),
    if (transitionSteps == null || transitionResolution == null || delay == null) {
        ByteArray(3).apply {
            set(0, (((delta shr 16) and 0xFF).toByte()))
            set(1, (((delta shr 24) and 0xFF).toByte()))
            set(2, ((tId and 0xFF).toByte()))
        }
    } else {
        ByteArray(5).apply{
            set(0, (((delta shr 16) and 0xFF).toByte()))
            set(1, (((delta shr 24) and 0xFF).toByte()))
            set(2, ((tId and 0xFF).toByte()))

            set(3, ((((transitionResolution shl 6) or transitionSteps) and 0xFF).toByte()))
            set(4, ((delay and 0xFF).toByte()))
        }
    }) {
    override fun getOpCode(): Int {
        return 0x8209 // Generic Delta Set
    }
}

In the hack above, I split the delta into "propertyId" and "values" fields.

In general, having a generic application message class for extension would be great (let's say making ApplicationMessage public), that way you can introduce a predictable way for extending the supported messages list.

vkurkchi avatar Nov 09 '23 12:11 vkurkchi

Currently I am occupied with other tasks. We are open to PRs :)

roshanrajaratnam avatar Nov 09 '23 20:11 roshanrajaratnam

@roshanrajaratnam I've created a PR, also I have one more suggestion, should I create feature request first, or make a PR so you can have a look?

vkurkchi avatar Nov 10 '23 10:11 vkurkchi

Hi thanks for the PR, I will have to take a look at this on Monday. Don't forget to sign the CLA on the PR.

Please do create a feature request first so we can take it from there. The reason being this library will go into maintenance mode as we are working on a Kotlin library internally.

Thanks again for your contribution :)

roshanrajaratnam avatar Nov 10 '23 12:11 roshanrajaratnam