Schedule no longer works

[ebaauw]

I overslept this morning, since my wakeup schedule didn't fire. Upon inspection, it's action contains a username (api key) in the address that I deleted months, if not years, ago. I suspect the changes in the API handling (9e9d092) now block the action.

[manup]

Yes looks like auth handling needs more careful testing, had similar issue today.

ffca4f9

[manup]

Can you please provide the schedule content, looking at the code it should still work since the auth checks are not done at this level.

[KodeCR]

Oops, sorry... before the changes the schedules node wasn’t checked for auth at all. That was one of the reasons to move it to the top level, so it not so easy to forget one. So basically this fixed a bug. If you change your rule to use an authorised api key it should work again. ?

[ebaauw]

I think so. Will see tomorrow morning...

[ebaauw]

No joy, schedule didn't fire this morning either. Good thing that I did set a backup alarm...

Here's the schedule (with the updated API key):

$ ph get /schedules/2
{
  "activation": "start",
  "autodelete": false,
  "command": {
    "address": "/api/85E340F30E/sensors/321/state",
    "body": {
      "status": -2
    },
    "method": "PUT"
  },
  "description": "Wakeup Alarm Week",
  "etag": "d23a2e9c8bd30ec9ce33c9d5600ecfbf",
  "localtime": "W120/T07:00:00",
  "name": "Wakeup Alarm Week",
  "status": "enabled",
  "time": "W120/T07:00:00"
}
$ ph get /config/whitelist/85E340F30E
{
  "create date": "2018-01-27T16:00:49",
  "last use date": "2018-12-10T17:51:46",
  "name": "ph#pi2"
}
$ ph get /sensors/321
{
  "config": {
    "on": true,
    "reachable": true
  },
  "etag": "4b699b9f694c8add98d7f013d4b5725c",
  "manufacturername": "homebridge-hue",
  "modelid": "CLIPGenericStatus",
  "name": "Bedroom Status",
  "state": {
    "lastupdated": "2018-12-11T07:41:28",
    "status": 1
  },
  "swversion": "-2,3",
  "type": "CLIPGenericStatus",
  "uniqueid": "/sensors/321"
}

[manup]

By checking the code it should work even with non existing/invalid apikey.
The schedules are evaluated within the schedule timer where unlike for external http requests the authentication isn't checked.

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/rest_schedules.cpp#L1034

[ebaauw]

Did some more digging in the logs. I'm seeing the same messages for the schedule:

Dec 11 07:00:00 pi2 deCONZ[30157]: 07:00:00:779 schedule 2: Wakeup Alarm Week trigger
Dec 11 07:00:00 pi2 deCONZ[30157]: 07:00:00:779 schedule 2 body: {"status":-2}

But I no longer see the web socket notification, nor a message for the rule that should be triggered.

Dec  6 07:00:00 pi2 dc_eventlog[6411]: /sensors/321/state: {"lastupdated":"2018-12-06T06:00:00","status":-2}
...
Dec  6 07:00:02 pi2 deCONZ[28717]: 07:00:00:285 schedule 2: Wakeup Alarm Week trigger 
Dec  6 07:00:02 pi2 deCONZ[28717]: 07:00:00:285 schedule 2 body: {"status":-2}
Dec  6 07:00:02 pi2 deCONZ[28717]: 07:00:00:288 rule event: /sensors/321 state/status num (-1 -> -2)
Dec  6 07:00:02 pi2 deCONZ[28717]: 07:00:00:288 trigger rule 197 - Bedroom Wakeup 1/3

As my backup alarm, I set the status from HomeKit - that did issue the web socket notification and did trigger the rule alright.

So it would seem that a schedule command no longer triggers the event?

[manup]

Dec 6 07:00:02 pi2 deCONZ[28717]: 07:00:00:288 rule event: /sensors/321 state/status num (-1 -> -2)
Dec 6 07:00:02 pi2 deCONZ[28717]: 07:00:00:288 trigger rule 197 - Bedroom Wakeup 1/3

I'm a bit confused this looks like the rule is triggered based on the event?

[ebaauw]

Yeah, that's the old log (Dec 6) from 2.05.49. These messages are missing from the 2.05.50, Dec 11 log.

[manup]

Ah ok sorry missed that :) I'll try to recreate similar setup and see where it hangs.

[ebaauw]

schedule failed: 404 Not Found [{"error":{"address":"/lights/3","description":"resource, /lights/3, not available","type":3}}]

It tries to handle the /sensors command as a /lights request,

[ebaauw]

And that's because the check for the right request type has been removed from handleLightsApi() (and from the other handlers).

    if (req.path[2] != QLatin1String("lights"))
    {
        return REQ_NOT_HANDLED;
    }

Oh, and indeed, the api key isn't checked ;-)

[manup]

Unexpected behavior ;)
Ok I think simplest fix will be bringing back the checks. The schedule timer could also dispatch but I'm worried there might be other places with similar handling.

[ebaauw]

but I'm worried there might be other places with similar handling.

Indeed, especially since the check wasn’t just with lights, groups and sensors, but also with e.g. resourcelinks. I could create a PR, but that might have to wait until this weekend.

[KodeCR]

I removed the check because it 's also done at top level. Is handleLightsApi called directly when the schedule triggers? If so, factoring out the top level API handling and calling that from both places would be better?

[ebaauw]

Then we’d lose the check that the command should only be for lights, groups, or sensors. Also, this would introduce checking the username/api key.

[ebaauw]

Fixed in v2.05.52.