forum

Packets are send out of the queue only when the device is ready to accpet them. This happens on periodical wakeup (check wakeup period time) or on manual wakeup by special button combination. To see this Z-Way is supposed to get a NIF or Wakup Notification.

So, either wait for the device to wake up or check the manual to find the key combination to send NIF (usually tripple press).

It is good to enable a schedule with periodical battery polling (once a week is enough). These packaets would be queued and processed once devices are awake.

As I said it does wake up, because it does send an alarm/tamper signal. It just does not read what is waiting in the queue at that very moment. It seems to be totally deaf.
The pepper1 database says that you submitted the certification report (2010-11-09 11:34:23) . In the context of what I observed it surprises me that it is described there as a Routing Smoke Sensor. A routing device which only wakes up if the battery is end of life, or if there is a smoke alarm.
PS: I am not trying to blame you, but I am puzzled and would like to understand. My present opinion is that it is just a badly designed device.

But it should send a NIF on tamper triple click. And it should not read pending queue on alarm events! It should do it only on manual or periodical wakeups, but not on alarm/tamper wakeups.

I did open the device which lead to a tamper alarm:

2012-10-13 10:50:02,989 Rules.INFO Unknown Alarm from node 12: [0, 0, 0, 0, 0]
2012-10-13 10:50:02,988 Rules.INFO Event: from 12:0 to 1:0, Alarm, value: [0, 0, 0, 0, 0]
2012-10-13 10:50:02,988 CmdCls.ERROR Alarm V1 type=0x1, reason=0x11 can not be mapped for Node-ID 12
2012-10-13 10:50:02,980 Z-Wave.INFO Got frame from device 12 to controller, but command class 0x71 for device is not registered - instanciating it as not supported

It seems to say that the device has not been properly registered. The Device configuration says that the interview "is complete". (0x71=COMMAND_CLASS_ALARM, the SF812 manual says
the Smoke Detector supports Command Classes including...
Command_Class_Battery
Command_Class_Verison (They mean Version I assume)
Command_Class_Sensor_Alarm
Command_Class_Association_V2
Command_Class_Manufacturer_Specific
Pepper One database does indeed indicate that 0x71 is not supported, but under control it is the only selected item. It is not immediately clear to me what these colums mean. Do you know if there is somewhere a document that describes the information items in this database?

Honestly, this DB is our internal kithen

Controlled means the device can send comands to other devices supporting this CC.

The only important line in your log is:
2012-10-13 10:50:02,988 CmdCls.ERROR Alarm V1 type=0x1, reason=0x11 can not be mapped for Node-ID 12

It means that we have not tested the device yet to do the manual mapping of events into new Z-Wave events (since it uses Alarm V1 instead of Alarm V2).

We have to try the device to do that mapping or take it from manual.

Thanks for the feedback. Don't bother to much about this. I am not going to use this device, because I do not like the fact that it will under no circumstance report its battery status around the time I have pushed its test button. Besides, I have the impression that my Zwave net has become much less responsive and reliable since I included it.
With your valuable responses this issue is closed as far as I am concerned.