Door Hinge Switch not logging to events.log will this break rules?

Morning/Evening all,

I recently got a GE door hinge pin switch. That’s added, recognized, and happy so far. I wrote a couple simple rules to say if update from switch says OFF, then turn the pantry light off, if update is ON, then turn light on.

Using the android app, I can toggle the switch and it turns the light on/off as I have the rules written. The problem is, when I physically activate the switch, nothing happens. I see the light blink and hear it click, but there’s no evidence of this change in the events.log.

When I toggle the switch from the android app, I do see the events in events.log along with the corresponding light turning on (or off).

I did enable debug logging for zwave, and I do see the action occurring in openhab.log, but I’m assuming the system isn’t going to trigger on debug logs.

I feel like I’m missing something basic, like I needed to set some thing/status of the switch when I added it, but I don’t know enough to say what that might be.

I assume if a thing doesn’t log to the the events log, then the rules can’t pick up on that to carry out an action?
Is there some step/process to have a battery-powered, binary switch log to the events log, or should that be happening by default?

Please post your Items (if defined in .items files) and Rule.

Rules usually get triggered by Items, not Things. events.log only shows state changes for Items. There are a few ways to trigger a rule using a channel on a Thing, but only a couple of bindings support that and zwave is not one of them.

Based on your description I’m going to assume you haven’t linked your Thing’s Channels to any Items.

My apologies, I see I threw the term “thing” around too loosely.

The “Thing” KitchenPantrySwitch is associated with “Channels” binary_sensor and battery-level.

Those Channels are linked items KitchenPantrySwitch and KitchenPantrySensor, and KitchenPantrySwitch_BatteryLevel item.

All of that was done via PaperUI.

My rule is as below:

rule "PantryLightOn"
	when
		Item KitchenPantrySwitch received update ON
	then
		sendCommand(KitchenPantryLight, ON)
	end

rule "PantryLightOff"
	when
		Item KitchenPantrySwitch received update OFF
	then
		sendCommand(KitchenPantryLight, OFF)
	end

These are simple rules so it isn’t a problem. But in the future it is a lot easier to read if you post code and logs in code fences:

```
code goes here
```

Anyway, if the Item is not appearing in events.log it means that the event is not making it into OH. So the problem lies somewhere between the Item definition to the zwave binding to the device itself.

Since you linked the Items to the proper channel in PaperUI there is unlikely to be a problem with the Item definition. But you should double check. Browse to the Thing, click on the Channel and it should tell you what Items that Channel is linked to. Verify that the right Item is linked to the right Channel.

You do see the action in the zwave logs (I assume from the sensor, right) which is good. It means the device is sending the messages as it should. So either the binding is having problems parsing it or indeed you have something wrong linking the Thing’s Channel to the correct Item.

To verify that you are not seeing some problem with the Light, add logInfo statements to the top of both rules so you can verify that they are not firing.

You can simplify your rules down into one rule with one line (two if you count the log statement):

rule "PantryLight"
when
    Item KitchenPantrySwitch changed
then
    logInfo("PantryLight", "Kitchen Pantry changed state: new state = " + KitchenPantrySwitch.state)
    KitchenPantryLight.sendCommand(KitchenPantrySwitch.state)
end

Thanks,
So I commented out the items in the config files, deleted the items from the channels and rebuilt those. I’m following the same process I have with my other (5 so far) zwave devices and those are working great. Only difference is this one is battery operated.

Below is the logs from openhab.log when physically actuating the switch:

2017-10-04 21:37:20.845 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 5: Application Command Request (ALIVE:DETAILS)
2017-10-04 21:37:20.845 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 5: Incoming command class BASIC
2017-10-04 21:37:20.846 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 5: Received Basic Request
2017-10-04 21:37:20.846 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 5: Basic Set sent to the controller will be processed as Basic Report
2017-10-04 21:37:20.846 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 5: Basic report, value = 0x00
2017-10-04 21:37:20.846 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2017-10-04 21:37:20.846 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2017-10-04 21:37:20.846 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 0
2017-10-04 21:37:20.847 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Transaction not completed: node address inconsistent.  lastSent=3, incoming=255
2017-10-04 21:37:24.612 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 05 03 20 01 FF 2A 
2017-10-04 21:37:24.613 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-10-04 21:37:24.613 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 05 03 20 01 FF 2A 
2017-10-04 21:37:24.613 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 05 03 20 01 FF 2A 
2017-10-04 21:37:24.613 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 05 03 20 01 FF 
2017-10-04 21:37:24.614 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 5: Application Command Request (ALIVE:DETAILS)
2017-10-04 21:37:24.614 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 5: Incoming command class BASIC
2017-10-04 21:37:24.614 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 5: Received Basic Request
2017-10-04 21:37:24.614 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 5: Basic Set sent to the controller will be processed as Basic Report
2017-10-04 21:37:24.615 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 5: Basic report, value = 0xFF
2017-10-04 21:37:24.615 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2017-10-04 21:37:24.615 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2017-10-04 21:37:24.615 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 255
2017-10-04 21:37:24.615 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Transaction not completed: node address inconsistent.  lastSent=3, incoming=255

Still nothing in the events.log

I guess I’ll try deleting the device, and the related settings and start from scratch and see if that gets me anywhere.

Removed the device from the system, deleted xml file and “items” and readded. Still nothing in the events.log. I’m officially lost at this point.

Is this your device?

If so, it looks like this device is not setup properly in the database. I’ve made a quick update, but @chris will need to review it.

http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/504

1 Like

Thanks @5iver changes look fine and I’ll probably do an update later today.

That is the device, yes.

When this change is pushed out, will that make it down to me by way of updating the addons package or should I unistall/reinstall the binding to make sure the database is updated properly?

As of now I"m running the 2.2.0~20171008013406-1 addons package.

Yes, you will need to reinstall the binding. Since you are on the snapshot version, just go to paper ui and click uninstall, wait 30 seconds and click install again. This should be enough…

Afternoon gents. Not sure if the changes have been commited/synced/etc, but last I checked the issues persists with the “202” rev of the binding.

Deleted all db entries, xml file, objects, etc etc related to this switch and readded. Works like a charm now.

2 Likes