Secure SRT321 - how to complete initialization?

mkaut · February 25, 2021, 9:44pm

After some problems, I have failed managed to add “Secure SRT321” Z-wave thermostat to my OH 2.5, running on RPi with Z-Stick Gen 5.
The device is recognized and I can see its channels, but no data is coming from it. In the log, I found

NODE 16: Polling deferred until initialisation complete

When I tried to heal the device, I see this in the log:

NODE 16: Can not start heal as initialisation is not complete (ASSOCIATIONS).

I found that all association groups were empty, so I associated all with Controller. In HABMIN, it said “pending” for quite some time, but now it looks like all groups have been associated.
I can also see that the device does not list any neighbours and the network viewer in HABMIN shows the node as disconnected from the rest of the network.

What can I do to make it work?

More info:
I have already tried deleted the node and discovering it again, but it did not help.
Here is a full sequence of what I did to add the device (since the ’ Inclusion Information’ in OH is both meaningless and wrong):

set the device in the installer mode
used the “+” in Paper UI and then selected “L” on the device - this adds the device to OH
selected “n” on the device, which transmits ‘node information frame’ (NIF) - after this, the device is recognized in OH

After that, I let the device there for one night, only tried selecting “Li” a couple of times, since this should keep it awake for 1 min.
As this did not helped, I switched off the ‘installer mode’ and let it be for another 12 hours.

mkaut · March 8, 2021, 8:31pm

A short update: it turns out the thermostat has to be in the installer mode in order to receive changes in associations. Once its Lifeline group gets associated to the controller, OH starts to receive values for all channels except Switch and “Battery Level”.
For the Switch channel, one needs to associate the “Switch Control” group to the controller as well - I have not tested associating it with an on/off device yet.

This means that I can now use the thermostat, but there are two issues remaining:

I still haven’t received a single update about battery level - I tried both with and without associating the “Battery Info” group to the controller.
The device is still not properly included in the network: it has no neighbours, the network viewer shows it as a disconnected node, and any attempt to heal it still fails with the same error message as above, followed by

[INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zwave:device:161058c2207:node16' has been updated.
[INFO ] [smarthome.event.ConfigStatusInfoEvent] - ConfigStatusInfo [configStatusMessages=[]]

(I even tried associating all groups to the controller, but it did not help.)

Any idea how to fix these last issues?

Maximo · March 9, 2021, 9:21am

I have a couple of these thermostats. Under Wakeup Configuration, make sure you have the controller node assigned. Usually this is node 1.

Also I point all 5 of the association groups to the controller.

To make sure the devices completes it’s initialisation by putting it into Installer mode and selecting L1 and pushing the dial. You’ll need to do this a few times, so have the ZWave log file open at the same time to see that data is being sent between the controller and the device.

mkaut · March 9, 2021, 10:49am

I checked and “Wakeup Node” in “Wakeup Configuration” in Paper UI is set to 1 - I do not recall setting this, so I guess it was like this from the start.

Do you mean that you see something in the log when you use “L1” on the device? This is not the case with me.

As a test, I tried to remove all group associations except for Lifeline and “Switch Control”. I used the “L1” on device before pressing “Save” (in HABmin) and this resulted in a lot of output in the log:

[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Configuration update received
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Configuration update set group_5 to [] (EmptyList)
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Association 5 consolidated to []
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Current members before update ZWaveAssociationGroup [index=5, name=null, profile1=null, profile2=null, associations=[node_1]]
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Members after config update ZWaveAssociationGroup [index=5, name=null, profile1=null, profile2=null, associations=[]]
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Controller is master - forcing associations
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Members after controller update ZWaveAssociationGroup [index=5, name=null, profile1=null, profile2=null, associations=[]]
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Association group 5 contains no members. Clearing.
[DEBUG] [ndclass.ZWaveAssociationCommandClass] - NODE 16: Creating new message for application command ASSOCIATIONCMD_REMOVE group=5, node=all
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: SECURITY not supported
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: Command Class COMMAND_CLASS_ASSOCIATION is NOT required to be secured
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Bump transaction 12760 priority from Config to Immediate
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Adding to device queue
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Added 12760 to queue - size 10
[DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
[DEBUG] [ndclass.ZWaveAssociationCommandClass] - NODE 16: Creating new message for application command ASSOCIATIONCMD_GET group 5
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: SECURITY not supported
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: Command Class COMMAND_CLASS_ASSOCIATION is NOT required to be secured
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Bump transaction 12761 priority from Config to Immediate
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Adding to device queue
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Added 12761 to queue - size 11
[DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Configuration update set group_4 to [] (EmptyList)
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Association 4 consolidated to []
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Current members before update ZWaveAssociationGroup [index=4, name=null, profile1=null, profile2=null, associations=[node_1]]
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Members after config update ZWaveAssociationGroup [index=4, name=null, profile1=null, profile2=null, associations=[]]
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Controller is master - forcing associations
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Members after controller update ZWaveAssociationGroup [index=4, name=null, profile1=null, profile2=null, associations=[]]
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Association group 4 contains no members. Clearing.
[DEBUG] [ndclass.ZWaveAssociationCommandClass] - NODE 16: Creating new message for application command ASSOCIATIONCMD_REMOVE group=4, node=all
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: SECURITY not supported
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: Command Class COMMAND_CLASS_ASSOCIATION is NOT required to be secured
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Bump transaction 12762 priority from Config to Immediate
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Adding to device queue
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Added 12762 to queue - size 12
[DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
[DEBUG] [ndclass.ZWaveAssociationCommandClass] - NODE 16: Creating new message for application command ASSOCIATIONCMD_GET group 4
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: SECURITY not supported
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: Command Class COMMAND_CLASS_ASSOCIATION is NOT required to be secured
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Bump transaction 12763 priority from Config to Immediate
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Adding to device queue
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Added 12763 to queue - size 13
[DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Configuration update set group_6 to [] (EmptyList)
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Association 6 consolidated to []
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Current members before update ZWaveAssociationGroup [index=6, name=null, profile1=null, profile2=null, associations=[node_1]]
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Members after config update ZWaveAssociationGroup [index=6, name=null, profile1=null, profile2=null, associations=[]]
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Controller is master - forcing associations
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Group is controller - forcing association
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Members after controller update ZWaveAssociationGroup [index=6, name=null, profile1=null, profile2=null, associations=[node_1_1]]
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Removing node_1 from association group 6
[DEBUG] [ndclass.ZWaveAssociationCommandClass] - NODE 16: Creating new message for application command ASSOCIATIONCMD_REMOVE group=6, node=1
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: SECURITY not supported
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: Command Class COMMAND_CLASS_ASSOCIATION is NOT required to be secured
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Bump transaction 12764 priority from Config to Immediate
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Adding to device queue
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Added 12764 to queue - size 14
[DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Adding node_1_1 to association group 6
[DEBUG] [ndclass.ZWaveAssociationCommandClass] - NODE 16: Creating new message for application command ASSOCIATIONCMD_SET, group=6, node=1
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: SECURITY not supported
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: Command Class COMMAND_CLASS_ASSOCIATION is NOT required to be secured
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Bump transaction 12765 priority from Config to Immediate
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Adding to device queue
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Added 12765 to queue - size 15
[DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
[DEBUG] [ndclass.ZWaveAssociationCommandClass] - NODE 16: Creating new message for application command ASSOCIATIONCMD_GET group 6
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: SECURITY not supported
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: Command Class COMMAND_CLASS_ASSOCIATION is NOT required to be secured
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Bump transaction 12766 priority from Config to Immediate
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Adding to device queue
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Added 12766 to queue - size 16
[DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Configuration update set group_2 to [] (EmptyList)
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Association 2 consolidated to []
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Current members before update ZWaveAssociationGroup [index=2, name=null, profile1=null, profile2=null, associations=[node_1]]
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Members after config update ZWaveAssociationGroup [index=2, name=null, profile1=null, profile2=null, associations=[]]
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Controller is master - forcing associations
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Members after controller update ZWaveAssociationGroup [index=2, name=null, profile1=null, profile2=null, associations=[]]
[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Association group 2 contains no members. Clearing.
[DEBUG] [ndclass.ZWaveAssociationCommandClass] - NODE 16: Creating new message for application command ASSOCIATIONCMD_REMOVE group=2, node=all
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: SECURITY not supported
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: Command Class COMMAND_CLASS_ASSOCIATION is NOT required to be secured
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Bump transaction 12767 priority from Config to Immediate
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Adding to device queue
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Added 12767 to queue - size 17
[DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
[DEBUG] [ndclass.ZWaveAssociationCommandClass] - NODE 16: Creating new message for application command ASSOCIATIONCMD_GET group 2
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: SECURITY not supported
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: Command Class COMMAND_CLASS_ASSOCIATION is NOT required to be secured
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Bump transaction 12768 priority from Config to Immediate
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Adding to device queue
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Added 12768 to queue - size 18

All this took under 1 second.

What worries me is the message queue: if I read it correctly, there is a queue of 18 messages for the device, and I have no idea how to clear it…

Is it so that the device is supposed to tell OH when it wakes up, so OH can send it updates? Because it looks like this does not happen with me

chris · March 9, 2021, 11:33am

You need to wake the device up, or wait for the device to wake up.

mkaut · March 9, 2021, 11:44am

That’s what the “Li” action is supposed to do. From the manual: “This function will keep the unit awake for 60sec, no Pass or Fail responses will be provided”.
The problem is I do not see any message in the log (with Z-wave in DEBUG) when I do this, which to me suggests that OH does not know that the device is awake…

By the way, the “Wakeup Information” in the device description is completely wrong, since the “P” action mentioned there is for protocol reset, not wakeup. (The “Include information” is also wrong, since it describes how to pair the thermostat with a specific receiver (where the thermostat plays a role of the main controller), not how to add it as a device to existing z-wave network…)

Maximo · March 9, 2021, 12:00pm

You have to wake up the device a number of times before it completes the initialisation process. So move the dial to L1 and press the dial, watch the ZWave logfile and repeat until there are no further messages queued.

I agree it’s a painful process to follow, but it only needs to be done once. Unless you remove and re-add the Thermostat.

chris · March 9, 2021, 12:02pm

Correct - this would be probably because the device isn’t waking up. If the device doesn’t wake, the binding simply will never send any data to it.

You mean the manual is wrong? Or the database is wrong? Given that it doesn’t seem that you are waking up the device, I think it’s worth getting that working before we decide what is wrong

mkaut · March 9, 2021, 12:33pm

Sorry for not being precise: I meant the information OH shows about the device (under “Overview”, in both Paper UI and HABmin), which I guess implies the database. The manual is correct, as far as I can see.
My plan was to first make the device work and then reach out to you with corrections for the description, but as you can see I have problems with the first part of the plan
By the way, this manual seems correct to me: http://manuals-backend.z-wave.info/make.php?lang=en&type=&sku=SEC_SRT321

What I find strange is that the device communicates with OH: when I change the setpoint on the thermostat, I can see the changes immediately in OH. When I change the setpoint in OH, the thermostat will update after a (long) while.

By the way, here is a log of me changing the setpoint in OH to 19 C:

[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Command received zwave:device:161058c2207:node16:thermostat_setpoint_heating --> 19 °C [QuantityType]
[DEBUG] [ter.ZWaveThermostatSetpointConverter] - NODE 16: Thermostat command received for 19 °C
[DEBUG] [.ZWaveThermostatSetpointCommandClass] - NODE 16: Creating new message for command THERMOSTAT_SETPOINT_SET
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: SECURITY not supported
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: Command Class COMMAND_CLASS_THERMOSTAT_SETPOINT is NOT required to be secured
[DEBUG] [ter.ZWaveThermostatSetpointConverter] - NODE 16: Sending Message: org.openhab.binding.zwave.internal.protocol.transaction.ZWaveCommandClassTransactionPayload@175e89f
[DEBUG] [.ZWaveThermostatSetpointCommandClass] - NODE 16: Creating new message for application command THERMOSTAT_SETPOINT_GET (Heating)
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: SECURITY not supported
[DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: Command Class COMMAND_CLASS_THERMOSTAT_SETPOINT is NOT required to be secured
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Bump transaction 12909 priority from Set to Immediate
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Adding to device queue
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Added 12909 to queue - size 12
[DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

What I find interesting is that the queue size is 12, while in the earlier message it was 18 - so I guess some messages are getting delivered after all. (But the node is still shown as not connected to the network in the network viewer in HABmin. )

Maximo · March 9, 2021, 1:47pm

That’s by design, it’s a battery device so only wakes up after a certain time, which you can configure under Wakeup Interval. Mine are setup to wakeup every 1800 seconds or half hour. It’s a compromise between battery life and speed of updates. The shorter time between the shorter the battery life, the longer time and it’s a longer battery life. My heating rules only alter a few times over a 24hour period so the time interval I have works fine for my needs at present.

mkaut · March 9, 2021, 2:29pm

I got that, but thanks. I was making the point that the communication works both ways, even if OH shows the device as not being part of the network (no neighbours).

Incidentally, I also ended on wakeup period of 1800 seconds. In addition, I have polling period of 1 hour and the command poll period on 1500 ms (default). What are you using?

Also, could you check whether your thermostats report battery state and whether the network viewer in HABmin shows them as connected to the network (or, alternatively, whether zwave_neighbours in Properties in Paper UI include anything)?

chris · March 9, 2021, 2:52pm

OH shows the device as not being part of the network (no neighbours).

Just because it shows no neighbours does not mean that it is not part of the network. It’s not uncommon for battery devices to not provide the neighbour list - they are more complex to get this information from, but it is still part of the network. Note that obviously battery devices are not performing routing. The neighbours are normally updated during the heal - or at the end of the initialisation.

Maximo · March 9, 2021, 2:56pm

In terms of polling I have mine sat to 1 day and 1500ms, so the default. Yes my battery state is being reported. Neither of my Thermostats are showing as having any neighbours, either in the attributes or the network viewer.

All 5 of the association groups are pointing at the controller.

chris · March 9, 2021, 2:58pm

Why do you need to do this?

Normally this is a bad idea, but maybe the device is poorly implemented and you felt the need to do this? Normally only the lifeline is required, and if you add multiple associations, you will receive duplicate messages and reduce battery life. Unless you’ve found the need to do this for some reason, it is not recommended.

mkaut · March 9, 2021, 3:02pm

Thanks, I did not know this. At least I have one less thing to worry about

chris · March 9, 2021, 3:05pm

From a quick look at the manual, it looks like the device is designed for only the lifeline to be connected - the lifeline is stated as providing a number of reports at least -:

mkaut · March 9, 2021, 3:07pm

My testing so far suggests that I need to associate the “Switch Control” group, if I want to receive the ON/OFF commands. (Maybe because the the thermostat is meant to control an actual device?)
Moreover, I always get the “Air Temperature” association - it comes back even if I delete it.

chris · March 9, 2021, 3:10pm

Useful to know - it might be good to add this to the database usage information…

I’m not familiar with the device, but it always worries me when people connect all the association groups as the next message see is often about duplicate messages causing problems with rules etc

Maximo · March 9, 2021, 3:12pm

There is no lifeline option on the device.

chris · March 9, 2021, 3:15pm

Maybe the manual is wrong, but I suspect it’s more likely just incorrectly named in the database isn’t it? With a ZWave Plus device - Group1 is ALWAYS the lifeline - this is required by the protocol spec.