Hue sensor does not switch off nor dim light

[ooii]

So, I'm continuing my deConz setup in replacement of my Hue bridge. I figured out how to add bulbs and I'm now working on automation through the Phoscon app. I managed to make lights switch on upon a motion but they are never dimmed nor switched off. Here are the transitions and settings. My four sensors are behaving the same way. What Am I doing wrong?

[manup]

I think the recently added config.delay for sensors causes this. I've fixed the code to create the sensor rules now. Please try again with version 2.05.15 which should arrive later today.

After installing 2.05.15 you need to force recreation of the rules — by just disable/enable the motion sensor checkbox briefly.

[ooii]

Is it possible to generate the ubuntu package please? Thanks a lot.

[manup]

2.05.15 is online: https://www.dresden-elektronik.de/deconz/ubuntu/beta/

[manup]

Damn sorry package had a error... re-uploaded 22:48

[ooii]

by just disable/enable the motion sensor checkbox briefly.

Is this the checkbox you mention? Because it's still not switching off/dimming.

[ooii]

@manup, just to let you know, in case you missed my last message, that it still does not work.

[nero01]

Hello, thanks for your help. I got my motion sensor working by installing the latest beta 2.05.15 and firmware update. It detecting presence and turning off the light now.

[stefan1957]

Hello Manup, i have got a problem with the motion sensor from Philips. They turn on the lights but leave them on. i am on version 2.05.16 with the latest firmware but still the same. It started on 2.05.14. I made new rules, deleted both sensors from deconz and ad them back but still the same problem. Do you have any suggestions to solve this problem? Thx in advanced Gr Stefan

[ooii]

Hi,

Just installed 2.05.16 and still the same issue. I deleted the rule then created a new one. Sensor still switches on the light but never does something else after that. I have another question: what is the tick (with a red circle in attached figure) supposed to do? Either disable or enabled, the sensor triggers the lights on. Please help with that.

[manup]

Hmm that's strange, does the walking man icon get active (darker) when the sensor triggers motion?

The checkmark in the red circle needs to be set for every motion sensor which should trigger the motion sensor control.

[ooii]

Hmm that's strange, does the walking man icon get active (darker) when the sensor triggers motion?

Yes, the walking man icon gets active.

Another strange behavior concerns the dimmer which cannot switch off the light if the same icon (green circle in the attached figure), but in the dimmer settings, is enabled. It only dims it briefly then the light is back on. PS: Can you please document somewhere (i) what's the purpose of this icon in the dimmer settings and (ii) how the dimmer can be configured?

[ooii]

After investigating a little bit through the REST API, I found some weird rules. Here is my setting . And here are three rules 13, 14, and 17, responsible of dimming light to, resp., 50%, 1%, and off. As you can see, rule 13 dims the light to 50% after 1 hour and 30 seconds, rule 14 dims it to 1% after 30 minutes and 30 seconds, and rule 17 switches off the light after 1 minute.

"13": {
        "actions": [
            {
                "address": "/sensors/7/state",
                "body": {
                    "status": 2
                },
                "method": "PUT"
            },
            {
                "address": "/groups/3/action",
                "body": {
                    "bri": 127,
                    "transitiontime": 100
                },
                "method": "PUT"
            }
        ],
        "conditions": [
            {
                "address": "/sensors/7/state/status",
                "operator": "eq",
                "value": "1"
            },
            {
                "address": "/sensors/7/state/status",
                "operator": "ddx",
                "value": "PT01:00:30"
            },
            {
                "address": "/sensors/6/state/presence",
                "operator": "eq",
                "value": "false"
            }
        ],
        "created": "2018-03-26T19:56:15",
        "etag": "55e1a424c4d5a8b9cf0e190003c7bc2b",
        "lasttriggered": "2018-03-27T08:19:40",
        "name": "pir-fsm-state-dimm1",
        "owner": "4D546F06ED",
        "periodic": 0,
        "status": "enabled",
        "timestriggered": 44
    },
    "14": {
        "actions": [
            {
                "address": "/sensors/7/state",
                "body": {
                    "status": 3
                },
                "method": "PUT"
            },
            {
                "address": "/groups/3/action",
                "body": {
                    "bri": 3,
                    "transitiontime": 100
                },
                "method": "PUT"
            }
        ],
        "conditions": [
            {
                "address": "/sensors/7/state/status",
                "operator": "eq",
                "value": "2"
            },
            {
                "address": "/sensors/7/state/status",
                "operator": "ddx",
                "value": "PT00:30:30"
            }
        ],
        "created": "2018-03-26T19:56:15",
        "etag": "55e1a424c4d5a8b9cf0e190003c7bc2b",
        "lasttriggered": "2018-03-26T21:59:04",
        "name": "pir-fsm-state-dimm2",
        "owner": "4D546F06ED",
        "periodic": 0,
        "status": "enabled",
        "timestriggered": 1
    },
"17": {
        "actions": [
            {
                "address": "/sensors/7/state",
                "body": {
                    "status": -1
                },
                "method": "PUT"
            },
            {
                "address": "/groups/3/action",
                "body": {
                    "on": false
                },
                "method": "PUT"
            }
        ],
        "conditions": [
            {
                "address": "/sensors/7/state/status",
                "operator": "eq",
                "value": "3"
            },
            {
                "address": "/sensors/7/state/status",
                "operator": "ddx",
                "value": "PT00:01:00"
            }
        ],
        "created": "2018-03-26T19:56:15",
        "etag": "55e1a424c4d5a8b9cf0e190003c7bc2b",
        "lasttriggered": "2018-03-27T08:18:57",
        "name": "pir-fsm-state-end",
        "owner": "4D546F06ED",
        "periodic": 0,
        "status": "enabled",
        "timestriggered": 2
    },

[ooii]

Is it an expected behavior that rules belonging to one sensor are still enabled when the sensor is disabled?

[manup]

"value": "PT01:00:30"

This is really strange I'll try to recreate the issue later, just to be sure are these rules the ones belonging to your sensor control or are there more sensor control defined for this or other groups?

Is it an expected behavior that rules belonging to one sensor are still enabled when the sensor is disabled?

Yes it just tells the sensor presence state, the enabled mark just defines if the sensor should play a role in the motion sensor control rules.

[ooii]

just to be sure are these rules the ones belonging to your sensor control or are there more sensor control defined for this or other groups?

I have only one sensor control.

Yes it just tells the sensor presence state, the enabled mark just defines if the sensor should play a role in the motion sensor control rules.

But how this (sensor should play a role or not) is reflected in the REST API?

[ooii]

And @manup, could you please answer my PS questions in this comment?

[ooii]

I wanted to start from scratch and delete the database. According to the api documentation, I need a post request at /api/<myApiKey>/config/reset with deleteDB set to true as parameter. I'm trying that with Postman and I'm getting a body contains invalid JSON error.

The equivalent cURL request of what I'm doing is:

curl -X POST \
  'http://192.168.0.22/api/<apiKey>/config/reset?deleteDB=true' \
  -H 'cache-control: no-cache' \
  -H 'postman-token: b97832d6-7116-67e5-5559-f3beaac5722f'

Is there something wrong?

[ebaauw]

You need to specify the parameter as a json body, not in the url.

[ooii]

Is there any "common" way to do that? I'm trying with

{"parameters" :{
        "deleteDB": "true"
    }
}

and with an array but I'm not getting it.

[ebaauw]

Just specify {”deleteDB”: true}

[ooii]

That was my first try. I finished doing it from the web interface. But, just for curiosity, I'm still trying and I start thinking there is an issue.

If I use this command line to create a user, everything works:

curl -X POST \
  http://192.168.0.22/api \
  -H 'Cache-Control: no-cache' \
  -H 'Postman-Token: f5314782-f262-473b-91ed-4086d69069d6' \
  -d '{"username":"testUserName"}'

But the same request, with url and body changed like this

curl -X POST \
  http://192.168.0.22/api/testUsername/config/reset \
  -H 'Cache-Control: no-cache' \
  -H 'Postman-Token: f5314782-f262-473b-91ed-4086d69069d6' \
  -d '{"deleteDB":true}'

ends with [{"error":{"address":"/config/reset","description":"missing parameters in body","type":5}}]

[manup]

It's not possible to delete the database without resetting the gateway.

    if ((!map.contains("resetGW")) || (!map.contains("deleteDB")))
    {
        rsp.httpStatus = HttpStatusBadRequest;
        rsp.list.append(errorToMap(ERR_MISSING_PARAMETER, "/config/reset", "missing parameters in body"));
        return REQ_READY_SEND;
    }

However to reset the database it's simpler to just delete the zll.db file (while deCONZ isn't running).

[ooii]

Maybe the api doc should reflect that, I spent hours (and some hair that I pulled out) trying to do it.

[manup]

Maybe the api doc should reflect that, I spent hours (and some hair that I pulled out) trying to do it.

Absolutely currently documentation lacks way behind, updating the docs is a big item on the current todo list.

[JafDev]

First of all thank you @manup for the great job ! I always had the problem described by @ooii and never took the time to have a look at it, until today. Just found this post as I started to study the code. @ooii is right, there is a bug with the timings generated by the phoscon app. After few tests:

• the 1st timing as always an offset of 1h
• the 2nd timing as always an offset of 30 minutes
• the 3rd timing is fine (=would be fine if the other were fine) After modifying the timings by hand - over the REST API - everything works as expected. JafDev

[beatpaul]

I have the same problem with the timings, is there a simple workaround without programming?

[manup]

I'm gonna look into the issues the coming days. Which browser do you use? We found some safari related issues with time handling in other parts of the app, maybe it's the same here.

[beatpaul]

Yes i‘m using safari!

I will try it in a different browser and inform you about the result

Very thanx for the advice!

__ (iPhonemail)__ DI Paul Track T: +43 699 15049818 M: paul_track@gmx.at

Am 26.04.2018 um 20:18 schrieb Manuel Pietschmann notifications@github.com:

I'm gonna look into the issues the coming days. Which browser do you use? We found some safari related issues with time handling in other parts of the app, maybe it's the same here.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[beatpaul]

Doing the settigs in Chrome Browser solved the Probelm for me!

[manup]

Cool thanks for checking it, so it seems indeed to be the same issue.

[ooii]

I'm also using Safari. I'll check later with Chrome.

[ooii]

After modifying the timings by hand - over the REST API - everything works as expected. JafDev

But if you uncheck the sensor then check it back, the wrong settings are back.

[ooii]

I'm also using Safari. I'll check later with Chrome.

Works fine with Chrome. Thanks.

[manup]

The Safari issue should be fixed in the next 2 versions.

[Kendobendo]

I just like to add my two cents to this issue. My sensor acts the same way. I'm running 2.05.29 and firmware 26210500. I've tried setting up the rules with both Firefox and Chrome. It behaves the same way. Lights stay on all the time after sensor detecting motion. I tried chaging from "Dusk to dawn" to "Always" but that didn't solve this. All my motion sensors were working fine a month or two ago. They always have. So something changed with last couple of updates.

I decided to try to fix all this tonight by resetting the gateway. Re-added all my devices. Still having the same problem. Is there a workaround that actually work?

[manup]

Please try version 2.05.30 there were some fixes related to the issue.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.