Non-zwave plus Jasco devices are not detecting physical events.

[Petro31]

I migrated from the built-in-homeassistant v1.4 ozw to qt-openzwave a few days ago. All non-zwave plus Jasco devices (12724-dimmer, 12722-switch) no longer report physical events. Meaning, if a user turns on the light at the light switch, the event does not appear in the ozw raw log. In 1.4, these events appeared in the raw log.

Between the migration, none of these devices were re-included, so the network is identical from the 1.4 to the 1.6. So this is either a bug in 1.6 or a configuration setting somewhere (I could not locate one).

[Petro31]

So I'm guessing this has to do with polling intensity. By default when a device is included, what's the polling intensity set to when it's not zwave-plus?

[Petro31]

What still doesn't make sense is why polling needs to be set. In v1.4, I did not have a polling intensity set. Yet these devices responded immediately. But now after migrating to 1.6, none of them respond.

[Petro31]

So after talking with other people with these devices, it appears as if the 'hails' are no longer being noticed by openzwave. Meaning they aren't even appearing in the raw logs.

However, if I roll back to 1.4, these hails are seen in the logs.

[Fishwaldo]

Logs? Can you check the Association Groups as well - Make sure the controller node ID is in at least group 1 (would have to check the manual if there are other groups specific to your device).

[Petro31]

@Fishwaldo How is this done? I'm learning, but slowly. Is this present in the cache, or viewed inside mqtt?

[Petro31]

Logs? Can you check the Association Groups as well - Make sure the controller node ID is in at least group 1 (would have to check the manual if there are other groups specific to your device).

There are no logs for this unfortunately. When performing physical actions, the logs are empty for the node in question.

[Petro31]

@Fishwaldo Here are the logs from version 1.4. This is what is missing in version 1.6. Mind you, I just switched back to 1.4 and it started working as expected instantly. However in version 1.6 these UPDATE_STATE_NODE_INFO_RECEIVED are completely missing from the raw logs.

HA OZW v1.4 Responses

Jasco 12724 Dimmer (node 10)

2020-06-16 16:52:17.366 Detail, Node010,   Received: 0x01, 0x10, 0x00, 0x49, 0x84, 0x0a, 0x0a, 0x04, 0x11, 0x01, 0x26, 0x27, 0x73, 0x70, 0x86, 0x72, 0x77, 0xb7
2020-06-16 16:52:17.366 Detail,
2020-06-16 16:52:17.366 Info, Node010, UPDATE_STATE_NODE_INFO_RECEIVED from node 10
2020-06-16 16:52:17.366 Detail, Node010, AdvanceQueries queryPending=0 queryRetries=0 queryStage=Dynamic live=1
2020-06-16 16:52:17.366 Detail, Node010, QueryStage_Dynamic
2020-06-16 16:52:17.366 Detail, Node010, Queuing (Send) SwitchMultilevelCmd_Get (Node=10): 0x01, 0x09, 0x00, 0x13, 0x0a, 0x02, 0x26, 0x02, 0x25, 0xb0, 0x5c
2020-06-16 16:52:17.366 Detail, Node010, Queuing (Query) Query Stage Complete (Dynamic)
2020-06-16 16:52:17.366 Detail,
2020-06-16 16:52:17.366 Info, Node010, Sending (Send) message (Callback ID=0xb0, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=10): 0x01, 0x09, 0x00, 0x13, 0x0a, 0x02, 0x26, 0x02, 0x25, 0xb0, 0x5c
2020-06-16 16:52:17.373 Detail, Node010,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2020-06-16 16:52:17.374 Detail, Node010,   ZW_SEND_DATA delivered to Z-Wave stack
2020-06-16 16:52:17.448 Detail, Node010,   Received: 0x01, 0x07, 0x00, 0x13, 0xb0, 0x00, 0x00, 0x08, 0x53
2020-06-16 16:52:17.448 Detail, Node010,   ZW_SEND_DATA Request with callback ID 0xb0 received (expected 0xb0)
2020-06-16 16:52:17.448 Info, Node010, Request RTT 82 Average Request RTT 82
2020-06-16 16:52:17.448 Detail,   Expected callbackId was received
2020-06-16 16:52:17.505 Detail, Node010,   Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x0a, 0x03, 0x26, 0x03, 0x03, 0xdd
2020-06-16 16:52:17.505 Detail,
2020-06-16 16:52:17.505 Info, Node010, Response RTT 138 Average Response RTT 139
2020-06-16 16:52:17.505 Info, Node010, Received SwitchMultiLevel report: level=3
2020-06-16 16:52:17.505 Detail, Node010, Refreshed Value: old value=0, new value=3, type=byte
2020-06-16 16:52:17.505 Detail, Node010, Changes to this value are not verified
2020-06-16 16:52:17.505 Detail, Node010,   Expected reply and command class was received
2020-06-16 16:52:17.505 Detail, Node010,   Message transaction complete
2020-06-16 16:52:17.505 Detail,
2020-06-16 16:52:17.505 Detail, Node010, Removing current message
2020-06-16 16:52:17.505 Detail, Node010, Notification: ValueChanged
2020-06-16 16:52:17.508 Detail, Node010, Query Stage Complete (Dynamic)
2020-06-16 16:52:17.508 Detail, Node010, AdvanceQueries queryPending=0 queryRetries=0 queryStage=Configuration live=1
2020-06-16 16:52:17.508 Detail, Node010, QueryStage_Configuration
2020-06-16 16:52:17.508 Detail, Node010, QueryStage_Complete
2020-06-16 16:52:17.509 Warning, CheckCompletedNodeQueries m_allNodesQueried=0 m_awakeNodesQueried=1
2020-06-16 16:52:17.509 Warning, CheckCompletedNodeQueries all=0, deadFound=0 sleepingOnly=1
2020-06-16 16:52:17.509 Detail, Node010, Notification: NodeQueriesComplete

Jasco 12722 Switch (node 23)

2020-06-16 16:56:15.993 Detail, Node023,   Received: 0x01, 0x10, 0x00, 0x49, 0x84, 0x17, 0x0a, 0x04, 0x10, 0x01, 0x25, 0x27, 0x73, 0x70, 0x86, 0x72, 0x77, 0xa8
2020-06-16 16:56:15.993 Detail,
2020-06-16 16:56:15.993 Info, Node023, UPDATE_STATE_NODE_INFO_RECEIVED from node 23
2020-06-16 16:56:15.993 Detail, Node023, AdvanceQueries queryPending=0 queryRetries=0 queryStage=Dynamic live=1
2020-06-16 16:56:15.993 Detail, Node023, QueryStage_Dynamic
2020-06-16 16:56:15.993 Detail, Node023, Queuing (Send) SwitchBinaryCmd_Get (Node=23): 0x01, 0x09, 0x00, 0x13, 0x17, 0x02, 0x25, 0x02, 0x25, 0xb1, 0x43
2020-06-16 16:56:15.993 Detail, Node023, Queuing (Query) Query Stage Complete (Dynamic)
2020-06-16 16:56:15.993 Detail,
2020-06-16 16:56:15.993 Info, Node023, Sending (Send) message (Callback ID=0xb1, Expected Reply=0x04) - SwitchBinaryCmd_Get (Node=23): 0x01, 0x09, 0x00, 0x13, 0x17, 0x02, 0x25, 0x02, 0x25, 0xb1, 0x43
2020-06-16 16:56:16.001 Detail, Node023,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2020-06-16 16:56:16.001 Detail, Node023,   ZW_SEND_DATA delivered to Z-Wave stack
2020-06-16 16:56:16.052 Detail, Node023,   Received: 0x01, 0x07, 0x00, 0x13, 0xb1, 0x00, 0x00, 0x06, 0x5c
2020-06-16 16:56:16.052 Detail, Node023,   ZW_SEND_DATA Request with callback ID 0xb1 received (expected 0xb1)
2020-06-16 16:56:16.052 Info, Node023, Request RTT 59 Average Request RTT 88
2020-06-16 16:56:16.052 Detail,   Expected callbackId was received
2020-06-16 16:56:16.107 Detail, Node023,   Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x17, 0x03, 0x25, 0x03, 0xff, 0x3f
2020-06-16 16:56:16.107 Detail,
2020-06-16 16:56:16.107 Info, Node023, Response RTT 114 Average Response RTT 144
2020-06-16 16:56:16.107 Info, Node023, Received SwitchBinary report from node 23: level=On
2020-06-16 16:56:16.107 Detail, Node023, Refreshed Value: old value=false, new value=true, type=bool
2020-06-16 16:56:16.107 Detail, Node023, Changes to this value are not verified
2020-06-16 16:56:16.107 Detail, Node023,   Expected reply and command class was received
2020-06-16 16:56:16.107 Detail, Node023,   Message transaction complete
2020-06-16 16:56:16.107 Detail,
2020-06-16 16:56:16.107 Detail, Node023, Removing current message
2020-06-16 16:56:16.107 Detail, Node023, Notification: ValueChanged
2020-06-16 16:56:16.110 Detail, Node023, Query Stage Complete (Dynamic)
2020-06-16 16:56:16.110 Detail, Node023, AdvanceQueries queryPending=0 queryRetries=0 queryStage=Configuration live=1
2020-06-16 16:56:16.110 Detail, Node023, QueryStage_Configuration
2020-06-16 16:56:16.110 Detail, Node023, QueryStage_Complete
2020-06-16 16:56:16.110 Warning, CheckCompletedNodeQueries m_allNodesQueried=0 m_awakeNodesQueried=1
2020-06-16 16:56:16.110 Warning, CheckCompletedNodeQueries all=0, deadFound=0 sleepingOnly=1
2020-06-16 16:56:16.110 Detail, Node023, Notification: NodeQueriesComplete

HA OZW v1.6 Responses

Jasco 12724 Dimmer (node 10)

Jasco 12722 Switch (node 23)

---

The v1.6 responses are blank, that's not a typo. As stated above, i am able to switch between the 2 setups and in 1.4 these devices report instantly, and in v1.6 they do not.

As for your comment about group associations, I never set up any group associations. If that was set up, it would be set up by default on the inclusion process.

[Fishwaldo]

By logs - I need to see the ozwdaemon logs from startup (without a ozwcache_*.xml present) so I can see what the device is reporting during the interview process.

You Can see the associations in MQTT:

Logs from 1.4 obviously do not help if we are debugging a 1.6 issue.

[Petro31]

It'll be a bit before I can get the startup logs. But I finally found some blurbs online about group associations. Although I don't fully understand how they work, I strongly believe this is my problem. I've also found the MQTT calls to create/remove these group associations. When looking at the associations in my setup, I notice that node 1 does not have any. This is also the case for the non-zwave plus devices.

So my question is (without fully understanding group associations), what do I use as attributes to create these associations?

OpenZwave/1/command/addassociation/

{
  'node':1, 
  'group': <what number.. does it matter?>,
  'target': 'what string?  I expect this to be a number',
}

Do I create this association on all nodes?

If I create this association on each node targeting node 1.... what do I create on node 1, I don't think it would target anything?

[Fishwaldo]

Group is device specific. All Devices have Group 1 - Which is defined by the specifications as "lifeline" - All updates on a device should send to "members" of this group. "target" the node you wish to recieve updates for. For MultiChannel Devices, its generally in the form of 1.1 (assuming your controller node is 1) for Single instance Devices its 1.

If your not getting updates, its likely as the controller node is not in any of the correct association groups. A change between OZW 1.4 and 1.6 was making this association "compliant" with the specifications. Given I see your device sending Node Info Frames when something is changing, its 1) Very old 2) chances are - buggy.

So I need to see the startup logs - As OZW will always attempt to add the controller node to group 1 if its not present. If its not there, its because the node is rejecting it for some reason...

[Petro31]

Ok, I'll get the logs tonight when I am home. Do you need the full 4 minute startup process or just the first 30 seconds or so? Also, does the container have a hard-disk log? I tried finding it through find -name "*.log" and turned up nothing in the qt-openzwave add on data directory.

[Fishwaldo]

Full logs would be best. (In case we miss something). If your using the allinone, logs are in the config/logs directory. If your using the standard container, logs are via docker logs. If your using HACS container - no idea.

[Petro31]

So getting the logs from the addon container is a pain in the ass. Everything goes to stdout for the container. Here's the first ~3 minutes. If you need other sections, I can attempt to grab it. First 3 Minutes.log

[Petro31]

It's more like the first minute.

[Petro31]

I actually don't know now. I tried putting an association on a node and it didn't take. Nothing in the logs. no added association.

[Fishwaldo]

Ok - A few things I see:

[20200617 20:52:09.868 EDT] [ozw.library] [info]: Info - Node: 34 Received Association report from node 34, group 1, containing 2 associations, [20200617 20:52:09.868 EDT] [ozw.library] [info]: Info - Node: 34 The group contains:, [20200617 20:52:09.868 EDT] [ozw.library] [info]: Info - Node: 34 Node 1, [20200617 20:52:09.868 EDT] [ozw.library] [info]: Info - Node: 34 Node 255, [20200617 20:52:09.868 EDT] [ozw.library] [info]: Info - Node: 34 Get Associations for group 2 of node 34,

Node 255 was a old bug from 1.4 days. You should remove node 255 from Association Group 1 on Node 34 otherwise it will send a "broadcast" to all devices when something happens (and make everything turn on/off - depending upon the end devices)

(Same for Node 40, 41, 43, 44, 45, 46, 47, 49, 50, 51)

Now unfortunately, I didn't see Node 10 in the Logs. (I guess it happened earlier)

You can grab the logs via docker with docker logs <containerid> > ozwdaemon.log

[Fishwaldo]

are any of the nodes above ones that you are having trouble with?

[Petro31]

Every node between 1 and 32 does not work on physical press. They are all the old version of Jasco switches/dimmers. It's about 20 devices (nodes are missing from replacing with new hardware over the years).

This weekend I'm going to switch to the docker compose all in one container so that I can get more control and better logging.

I think issues like this should be brought up to frenck to let him know that the current addon implementation does not supply sufficient debugging for issues. Either way, I'll post a longer startup log after I make the switch to the stand alone container.

Thanks a ton for your support, I'll post the logs in the next day or 2 and tag you.

[Petro31]

are any of the nodes above ones that you are having trouble with?

No, the nodes above are working great.

[aklaiber82]

I am having the same issue with the same switches. Can you tell me how you switched from ozw 1.6 to 1.4? I am using the docker container for qt-openzwave. Thanks!

[Petro31]

1.4 doesn't have a qt-openzwave build. It's integrated into the software I am using outside this.

[Petro31]

@Fishwaldo just spit balling here, but did the command class association exist in 1.4? None of these old jasco devices have it in the mfg config. I'm wondering If I could just add that and it would work?

[Petro31]

@Fishwaldo heres extended logs. ozwdaemon.log

Everything in this image is what does not properly report a physical switch change. Basically all old Jasco devices.

[Fishwaldo]

Your not going to believe it:

ozwdaemon-2.log:[20200623 1:02:48.693 UTC] [ozw.library] [info]: Info - Node: 32 Get Associations for group 1 of node 32 ozwdaemon-2.log:[20200623 1:02:48.932 UTC] [ozw.library] [info]: Info - Node: 34 Get Associations for group 1 of node 34 ozwdaemon-2.log:[20200623 1:02:49.325 UTC] [ozw.library] [info]: Info - Node: 40 Get Associations for group 1 of node 40 ozwdaemon-2.log:[20200623 1:02:49.827 UTC] [ozw.library] [info]: Info - Node: 41 Get Associations for group 1 of node 41 ozwdaemon-2.log:[20200623 1:02:51.236 UTC] [ozw.library] [info]: Info - Node: 43 Get Associations for group 1 of node 43 ozwdaemon-2.log:[20200623 1:02:51.919 UTC] [ozw.library] [info]: Info - Node: 44 Get Associations for group 1 of node 44 ozwdaemon-2.log:[20200623 1:02:52.606 UTC] [ozw.library] [info]: Info - Node: 45 Get Associations for group 1 of node 45 ozwdaemon-2.log:[20200623 1:02:53.166 UTC] [ozw.library] [info]: Info - Node: 46 Get Associations for group 1 of node 46 ozwdaemon-2.log:[20200623 1:02:53.704 UTC] [ozw.library] [info]: Info - Node: 47 Get Associations for group 1 of node 47 ozwdaemon-2.log:[20200623 1:02:55.073 UTC] [ozw.library] [info]: Info - Node: 49 Get Associations for group 1 of node 49 ozwdaemon-2.log:[20200623 1:02:55.210 UTC] [ozw.library] [info]: Info - Node: 50 Get Associations for group 1 of node 50 ozwdaemon-2.log:[20200623 1:02:55.694 UTC] [ozw.library] [info]: Info - Node: 51 Get Associations for group 1 of node 51 ozwdaemon-2.log:[20200623 1:02:55.865 UTC] [ozw.library] [info]: Info - Node: 52 Get Associations for group 1 of node 52 ozwdaemon-2.log:[20200623 1:02:56.430 UTC] [ozw.library] [info]: Info - Node: 53 Get Associations for group 1 of node 53 ozwdaemon-2.log:[20200623 1:02:57.467 UTC] [ozw.library] [info]: Info - Node: 55 Get Associations for group 1 of node 55 ozwdaemon-2.log:[20200623 1:02:58.250 UTC] [ozw.library] [info]: Info - Node: 57 Get Associations for group 1 of node 57 ozwdaemon-2.log:[20200623 1:02:59.153 UTC] [ozw.library] [info]: Info - Node: 58 Get Associations for group 1 of node 58 ozwdaemon-2.log:[20200623 1:02:59.727 UTC] [ozw.library] [info]: Info - Node: 61 Get Associations for group 1 of node 61 ozwdaemon-2.log:[20200623 1:02:59.837 UTC] [ozw.library] [info]: Info - Node: 62 Get Associations for group 1 of node 62 ozwdaemon-2.log:[20200623 1:02:59.875 UTC] [ozw.library] [info]: Info - Node: 63 Get Associations for group 1 of node 63 ozwdaemon-2.log:[20200623 1:03:00.801 UTC] [ozw.library] [info]: Info - Node: 64 Get Associations for group 1 of node 64 ozwdaemon-2.log:[20200623 1:03:01.353 UTC] [ozw.library] [info]: Info - Node: 65 Get Associations for group 1 of node 65 ozwdaemon-2.log:[20200623 1:03:02.224 UTC] [ozw.library] [info]: Info - Node: 67 Get Associations for group 1 of node 67 ozwdaemon-2.log:[20200623 1:03:04.257 UTC] [ozw.library] [info]: Info - Node: 68 Get Associations for group 1 of node 68 ozwdaemon-2.log:[20200623 1:03:04.918 UTC] [ozw.library] [info]: Info - Node: 69 Get Associations for group 1 of node 69 ozwdaemon-2.log:[20200623 1:03:06.896 UTC] [ozw.library] [info]: Info - Node: 70 Get Associations for group 1 of node 70 ozwdaemon-2.log:[20200623 1:03:07.689 UTC] [ozw.library] [info]: Info - Node: 71 Get Associations for group 1 of node 71 ozwdaemon-2.log:[20200623 1:03:08.165 UTC] [ozw.library] [info]: Info - Node: 72 Get Associations for group 1 of node 72 ozwdaemon-2.log:[20200623 1:08:28.808 UTC] [ozw.library] [info]: Info - Node: 56 Get Associations for group 1 of node 56

None of the affected nodes are in the Log!

@Fishwaldo just spit balling here, but did the command class association exist in 1.4? None of these old jasco devices have it in the mfg config. I'm wondering If I could just add that and it would work?

It did - but at least what I can infer so far from your logs, that these devices are not advertising support for COMMAND_CLASS_ASSOCIATION.

Normally, you would expect to see this in a Log (these are from a "working" implementation):

[20200217 22:16:35.755 UTC] [ozw.library] [info]: Info - Node: 17 Received reply to FUNC_ID_ZW_GET_NODE_PROTOCOL_INFO [20200217 22:16:35.756 UTC] [ozw.library] [info]: Info - Node: 17 Protocol Info for Node 17: [20200217 22:16:35.757 UTC] [ozw.library] [info]: Info - Node: 17 Listening = false [20200217 22:16:35.757 UTC] [ozw.library] [info]: Info - Node: 17 Frequent = false [20200217 22:16:35.758 UTC] [ozw.library] [info]: Info - Node: 17 Beaming = true [20200217 22:16:35.759 UTC] [ozw.library] [info]: Info - Node: 17 Routing = true [20200217 22:16:35.760 UTC] [ozw.library] [info]: Info - Node: 17 Max Baud Rate = 40000 [20200217 22:16:35.760 UTC] [ozw.library] [info]: Info - Node: 17 Version = 3 [20200217 22:16:35.761 UTC] [ozw.library] [info]: Info - Node: 17 Security = false [20200217 22:16:35.762 UTC] [ozw.library] [info]: Info - Node: 17 Basic device class (0x04) - Routing Slave [20200217 22:16:35.762 UTC] [ozw.library] [info]: Info - Node: 17 Generic device Class (0xa1) - Alarm Sensor [20200217 22:16:35.763 UTC] [ozw.library] [info]: Info - Node: 17 Specific device class (0x07) - Routing Smoke Sensor [20200217 22:16:35.764 UTC] [ozw.library] [info]: Info - Node: 17 COMMAND_CLASS_BASIC will be mapped to COMMAND_CLASS_NOTIFICATION [20200217 22:16:35.765 UTC] [ozw.library] [info]: Info - Node: 17 Mandatory Command Classes for Node 17: [20200217 22:16:35.766 UTC] [ozw.library] [info]: Info - Node: 17 COMMAND_CLASS_NOTIFICATION [20200217 22:16:35.766 UTC] [ozw.library] [info]: Info - Node: 17 COMMAND_CLASS_MANUFACTURER_SPECIFIC [20200217 22:16:35.767 UTC] [ozw.library] [info]: Info - Node: 17 COMMAND_CLASS_BATTERY [20200217 22:16:35.767 UTC] [ozw.library] [info]: Info - Node: 17 COMMAND_CLASS_WAKE_UP [20200217 22:16:35.768 UTC] [ozw.library] [info]: Info - Node: 17 COMMAND_CLASS_ASSOCIATION [20200217 22:16:35.769 UTC] [ozw.library] [info]: Info - Node: 17 COMMAND_CLASS_VERSION [20200217 22:16:35.769 UTC] [ozw.library] [info]: Info - Node: 17 Mandatory Command Classes controlled by Node 17: [20200217 22:16:35.770 UTC] [ozw.library] [info]: Info - Node: 17 COMMAND_CLASS_BASIC

Or Later during the Interview Process:

[20200217 22:22:31.540 UTC] [ozw.library] [info]: Info - Node: 9 UPDATE_STATE_NODE_INFO_RECEIVED from node 9 [20200217 22:22:31.541 UTC] [ozw.library] [info]: Info - Node: 9 Optional CommandClasses for node 9: [20200217 22:22:31.542 UTC] [ozw.library] [info]: Info - Node: 9 COMMAND_CLASS_SWITCH_BINARY (Existing) [20200217 22:22:31.543 UTC] [ozw.library] [info]: Info - Node: 9 COMMAND_CLASS_BASIC (Existing) [20200217 22:22:31.543 UTC] [ozw.library] [info]: Info - Node: 9 COMMAND_CLASS_MANUFACTURER_SPECIFIC (Existing) [20200217 22:22:31.544 UTC] [ozw.library] [info]: Info - Node: 9 COMMAND_CLASS_VERSION [20200217 22:22:31.545 UTC] [ozw.library] [info]: Info - Node: 9 COMMAND_CLASS_SWITCH_ALL (Existing) [20200217 22:22:31.546 UTC] [ozw.library] [info]: Info - Node: 9 COMMAND_CLASS_ASSOCIATION [20200217 22:22:31.547 UTC] [ozw.library] [info]: Info - Node: 9 COMMAND_CLASS_METER [20200217 22:22:31.548 UTC] [ozw.library] [info]: Info - Node: 9 COMMAND_CLASS_CONFIGURATION

(these are just samples, but its to demonstrate that a node advertises what it supports).

Your Node 10:

[20200623 0:39:45.275 UTC] [ozw.library] [info]: Info - Node: 10 Received reply to FUNC_ID_ZW_GET_NODE_PROTOCOL_INFO [20200623 0:39:45.275 UTC] [ozw.library] [info]: Info - Node: 10 Protocol Info for Node 10: [20200623 0:39:45.275 UTC] [ozw.library] [info]: Info - Node: 10 Listening = true [20200623 0:39:45.275 UTC] [ozw.library] [info]: Info - Node: 10 Beaming = true [20200623 0:39:45.275 UTC] [ozw.library] [info]: Info - Node: 10 Routing = true [20200623 0:39:45.275 UTC] [ozw.library] [info]: Info - Node: 10 Max Baud Rate = 40000 [20200623 0:39:45.275 UTC] [ozw.library] [info]: Info - Node: 10 Version = 4 [20200623 0:39:45.275 UTC] [ozw.library] [info]: Info - Node: 10 Security = false [20200623 0:39:45.275 UTC] [ozw.library] [info]: Info - Node: 10 Basic device class (0x04) - Routing Slave [20200623 0:39:45.275 UTC] [ozw.library] [info]: Info - Node: 10 Generic device Class (0x11) - Multilevel Switch [20200623 0:39:45.275 UTC] [ozw.library] [info]: Info - Node: 10 Specific device class (0x01) - Multilevel Power Switch [20200623 0:39:45.275 UTC] [ozw.library] [info]: Info - Node: 10 COMMAND_CLASS_BASIC will be mapped to COMMAND_CLASS_SWITCH_MULTILEVEL [20200623 0:39:45.275 UTC] [ozw.library] [info]: Info - Node: 10 Mandatory Command Classes for Node 10: [20200623 0:39:45.276 UTC] [ozw.library] [info]: Info - Node: 10 COMMAND_CLASS_BASIC [20200623 0:39:45.276 UTC] [ozw.library] [info]: Info - Node: 10 COMMAND_CLASS_SWITCH_MULTILEVEL [20200623 0:39:45.276 UTC] [ozw.library] [info]: Info - Node: 10 COMMAND_CLASS_SWITCH_ALL [20200623 0:39:45.276 UTC] [ozw.library] [info]: Info - Node: 10 COMMAND_CLASS_MANUFACTURER_SPECIFIC [20200623 0:39:45.276 UTC] [ozw.library] [info]: Info - Node: 10 Mandatory Command Classes controlled by Node 10: [20200623 0:39:45.276 UTC] [ozw.library] [info]: Info - Node: 10 None

(I don't see a UPDATE_STATE_NODE_INFO_RECEIVED for Node 10 in your logs, thats not bad - Just a stage of the interview process)

You can try adding the following and see if that fixes things:

  <CommandClass id="133">
    <Associations num_groups="1">
      <Group index="1" label="Lifeline" max_associations="1"/>
    </Associations>
  </CommandClass>

The Documentation on these devices is sparse, to put it nicely :(

If that doesn't work - I gather you have become "handy" with MQTT - You can just do a refreshNodeInfo and send the latest ozwdaemon.log file - It should capture everything. Sounds like we are going to have to "force" the association group if the above doesn't work.

[steve28]

@Fishwaldo should there be a COMMAND_CLASS_ASSOCIATION for each node?

[Petro31]

@Fishwaldo Well, bad news. Adding the CommandClass Association did not work. It's properly set now in MQTT, I assume it's also in the cache. However it still doesn't report. Here are the logs for the refreshnodeinfo:

refreshnodeinfo.txt

[Petro31]

@Fishwaldo here's the zwavecache from 1.4. This is an older version of the file, I don't have access to my config directory when at work. Either way, this is the same network and it has node 10.

zwcfg_0xd9f660ea.zip

[Fishwaldo]

[20200625 1:33:47.330 UTC] [ozw.library] [info]: Info - Node: 10 Sending (Query) message (Callback ID=0xf9, Expected Reply=0x04) - AssociationCmd_GroupingsGet (Node=10): 0x01, 0x09, 0x00, 0x13, 0x0a, 0x02, 0x85, 0x05, 0x25, 0xf9, 0xb1 ... [20200625 1:33:57.331 UTC] [ozw.library] [critical]: Error - Node: 10 ERROR: Dropping command, expected response not received after 1 attempt(s). Command: "AssociationCmd_GroupingsGet (Node=10): 0x01, 0x09, 0x00, 0x13, 0x0a, 0x02, 0x85, 0x05, 0x25, 0xf9, 0xb1"

[20200625 1:33:57.456 UTC] [ozw.library] [info]: Info - Node: 10 Sending (Send) message (Callback ID=0xfb, Expected Reply=0x04) - AssociationCmd_Get (Node=10): 0x01, 0x0a, 0x00, 0x13, 0x0a, 0x03, 0x85, 0x02, 0x01, 0x25, 0xfb, 0xb7 ... [20200625 1:34:07.457 UTC] [ozw.library] [critical]: Error - Node: 10 ERROR: Dropping command, expected response not received after 1 attempt(s). Command: "AssociationCmd_Get (Node=10): 0x01, 0x0a, 0x00, 0x13, 0x0a, 0x03, 0x85, 0x02, 0x01, 0x25, 0xfb, 0xb7"

So confirmed this device does not support ASSOCIATION CC. Bummer.

Also the zwcfg you uploaded confirmed that 1.4 does not have any ASSOCIATION CC either.

As mentioned on discord - Only way I can see this working in 1.4: 1) Polling (maybe automatically triggered by the old zwave integration 2) It sends a Node Info Frame.

I'm honestly out of ideas here. My very last things I would try: 1) Trigger a "sendnodeinfo" via MQTT to Node 10 - See if it gets it to reciprocate (ozw 1.4 didnt do that - I'm grasping for straws) 2) Exclude/Include the device again.

If neither of that works, I'm out of ideas. (apart from Polling... ugh)

[Petro31]

So what does include/exclude do that refreshnodeinfo doesnt? I have a feeling it will fix the issue and I was planning on doing it tonight. What I don't understand is how I can switch between 1.4 and 1.6 and 1.4 see's these responses where 1.6 doesn't. Is there a whole other level of configuration that is stored in the network that's not exposed to the user through the cachefile or machine files?

[aklaiber82]

In 1.4 with the default z wave integration in home assistant it enabled polling on all my old ge devices automatically. Polling 25 devices brought my network to its knees though. In the 1.6 open z wave it didn’t auto enable it. I had to manually enable it for old dimmers since they had too slow a ramp but not for switches. They still update status fine but lost the association feature.

On Thu, Jun 25, 2020 at 10:54 AM Petro31 notifications@github.com wrote:

So what does include/exclude do that refreshnodeinfo doesnt? I have a feeling it will fix the issue and I was planning on doing it tonight. What I don't understand is how I can switch between 1.4 and 1.6 and 1.4 see's these responses where 1.6 doesn't. Is there a whole other level of configuration that is stored in the network that's not exposed to the user through the cachefile or machine files?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OpenZWave/qt-openzwave/issues/110#issuecomment-649600308, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOIIKUH7FIHUZCGMSHK27YDRYNQKDANCNFSM4N7SDISQ .

[Petro31]

@Aklaiber82

That doesn't make sense because poll_intensity="0" is set on pretty much every device in my old zwave config, which is listed above. Although the 4 old dimmers do have poll_intensity="1". But the other devices do not and they do not function.

[Petro31]

I’m gonna leave this open for a bit if you don’t mind @Fishwaldo. I won’t be able to do anymore testing until Monday the 6th.

[Fishwaldo]

That’s fine.