@chris does my secondary controller need to be in inclusion mode for this to work? just took the device to the secondary controller and triple clicked to put into inclusion mode as it sends all its updates once it exits inclusion mode. but this didn’t work
works 100% as I would expect! 
awesome
Great - thanks…
I hope to have the ‘pending’ feature added soon to so we can start to get on top of the issue where configuration isn’t reported inline with the device state…
I think I havent seen that “null message” error before … however I dont see anything NOT working
19:58:54.756 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 6C 00 00 05 82
19:58:54.760 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
19:58:54.762 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 6C 00 00 05 00 00 8C
19:58:54.762 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'zwave_device_15348538564_node12_switch_dimmer4' received command 100
19:58:54.764 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 6C 00 00 05 00 00 8C
19:58:54.767 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, payload=6C 00 00 05
19:58:54.767 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 12: Command received zwave:device:15348538564:node12:switch_dimmer4 --> 100
19:58:54.769 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 12: SendData Request. CallBack ID = 108, Status = Transmission complete and ACK received(0)
19:58:54.769 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 12: Creating new message for command SWITCH_MULTILEVEL_SET
19:58:54.771 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 12: Encapsulating message, instance / endpoint 4
19:58:54.772 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent message Message: class=SendData[0x13], type=Request[0x00], priority=Set, dest=12, payload=0C 07 60 0D 01 01 26 01 63
19:58:54.772 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 12: Creating new message for command MULTI_CHANNEL_ENCAP endpoint 4
19:58:54.773 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 12: Node doesn't support get requests
19:58:54.775 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 3. Queue={}
19:58:54.776 [ERROR] [ve.internal.protocol.ZWaveController] - Null message for sendDataHi Chris, I just uploaded a Kwikset 912 door lock xml file to your site but the values it parsed looked a bit funny, let me know if you need me to do anything. I’ll also upload a 910 xml file shortly, although I’m assuming they should be similar looking if not actually the same device id ( i think they share a universal Kwikset zwave card).
Not sure where to discuss this, so I’ll start here. Chris, my locks seem to be working great. I added the channels from the yale xml file to the one your site generated for the kwikset, I also added association groups. All is well.
Two things have come up in testing. First is the AlarmCommandClass, I have added additional types to it to support the various locking/tamper/battery alarms (pasted below), but the channel type for alarm_general is a switch, not a number. Before I go changing stuff I wanted to consult what’s the right way to handle reporting the alarm type, should this be a generic DecimalType channel (door_alarm) ? I’m kinda playing with that approach now.
Second is that sending commands to lock and unlock work fine, and if the binding polls the lock for its state, that also works, but the lock won’t send basic updates to the lock_door channel when it changes physical state. What’s interesting is that the lock will quickly send alarms when it locks and unlocks, so my assumption right now is that after an alarm is received you would need to poll the door for its locked or unlocked state. Not sure where the appropriate place would be to put that kind of logic in the binding (sounds messy)
public enum AlarmType { GENERAL(0, "General"), SMOKE(1, "Smoke"), CARBON_MONOXIDE(2, "Carbon Monoxide"), CARBON_DIOXIDE(3, "Carbon Dioxide"), HEAT(4, "Heat"), FLOOD(5, "Flood"), ACCESS_CONTROL(6, "Access Control"), BURGLAR(7, "Burglar"), POWER_MANAGEMENT(8, "Power Management"), SYSTEM(9, "System"), EMERGENCY(10, "Emergency"), CLOCK(11, "Clock"), APPLIANCE(12, "Appliance"), HOME_HEALTH(13, "Home Health"), MANUAL_LOCKED(21, "Manual Locked"), KEYPAD_LOCKED(18, "Locked with Keypad"), COMMAND_LOCKED(19, "Locked by Command"), RF_LOCKED(24, "Locked by RF module"), AUTO_LOCKED(27, "Auto Locked"), UNLOCKED(16, "Unlocked"), KEYPAD_UNLOCK(19, "Unlocked by Keypad"), MANUAL_LOCK(22, "Manual unlocked"), RF_UNLOCK(25, "Unlocked by RF module"), DEADBOLT_JAMMED(9, "Bolt is Jammed"), CODE_ADDED(13, "Code was Added"), ALL_CODES_DELETED(32, "All Codes Deleted"), CODE_DELETED(33, "User Code Deleted"), CODE_CHANGED(112, "User Code Changed"), POWER_CYCLED(130, "Power Cycled"), DUPLICATE_CODE(113, "Duplicate Code"), TAMPAR_ALARM(161, "Failed Code"), BATTERY_LOW(167, "Battery Low"), BATTERY_CRITICAL(168, "Battery Critical"), BATTEERY_TOO_LOW(169, "Battery too low to operate");
FYI I was able to get the lock to update its state with a simple rule
rule "FRONT DOOR LOCK" when Item Lock_Front_Gate_Alarm_General changed then sendCommand(Lock_Front_Gate_Lock,"REFRESH") end
The way it currently works is not to report alarm type - there are separate channels for each alarm type, so a switch (ON/OFF) is all that should be needed I think. This is also what we had in OH1.
Looking at your list of commands I see duplicates - this clearly won’t work. Is that a mistake, or are there multiple definitions for some numbers? At the end of the day, the enum name is irrelevant - what matters is the channel definitions.
I think that maybe at some stage we might look to adding some sort of poll on update as a general feature, but let’s not jump into that - it looks like you’ve got things working with the rule for now.
I’ll take a look at this in the next day or so. I suspect that it might not have processed your file as another might have been loaded previously. Yours has all the secure stuff in it, so I will re-run it through the processor to make sure it adds all the ‘good stuff’ .
Yes, I had hastily put it together which is why there is no PR 
I have an updated version, but the little info I can find on the alarm CC conflicts with what is already there, you can see I commented out the deadbolt below as it conflicts with the system type. I sourced most of these from the Yale guide plus some references from smarthings,
public enum AlarmType { GENERAL(0, "General"), SMOKE(1, "Smoke"), CARBON_MONOXIDE(2, "Carbon Monoxide"), CARBON_DIOXIDE(3, "Carbon Dioxide"), HEAT(4, "Heat"), FLOOD(5, "Flood"), ACCESS_CONTROL(6, "Access Control"), BURGLAR(7, "Burglar"), POWER_MANAGEMENT(8, "Power Management"), SYSTEM(9, "System"), EMERGENCY(10, "Emergency"), CLOCK(11, "Clock"), APPLIANCE(12, "Appliance"), HOME_HEALTH(13, "Home Health"), MANUAL_LOCKED(21, "Manual Locked"), KEYPAD_LOCKED(18, "Locked with Keypad"), RF_LOCKED(24, "Locked by RF module"), AUTO_LOCKED(27, "Auto Locked"), UNLOCKED(16, "Unlocked"), KEYPAD_UNLOCK(19, "Unlocked by Keypad"), MANUAL_UNLOCK(22, "Manual unlocked"), RF_UNLOCK(25, "Unlocked by RF module"), //DEADBOLT_JAMMED(9, "Bolt is Jammed"), //CODE_ADDED(13, "Code was Added"), ALL_CODES_DELETED(32, "All Codes Deleted"), CODE_DELETED(33, "User Code Deleted"), CODE_CHANGED(112, "User Code Changed"), POWER_CYCLED(130, "Power Cycled"), DUPLICATE_CODE(113, "Duplicate Code"), TAMPAR_ALARM(161, "Failed Code"), BATTERY_LOW(167, "Battery Low"), BATTERY_CRITICAL(168, "Battery Critical"), BATTEERY_TOO_LOW(169, "Battery too low to operate");
Just a quick update, i finally got my motion sensors to be detected, no amount of taking them to the secondary controller and waking them worked so i instead pushed a config change to association group 1 to include the secondary controller then thy just started popping in.
now i do have a Zipato PH-PSE02-EU Siren which is a re-badged Phileo PSE02-EU and is the same also as the Dlink DCH-Z510 i know all three sirens use the same config as i wrote device handlers for the ST platform that is identical for all three.
anyway this isn’t in the database, then it joins it has the following after the Node ID 
the XML file generated is
<node>
<deviceClass>
<basicDeviceClass>ROUTING_SLAVE</basicDeviceClass>
<genericDeviceClass>BINARY_SWITCH</genericDeviceClass>
<specificDeviceClass>SIREN_SWITCH_BINARY</specificDeviceClass>
</deviceClass>
<homeId>0xe2d4ea9c</homeId>
<nodeId>4</nodeId>
<version>4</version>
<manufacturer>0x13c</manufacturer>
<deviceId>0xa</deviceId>
<deviceType>0x4</deviceType>
<listening>true</listening>
<frequentlyListening>false</frequentlyListening>
<routing>true</routing>
<security>false</security>
<beaming>true</beaming>
<maxBaudRate>40000</maxBaudRate>
<nodeInformationFrame>
<int>94</int>
<int>114</int>
<int>134</int>
<int>89</int>
<int>115</int>
<int>90</int>
<int>152</int>
<int>122</int>
</nodeInformationFrame>
<supportedCommandClasses>
<entry>
<commandClass>SWITCH_BINARY</commandClass>
<binarySwitchCommandClass>
<version>1</version>
<instances>1</instances>
<isGetSupported>true</isGetSupported>
</binarySwitchCommandClass>
</entry>
<entry>
<commandClass>VERSION</commandClass>
<versionCommandClass>
<version>1</version>
<instances>1</instances>
<libraryType>LIB_SLAVE_ENHANCED</libraryType>
<protocolVersion>3.95</protocolVersion>
<applicationVersion>1.8</applicationVersion>
</versionCommandClass>
</entry>
<entry>
<commandClass>MANUFACTURER_SPECIFIC</commandClass>
<manufacturerSpecificCommandClass>
<version>1</version>
<instances>1</instances>
</manufacturerSpecificCommandClass>
</entry>
<entry>
<commandClass>NO_OPERATION</commandClass>
<noOperationCommandClass>
<version>1</version>
<instances>1</instances>
</noOperationCommandClass>
</entry>
<entry>
<commandClass>POWERLEVEL</commandClass>
<powerLevelCommandClass>
<version>1</version>
<instances>1</instances>
</powerLevelCommandClass>
</entry>
<entry>
<commandClass>BASIC</commandClass>
<basicCommandClass>
<version>1</version>
<instances>1</instances>
<isGetSupported>true</isGetSupported>
</basicCommandClass>
</entry>
<entry>
<commandClass>DEVICE_RESET_LOCALLY</commandClass>
<deviceResetLocallyCommandClass>
<version>1</version>
<instances>1</instances>
</deviceResetLocallyCommandClass>
</entry>
<entry>
<commandClass>ZWAVE_PLUS_INFO</commandClass>
<zwavePlusCommandClass>
<version>1</version>
<instances>1</instances>
<zwPlusVersion>1</zwPlusVersion>
<zwPlusRole>5</zwPlusRole>
<zwPlusNodeType>0</zwPlusNodeType>
<zwPlusDeviceType>0xf00</zwPlusDeviceType>
<zwPlusInstallerIcon>0xf00</zwPlusInstallerIcon>
<isGetSupported>true</isGetSupported>
</zwavePlusCommandClass>
</entry>
</supportedCommandClasses>
<securedCommandClasses/>
<nodeNeighbors>
<int>1</int>
<int>2</int>
<int>3</int>
<int>5</int>
<int>6</int>
<int>7</int>
<int>14</int>
<int>16</int>
<int>17</int>
<int>18</int>
<int>19</int>
<int>21</int>
<int>22</int>
<int>41</int>
<int>46</int>
<int>47</int>
<int>48</int>
<int>49</int>
<int>74</int>
<int>75</int>
<int>76</int>
<int>77</int>
<int>86</int>
<int>88</int>
<int>89</int>
<int>90</int>
<int>91</int>
<int>94</int>
</nodeNeighbors>
<lastSent>2016-03-22 19:53:58.257 UTC</lastSent>
<lastReceived>2016-03-22 19:53:58.296 UTC</lastReceived>
</node>
For
http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/290
I wanted to use the copy config option in the database
to copy FROM
http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/170
I get an error. The device should identical in Parameters etc.
1136 Column count doesn't match value count at row 1 SQL=INSERT INTOjoo_zwave_parameters(device,param_id,label,units,description,size,value_min,value_max,value_default,read_only,write_only,overview,created_by) VALUES (290,'2','0','Basic Set Level','','Setting the BASIC command value to turn on the light.<br/>\r\n <ul><li>-1 = 0xFF(-1) turns on the light. (Default)</li>\r\n <li>0 = Turn off the light.</li>\r\n <li>1 - 100 = For dimmers 1 to 100 means the light strength.</li></ul>','1','0','-1','100','-1','','','','0','',310)
Something seems to have broken in 2.0.0.201603220202… I have tons of “Not the right scale” events in my debug log since I upgraded the binding yesterday…
2016-03-23 18:39:07.896 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 14 00 04 00 03 0E 32 02 21 64 00 00 00 1A 00 3C 00 00 00 1A AB
2016-03-23 18:39:07.896 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-03-23 18:39:07.896 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 14 00 04 00 03 0E 32 02 21 64 00 00 00 1A 00 3C 00 00 00 1A AB
2016-03-23 18:39:07.896 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 14 00 04 00 03 0E 32 02 21 64 00 00 00 1A 00 3C 00 00 00 1A AB
2016-03-23 18:39:07.896 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, payload=00 03 0E 32 02 21 64 00 00 00 1A 00 3C 00 00 00 1A
2016-03-23 18:39:07.896 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Application Command Request (ALIVE:DONE)
2016-03-23 18:39:07.897 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Incoming command class METER
2016-03-23 18:39:07.897 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 3: Received Meter Request
2016-03-23 18:39:07.897 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 3: Meter: Type=Electric(1), Scale=kWh(0), Value=0.026
2016-03-23 18:39:07.897 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveMeterValueEvent
2016-03-23 18:39:07.897 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got an event from Z-Wave network: ZWaveMeterValueEvent
2016-03-23 18:39:07.897 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got a value event from Z-Wave network, endpoint = 0, command class = METER, value = 0.026
2016-03-23 18:39:07.897 [DEBUG] [ternal.converter.ZWaveMeterConverter] - Not the right scale E_W <> E_KWh
2016-03-23 18:39:07.897 [DEBUG] [ternal.converter.ZWaveMeterConverter] - Not the right scale E_A <> E_KWh
2016-03-23 18:39:07.897 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Updating zwave:device:0f08878c:node3:meter_kwh to 0.026
2016-03-23 18:39:07.897 [DEBUG] [ternal.converter.ZWaveMeterConverter] - Not the right scale E_V <> E_KWh
2016-03-23 18:39:07.897 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Updating zwave:device:0f08878c:node3:meter_reset to 0.026
The above example is from an Aeon Labs Micro Smart Energy Switch G2 (DSC18) but I have them for other sensors as well. On a somewhat related note: the meter_reset doesn’t work anymore either (related?). Confirmed to work until some two days ago but now doesn’t do anything…: it throws a warning that no message was received from the converter.
2016-03-23 18:44:31.953 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Command received zwave:device:0f08878c:node8:meter_reset --> ON
2016-03-23 18:44:31.953 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: No messages returned from converterThis is just a debugging message for something I was testing. What exactly isn’t working for you?
This is caused by the database change - I’ve updated the database and this will be fixed in the next release (probably a few days due to waiting for some ESH changes).
Please let me know what the other problem is and I’ll look into that too…
Cheers
Chris
Not yet, sorry. I’ll look at this tonight or tomorrow (I wasn’t around last night)…
Cheers
Chris
The problem with the other issue is that I noticed a change in meter readings. For instance a small appliance started reporting 10’s of kWh’s every hour whereas before these would report like a factor of 100 less (less than 1 kWh’s).
It might have been caused by me messing around with InfluxDB persistence so I need to double check to see if can reproduce with a clean setup and capture the logs. I’ll just ignore all the debug messages you mentioned below.
Hmmm - I can’t really see that anything I’ve changed will have changed meter readings by 100W 
I just manually decoded the message in your log, and the device appears to be reporting 0.026, and the binding is decoding this value correctly. In the above, the 64 is the scale value, and (the 6 gets shifted to mean divide by 3), and the 1A is the value (26), so 26/3 = 0.026…