That makes sense. Thanks.
One small bug. Everything works perfect from the main switch, but with the Aux switch if I turn on, change dim level, and then turn off. OH is picking up the change in dim levels but not the on / off. Attached is a debug log following that sequence (Node 4).
https://drive.google.com/open?id=0B77VHtwPft8eUEZlNWcyN3JDb3c
On a side note, with the uninstall/reinstall of the updated binding one of my two sensors appears to be staying on line nowā¦
I probably wonāt get to look at this until tomorrow.
I guess the controller decided itās not FAILed any more! I wish I new how it makes this decisionā¦
No rush at all. Thanks again for all the hard work!!
I did shorten the wake time interval to 10 minutes, but it didnāt look like that updated yet before it started staying online. I did remove / install the new zwave binding while keeping the system up which also corresponded to the change. Iāll experiment if it goes back in failed mode to see if I can figure out what made the difference.
I have noticed that failed is mostly a temporary state. If the device wakes up, or communicates in any way, it is no longer marked as failed. The ZCOMBO has a mind of its own, only communicating when it feels like. It gets marked as failed often, and then when it wakes up or heart-beats, it gets marked healthy again.
This has also been my experience when I developed this approach, but if I understand correctly the device did wake up a number of times and it stayed failed (right?). Itās worth confirming this - I dont think the log I looked at had any device messages so canāt confirm it in this case.
It would broadcast a door status change but stayed failed. Not sure if it did a regularly scheduled wake up (I had it originally set for every hour). I updated to the latest snapshot last night and 1 of the 2 sensors went into failed status. I just kicked it into the 10 minute wake mode and it reconnected and seems solid this morning.
Ok, so it seems the approach is ok then? Even with the old system, it would not initialise until the device wakes up so itās the same here. It will still receive messages in the event of a notification, so this all looks ok I think?
The old version seemed able to wake it up sooner or just didnāt report the failed attempts to the log file every 30 seconds. But at least I have a way to force it to get back on line so Iām good. Thanks.
No - the wakeup is done completely by the device - the binding can not wake a device up at all.
Yes - the concept has changed as I said above, so the old binding doesnāt do this check on startup, so you wonāt see this message - it will still take the same time though.
Hi Chris,
Have been trying to talk to my ID Lock all weekend but without sucess.
I manage to do the secure inclusion one time, but then the controller got marked as failed and i read on forum that sometimes it helped to delete it and add it again. This just made everything worse, and i could not do the secure inclusion again. In the log file it just saying āSecure inc FAILEDā. Have added and deleted the driver and tryed from scratch without luck. Could it be that it was Secured included with another Secreat key? I have ofcourse excluded and included lots of time. Any tips are very much appreciated:)
Side question, when will the driver be added as a standard driver?
If you have excluded the device, and re-added it again, then it doesnāt matter what key is used in the past - it will always use the latest key. Iām not really sure what to suggest - I could take a look at a log if you want to email one (please email - donāt post on the forum).
Probably at version 2.2 in a few months time - thereās a few issues to resolve yet I think.
Iām posting here because I would expect my mesh network to heal properly, but itās actually becoming less stable.
Iām seeing a weird behavior with a new Aeotec MultiSensor 6 that I recently added it to my ZWave network. The sensor itself is doing fine. I have it running on batteries, so when it senses motion and wakes up and correctly sends the Motion ON state. It is correctly reporting all of the other items fine.
Where Iām seeing some really weird behavior is in the mesh network and the neighbors. It appears that other nodes are considering it a good hop, or a secondary controller and when it goes to sleep those nodes go into an Offiline. Iāve been fighting this for the past two days finally resetting all nodes and rebuilding my Things and re-associating Items which has sucked. Iām holding off reinserting it into my network until I understand this better.
Iāve been looking for a setting on the MultiSensor that will prevent it from being an intermediate node, or a way to tell the other nodes to ignore it. What am I missing?
Advice or Guidance would be greatly appreciated.
TIA,
Tony
Thereās no way to influence the mesh network - this is all done by the controller itself and thereās no functions to change routes, find routing information, or pretty much anything else along these lines in ZWave.
The multisensor is a battery device so shouldnāt ever be used for routing by the device - unless of course youāve previously been using it with USB power - then things can get confusingā¦
@chris - emailed you over the debugs a couple of weeks ago. The issue is a bit of a showstopper in that it seems I cannot successfully add these dimmer devices using this binding. Works fine with standard binding and no securityā¦
Ok so few new problems Iāve found or bugs to outline for you @chris ā¦ I know how much you love more bugs! 
- I noticed that my old lock, the BE469 from Schlage, with the latest binding, is showing āAssociation Groupsā even though the device doesnāt support them. At least my understanding from looking up the item: BE469 - pick your option from there, none list association groups. And for giggles I tried setting it up to the OH Controller group, but no luck in updates miraculously working.
- I am testing a different lock that does support association groups instead so I can get the instant status feedback to OpenHAB via the alarms feed (I think similar to what yourself and others are doing). Unfortunately, my luck is not going so well. Iāve run into issues, and finally had time to test it out and record the log outputs, but Iām seeing different info than last time. Either way the short snippet of what is happening in DEBUG mode when trying to control the lock through OH, is COMMAND_CLASS_DOOR_LOCK not found:```
2017-03-14 23:07:28.193 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Command received zwave:device:15a1b48bdc7:node43:lock_door --> ON
2017-03-14 23:07:28.193 [WARN ] [nal.converter.ZWaveDoorLockConverter] - NODE 43: Command class COMMAND_CLASS_DOOR_LOCK not found
2017-03-14 23:07:28.193 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: No messages returned from converter
3. In working through testing this out, I used the latest binding and attempted to REMVOE the lock from the controller first again and start fresh. Just in case the latest binding fixed the issue I had seen. Well now, it seems the binding is not correctly setting the controller to truly remove the devices, or the devices are not truly being removed from the OH view of available NEW Wave devices. I'm betting on the latter of the 2 options, as I do see messages when attempting to remove them from the controller, it says the NODE is not available. I have logs of this activity and the responses for NODE not available if you'd like or it helps to isolate the issue.Oh. You mean a device can recognize if itās on battery or usb power and adapt to it? And also it remembers? I have a Aeotec multisensor that I used batteries for when first setting it up and at some point after that I changed to usb power. That sensor has always been acting a bit strange, could this be the problem?
(Sorry if the question is slightly off topic, just saw a potential way of getting new information about a long standing problem)
After changing power from battery to usb or vice versa you need to exclude and reinclude the device from the controller. Sometimes you even need to do an additional master reset on that device (if it is not performed during excluding).
1 Like
Yes - the problem is it will tell the controller that it is a routing device if it is on USB power. If you then change to battery power, the controller will still think it is a routing device since these flags can only change when the device is initially be included. As @sihui says - you should exclude it and add it back in with battery power.
1 Like
If itās working fine without security, then it canāt be a āshowstopperā I guess?
I canāt find the logs you sent so please resend.