Nexa ZMD-107 motion detector not accepting configurations

I have a Nexa ZMD-107 (basically a Everspring SP817). The issue is that it never seems to wake up in order to accept configuration changes. I can’t ping the device and it also doesn’t wake up when removing the cover (triggering tampering).

Apart from the issues with the configuration changes, the device seems to work as intended. Any ideas how I can wake up the device in order to make it accept the changes?

Note: I have some battery powered aeotec devices, these also fail to receive config changes, BUT they have a physical action button you can press, which wakes up the device and the changes are received. This used to work with the aeotec devices.

Usually the sequence of buttons you press to include the device are also used to wake the device up. According to the manual you have to press the tamper switch 3 times to put it inclusion mode. I would try that first. Product Network Management Instructions. Also the commands are stored in a queue until the device wakes up. The default for that device is 4 hours. So if you you just wait they will eventually get applied.

According to the manual you have to press the tamper switch 3 times to put it inclusion mode.

I should have mentioned that in the first post, but I did try this. The device does not accept the new configurations. Seems like the device enters some special calibration and testing mode when the back cover is removed.

As mentioned though, this trick (using the activity button) works with other battery powered devices. Also I have never had issues pushing configurations (without pressing any button). This issue came I think with an update of zwaveJS (unfortunately don’t know which, did not keep track.).

Sorry, but that has never worked for battery devices (exception being FLIRS ones, like locks). They don’t listen for commands unless they are awake.

@Btbo Did you ever sort this out? I see the same problem, and it’s not caused by the device being asleep. I do wake it up, but setting the config parameter fails with the following log entries:

2024-12-09 21:52:51.749 INFO Z-WAVE: Calling api writeValue with args: [
{ nodeId: 33, commandClass: 112, endpoint: 0, property: 4 },
60,
null,
[length]: 3
]
2024-12-09 21:52:51.754 INFO Z-WAVE: Writing 60 to 33-112-0-4
2024-12-09T20:52:54.200Z CNTRLR « [Node 033] Received updated node info
2024-12-09 21:52:54.206 INFO Z-WAVE: [Node 033] Is now awake
2024-12-09T20:52:54.208Z CNTRLR [Node 033] The node is now awake.
2024-12-09 21:52:54.219 INFO Z-WAVE: [Node 033] Node info (NIF) received
2024-12-09 21:52:54.376 ERROR Z-WAVE: Unable to write 60 on 112-0-4: Fail
2024-12-09 21:52:54.378 INFO Z-WAVE: Success zwave api call writeValue { status: 2 }
2024-12-09 21:52:55.537 INFO Z-WAVE: [Node 033] Value updated: 112-0-4 180 => 180
2024-12-09T20:52:55.800Z CNTRLR » [Node 033] Sending node back to sleep...
2024-12-09 21:52:55.838 INFO Z-WAVE: [Node 033] Is now asleep
2024-12-09T20:52:55.841Z CNTRLR [Node 033] The node is now asleep.

This workaround worked (create a custom device file):

and a discussion here