Zwave multisensor

[orct...@gmail.com]

hi

i am trying to get the following Zwave multisensor to work but not having much luck. I have attached the node , boot log and zwave log files. The only time it seems to actually pull any data is whe it associates the first time to the Zwave controller. There after does not seem to update any values. Also if i restart the OR controller, it does not pull any data and all the values show N/A

Z-Wave Plus PIR Multi Sensor, Temperature - Humidity - Light

https://www.monoprice.com/Product?p_id=15902&gclid=Cj0KEQjwn_3GBRDc8rCnup-1x8wBEiQAdw3OAYxUHSwJpksnL0hev1nQ2nUASNsVFI5sYs8bL5z6gL4aAhA18P8HAQ



NFO 2017-04-01 11:11:26,069 :  Controller                  : Z-Wave
node info (ID=15) : [[Device Classes :
'BASIC_TYPE_ROUTING_SLAVE','

GENERIC_TYPE_SENSOR_NOTIFICATION','SPECIFIC_TYPE_NOTIFICATION_SENSOR'],[Capabilities
: 'NODEINFO_CAPABILITY_ROUTING'],[Security :
'NODEINFO_SECURITY_OPTIONAL_FUNC_SUPPORT']].
ERROR 2017-04-01 11:11:26,158 : Command                     : Failed
to execute [Command : NodeID='15', EndPoint='0',
CommandString='BATTERY', ParamValue='--'] because could not find a
suitable Z-Wave command class for command 'BATTERY'.
ERROR [main]: Command                     : Failed to execute [Command
: NodeID='15', EndPoint='0', CommandString='BATTERY', ParamValue='--']
because could not find a suitable Z-Wave command class for command
'BATTERY'.
ERROR 2017-04-01 11:11:26,183 : Command                     : Failed
to execute [Command : NodeID='15', EndPoint='0',
CommandString='AIR_TEMPERATURE_SCALE_CELSIUS', ParamValue='--']
because could not find a suitable Z-Wave command class for command
'AIR_TEMPERATURE_SCALE_CELSIUS'.
ERROR [main]: Command                     : Failed to execute [Command
: NodeID='15', EndPoint='0',
CommandString='AIR_TEMPERATURE_SCALE_CELSIUS', ParamValue='--']
because could not find a suitable Z-Wave command class for command
'AIR_TEMPERATURE_SCALE_CELSIUS'.
ERROR 2017-04-01 11:11:26,198 : Command                     : Failed
to execute [Command : NodeID='15', EndPoint='0',
CommandString='AIR_TEMPERATURE_SCALE_FAHRENHEIT', ParamValue='--']
because could not find a suitable Z-Wave command class for command
'AIR_TEMPERATURE_SCALE_FAHRENHEIT'.
ERROR [main]: Command                     : Failed to execute [Command
: NodeID='15', EndPoint='0',
CommandString='AIR_TEMPERATURE_SCALE_FAHRENHEIT', ParamValue='--']
because could not find a suitable Z-Wave command class for command
'AIR_TEMPERATURE_SCALE_FAHRENHEIT'

[orct...@gmail.com]

user manual is available here for reference

http://downloads.monoprice.com/files/manuals/15902_Manual_160722.pdf

[Rainer Hitz]

I think communication with this device is OK because the node15.xml file looks good. I assume that you have configured polling calls with drools and the multisensor hasn’t been configured when these calls are triggered the first time which results in an error message. This seems to be a timing issue but it shouldn’t be a problem. When the next polling call arrives the device object should be ready. 

First of all I’ld suggest that you configure an association from the device to the controller because the device doesn't know where to send asynchronous events without this association. In order to do this open the node15.xml file with a text editor and add the association to the <configuration> section as in the following snippet :

<configuration hash="8B3B690C7F146CE4B7849E0147043B51">
    <associations>
      <association-group id="1" capacity="5">
        <association>
          <node>1</node>
        </association>
      </association-group>
    </associations>
    <parameters />
    <wake-up interval="3600" />
</configuration>

After you’ve saved this file restart the controller. The association configuration will be written to the device the next time when the multisensor device wakes up. In the worst case you have to wait 3600 seconds before this happens because the current wake-up interval of the device is 3600 seconds (see configuration section : <wake-up interval="3600" />). It’s also possible to wake up the device manually. In order to do this you have to press the button (it’s called program switch in the manual). Therefore I’ld suggest that you press the device button after restart of the controller so that whole procedure is accelerated. After this procedure the device sends automatically certain events to the controller - no polling is needed (maybe battery status is an exception). For example motion detection is immediately sent to the controller. The following commands can be used :

STATUS

BATTERY

LUMINANCE_SCALE_PERCENTAGE

HUMIDITY_SCALE_PERCENTAGE

AIR_TEMPERATURE_SCALE_FAHRENHEIT

AIR_TEMPERATURE_SCALE_CELSIUS

ALARM_TYPE_HOME_SECURITY 

I think that the commands STATUS and ALARM_TYPE_HOME_SECURITY show the same status if you bind them to a switch sensor.

Also note that you can configure the wake up interval of the device. Valid values for the wake up interval are 600, 1200, 1800, 2400, 3000, 3600,…,604800 (see COMMAND_CLASS_WAKE_UP_V2 in the node15.xml file). The default value is 3600 seconds. You have to think about this value when it comes to battery life time. 

In general when you restart the controller you'll see N/A for all sensor values of the multisensor device until it wakes up the next time. If motion is detected it's immediately sent to the controller and you should see a motion status update in the GUI. If you press the program switch of the multisensor device you'll see an update for all sensor values.

[orct...@gmail.com]

Thanks! That fixed most of the issues and it seems to reporting values :)
Only thing that I can't seem to get working is the motion sensor- is the STATUS command looking for the motion?

[Rainer Hitz]

Yes in this case the STATUS command is responsible for receiving motion status updates because the device uses BASIC SET commands to send motion updates (see OPERATION section of the manual). Note that the device retracts the motion detected status after 3 minutes of inactivity. That means during your tests you should cover the device for 3 minutes in order to see this behaviour. You should see the following in the log :

Motion

======

CCSecurity : Node '52' : [COMMAND_CLASS_SECURITY::SECURITY_MESSAGE_ENCAPSULATION] --> Decrypted : [APP_CMD_HANDLER_FRAME : NodeID='52', Status=[RECEIVE_STATUS_TYPE_SINGLE], CommandClass='COMMAND_CLASS_BASIC', Command='0x01', Parameters: [0xFF]].

CCBasic    : Node '52:0' : [COMMAND_CLASS_BASIC::BASIC_REPORT, Value='0xFF'].

No Motion

=========

CCSecurity : Node '52' : [COMMAND_CLASS_SECURITY::SECURITY_MESSAGE_ENCAPSULATION] --> Decrypted : [APP_CMD_HANDLER_FRAME : NodeID='52', Status=[RECEIVE_STATUS_TYPE_SINGLE], CommandClass='COMMAND_CLASS_BASIC', Command='0x01', Parameters: [0x00]].

CCBasic                : Node '52:0' : [COMMAND_CLASS_BASIC::BASIC_REPORT, Value='0x00'].

After reading the manual a second time I’ve noticed that they do not use standard COMMAND_CLASS_ALARM_V2 alarm codes. The device sends a proprietary COMMAND_CLASS_ALARM_V1 code [0xFF : Motion Detected]. A standard code would be for example [0x07 : EVENT_HOME_SECURITY_MOTION_DETECTION]. For this reason the command ALARM_TYPE_HOME_SECURITY will not work. I still have to find a solution for these proprietary alarm codes. I thought new Z-Wave Plus devices do not use these old proprietary V1 alarm codes anymore.

If it still doesn’t work please send me the log at the time when the motion detection status update is sent.

[orct...@gmail.com]

Hi Rainer

The command ALARM_TYPE_HOME_SECURITY seems be working for tamper detection i.e. When i pull the cover containing the battery it sends this alarm. When i put the cover back, it send another stating normal state.

I tried it with 3 other devices I from this same manufacturer (garage door ans recessed door sensors) and they all seem to use it for tamper detection- thanks for pointing me in this direction as i was looking to see how to get those tamper alarms.

I will play around with the motion a little more to see if the sensor will send the motion based trigger - i thought it should have been instantaneous upon motion detection but as you suggest there is a 3 mins of continuous sensing before it will trigger which seems pretty excessive

I will let you know what i find out.

[orct...@gmail.com]

Hi Rainer
I have been trying to get the motion working on this sensor but not having any luck. At first I thought it was a hardware fault so I bought another one but both are behaving in the same manner. I reached out to the manufacturer and this how they responded:

The sensor uses all command classes listed in the manual. Since we don't know how the library for openremote works, we wouldn't know which information would help. We have several custom device handlers created by SmartThings users for this sensor and they were able to pull all the information from the manual. The issue seems to be in the fact that there needs to be a device-specific entry for this sensor in the openremote library - this is something their support should be able to confirm. The device uses all standard Z-Wave Plus commands and implementation protocol.

Since it's not properly recognized by the controller, it never fully configured so the LED indicator are not behaving properly either (they will only activate once the sensor is fully enrolled in the network).

We recommend getting in touch with the software's support to see what information is needed to get the device enrolled for full support.

[Rainer Hitz]

The sensor has been successfully added to the Z-Wave network and an association from the device to the controller has been successfully configured otherwise the ALARM_TYPE_HOME_SECURITY command would not work. No other configurations are needed when a device is added to the Z-Wave network because a Z-Wave device has to work with default parameter settings (according to the Z-Wave specification) after it has been included to the network. 

The parameter values which are responsible for the motion detection functionality (see monoprice 4-in-1 manual) have the following values :

Parameter 5, Retrigger Time, Size 1, Default 3 Minutes
Parameter 6, Sensitivity, Size 1, Default 4

That means means motion detection should work. It's theoretically conceivable that the manual is wrong and the default value for 'Sensitivity' (Parameter 6) is zero and therefore motion detection doesn't work. You could try to configure Parameter 6. 

I do not understand the following response from monoprice support. I think you have to explain a bit more what you've experienced with the LEDs

Since it's not properly recognized by the controller, it never fully configured so the LED indicator are not behaving properly either (they will only activate once the sensor is fully enrolled in the network).

 

 btw it's also possible to configure LED behaviour :

Parameter 7, Size 1, Value [1, 2, 3], Default 3
Mode 1 : The LED is off and does not ever flash.
Mode 2 : The LED "breathes" to indicate the temperature range and flashes quickly when motion is detected.
Mode 3 : The LED quickly flashes the temperature or whenever motion is detected. This is the default behaviour.

Again it's conceivable that the manual is wrong and the default value for LED Mode is different than 3.

What happens when you cover the device with a blanket for more than 3 minutes and uncover it. Do you see something in the log that is related to the device - if yes please send it to me.

[orct...@gmail.com]

HI Rainer,

thanks for taking the time to look in to this. Just to summarize, all the environmental values are working and reporting as expected (temp, humidity, luminance, tamper). Just motion does not seem to work. I don't see any messages coming through (in log and no update on the UI for the motion which is tied to command STATUS) when i keep the sensor covered for over 3 minutes.

The LEDs in mode 3 (default according to manual) are supposed to blink every 3 minutes in a specific color depending on the temperature how ever i don't see the LED blink. According to their support engineer, this type of behavior indicates that the sensor is not fully configured (not sure what it means). Also according to them if the sensor is not fully configured by the controller, it will not send out any messages for motion nor will the LED blink like it is supposed to when it detects motion.

I changed the paramter in the node file and initialized the node (increased sensitivity for motion 1 - highest sensitivity according to manual). I also changed the LED mode to 2- which is supposed to continually blink the LEDs  with a color  depending on the temperature range but i see neither LEDs or motion work. I think it is taking the parameters because when i reinitialize the node it says configuration written successfully and other parameters related to temperature and luminance seem to be taking effect.

Keeping the sensor covered for over 3 minutes i don't see any messages come through in the zwave log.

I have attached messages for node 16 from zwave log from time of controller restart, manual wake up for first time, subsequent manual wake, covering the sensor for over 3 minutes and then uncovering the sensor.
I have also attached the node file

also here is the link to a much better manual by zooz for the same sensor.
http://www.getzooz.com/downloads/zooz-z-wave-plus-4-in-1-sensor-zse40-manual-v2.pdf

thanks for helping out with this one.

[orct...@gmail.com]

Hi Rainer,

Just wondering if had a chance to look in to this. If you need more information or any other logs etc please let me know.

[Rainer Hitz]

I couldn't find any obvious reason why it doesn't work so far. I'm currently double checking the specification in order to figure out what's missing and therefore I've implemented COMMAND_CLASS_ZWAVEPLUS_INFO and created the following new version : Z-Wave 3.2.2-Beta1 

As the name implies COMMAND_CLASS_ZWAVEPLUS_INFO is for reading information from the device and not for configuring the device. Therefore I don't think that it will solve the problem - but whoever knows. If you want to try the new version you should exclude the device from the network and include it again. Note that all configuration settings (associations, parameters) are lost after you've excluded it from the network. If it still doesn't work please send me the logs as the last time.

Do you think the Monoprice 15902 and the Zooz ZSE40 devices are the same ? Did you get in contact with Monoprice or Zooz support ?

[orct...@gmail.com]

HI Rainer,

thanks. I will try the new Z-wave file and let you know what i find out. Do i have to create a new command in designer for COMMAND_CLASS_ZWAVEPLUS_INFO or is this something that gets implemented during the initial discovery of the device?

I am certain that the Monoprice and Zooz devices are same. I have been in touch with the Zooz support and their response has been as follows: 

The sensor uses all command classes listed in the manual. Since we don't know how the library for openremote works, we wouldn't know which information would help. We have several custom device handlers created by SmartThings users for this sensor and they were able to pull all the information from the manual. The issue seems to be in the fact that there needs to be a device-specific entry for this sensor in the openremote library - this is something their support should be able to confirm. The device uses all standard Z-Wave Plus commands and implementation protocol.

Since it's not properly recognized by the controller, it never fully configured so the LED indicator are not behaving properly either (they will only activate once the sensor is fully enrolled in the network). 

All information regarding command classes used by the sensor is included in the manual. If there is anything specific required by Openremote software, please let us know and we'll provide you with the information.

Once the sensor is properly recognized and configured in the software, the LED indicator should start behaving normally as well. It's best to work with Openremote to see what's required for a device to be added to their library. Otherwise, it may be challenging to get support for it since we're not familiar with this platform yet.

Thanks!

[Rainer Hitz]

There's no need for additional designer commands because COMMAND_CLASS_ZWAVEPLUS_INFO is only used internally.

AFAIK SmartThings needs Z-Wave device handlers because it's not possible with SmartThings to configure parameters in a generic way after a device has been included to the network. These device handlers are mainly used to configure device parameters. With OpenRemote it's possible to configure all parameters without programming. I think parameter configuration is not the problem.

I think the following sentence contains some valuable information :

Once the sensor is properly recognized and configured in the software, the LED indicator should start behaving normally as well.

It seems that the device expects something that is currently missing at inclusion time of the device. I've read in the Z-Wave Plus specification that the interview process should start with a COMMAND_CLASS_ZWAVEPLUS_INFO::ZWAVEPLUS_INFO_GET command. The new version doesn't send this command as the very first command. Maybe I have to change this if it still doesn't work. 

[orct...@gmail.com]

Hi Rainer,

i tried the new zwave file but it doesnt seem to have helped. I have attached the log files. I tried including and excluding the sensor twice so the first time it was NODE 18 and second time it was NODE 19.

It is behaving the same way as before- Motion does not seem to do anything and the LEDs don't blink. Everything else seems to be reporting fine.

I hope this helps and you are able to find a fix.

[Rainer Hitz]

I've ordered the Monoprice 15902 for the test lab because I want to make sure that the issue will be fixed if it's related to Z-Wave Plus. Unfortunately the device will arrive on May 4th at the earliest (US-->Europe). I'll send you status updates about the progress (device has arrived...).

[orct...@gmail.com]

Thanks ! Greatly appreciate the support

[orct...@gmail.com]

Hi Rainer

Just checking to see if you had a chance to look in to this a little more

Thanks

[Rainer Hitz]

The device hasn't arrived yet. Tracking shows that it's currently in Norway - final destination Germany :-)

[Rainer Hitz]

I've received the device and it should (almost) work with the following version :

Z-Wave 3.2.2 Beta2

There's still a problem with the initial motion state. It works after the device has sent the first motion detection status update. That means after device inclusion cover the device for 3 minutes - after this procedure the motion detection status update works as expected. I'll try to fix this but I'm not sure if it's feasible. The device doesn't respond to a BASIC_GET command and I'm not sure if it's possible to retrieve the initial motion status with COMMAND_CLASS_ALARM.

The LUMINANCE_SCALE_PERCENTAGE command behaves strangely because it returns always 100% regardless of whether the device is covered or exposed to direct sunlight. I have to double check if the the calculation of the sensor value is correct.

Honestly I can't tell you why it's working now (motion detection). I haven't fixed a bug that is related to this issue. I'm currently working on COMMAND_CLASS_GRP_INFO. Maybe implementation of this command class fixed this issue.

[orct...@gmail.com]

Hi Rainer

Thanks I will try this new beta zwave and let you know this weekend how it works.

With the zwave 3.2.1.jar luminance and all other parameters (except motion) work perfectly for me.

[orct...@gmail.com]

Hi Rainer,

Just wanted let you know that the motion is now working! Thanks for your help. Also the Leds seems to be working

Only thing I am noticing is that when there is motion both the motion (STATUS) and Tamper (ALARM_TYPE_HOME_SECURITY) get triggered. Maybe that's how it's suppose to be.

Thanks again

[orct...@gmail.com]

Hi Rainer,

i have been using this Multisensor with the new beta Zwave file you provided and all the values including motion seem to be working fine except that i keep getting this error message in the logs frequently. Any ideas why?

 ERROR 2017-06-20 21:39:19,817 : The encrypted Z-Wave command [APP_CMD_HANDLER_FRAME : NodeID='25', Status=[RECEIVE_STATUS_TYPE_SINGLE], CommandClass='COMMAND_CLASS_SECURITY', Command='0x81', Parameters: [0x55, 0xDD, 0xD1, 0x68, 0xB3, 0xB0, 0xB8, 0x45, 0x68, 0x26, 0x82, 0x17, 0xDE, 0x28, 0x86, 0x30, 0x89, 0x4B, 0xAC, 0xC0, 0xA8]] has been discarded because of unknown nonce identifier '222'.

ERROR [pool-2-thread-4703]: The encrypted Z-Wave command [APP_CMD_HANDLER_FRAME : NodeID='25', Status=[RECEIVE_STATUS_TYPE_SINGLE], CommandClass='COMMAND_CLASS_SECURITY', Command='0x81', Parameters: [0x55, 0xDD, 0xD1, 0x68, 0xB3, 0xB0, 0xB8, 0x45, 0x68, 0x26, 0x82, 0x17, 0xDE, 0x28, 0x86, 0x30, 0x89, 0x4B, 0xAC, 0xC0, 0xA8]] has been discarded because of unknown nonce identifier '222'.

ERROR 2017-06-20 21:42:22,153 : The encrypted Z-Wave command [APP_CMD_HANDLER_FRAME : NodeID='25', Status=[RECEIVE_STATUS_TYPE_SINGLE], CommandClass='COMMAND_CLASS_SECURITY', Command='0x81', Parameters: [0x8C, 0x9E, 0xD4, 0xC4, 0xF5, 0xE5, 0x50, 0x9D, 0xAE, 0x35, 0x77, 0x4E, 0xE2, 0xAA, 0xF5, 0x3A, 0x18, 0xD2, 0xD7, 0x7A, 0xCB, 0x92, 0x74, 0xA1, 0x3D, 0x68, 0xF3, 0xC5, 0xAD]] has been discarded because of unknown nonce identifier '203'.

ERROR [pool-2-thread-4705]: The encrypted Z-Wave command [APP_CMD_HANDLER_FRAME : NodeID='25', Status=[RECEIVE_STATUS_TYPE_SINGLE], CommandClass='COMMAND_CLASS_SECURITY', Command='0x81', Parameters: [0x8C, 0x9E, 0xD4, 0xC4, 0xF5, 0xE5, 0x50, 0x9D, 0xAE, 0x35, 0x77, 0x4E, 0xE2, 0xAA, 0xF5, 0x3A, 0x18, 0xD2, 0xD7, 0x7A, 0xCB, 0x92, 0x74, 0xA1, 0x3D, 0x68, 0xF3, 0xC5, 0xAD]] has been discarded because of unknown nonce identifier '203'.

ERROR 2017-06-20 21:49:10,437 : The encrypted Z-Wave command [APP_CMD_HANDLER_FRAME : NodeID='25', Status=[RECEIVE_STATUS_TYPE_SINGLE], CommandClass='COMMAND_CLASS_SECURITY', Command='0x81', Parameters: [0x6E, 0x49, 0xC9, 0x09, 0x36, 0x3C, 0xD2, 0x2E, 0xAE, 0xAF, 0xE5, 0x1A, 0xC9, 0x99, 0x75, 0x7D, 0x6B, 0x7F, 0x6B, 0x38, 0xA0, 0x12, 0x2C, 0x1F, 0x7C, 0xDB, 0x8C, 0x4D]] has been discarded because of unknown nonce identifier '56'.

ERROR [pool-2-thread-4709]: The encrypted Z-Wave command [APP_CMD_HANDLER_FRAME : NodeID='25', Status=[RECEIVE_STATUS_TYPE_SINGLE], CommandClass='COMMAND_CLASS_SECURITY', Command='0x81', Parameters: [0x6E, 0x49, 0xC9, 0x09, 0x36, 0x3C, 0xD2, 0x2E, 0xAE, 0xAF, 0xE5, 0x1A, 0xC9, 0x99, 0x75, 0x7D, 0x6B, 0x7F, 0x6B, 0x38, 0xA0, 0x12, 0x2C, 0x1F, 0x7C, 0xDB, 0x8C, 0x4D]] has been discarded because of unknown nonce identifier '56'.

ERROR 2017-06-20 22:21:21,279 : The encrypted Z-Wave command [APP_CMD_HANDLER_FRAME : NodeID='25', Status=[RECEIVE_STATUS_TYPE_SINGLE], CommandClass='COMMAND_CLASS_SECURITY', Command='0x81', Parameters: [0xDB, 0xBC, 0xF3, 0x33, 0xED, 0x93, 0x22, 0xD7, 0x68, 0x3F, 0xDC, 0x81, 0x9D, 0x88, 0x55, 0x15, 0x51, 0x3B, 0xEB, 0xD2, 0xA9, 0x35, 0xC8, 0xCC, 0x4A, 0x1A, 0xD3, 0xD3]] has been discarded because of unknown nonce identifier '210'.

ERROR [pool-2-thread-4742]: The encrypted Z-Wave command [APP_CMD_HANDLER_FRAME : NodeID='25', Status=[RECEIVE_STATUS_TYPE_SINGLE], CommandClass='COMMAND_CLASS_SECURITY', Command='0x81', Parameters: [0xDB, 0xBC, 0xF3, 0x33, 0xED, 0x93, 0x22, 0xD7, 0x68, 0x3F, 0xDC, 0x81, 0x9D, 0x88, 0x55, 0x15, 0x51, 0x3B, 0xEB, 0xD2, 0xA9, 0x35, 0xC8, 0xCC, 0x4A, 0x1A, 0xD3, 0xD3]] has been discarded because of unknown nonce identifier '210'.

[Rainer Hitz]

Thanks for the feedback - I'll look into this and try to reproduce it.

[orct...@gmail.com]

Hi Rainer

Another quick note- the battery status does not seem to update at all except when the sensor is forced to wake up by pulling the cover off- so I need to manually poll for battery status using battery command or should it be sending full reports including battery status based on the wake up interval?

I guess this would apply to other zwave battery powered sensors too - do they need to be polled or should they be sending battery value updates periodically upon wake up?

[Rainer Hitz]

Honestly I haven't figured out how battery powered devices usually report their battery status. Actually it would make sense to report it automatically after it has decreased a certain amount/percentage. I think in the manual of the Monoprice 4-in-1 sensor you can read that the BATTERY GET command has to be used to retrieve the battery status which is an indication to me that the battery status has to be polled.

[Rainer Hitz]

I could not reproduce it with this sensor so far but I've seen this behavior in combination with the Aeotec MultiSensor 6.

The so called 'Nonce' is a number vector that is used to encrypt Z-Wave messages and as the name implies can only be used once. For each new encrypted Z-Wave message the 'Nonce' is different for security reasons in order to prevent replay attacks. 

It seems that the Aeotec MultiSensor 6 tries sometimes to use a 'Nonce' more than once and the OpenRemote Z-Wave implementation rightfully discards a Z-Wave message with a 'Nonce' that has been used before.

[orct...@gmail.com]

Thanks Rainer I will try to poll it periodically with Battery command and see if it responds. Btw when the command is sent and if the device is sleeping does the controller keep retrying till it gets a response back or does it get discarded?

[Rainer Hitz]

If you try to send a command to a battery powered device the command is stored in a queue until the device wakes up. When the device wakes up it sends COMMAND_CLASS_WAKE_UP::WAKE_UP_NOTIFICATION to the controller. The controller in turn sends all commands in the queue to the device and sends COMMAND_CLASS_WAKE_UP::WAKE_UP_NO_MORE_INFORMATION as last command. The device receives this last command and falls back to sleep mode.   

[orct...@gmail.com]

Perfect thank you!