New Aeotec Door/Window Sensor 7 not in Database yet?

sihui · August 9, 2019, 1:16pm

Hit the exclude button for the binding, the device gets resetted automatically, switch the binding to debug, include it again, post the log.
Edit: no need for all the other stuff, where did you get that from?

calevans · August 9, 2019, 1:34pm

Trial and error. Developer overkill mindset.

It’s a “When all else fails, nuke it form space.” kind of thing.

Cheers!
=C=

calevans · August 9, 2019, 2:08pm

Just so I know for sure what I am doing. When I bring up the Thing in PaperUI->Config->Things->Node 35, pressing the trashcan button is “hitting the exclude button”. Correct?

Cheers!
=C=

sihui · August 9, 2019, 2:28pm

Never did that with PaperUI, in HABmin call the Thing, go to Advanced Settings, hit Exclude Device (or remove from controller or something like that, I am not near a computer, sorry)

Bruce_Osborne · August 9, 2019, 2:39pm

This should work in the PaperUI:

but this is the recommended way in HABmin:

then

omatzyo · August 9, 2019, 3:36pm

From habmin, select the controller thing, then select show advanced settings and then put controller in exclude mode… then triple tap the sensor button.

calevans · August 9, 2019, 11:07pm

Ok, tried that, nothing. Tried the way @omatzyo suggested and it deleted NODE 36 (the unknown device) but not NODE 35.

2019-08-09 18:40:49.511 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 35: Remove failed node failed as node not found
2019-08-09 18:41:31.233 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 35: Remove failed node failed as node not found

But if I refresh the page on HABMin, it’s still there. :S

So I manually deleted it.

Anyhow, here is the log for inclusion
zwave.log (243.7 KB)

Oh, and these were not in the log because of the grep I used.

2019-08-09 18:55:01.339 [DEBUG] [al.protocol.ZWaveInclusionController] - ZWave inclusion controller finalised
2019-08-09 18:55:01.344 [DEBUG] [al.protocol.ZWaveInclusionController] - ZWave inclusion controller finalised

Now here is what is interesting. Up till this point, 2 devices have been installing but one was unknown. Now 2 devices are installing (In the log file 35 and 38) and now it recognizes them BOTH as the Door/Sensor 7.

My Items still associate with NODE 35, but when I try and test it, neither node responds. Even with the log file in debug mode, I get nothing.

Initialization did not create .XML files for either device.

I can try the “nuke it from space” method and re-include if you think that would give you more info to go on.

Cheers!
=C=

omatzyo · August 9, 2019, 11:40pm

Could this have something to do with why the new binding is not generating an xml?

sihui · August 10, 2019, 5:43am

No, here is the way to do it in PaperUI:

sihui · August 10, 2019, 5:51am

Won’t work as the device is still on the controller. You only deleted it from openHAB, not from the controller.

There is nothing in the log for node 35:

As long as you have no xml and you are trying something like “nuke it from space” we can’t help.
Please follow the official basic zwave docs and come back if you are familiar with them.

Thanks.

omatzyo · August 10, 2019, 12:57pm

Even after a few days the only reference in the log is:

2019-08-10 08:43:47.311 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Polling...
2019-08-10 08:43:47.315 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Polling deferred until initialisation complete

Yet, the logs previously show:

2019-08-07 08:56:14.387 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Initialising Thing Node...
2019-08-07 08:56:14.389 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Initialising cmd channel zwave:device:16aef262550:node15:sensor_binary for OnOffType
2019-08-07 08:56:14.392 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Initialising state channel zwave:device:16aef262550:node15:sensor_binary for OnOffType
2019-08-07 08:56:14.395 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Initialising cmd channel zwave:device:16aef262550:node15:scene_number for DecimalType
2019-08-07 08:56:14.397 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Initialising state channel zwave:device:16aef262550:node15:scene_number for DecimalType
2019-08-07 08:56:14.398 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Initialising cmd channel zwave:device:16aef262550:node15:alarm_access for OnOffType
2019-08-07 08:56:14.399 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Initialising state channel zwave:device:16aef262550:node15:alarm_access for OnOffType
2019-08-07 08:56:14.401 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Initialising cmd channel zwave:device:16aef262550:node15:alarm_burglar for OnOffType
2019-08-07 08:56:14.402 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Initialising state channel zwave:device:16aef262550:node15:alarm_burglar for OnOffType
2019-08-07 08:56:14.403 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Initialising cmd channel zwave:device:16aef262550:node15:battery-level for PercentType
2019-08-07 08:56:14.404 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Initialising state channel zwave:device:16aef262550:node15:battery-level for PercentType
2019-08-07 08:56:14.406 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Polling initialised at 1800 seconds - start in 1596600 milliseconds.
2019-08-07 08:56:14.407 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Device initialisation complete.

omatzyo · August 10, 2019, 1:00pm

And I’m apparently able to update other configuration parameters. For example, turning off the tilt sensor:

2019-08-07 09:03:24.704 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Application Command Request (ALIVE:VERSION)
2019-08-07 09:03:24.705 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: Incoming command class COMMAND_CLASS_CONFIGURATION, endpoint 0
2019-08-07 09:03:24.706 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: SECURITY NOT required on COMMAND_CLASS_CONFIGURATION
2019-08-07 09:03:24.707 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 15: Received COMMAND_CLASS_CONFIGURATION V1 CONFIGURATIONCMD_REPORT
2019-08-07 09:03:24.709 [DEBUG] [class.ZWaveConfigurationCommandClass] - NODE 15: Node configuration report, parameter = 14, value = 0, size = 1
2019-08-07 09:03:24.711 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got an event from Z-Wave network: ZWaveConfigurationParameterEvent
2019-08-07 09:03:24.712 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_CONFIGURATION, value=org.openhab.binding.zwave.internal.protocol.ZWaveConfigurationParameter@cf4c53
2019-08-07 09:03:24.714 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Update CONFIGURATION 14/1 to 0
2019-08-07 09:03:24.715 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Commands processed 1.
2019-08-07 09:03:24.716 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@51dcc8.
2019-08-07 09:03:24.718 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Command verified org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@51dcc8.
2019-08-07 09:03:24.719 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: notifyTransactionResponse TID:152 DONE
2019-08-07 09:03:24.721 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2019-08-07 09:03:24.722 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 1
2019-08-07 09:03:24.723 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-08-07 09:03:24.724 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty

chris · August 10, 2019, 1:16pm

Please wake up the device a few times so that it can be fully discovered. Discovery is not complete and the interrogation from this log has only just started - until this is done, it will not work properly.

Note that a log during inclusion is not required - you can simply either restart the binding (since there is no XML file anyway) or use the reinitialise device option in the parameters.

omatzyo · August 10, 2019, 1:21pm

Hi Chris.

I’ve tried restarting the binding. No luck there so far. And there is no reinitialise on any of my entries for this device:

I do see it on my other devices that have been added before.

chris · August 10, 2019, 1:26pm

Are you waking up the device? I believe that this is a battery device (correct?) and therefore it will need to be manually woken up for it to initialise.

This might not be displayed while the device is still in the initialising state in which case you just need to wake up the device (possibly a few times).

omatzyo · August 10, 2019, 1:29pm

Correct, it is a battery device. I had been keeping it awake. In fact I killed the battery on a couple of them already.

chris · August 10, 2019, 1:29pm

Can you provide the log please so I can see if it is waking up?

omatzyo · August 10, 2019, 1:41pm

Of course!

See node 14 and node 15.

omatzyo · August 14, 2019, 7:38pm

Hi all. Of course you were absolutely right about keeping it awake… I sat down with node 15 and just triple tapped waited 1 second, triple tapped, etc… until I saw the xml appear. So that is great!

Here is the xml.

Next, I tried the magnet. It seems there may another issue. The log shows:

2019-08-14 14:54:05.684 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 15: Alarm converter processing NOTIFICATION
2019-08-14 14:54:05.686 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 15: Alarm converter NOTIFICATION event is 22, type OnOffType
2019-08-14 14:54:05.688 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 15: Alarm converter NOTIFICATION event is 22, channel alarm_access is not implemented.
2019-08-14 14:54:05.689 [TRACE] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Checking channel=zwave:device:16aef262550:node15:alarm_burglar, cmdClass=COMMAND_CLASS_ALARM, endpoint=0
2019-08-14 14:54:05.691 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 15: Alarm converter processing NOTIFICATION
2019-08-14 14:54:05.693 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 15: Alarm converter NOTIFICATION event is 22, type OnOffType

I do have all of the available channels linked, here are my items:

Number	OutsideDoorZone001a_batterya "Door to Garage Battery [%d %%]" (Battery_Operated) {channel="zwave:device:16aef262550:node15:battery-level" }
Switch OutsideDoorZone001asa "The Door to the Garage" (OutsideDoors)  {channel="zwave:device:16aef262550:node15:sensor_binary" }
Switch OutsideDoorZone001aaa "The Door to the Garage" (OutsideDoors)  {channel="zwave:device:16aef262550:node15:alarm_access" }
Switch OutsideDoorZone001aba "The Door to the Garage" (OutsideDoors)  {channel="zwave:device:16aef262550:node15:alarm_burglar" }

And they look great in habmin:

And some of the channels are being updated:

Here is the full log including the time during node 15 completion of initialisation and attempting to activated the magnet.
https://www.dropbox.com/s/9miuzeqob2i72dy/matz_node_15_zwa008.log?dl=0

Thanks for looking at this!!

chris · August 15, 2019, 6:40am

I’ve updated the alarm_access channel to sensor_door. Hopefully this will solve the issue. Once the database is updated (possibly tomorrow evening) then you will need to update the binding, and then delete the thing and add it back (no need to exclude/include or do anything with the device itself).