Z-Wave will not finish initialization of CT32 Thermostat

[airix1]

I have a CT32 Thermostat (link to pepper1 db) that initialized quickly with an older version of the zwave binding (circa March this year), but will not initialize with the most recent build from cloudbees (Nov 28th). The most recent build does not even create a nodeX.xml for the device. I've attached the node.xml from the march version, as well as the zwave logs from the newest version. node.xml zwave.log

I'm also attaching the device xml for the zwave database that I've created ct32.xml and the product portion for the product.xml product

If there is anything else I can do to help troubleshoot this let me know.

[cdjackson]

This is a bit strange. It looks like the association class is reporting multi instance, which is wrong. I don’t know why at the moment - it needs more analyses, but it would be worth deleting the XML file just to see if it makes any difference.

[airix1]

I've deleted the XML file, but the newer version of the binding does not end up creating a XML file for that node.

[airix1]

Some info that may help: (https://radiothermostat.desk.com/customer/portal/kb_article_attachments/56875/original.pdf?1434142296) I believe this is the same module that is in both the CT32 and CT101 thermostats.

Association group:
This device support one association group, and up to two nodes in that group. If at least one node is added to association group one (1), the thermostat will send the following association reports when the respective state has changed:
• Thermostat Mode Report
• Thermostat Operating State Report
• Fan Mode Report
• Fan State Report
• Setpoint Report (for all supported setpoints)
• Sensor Multilevel Report (if enabled by Configuration Command Class)
The association command class can be configured to send encapsulated reports via the Multi Instance Command Class or the Multi Channel Command Class. If the association configuration commands are sent inside encapsulated commands, the thermostat will respond with encapsulated reports of the same type (Multi Instance v1 or Multi Channel v3). Encapsulation is the only way to configure the thermostat to send humidity sensor multilevel association reports.
For example, if an Association Set is encapsulated in a Multi Channel Command Encapsulation command is sent to the humidity instance (2), then the thermostat will encapsulate all un-solicited humidity sensor multilevel reports in the Multi Channel Command Encapsulation Command. The default instance is the temperature instance (1). If the Association Set is sent un-encapsulated then the thermostat will send all un-solicited temperature sensor multilevel reports unencapsulated.
All association reports other than the humidity multilevel are in the default instance (1). The thermostat will encapsulate the association reports based on the last Association Set encapsulation type received (i.e. un-encapsulated, Multi Instance v1, or Multi Channel V3).

[cdjackson]

Interesting. Looking at some logs from the CT101 last night it appears as though the device wasn't responding to encapsulated requests. Maybe there's a difference with the version - I'll take a look at this.

Thanks.

Sent from my iPhone

On 5 Dec 2015, at 03:57, airix1 notifications@github.com wrote:

Some info that may help: (https://radiothermostat.desk.com/customer/portal/kb_article_attachments/56875/original.pdf?1434142296) I believe this is the same module that is in both the CT32 and CT101 thermostats.

Association group: This device support one association group, and up to two nodes in that group. If at least one node is added to association group one (1), the thermostat will send the following association reports when the respective state has changed: • Thermostat Mode Report • Thermostat Operating State Report • Fan Mode Report • Fan State Report • Setpoint Report (for all supported setpoints) • Sensor Multilevel Report (if enabled by Configuration Command Class) The association command class can be configured to send encapsulated reports via the Multi Instance Command Class or the Multi Channel Command Class. If the association configuration commands are sent inside encapsulated commands, the thermostat will respond with encapsulated reports of the same type (Multi Instance v1 or Multi Channel v3). Encapsulation is the only way to configure the thermostat to send humidity sensor multilevel association reports. For example, if an Association Set is encapsulated in a Multi Channel Command Encapsulation command is sent to the humidity instance (2), then the thermostat will encapsulate all un-solicited humidity sensor multilevel reports in the Multi Channel Command Encapsulation Command. The default instance is the temperature instance (1). If the Association Set is sent un-encapsulated then the thermostat will send all un-solicited temperature sensor multilevel reports unencapsulated. All association reports other than the humidity multilevel are in the default instance (1). The thermostat will encapsulate the association reports based on the last Association Set encapsulation type received (i.e. un-encapsulated, Multi Instance v1, or Multi Channel V3). — Reply to this email directly or view it on GitHub.

[airix1]

Hi Chris, any update with the multi instance associations?

[cdjackson]

Not really. Can you email me a log from your system?

[bigbasec]

Same issue here with both a CT30(with the newer Usnap module, which I think turns it into a CT32), and the CT101. Neither one of them will actually "finish" the initialization, nor does it create an xml file.

[cdjackson]

Can you email me a log from your system?

[airix1]

That jar you gave me to try has been working great so far Chris.

[cdjackson]

Thanks @airix1.

@bigbasec please confirm what version of the binding you're using?

[bigbasec]

Latest and greatest from git as of this afternoon. Though I think I may have found a couple issues on my end, and one in the db. The CT 101 has no configurable options w/ the default, though the pepper db shows it having the same options as the CT 32, so I updated the products.xml, and am waiting for the initialization to complete now to see if that made any difference. I usually need to wait overnight, as the CT101 I have is battery powered, the CT30 is hardwired, so that is usually quicker. I removed, and re-added both this afternoon, so we'll see what happens I guess.

So far with an uptime of about 20 minutes, it has not serialized, so I have no nodeXY.xml.

[bigbasec]

Not saying it's a problem, but I am seeing this for both thermostats : 2016-01-05 18:07:50.173 ERROR o.o.b.z.i.p.i.ZWaveNodeStageAdvancer[:316]- NODE 23: Node advancer: Retries exceeded at STATIC_VALUES 2016-01-05 18:07:50.174 DEBUG o.o.b.z.i.p.i.ZWaveNodeStageAdvancer[:329]- NODE 23: Retry timout: Can't advance

I guess I'll see if they ever complete. They do both seem to be responding to commands, short of the CT101 not updating the battery level.

[cdjackson]

Please provide a debug log of what is happening prior to this message. You shoul see some repeating blocks of messages.

Sent from my iPhone

On 5 Jan 2016, at 23:18, bigbasec notifications@github.com wrote:

Not saying it's a problem, but I am seeing this for both thermostats : 2016-01-05 18:07:50.173 ERROR o.o.b.z.i.p.i.ZWaveNodeStageAdvancer[:316]- NODE 23: Node advancer: Retries exceeded at STATIC_VALUES 2016-01-05 18:07:50.174 DEBUG o.o.b.z.i.p.i.ZWaveNodeStageAdvancer[:329]- NODE 23: Retry timout: Can't advance

I guess I'll see if they ever complete. They do both seem to be responding to commands, short of the CT101 not updating the battery level.

— Reply to this email directly or view it on GitHub.

[bigbasec]

Do you want the full log, or just a grep for that specific node? Here is the most recent grep for the CT30 w/ the updated USNAP module :

2016-01-06 13:42:05.408 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:1268]- NODE 23: Sending REQUEST Message = 01 0D 00 13 17 06 60 0D 01 01 85 05 25 1F 27 2016-01-06 13:42:05.421 DEBUG o.o.b.z.i.p.s.SendDataMessageClass[:38]- NODE 23: Sent Data successfully placed on stack. 2016-01-06 13:42:05.461 DEBUG o.o.b.z.i.p.s.SendDataMessageClass[:74]- NODE 23: SendData Request. CallBack ID = 31, Status = Transmission complete and ACK received(0) 2016-01-06 13:42:05.509 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:38]- NODE 23: Application Command Request (ALIVE:STATIC_VALUES) 2016-01-06 13:42:05.510 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:56]- NODE 23: Incoming command class MULTI_INSTANCE 2016-01-06 13:42:05.511 DEBUG o.o.b.z.i.p.c.ZWaveMultiInstanceCommandClass[:145]- NODE 23: Received Multi-instance/Multi-channel Request 2016-01-06 13:42:05.511 ERROR o.o.b.z.i.p.c.ZWaveMultiInstanceCommandClass[:229]- NODE 23: Unsupported command class 0x01 2016-01-06 13:42:05.516 DEBUG o.o.b.z.i.p.i.ZWaveNodeStageAdvancer[:1013]- NODE 23: Node advancer - STATIC_VALUES: Transaction complete (SendData:Request) success(true) 2016-01-06 13:42:05.516 DEBUG o.o.b.z.i.p.i.ZWaveNodeStageAdvancer[:203]- NODE 23: Node advancer - checking initialisation queue. Queue size 2. 2016-01-06 13:42:05.517 DEBUG o.o.b.z.i.p.i.ZWaveNodeStageAdvancer[:209]- NODE 23: Node advancer - message removed from queue. Queue size 1. 2016-01-06 13:42:05.517 DEBUG o.o.b.z.i.p.i.ZWaveNodeStageAdvancer[:269]- NODE 23: Node advancer - STATIC_VALUES: queue length(1), free to send(true) 2016-01-06 13:42:05.518 DEBUG o.o.b.z.i.p.i.ZWaveNodeStageAdvancer[:1131]- NODE 23: Initialisation retry timer started 1800000 2016-01-06 13:42:05.520 DEBUG o.o.b.z.i.p.i.ZWaveNodeStageAdvancer[:242]- NODE 23: Node advancer - queued packet. Queue length is 1 2016-01-06 13:42:05.521 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:1327]- NODE 23: Response processed after 113ms/4980ms. 2016-01-06 13:42:05.523 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:1268]- NODE 23: Sending REQUEST Message = 01 0D 00 13 17 06 60 0D 01 02 85 05 25 21 1A 2016-01-06 13:42:05.536 DEBUG o.o.b.z.i.p.s.SendDataMessageClass[:38]- NODE 23: Sent Data successfully placed on stack. 2016-01-06 13:42:05.618 DEBUG o.o.b.z.i.p.s.SendDataMessageClass[:74]- NODE 23: SendData Request. CallBack ID = 33, Status = Transmission complete and ACK received(0) 2016-01-06 13:42:05.666 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:38]- NODE 23: Application Command Request (ALIVE:STATIC_VALUES) 2016-01-06 13:42:05.666 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:56]- NODE 23: Incoming command class MULTI_INSTANCE 2016-01-06 13:42:05.667 DEBUG o.o.b.z.i.p.c.ZWaveMultiInstanceCommandClass[:145]- NODE 23: Received Multi-instance/Multi-channel Request 2016-01-06 13:42:05.668 ERROR o.o.b.z.i.p.c.ZWaveMultiInstanceCommandClass[:229]- NODE 23: Unsupported command class 0x01 2016-01-06 13:42:05.672 DEBUG o.o.b.z.i.p.i.ZWaveNodeStageAdvancer[:1013]- NODE 23: Node advancer - STATIC_VALUES: Transaction complete (SendData:Request) success(true) 2016-01-06 13:42:05.672 DEBUG o.o.b.z.i.p.i.ZWaveNodeStageAdvancer[:203]- NODE 23: Node advancer - checking initialisation queue. Queue size 1. 2016-01-06 13:42:05.673 DEBUG o.o.b.z.i.p.i.ZWaveNodeStageAdvancer[:209]- NODE 23: Node advancer - message removed from queue. Queue size 0. 2016-01-06 13:42:05.673 DEBUG o.o.b.z.i.p.i.ZWaveNodeStageAdvancer[:269]- NODE 23: Node advancer - STATIC_VALUES: queue length(0), free to send(true) 2016-01-06 13:42:05.674 DEBUG o.o.b.z.i.p.i.ZWaveNodeStageAdvancer[:1131]- NODE 23: Initialisation retry timer started 1800000 2016-01-06 13:42:05.674 ERROR o.o.b.z.i.p.i.ZWaveNodeStageAdvancer[:316]- NODE 23: Node advancer: Retries exceeded at STATIC_VALUES 2016-01-06 13:42:05.675 DEBUG o.o.b.z.i.p.i.ZWaveNodeStageAdvancer[:329]- NODE 23: Retry timout: Can't advance

[bigbasec]

Anything else I can do to help?

[cdjackson]

I need to see the block where it is itterating through the command classes at the STATIC stage. This should show something where it lists all command classes, and shows what it's sending

Please either email me the full log, or grep the log for node 23 and look for recurring block where it says Node advancer: STATIC_VALUES - checking and Node advancer: STATIC_VALUES - found

[bigbasec]

Emailed it to you Chris, thank you again!

[bigbasec]

Just making sure you got it?

[cdjackson]

Yep, thanks - just replied to you…

[bigbasec]

Just checking if there is any update on this before I pull the trigger on 3 new thermostats?