Deconz-rest-plugin: TRADFRI motion sensor wrong timing in Deconz

[Marlor]

The new IP44 TRADFRI motion sensors E1745 can only be used in 3 Minute intervals but Deconz sets them to clear after 1 Minute.

This is a picture of constant motion

Same motion sensor, same battery with the TRADFRI GW:

[flopp999]

I also noticed this.
I also noticed that if I move in front of the motion sensor it still says OFF after 1 minute.
Normal behavior would be ON until I stop moving in front of it and then after 1 minute(3 minutes) goes to OFF

[flopp999]

It also seems to be "lock" when it has sent "OFF", I cannot get it to send "ON" until 1 minute has passed since it sent "OFF"

[Panoru84]

Hello @Marlor & @flopp999
Did anyone of you find a solution for this?
It's very sad not to get constant status updates.
If there is any motion this should be detected and transmitted all the time.

[ebaauw]

The Trådfri motion sensors do _not_ send anything when motion is no longer detected. When they detect motion, they send an _On with Timed Off_ command to the associated group. The REST API plugin eavesdrops on this command, and sets state.presence on the sensor resource to true. It also sets config.delay to the time specified in the command: between 1 and 10 minutes for the old model (depending on the dial setting), and 3 minutes for the new model. The sensor will not register new motion, until shortly before this time has passed. The REST API plugin sets state.presence to false automatically, config.duration seconds after it set state.presence to true. I think config.duration is initialised to 60, leading to two minutes in the dark for the new model. Set config.duration to 0 and the REST API plugin will use config.delay instead, making sure state.presence is set to false at the same moment the lights in the associated group turn off automatically.

[Marlor]

So its fixed if you set config.duration to 0 as default, on E1745, in the next deconz Firmware?

[akmolina28]

I'm having the same issue with a Smartthings (Samjin) motion sensor. When the sensor flips to OFF, it is blocked from flipping back to ON unless there is no motion for a minute.

[Mimiix]

It seems this issue is resolved or otherwise inactive. If it is not, please re-open!

[Marlor]

Not fixed in 2.05.76

[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.

[Marlor]

Not fixed

[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.

[Marlor]

activity

[SwoopX]

Why do you still keep this issue open? As I see it, the solution has been explained. Have you configured your sensors accordingly?

[Marlor]

The motion sensor is flickering at default config.
ebaauws post is just a workaround until it is fixed in firmware

[MattWestb]

Some thing to putting in the 2.05.79 with planed release date 2020-07-15 ?

[SwoopX]

ebaauws post is just a workaround until it is fixed in firmware

@Marlor I admit, I'm blind at times, but where has he mentioned that anything needs to be fixed? I also do not see any reference to the firmware. Again, he has presented the solution and you're free to use it ever since.

[Marlor]

This is only happening in Deconz. Surely it is not intended behavior?
Zigbee2mqtt, ZHA, TRADFRI gateway and even direkt connection motion sensor -> light
are working as you expect: motion until no one is in the room, without 1min pauses every 2min

[SwoopX]

Can you please let me know why you just refuse to configure the sensor via REST API to get what you want? I really have difficulties in undertanding this.

[Marlor]

Du you really believe this standard behavior is ok?
Everyone using the E1745 has to be lucky enough to stumble upon this github issue and has to know how to use the REST API?
Of course this is good enough as workaround but probably should be fixed.

[MattWestb]

@ebaauw Can you pleas making one pull request with your changed config so the users don't need going the long way around for getting one working system with in deCONZ supported products.

[ebaauw]

I'm sorry, I have no idea what "changed config" you're talking about. I only use Hue motion sensors myself. Imho the Trådfri motions sensors are unsuitable for use in home automation rules. IKEA created them as controllers, and they should be used as such. That works brilliantly, and even when the gateway is down.

[MattWestb]

Then im sorry 2 !
The user was writing "config.duration to 0 as default, on E1745" was working that you was suggested but must being done thru REST api.
I have 2 HUE ones but for the moment being used as light level sensors not motion.
I like the LL control that Ikea is using in both there old and new sensors.
If a power outage have occurred or killed SD-card happens and coming home late in the night i still have the light working then going inside the apartment.
And you have the full understanding how working with lights (LL profile) and HA and using the right type for the right situation. The latest mess here its the new Aqara Opple switches that looks very good as LL controllers but being used as more or less HA only.
Thanks for spending your time for nothing.

[Marlor]

Yes the Trådfri motions sensors are unusable in home automation, only in Deconz and only because this Bug here.

[MattWestb]

Very true and its the same with the old nice aqara switches that works very well in HA and is 110% worthless then working with lights and using bindings.
The good thing its you hav getting one workaround that working for you but its more or less one hack.
Edit: The hard coded time its coming from the very hacky hack to override / disable the motion sensor with one switch in Phoscon App

[ebaauw]

Yes the Trådfri motions sensors are unusable in home automation, only in Deconz and only because this Bug here.

As I explained above, the three-minute interval before the next motion report is set in the new Trådfri motion sensor's firmware. It's up to you whether you want to call this a bug, but it needs to be fixed by IKEA (which I think is highly unlikely to happen).

Please show us what other gateways work with the Trådfri motion sensor without this "recharging" interval. Afaik the Trådfri hub doesn't even expose the motion sensor: it uses it solely as a controller.

The hard coded time its coming from the very hacky hack to override / disable the motion sensor with one switch in Phoscon App

Technically, you cannot disable or override the motion sensor. It's firmware simply doesn't provide any function for that. The old sensor has a physical dial to set the interval, but this cannot be changed from Zigbee. It can only be read when the sensor sends its _On with Timed Off_ command.

All deCONZ does is reset state.presence to false automatically, config.duration seconds after the sensor has reported motion. This is because the sensor does not report when it no longer detects motion. You need to align config.duration to the sensor's interval. This is done by a PUT to the sensor's config with a body of {"duration": 0} (to use config.delay) or "{"duration": 180} (for three minutes).

The latest mess here its the new Aqara Opple switches that looks very good as LL controllers but being used as more or less HA only.

That was a deliberate decision, see the corresponding issue. Please stick to this issue's topic.

Thanks for spending your time for nothing.

I'm sorry things aren't working to your expectations, but please remain civil. If you just want to complain, please go to Facebook or wherever.

[MattWestb]

Sorry ebaauw the last was comment was not meant negative wos writing too fast, and you have helping the user and finding a working workaround so sud instead saying thank you very much for explaining and helping with the manual configuration of the timing in deCONZ.
Best regards.

[Mimiix]

@Marlor What would be a fix for you? Where does this need to be addressed?

[Marlor]

@ebaauw
here is a snippet from the zha gateway build in Homeassistant:

Working as expected. Constant motion as long as you are in the room + 3 Min, did leave at ~23:55.
The problem is not the 3 min interval in hardware, 1Min, 3 Min or 30Min doesn't matter (as long as on_with_timed_off is send accordingly).
The problem is that deconz is resetting the state prematurely.

@Mimiix
Looks like a general problem with the on_with_timed_off function in deconz. Possibly effecting more than this sensor.
The sensor is sending on_with_timed_off 180s but the state gets reset before the 3min, after 1min

2020-07-22 10:19:42 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x081d:1:0x0006]: received 'on_with_timed_off' command with [0, 1800, 0] args on cluster_id '6' tsn '2'

2020-07-22 10:21:24 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x081d:1:0x0006]: received 'on_with_timed_off' command with [0, 1800, 0] args on cluster_id '6' tsn '3'

Maby on_with_timed_off should have priority over or ignore config.delay/config.duration?

[Mimiix]

@Marlor I misread, that's why i removed my comment ;)

But wait, i am confused: Are you using the deCONZ addon + integration or just the Conbee /raspbee with ZHA?

[Marlor]

Conbee II + deCONZ addon + integration

I used ZHA just to test and see how they are handling the sensor and easy log of the sensor communication, sorry for confusing you

In essence
As long as there is Motion, the sensor will send on_with_timed_off 180s every 100s
This way they overlap and there would never be a pause
But deCONZ ignores the 180 and resets the state after 60s

That's why i expect an error in the on_with_timed_off implementation.

[SwoopX]

Ok, looks like we're now getting to something more solid. I guess we should see if we can spot anything suspicious.

[ebaauw]

As long as there is Motion, the sensor will send on_with_timed_off 180s every 100s
This way they overlap and there would never be a pause
But deCONZ ignores the 180 and resets the state after 60s

So if you would be using the sensor as controller, you wouldn’t have a problem. Instead you’re using it as sensor, creating automations on state.presence. As I explained above, the API plugin resets state.presence automatically after config.duration seconds. If you set that to 180 or larger, de API plugin wouldn’t reset it, since the next _On with Timed Off_ will reset the timestamp on state.presence.

[Marlor]

Yes the combination state.presence config.duration and on_with_timed_off is a bit buggy.
Or on_with_timed_off itself.

[ebaauw]

deCONZ doesn't play a part in the _On with Timed Off_ command; the motion "sensor" sends this command directly to its bound group. Any lights in that group will turn on when receiving the command, even when deCONZ is down. The lights turn themselves off automatically after the on time specified in the command, again even when deCONZ is down. This is using the "sensor" as a controller, the way IKEA intended.

Next to this, the REST API plugin eavesdrops on the group commands sent by the motion "sensor". When it sees one, it sets config.group to the addressed group, sets state.presence to true, sets config.delay to the on time (180s for the new model), sets state.dark to the only when on parameter. After config.dureation seconds, the REST API sets state.presence to false automatically, without any involvement of the motion "sensor".

When creating automations based on state.presence (either using deCONZ rules or using another home automation system), you're using the motion "sensor" as a sensor. However, it's a lousy sensor, as it doesn't report when it no longer detects motion. Hence the automatic reset of state.presence by the REST API plugin. Imho, we should never have exposed (read-write) config.duration for this device. We should have used (read-only) config.delay instead. I already changed the logic months (years?) ago, so that when you set config.duration to 0, the API plugin uses config.delay to set state.presence to false automatically. This actually made a lot more sense for the old model, where you can specify the on time with a dial on the device; for the new model, you could just as well set config.duration to 180. Other than removing config.duration altogether, there's nothing to fix in the REST API plugin.

[Marlor]

There is no group, only deCONZ and the Sensor.
The sensor is sending the command on_with_timed_off to deCONZ
and deCONZ is (miss)interpreting the command.

Do you think the API call "set active for x seconds" should set the state for x seconds
or a flat 60s?

Again, this is no hardware Bug. ZHA, Zigbee2mqtt etc have no problems with on_with_timed_off

[ebaauw]

Did you even try to read what I'm writing?

There is no group, only deCONZ and the Sensor.
The sensor is sending the command on_with_timed_off to deCONZ
and deCONZ is (miss)interpreting the command.

Please show me the sniffer log to prove that the sensor doesn't send a group command. Please list the ZHAPresence /sensors resource showing no config.group and an incorrect value in config.delay.

Do you think the API call "set active for x seconds" should set the state for x seconds
or a flat 60s?

Zigbee devices don't use the API; they talk Zigbee commands. The API call to have the gateway send _On with Timed Off_ is a PUT to a /lights state or a /groups action with a body of {"on": true, "ontime": 180}.

I think the Zigbee _On with Timed Off_ command should result in state.presence being true for the on time specified in the command. This is the behaviour of the REST API Plugin when you set config.duration to 0.

[Marlor]

I think the Zigbee _On with Timed Off_ command should result in state.presence being true for the on time specified in the command.

That would be ideal, there are probably more sensors out there using _On with Timed Off_ which would benefit from the fix.
I imagine most of them use less than 60s so the the bug did not show

[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.

[Marlor]

Not fixed