FP300 on Matter/Thread ignores HoldTime writes - 1 of 5 units, same fw 1.1.3.8

Hi! - I have five (5) FP300s running Matter over Thread in Home Assistant, and I think I’ve got a clean single-unit defect isolated for you.

All five are on firmware 1.1.3.8, same house, same Thread network, same HA instance. Four of them honor the HoldTime attribute exactly as written. One of them ignores it completely and appears to run at roughly a 10-15 second hold no matter what I set.

Here is a full day of occupancy data from all four bathroom units, 2026-07-28, pulled from the HA history API. The “ON events shorter than HoldTime” column is the part that matters; an ON event physically cannot be shorter than the configured hold if the setting is being honored.

Unit       HoldTime   ON events   Shorter than HoldTime   Min ON   Median ON   Max ON
FP300-1      60 s        61          54  (89%)             17 s      30 s       87 s
FP300-2      60 s        22           0  ( 0%)             65 s     127 s      339 s
FP300-3     120 s        19           0  ( 0%)            129 s     141 s      337 s
FP300-5     120 s        29           0  ( 0%)            145 s     380 s     1155 s

FP300-2, -3 and -5 are textbook; not one ON event in the whole day fell below the configured hold. FP300-1 had 54 of 61 events below its 60 second hold, with a minimum of 17 seconds.

The result is that FP300-1 chatters badly. Six day trend on that unit, one row per day:

Date        Sensitivity   HoldTime   On/Off transitions   Total ON    Longest ON
2026-07-23     high         60 s              16           6.1 min     1.0 min
2026-07-24     high         60 s              16          13.4 min     4.5 min
2026-07-25     high         60 s              70          28.4 min     3.4 min
2026-07-26     high         60 s             112          36.4 min     2.4 min
2026-07-27     standard     60 s             118          36.0 min     1.9 min
2026-07-28     standard     60 s             122          36.4 min     1.5 min

Total ON time is stable at ~36 min/day, which matches actual use of that bathroom. So the sensor is seeing the right amount of occupancy; it’s just chopping it into 30 second fragments instead of holding it.

What I have ruled out:

Connectivity - the unit has logged 100.0% uptime with zero dropouts and zero unavailable states for six straight days. Battery is 3.028 V / 100% (CR2450).

Thread mesh - the other four units on the same mesh are fine. I ran a full RF audit of the network on 2026-07-27.

Sensitivity - I dropped this unit from High to Standard on 2026-07-26 and it made no difference to the flapping (112 to 118 to 122 transitions across the change). It did shorten the longest ON, which is the opposite of helpful.

Firmware - all five units report installed_version 1.1.3.8 with no update available.

I also want to flag something on the Home Assistant side that may be masking this for other users. The HoldTime number entity HA exposes reports min 1 / max 65534, so HA accepts any value you type and reports it as applied. There is no feedback that the device didn’t take it. On this unit HA reads back HoldTime = 60 while the device is clearly running at ~10-15 seconds. If the device is ACKing the write and then not persisting it, that would explain a lot of the “I set the timeout and nothing changed” reports on this forum.

Two questions:

Is there anything I can do remotely to force this unit to re-commit the HoldTime attribute? I’d rather not reset it since that changes the device ID and breaks my automations.

If not, I think this one is a hardware/firmware fault and I’d like to start an exchange. Happy to send device ID and server region by DM, and happy to run any test firmware you want on it since I have three known-good controls sitting right next to it.

Thx!
Chad

3 Likes

Hi there, it looks like you’re experiencing a support-related issue. We’ve automatically created a support ticket for you and will reach out via the forum email within the next two business days.

If other members have any suggestions or insights on this topic, feel free to share!

That’s a really clean writeup, — most people just say ‘my sensor’s flaky’ and leave it at that.

One thing I’d try before requesting an exchange: fully unpair that one unit and re-pair it from scratch, not just power-cycle it. I’ve seen individual Zigbee/Thread devices get stuck holding onto a stale attribute value that a soft reset doesn’t clear. Sometimes a real re-join forces it to resync everything including HoldTime.

If that doesn’t fix it, yeah, sounds like a legit defective unit and an exchange is the right call. And you’re right to flag the silent-failure issue — HA has no way to know the device rejected the write, it just assumes success. Worth mentioning that explicitly if you follow up with support, since it’s a real gap, not user error.

Came to the comments just to say this. Thanks for taking a data driven approach to the problem.

Just curious how this translates to device behavior, how is the accuracy of detections and any automations you have built?