The log viewer on my site.
The secure inclusion isn’t in the log so not much I can comment on.
Does your lock allow basic command class - or maybe the wallmote can send a door lock command?
I think that’s unlikely. As I said before, most (if not all all) zwave devices use the same chipset, and the same basic software. Also, as you’ve shown, the wallmote is including fine, and I’ve also used the ZW100 successfully.
I’ll try to do some more testing on a clean setup later in the week and see if I can derive any trends using your log viewer. Thanks for helping me look today.
The lock is non-zwave. It’s a commercial access control system that answers to HTTP requests (over SSL). The argument for secure inclusion being that any device that can send a command that leads to OpenHAB requesting a door unlock must also be secure.
Not related to your issue, but I’m really really curious about that. Actually, I’m curious if anyone with an HUSBZB-1 could do an
egrep -r "Not initialized" *
in their logs folder to see if there are any messages that come from nodes that do not exist. I’m currently trying to document an issue with the firmware where there are messages coming from the stick with incorrectly reported nodes. I’ve actually seen messages come in from nodes that can’t possibly exist (>232), on two different HUSBZB-1s. Like this…
zwave/zwave.log:2018-01-04 15:04:59.937 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 248: Not initialized (ie node unknown), ignoring message.
The messages I was seeing were along the lines of:
2018-01-06 23:26:59.977 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 27: listening == false, frequentlyListening == false, awake == true
2018-01-06 23:26:59.987 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 27: WakeupTimerTask 1 Messages waiting, state EMPTYNODE
I think Node 27 might have once been a legitimate node that I had excluded. I didn’t have debug logging enabled at the time so I’m not 100% certain. I haven’t seen this type of traffic again today.
1 Like
Dear @chris!
I changed to the current version of this binding due to switching from a raspberry to a NUC. I guess I followed most of the “To Dos” (would be good to put them all in the first post)
-
Downloaded jar from 2/1/2018
-
uninstalled (changed addons.cfg) Zwave binding
-
Deleted all things and added them newly (OH2 Z-Wave refactoring and testing... and SECURITY --> https://docs.openhab.org/administration/runtime.html#things)
-
changed logging to get a separate file
In addition I deleted several dead nodes as I never had success with habmin (Remove a ghost Z-Wave Node from HABmin).
A few questions/comments (let me know if I should provide logs or anything else):
- most probably not related to the binding version - but probably related to the inclusion issue: I updated my heat it thermostat and tried to update the database (my FW-Version is higher i think) - got error messages when uploading the XML ("Manufacturer 7FFFFFFF is not known! Please update the manufacturer database and try again) --> see http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/247
- I cannot include further devices (trying to include two fibaro flood sensor GEN5) --> Node 57 is the mentioned thermostat above --> could it be, that the incomplete recognition of Node 57 hinders the inclusion of new devices? Please find attached the log here: https://ufile.io/ppdo3
Regards,
Herbert
I have a quite a few, for the same two devices:
openhab.log.7:2018-01-03 16:18:16.514 [WARN ] [nal.protocol.ZWaveTransactionMana ger] - NODE 12: Not initialized (ie node unknown), ignoring message.
openhab.log.7:2018-01-03 16:19:06.370 [WARN ] [nal.protocol.ZWaveTransactionMana ger] - NODE 13: Not initialized (ie node unknown), ignoring message.
openhab.log.7:2018-01-03 16:19:08.359 [WARN ] [nal.protocol.ZWaveTransactionMana ger] - NODE 13: Not initialized (ie node unknown), ignoring message.
Not sure what a HUSBZB-1 is…
This is a test network I was using to try to get this stuff actually working. 12 doesn’t correspond to any actual device in the network. 13 is an Aeotec Minimote that sometimes eventually works, but most of the time never does. 12 may have been related to it.
I did a hard reset on the network since then in an attempt to get secure associations working, so I don’t have any better data. Previously I was able to switch over to Z-way to see what the controller thought a device was when it mysteriously showed up in OH2.
This is quite common if you have old devices that have been excluded from the controller, but not reset. Normally a device will be reset when excluded, and that stops it sending stuff, but if that doesn’t happen, then it’s common that you get this message.
I know that’s not the case for @5iver, but just thought I’d mention that this message can be generated through reasonably normal operation.
This can occur if the interrogation phase doesn’t complete. It’s most common on battery devices where they haven’t been woken up, and the interrogation doesn’t complete - the 7FFFFFF is a default value.
Probably not - the node above is included ok as best as I can tell, and I think if you wake it up, it will likely complete the interrogation and be recognised. This won’t prevent you from including other devices.
From the log we see the controller is rejecting the include command - I’m not sure why as it doesn’t provide useful feedback like that 
. I’d suggest to reset the controller to see if that helps - otherwise, maybe there is something strange with the inclusion of node 57, but I would be surprised.
Good luck
Yeah I figured it was something like that. Although the close proximity to the two is a little weird – I only have that one device it could be (the remote).
I decided to just wait on messing with this again until the dev merge back to the mainline, reset everything again and try from a know good state and see if I can get the binding working this time.
Interesting I Saw This Message for a device that is actually still included and a valid device that Works. I think only on Startup of openhab that warn Message was there. Maybe Communication before the device was read from the Controller… no clue
Just as Information … dont See any negative side effects.
I guess it’s possible that a message received before the binding is initialised will also cause this. The time window is small, but it could certainly happen if the message comes in before the binding gets the list of known nodes from the controller.
I want to give a small update on this issue.
10days ago I had 3 devices that are actually communicating with the controller but are marked as FAILED by the controller.
As described when they send something Habmin lists them as online and instantly afterwards get the “isFailed” information and set them to Offline again.
For two devices I found a solution now. In a regular “Heal” these devices were probably skipped as they were listed as Offline.
I started a manual heal on them while I manually did wake them up. This heal seemed to have effect and they are Online again now. In the meanwhile until I tried this (10 days) the controller kept them flagged as Failed despite they did commuicate very often with the controller (both are PIRs and are triggered a lot)
For the 3rd device the issue is still there. But that device is a sh**ty SF812 smoke detector. This device does not support any kind of wake up (probably acutally not zwave compliant). Therefore I can understand the controller flags it dead.
It only reports in case of fire, test fire alarm and low batt. I triggered a few test alarms. These are received by the controller and processed perfectly. But since there is no wake up and therefore no Heal possible … still flagged failed.
This is merely an update about my observations
Dear Chris!
Thx for the feedback. The device is not battery operated - it’s this one: http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/247
Could you please just check if the db needs to be updated due to a newer FW-Version (I uploaded the xml file with the mentioned error).
Concerning controller reset: do you mean hard or soft reset in habmin (hard reset is hard with many devices…)?
All the points mentioned (not finalised interrogation, cannot add further node) concern the thermostat device (node 57).
Regards,
Herbert
About group associations: It looks like the association can only be set to the node, not the endpoint. Maybe i need to explain it a bit more.
I have two Fibaro Dimmer 2’s. Each module controls its own light with S1 button. On each device association group 4 (corrosponding to S2 button) is set to the other node. This way i can control both lights from each dimmer.
BUT 
when i press S1 on one module, the S2 button of the other module does not get updated.
Module A => press S1 => Light turns on.
Module B => press S2 => nothing happens (it sends On frame to Light A), because it doesn’t know module A was allready turned on.
Module B => press S2 => Light turns off.
Not sure of ZWave protocol / Fibaro dimmers support this, but it would be nice if you could set asociation group 2 (S1) to module S2 endpoint
Another thing: I think i asked about this before in a different thread. But is there a reason why association group 4 (s2) cannot be set to the node itself. I would like to be able to do so. Say this module S1 controls one light in the room and S2 is associated to all of the lights in that room. I have to click both buttons to turn everything on/off. If you would be able to association group 4 with the node itself, you could just press S2 to turn everything in that room off.
It won’t be a database issue - the binding should download this data from the device without any database information.
I meant a soft reset for now - just unpower the stick will also do the same thing (ie remove it from the USB).
Cheers
Chris
Well, this shouldn’t be the case so we will need more information on the device, logs, and what you’re trying to do exactly.
Does the device actually support multi-instance associations? According to the database it doesn’t, but maybe that’s incorrect?
There are lots of different ways that different devices trigger multi-instance reports. This is something that has changed a lot over the past year or two with 3 different versions of the MCA command class and probably a lot more implementations as different manufacturers have implemented different things. It really seems a bit of a mess (IMHO!).
No - this should work if the device supports multi-channel association. I’m not sure if it’s a good idea, but that’s a different question.
Have updated to the new binding.
Deleted all things
Uninstalled old binding
Copied new binding to addons
Added back all things
Now i can not get ZW095 gen5 home energy meter to report values.
It seems that i can not set Association Group.
If i set it to OpenHAB Controller
I get another value when going back into configuration
and i have no reporting to controller.
/Mike
Do you get the same result if you set the association through Habmin? Be aware that the associations will display as empty or an X on some devices after selecting another device.
