SilverCrest (Lidl) motion sensor - usage and control logic problems

Advice
1

Hi there,
I hope there are some others out here who use those sensors.
Despite the problems with latest Phoscon app not showing the devices in the list I have other issues using the devices.
I cannot say they are not working, they are but not as expected.
I wanted to hear some other opinions if that is meant to be that way or maybe figure out where the problem might be, maybe also a misunderstanding from my side.

From what I tested so far is that the device goes to a so called energy save mode after about 5 minutes run time. During that 5 minutes after start up the device constantly recognizes motion shown by the red LED on top and also sending its state to Phoscon and in my case to Home Assistant.
After that 5 minutes it detects motion and the red LED lits, if nothing moves then after about 60 seconds the motion status gets cleared.
My problem is that the device does then not send another motion signal to Phoscon if there has been motion while that timeout of 60 seconds.
Let me describe a different way, the monitored area is idle for a long time, then motion occurs the device lights red and sends the status. Then no motion occurs. After 60 seconds the status gets cleared in Phoscon. If then motion happens again after at least 70 seconds the device lights red again and send its status. But if in those 60 seconds motion occurs the status is cleared after 60 seconds but no new status update is sent.
So I always run into a “there is still motion in the area but the status gets cleared” situation. A new motion event is just sent if there has been no motion for at least 70 seconds.

Can someone verify that? Is that the way it works or how it is meant to be? Do other sensors work differently?

What I want is to have a light on while there is motion, but with this behavior of the sensor I have it on for 60 seoncds and if there is still motion the light turns off and does not get back on if there is constant motion. There has to be a pause of motion for 70 seconds…

Any help appriciated…

~Alexander

2

I think i’ve seen the same with mine and that’s why i’m not using it. I am not sure if this is a “Device feature”, a bug in deCONZ or maybe some config i can change.

3

Hmmm ok, which you use instead if you use any and do they behave any different? Maybe the sensors by IKEA?

4

None as I didn’t find a good use case.

The hue motion sensor seems to be great.

5

For my use case I need 4 sensors, the Hue are more than twice as expensive, that sucks…
Already have 5 Lidl now but with that behavior I can’t really do what I want.

I want to control the light in a stair case. Before that light was controlled by a simple central timer unit. I replaced it with a current impuls relay. I want to activate the light manually with the switches and then keep it on as long there is motion.
With the logic of the Lidl sensors I have 60 seconds plus what ever delay I configured in the logic after in HA or NodeRed.
If I would dance the whole day in front of one sensor I would only get one signal out of it my tests show so far…
I can’t believe that this is by design, I am curious how this sensor work with the original Lidl control unit…

6

It’s a bit easy to say, but you get what you pay for. In this case that’s really clear. I haven’t seen any motion sensors having the same quality as the Hue one. It does suck, but you get one heck of a device.

If it’s a wooden floor , perhaps a vibration sensor could work?

7

“Wer billig kauft kauft zweimal”… I know…

I did some additional tests, as I ran the software on an RPi3 with a RaspBee II headless I backed up my config and used a GUI image on a new SD card, restored the config…

As far as I can tell for the moment it seems the network has the information that there is still motion, though HA gets a reset after 60 seconds. For what I can tell for now is that I assume a problem in the REST API but before creating a bug report I will try to nail it a bit more…

8

BTW no wooden floor, massive stone plates on concrete…

9

I’ll check if i still see it with mine, than i can sniff the network and see what the device sends.

That way, wecan make sure it’s a bug or not.

10

Cool, thanks for the help…

I am looking at the “cluster info” in the app for the “IAS Zone” of the devices. “Alarm 1” does not get cleared if there is motion even the device does not indicate it by flashing red.
It seems by design the LED just flashes RED if there is motion after the idle timeout of roughly about 70 seconds…

11

Gotta make some jumps in that case :joy:

12

OK after testing with two devices running for a long time so already out of initial mode and in “power saving mode” I can confirm my previous assumptions.
In “power saving mode”, which the device enters about 5 minutes after inserting the battery, the LED only lights red when motion is detected after a motion idle time of about 70 seconds.
The REST API resets the motion status after 60 seconds even if the device still shows motion in the deCONZ app (Cluster info tab, IAS Zone Cluster, Zone Status Alarm 1).
Looking at the REST API in the Phoscon web interface it show the same, there is not presence shown any more after 60 seconds…
As far as I can tell the devices also send a signal when they go back to no motion.

13

It seems that the device is doing the same. I have a sniff running on it:

If it sees motion, i see this:

image
image1284×361 5.52 KB

It doesn’t do anything during the next 2 minutes i was moving it around. Meaning: It doesn’t send anything. But it doesnt report “clear” either. So just remains “moving”.

The next thing i did, was move my hand in front of it once and then wait:

image
image1389×777 29.9 KB

What i did see, is that it took around 1 minute(check timestamp difference) to report “no motion/not armed”.

Knowing that, i can assume that the device waits until last movement and then has 60 second cooldown. Testing that theory, i tested with moving my hand for around 1 minute and then lying it down. That does confirm after sniffing:

image
image1188×776 29.6 KB

I also noticed this while sniffing. In HA , report CLEAR is been given earlier (probably due to the API sending that). While the packet isnt there.

image
image1555×817 49.2 KB

So it’s safe to assume there’s a bug involved. However, I am not sure if this has been fixed in 2.13.1 (https://github.com/dresden-elektronik/deconz-rest-plugin/pull/5276). I am running 2.12.6-beta.

14

I’ll run this trough Manuel and see what he says.

15

I don’t get this, you say it may be fixed in an earlier version? So it came back? Or do I miss something here?

But thanks so far for also having a look into this, I hope this can be fixed :smiley:

16

I made a typo…

I am running 2.12.6 :slight_smile: not 16. Sorry!

17

Spoke to manup, made a Bug report :slight_smile:

Thanks for this @Alex9779

18

Nice… Thanks!
So the commit you mentioned which is in beta already does not fix that? So I don’t have to check with beta an just have to watch the issue until fixed?

19

As far as i know, that commit is for another device and doesn’t apply to this one.

It’s good to follow my issue :slight_smile:

20

I was curios and tried 2.13.1 and with that version it works…
As far as I can tell from this line:

the ID is TY0202 which is also part of the PR/commit you mentioned…