BTW no wooden floor, massive stone plates on concrete…
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.
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…
Gotta make some jumps in that case 
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.
It seems that the device is doing the same. I have a sniff running on it:
If it sees motion, i see this:
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:
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:
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.
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.
I’ll run this trough Manuel and see what he says.
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 
I made a typo…
I am running 2.12.6 
not 16. Sorry!
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?
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
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…
And BTW the problems from here and here seem also to be solved, the sensors are now listed in the Phoscon web app…
Mine always showed in Phoscon. But i have a _TZ3000_3ooaz3ng '/ TS0121
Hmmm ok, strange, I have these devices:
I have the same. But Tuya tend to change the model ID’s over time.
Did you test it with 2.13.1?
Yes, I told before, maybe you missed that…
With 2.13.1 it works as expected, the devices stays in alarm mode even in the REST API and so in HA until the alarm gets cleared by the device itself after that ˜60 seconds timeout after no more motion occurred…
Looking at the commit you linked earlier that one includes at least my device ID, not yours so…
A fix for that behavior has been implemented in 2.13.0