Deconz-rest-plugin: Unexpected JSON response in rule conditions

Created on 1 Sep 2017  路  7Comments  路  Source: dresden-elektronik/deconz-rest-plugin

The JSON type of the value property in conditions not always correct. Depending on the called rest endpoint (getFullState / getAllRules) it returns null or a string. Only the response of the rule by id endpoint is as expected (getRule).

Some examples with annotations:

Full state: http://{{host}}/api/{{username}}
rest_rules.cpp#L180 missing null check?

"conditions": [
    {
        "address": "/sensors/5/state/buttonevent",
        "operator": "eq",
        "value": 16
    },
    {
        "address": "/sensors/5/state/lastupdated",
        "operator": "dx",
        "value": null      [Not expected]
    }
]

http://{{host}}/api/{{username}}/rules
rest_rules.cpp#L100 remove toString?

"conditions": [
    {
        "address": "/sensors/5/state/buttonevent",
        "operator": "eq",
        "value": "16"     [Expect an int, no quotes]
    },
    {
        "address": "/sensors/5/state/lastupdated",
        "operator": "dx"  [OK, no value null]
    }
]

http://{{host}}/api/{{username}}/rules/{{id}}

"conditions": [
    {
        "address": "/sensors/5/state/buttonevent",
        "operator": "eq",
        "value": 16
    },
    {
        "address": "/sensors/5/state/lastupdated",
        "operator": "dx"
    }
]

http://{{host}}/api/{{username}}

"conditions": [
    {
        "address": "/sensors/8/state/open",
        "operator": "eq",
        "value": true       [OK]
    },
    {
        "address": "/sensors/8/state/lastupdated",
        "operator": "dx",
        "value": null       [Not expected]
    }
]

http://{{host}}/api/{{username}}/rules

"conditions": [
    {
        "address": "/sensors/8/state/open",
        "operator": "eq",
        "value": "true"     [Expect boolean, no quotes]
    },
    {
        "address": "/sensors/8/state/lastupdated",
        "operator": "dx"
    }
]

http://{{host}}/api/{{username}}/rules/{{id}}

"conditions": [
    {
        "address": "/sensors/8/state/open",
        "operator": "eq",
        "value": true       [OK]
    },
    {
        "address": "/sensors/8/state/lastupdated",
        "operator": "dx"    [OK]
    }
]

All 7 comments

Good catch I'll currently work on the rules and will check the null issues.

The values actually are exposed as string and will be cast to their respective data type.

Official hue description

value, string 1..64: The resource attribute is compared to this value using the given operator. The value is cast to the data type of the resource attribute (in case of time, casted to a timePattern). If the cast fails or the operator does not support the data type the value is cast to the rule is rejected.

Output from the hue bridge:

"conditions": [
            {
                "address": "/config/localtime",
                "operator": "in",
                "value": "T08:00:00/T23:00:00"
            },
            {
                "address": "/sensors/9/state/presence",
                "operator": "eq",
                "value": "true"
            },
            {
                "address": "/sensors/9/state/presence",
                "operator": "dx"
            },
            {
                "address": "/sensors/11/state/status",
                "operator": "lt",
                "value": "1"
            },
            {
                "address": "/sensors/10/state/dark",
                "operator": "eq",
                "value": "true"
            }
        ]

The wrong string cast is fiexed now, however I couldn't find why you get null values, the code does check for it.

Which version of deCONZ are you running?

Here is output on my PC:

"conditions": [
        {
            "address": "/sensors/21/state/status",
            "operator": "gt",
            "value": "-1"
        },
        {
            "address": "/sensors/20/state/presence",
            "operator": "eq",
            "value": "true"
        },
        {
            "address": "/sensors/20/state/presence",
            "operator": "dx"
        }
    ]

Ah I see ruleToMap() has the error ...

You might also check and filter an empty body in an action (typically the case when recalling a scene). As the Hue syntax for recalling scenes differs, there's no comparing to the Hue bridge here.

I'm still seeing some inconsistencies with rule responses on 2.04.73 - see #169 for a sample response.

The commit with the fix is from after 2.04.73 - you'll have to wait for the next version, or compile the REST API plugin yourself using this commit (or a later one).

Should be resolved in version 2.04.75, I close this for now.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

qm3ster picture qm3ster  路  3Comments

flex-0 picture flex-0  路  4Comments

salopette picture salopette  路  4Comments

horchi picture horchi  路  5Comments

1onar picture 1onar  路  5Comments