Motion sensor presence commands have changed. Request update.

[JohnBentley]

## Intro

It appears that Philips has recently changed some of the Motion sensor presence conditions. I request the All4Hue app be updated to support the new form of these Motion sensor presence conditions; and deprecate the old conditions.

I've observed the change through experiment and interrogating the hue bridge. That is, by creating presence rules via the Official Philips Hue app, observing those rules via the API; then creating presence rules in All4Hue, and observing those rules via the API.

Additionally, when I observe from All4Hue the relevant presence rules that have been created in the Official Philips Hue app, this will show up as an "Unsupported" condition.

So it's not from anything in the official documentation https://developers.meethue.com/develop/hue-api/ that I come by this. Indeed I can't find anything in that documentation that stipulates what the presence conditions should be (perhaps I'm missing it).

There are the following conditions to think about:
* Presence updated (has changed)
* Presence updated with delay (has changed)
* Presence detected; or Presence not detected. (Unchanged)

The Philips hue bridge works with any of the following conditions. However it would be a good idea to keep up with where the official Philips code base has shifted to; and to see, in All4Hue, support for all conditions created by Philips (these are the only conditions that All4Hue doesn't support, as far as I've seen).

## My Environment

As at 2019-08-02 I'm up to date:
Philips hue bridge. BSB002 | 1933087030 (The square bridge, with rounded corners)
Motion sensors. SML001 | 6.11.27575

## Presence updated

* All4Hue currently creates:

Code: Select all

    "conditions": [
      {
        "address": "/sensors/66/state/lastupdated",
        "operator": "dx"
      },

* Philips official app creates:

Code: Select all

     "conditions": [
    {
      "address": "/sensors/66/state/presence",
      "operator": "dx"
    },

## Presence updated with delay

* All4Hue currently creates:

Code: Select all

    "conditions": [
      {
        "address": "/sensors/66/state/lastupdated",
        "operator": "ddx",
        "value": "PT00:00:05"
      },

* Philips official app creates:

Code: Select all

  "conditions": [
    {
      ~~"address": "/sensors/66/state/status",~~
       "address": "/sensors/66/state/presence",
      "operator": "ddx",
      "value": "PT00:00:05"
    }
  ],

## Presence detected; or Presence not detected

Unchanged. Both the Philips official app and All4Hue app create the same sort of command.

Edit: Corrected "address": "/sensors/66/state/status" to "address": "/sensors/66/state/presence".

[MarcusZ.]

Hello JohnBentley,

I agree that stuff created by the original app should not be shown as unsupported in all4hue, and I think that Rene will probably correct this interpretation issue sooner or later. Please re-check your "Presence updated with delay" official app example before, as "/sensors/66/state/status" is no valid URI for the motion sensor (but presence would be).

Furthermore, from API perspective and concerning the motion sensor (!), reacting on a change of lastupdated should still be equal to a change of presence, unless philips changed behavior without notice or documentation - did you already check this out? (For other sensors like memory sensor, using lastupdated vs status may be a difference.)

Last but not least, unless philips marks something explicitly as deprecated in the API documentation (or it stops working), I believe there would no further change be advised (just be prepared).

Regards,
Marcus

[JohnBentley]

Thanks Marcus.

Good of you to catch my error. I've edited the OP to correct "/sensors/66/state/status" to "/sensors/66/state/presence" (after double checking you are correct that this is with what the Official app produces for "Presence updated with delay" )

> reacting on a change of lastupdated should still be equal to a change of presence ... did you already check this out?

Yes. As I wrote ...
> The Philips hue bridge works with any of the following conditions.

.
> unless philips marks something explicitly as deprecated in the API documentation (or it stops working), I believe there would no further change be advised (just be prepared).

You'll be aware that, as a general matter with software development, often the documentation lags behind the code base. And where there is a difference that doesn't constitute a bug in the code, the code ought be regarded as authoritative.

Noting that to deprecate a command is to continue to support it but no longer promoting it as the preferred command to use: my suggestion is that all4hue continue to support both the old and new forms while preferring the new.

So when it comes to displaying presence conditions in All4Hue that where created by either the old official app/bridge or the new ... I'd suggest the old one be tagged as "old" or "deprecated" or whatever.

If Rene agrees with us that "stuff created by the original app should not be shown as unsupported in all4hue," then he has three possible choices when it comes to generating presence conditions *created by* All4Hue:

* Support both (the old) "lastupdated" and (the new) "presence" equally, but give a choice to users which they'd like to go with (which would be cumbersome ... what basis would a user have for preferring one over the other?)
* Continue to use the old "lastupdated".
* Use the new "presence".

I'd suggest the choice is between the last two options and swings whether it likely the new "presence" form represents the future; or is a brief experiment.

[ReneWahl]

Hi,

Understood. After investigation I will get back to you here. Sorry for the delay..

BR
Rene

[shazzy]

I second that request. I am actually a bit hesitant to start programming my motion sensors using all4hue out of fear my commands will stop working in the next larger bridge firmware update.

Updating the commands would also allow tweaking of rules which have been created by other apps (e.g. iConnectHue or the official hue app). A workaround would be to allow raw text edit of unknown actions / commands.

[ReneWahl]

I am working on this already. The situation is that the value "lastupdated" is available for all sensors and thus the condition works for all kinds of sensors. In contrast to that, "presence" is an individual value of the motion sensor. It is always more effort to support all individual parameters of all sensors instead of only a common value/condition like "lastupdated".

I will try to provide an update this year..

BR
Rene

[MarcusZ.]

Fine. When doing so, maybe you could also tweak the generic status memory sensor, to allow lastupdated and status changed:
- lastupdated dx: sensor was updated
- status dx: value also has changed
Both are good for some use cases...

Regards,
Marcus

[ReneWahl]

Yes, of course, Marcus I have adapted the app accordingly and will provide a BETA version within the next hours/days.