Aeon Recessed Door Sensor

ptmuldoon · November 6, 2016, 3:45pm

This may or may not be related to a similar issue with the Monoprice Garage Door Sensor issue. But my Aeon Recessed Door Sensor is reporting an ‘err’ value in site map.

My Items file looks like this:

And SiteMap shows listed as:
Text item=FF_Sensor_Frontdoor

And debug log shows the value changing between ON and Off, but I’m gettin an “err” in the sitemap?

2016-11-06 10:36:54.746 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 15: Application Command Request (ALIVE:DETAILS)
2016-11-06 10:36:54.746 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 15: Incoming command class BASIC
2016-11-06 10:36:54.746 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 15: Received Basic Request
2016-11-06 10:36:54.746 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 15: Basic Set sent to the controller will be processed as Basic Report
2016-11-06 10:36:54.746 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 15: Basic report, value = 0xFF
2016-11-06 10:36:54.746 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2016-11-06 10:36:54.746 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2016-11-06 10:36:54.746 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 255
2016-11-06 10:36:54.746 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Updating channel state zwave:device:158135ef039:node15:sensor_door to ON [OnOffType]

pahansen · November 6, 2016, 8:10pm

Your mapping is a bit odd.

I have:

Contact    doorSide    "Side Door is [MAP(contact.map):%s]"

And contact.map:

CLOSED=Closed
OPEN=Open
NULL=Unknown
-=Unknown

ptmuldoon · November 7, 2016, 12:56am

Thanks for catching the error in the mapping. But after fixing that, i’m stuck with an Undefined message in the Site Map.

I also tried with a separate mapping file of ON=Open, OFF=Closed, but it still just says undefined in the sitemap.
I’ll keep experimenting but seems like things are all correct. The ZWave debug is showing the sensor changing from ON to OFF, etc, and now mapping appears correct, yet get an Undefined error.

I believe this Aeon Recessed Door sensor should also report the Battery status. This is the battery item, but also cant’ get the status of it. But I really don’t understand well the [%d %%] and that taken from my OH1 definitions.

pahansen · November 7, 2016, 2:11am

If the item state is being reported as Undefined then it’s at least returning a value that is mapped as Undefined in the mapping.

The [%d %%] can be broken down into two parts. %d refers to the value in its raw state (eg, 0, 1, On, Off etc) and the %% is using the first % symbol to tell OH that it should read the following symbol as only a symbol, and not in any context of a piece of code/whatever. In this case the second symbol is a % so the output would be 99 %.

I had a better think about it and don’t know that the problem really lies in the mapping, however can you visit http://yourohip:port/rest/items/FF_Sensor_Frontdoor/state and see what it says there? It should show the actual state of the item, regardless of if you have it mapped.

What does the zwave network map show in Habmin? Is the node associated right? Have you linked the node to the item in habmin/paperUI?

ptmuldoon · November 7, 2016, 1:29pm

Im traveling today and all week but just checked remotely and testing with the url direct the state returns as Null

But yes, in habmin the sensor is showing correctly linked and the log shows the sensor changing between ON and OFF.

I also tried checking the battery state in the url and that also returns as Null.

Do you have the same sensor? I wonder if something with the item in database or perhaps the sensor itself. And i have excluded and reincluded the sensor and get the same results

pahansen · November 7, 2016, 8:02pm

Yeah, I have the exact same sensor. Two of them. Details are below:

Items: (note I don’t have the channel linked in the items)

////Contact Switches
Contact       doorCarport                "Carport Door is [MAP(contact.map):%s]"       <door>             (gOutdoor, gSecurity)
Number        doorCarportBattery         "Carport Door Battery [%d %%]"                <battery>          (gOutdoor, gBattery)

Contact       doorSide                "Side Door is [MAP(contact.map):%s]"        <door>             (gOutdoor, gSecurity)
Number        doorSideBattery         "Side Door Battery [%d %%]"                 <battery>          (gOutdoor, gBattery)

Sitemap:

Text item=doorCarport
Text item=doorCarportBattery

PaperUI linking:

So the last thing I would check would be that it has been associated to your OH zwave controller properly. You can do this in Habmin.

DavidR · November 7, 2016, 9:36pm

I had a similar problem with the Aeon Multisensor movement detector. Changing the item from a Contact to Switch worked.

ptmuldoon · November 8, 2016, 9:22pm

@pahansen

I’m away for the work the next few day, but after seeing your screen shots, we do actually have different sensors. I have the ZW089 Recessed Door Sensor Gen5 compared to your DSB54 sensor.

I see your’s is labeled as as Routing_Sensor_Binary. Mine is labeled as a Notification_Sensor.

I do not know if any of that matters, but I’m showing no issues in Habmin or in the PaperUI that i can see. And I post some screen shots myself when I get back home this weekend.

pahansen · November 8, 2016, 9:35pm

You’re right. To be honest, I thought there was only one kind/version of Aeon’s Gen5 recessed door sensor.

ptmuldoon · November 8, 2016, 9:46pm

I wonder if there is a way to force my sensor to be recognized the same as yours? I’m guessing the pairing is done automatically by the controller and sensor… But maybe I sub in DSB54 XML node info for mine?

pahansen · November 8, 2016, 9:48pm

I highly doubt it, but my xml file is attached if you want to look at it.

node4.xml (7.1 KB)

ptmuldoon · November 12, 2016, 2:25pm

Ok, I’m back home and looking at this sensor again.

This the ZW089 Sensor and shows an ON|OFF value in habmin, but is also not showing any Battery Channel. The device shows initialized fine as well, yet can not only get an undefined state in site.

Habmin Screenshots of the ZW089 sensor

And under the channels, the battery actually shows no link/channel

And in my Items File I have

Contact FF_Sensor_Frontdoor "Front Door [MAP(contact.map):%s]" (Door) { channel="zwave:device:158135ef039:node15:sensor_door" }

And contact map is trying to set to map to an ON|OFF State as follows:

ON=Closed
OFF=Open
NULL=unknown
-=undefined

And in the log file for the node I get the below. It appears it sets the value to ON of OFF but then then the controller says it is incomplete?

2016-11-12 09:06:24.517 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 15: Application Command Request (INITIALIZING:PING)
2016-11-12 09:06:24.517 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: Node is ALIVE. Init stage is PING.
2016-11-12 09:06:24.517 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveNodeStatusEvent
2016-11-12 09:06:24.517 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got an event from Z-Wave network: ZWaveNodeStatusEvent
2016-11-12 09:06:24.517 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Setting ONLINE
2016-11-12 09:06:24.517 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 15: Node Status event during initialisation - Node is ALIVE
2016-11-12 09:06:24.517 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 15: Node advancer - PING: queue length(0), free to send(true)
2016-11-12 09:06:24.517 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 15: Node advancer: loop - PING try 1: stageAdvanced(false)
2016-11-12 09:06:24.517 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 15: Node advancer: PING - send NoOperation
2016-11-12 09:06:24.517 [DEBUG] [ndclass.ZWaveNoOperationCommandClass] - NODE 15: Creating new message for command No Operation
2016-11-12 09:06:24.518 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 15: Node advancer - queued packet. Queue length is 1
2016-11-12 09:06:24.518 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 15: Putting message SendData in wakeup queue.
2016-11-12 09:06:24.518 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 15: Node Status event - Node is ALIVE
2016-11-12 09:06:24.518 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 15: Incoming command class BASIC
2016-11-12 09:06:24.518 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 15: Received Basic Request
2016-11-12 09:06:24.518 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 15: Basic Set sent to the controller will be processed as Basic Report
2016-11-12 09:06:24.518 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 15: Basic report, value = 0xFF
2016-11-12 09:06:24.518 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2016-11-12 09:06:24.518 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2016-11-12 09:06:24.518 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 255
2016-11-12 09:06:24.518 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Updating channel state zwave:device:158135ef039:node15:sensor_door to ON [OnOffType]
2016-11-12 09:06:24.519 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 15: CC event during initialisation stage IDLE
2016-11-12 09:06:24.519 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 2: Transaction not completed: node address inconsistent.  lastSent=2, incoming=255
2016-11-12 09:06:29.656 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 0F 03 20 01 00 DF 
2016-11-12 09:06:29.659 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-11-12 09:06:29.659 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 0F 03 20 01 00 DF 
2016-11-12 09:06:29.659 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 0F 03 20 01 00 DF 
2016-11-12 09:06:29.659 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0F 03 20 01 00 
2016-11-12 09:06:29.660 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 15: Application Command Request (ALIVE:DETAILS)
2016-11-12 09:06:29.660 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 15: Incoming command class BASIC
2016-11-12 09:06:29.660 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 15: Received Basic Request
2016-11-12 09:06:29.660 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 15: Basic Set sent to the controller will be processed as Basic Report
2016-11-12 09:06:29.660 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 15: Basic report, value = 0x00
2016-11-12 09:06:29.660 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2016-11-12 09:06:29.660 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2016-11-12 09:06:29.660 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 0
2016-11-12 09:06:29.660 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Updating channel state zwave:device:158135ef039:node15:sensor_door to OFF [OnOffType]
2016-11-12 09:06:29.660 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 2: Transaction not completed: node address inconsistent.  lastSent=2, incoming=255

chris · November 12, 2016, 3:33pm

Are you sure - I can see the battery channel in your image - it’s called “Battery Level”. It doesn’t look like you’ve linked any items to it, but the channel is there.

chris · November 12, 2016, 4:16pm

Sorry - just looking at some more of your message between wiring up some more ZWave switches

The log doesn’t say “it” is incomplete - it says the transaction is incomplete because this is not a transaction. A transaction is where the controller initiates a request - from what I can tell here, that’s not the case - it’s perfectly normal and doesn’t in any case prevent channels being updated.

However - at least one problem seems to be with the database definition so I’ll try and fix this. Someone has added an extra channel for the BASIC class, and this is wrong and it’s meant that we have two channels with the same name - god knows that that does, but it can’t be good.

ptmuldoon · November 12, 2016, 6:03pm

Thanks Chris,

Yes, you were correct the Battery Level was not linked. It seemed strange but I thought you can/should be able to link that within Habmin and wasn’t seeing or missed where to do it. But I saw it in the PaperUI and linked the item.

But a sitemap is still returning no value for battery as well. Here’s what my item looks like for the battery.

FYI…I’m still having a similar issue with my MonoPrice Garage Door Tilt Senor, and a separate issue with my Fan Switch. But will post separate on those once we got this one figured out.

chris · November 12, 2016, 6:27pm

Yes - just press the link button -:

[quote=“ptmuldoon, post:15, topic:16302”]
But a sitemap is still returning no value for battery as well.
[/quote]

This is wrong - it should be “battery-level”, not “battery_level”. It’s a different naming convention as this channel is a (so called) system channel.

ptmuldoon · November 12, 2016, 7:19pm

Thanks Chris on catching that. I see now in the PaperUI how it shows the correct syntax. But shouldn’t the battery show a linked channel in Habmin without even having it included/linked to a specific item in the items file?

Is it normal for an item defined in your items file to show up in the PaperUI? After linking the item in the PaperUI, I actually see “FD Battery” items showing in the PaperUI but no other custom ones?

chris · November 12, 2016, 7:23pm

You mean if you have no item, it should show a linked channel? If you have simple mode enabled, then probably it should, otherwise no.

I would assume so - I don’t use PaperUI, but I think it should.

What do you mean? What’s a “custom one” (one what?).

ptmuldoon · November 12, 2016, 8:19pm

Yes, this what I meant. And just found it was strange that it seemed the battery item may (unsure) be getting unlinked when I comment out the associated item file it. I don’t know how it may have become unlinked.

So it working to simplify the troubleshooting, I have commented out the items file info. I have the channels linked in the PaperUI, and when I look in the BasicUI I see neither the door status nor the battery level.

chris · November 12, 2016, 8:24pm

If you remove the item, then it can’t be linked - right? If you have simple mode enabled, then it will create an item for you, but it won’t be the same name as you have specified in your items file, so it won’t appear in the sitemap.

Maybe I misunderstand what you’re trying to do but I don’t understand why you expect the item to remain if you are removing it from the file.

Battery level is not updated very often - give it a day or so. Otherwise, check the logs - I’m not sure what else to suggest really as without logs I can only speculate.