Vision ZD2102 Door sensor not working

Since my Philio PST02-1C sensors are not yet supported I went out and purchased a couple of Vision ZD2102 door sensors.

I checked to make sure that support was included in Indigo before I purchased these.

When adding them to Indigo, they only show up as a routing slave though.
I now have 4 sets (around 200 euro) of door sensors that are not working with Indigo, is there a way to get any of these working please ?
I already submitted the device info, but here is what shows up in the event log.

When adding the sensor to Indigo :
Z-Wave Syncing - started for device "008 - Routing Slave"
Z-Wave Syncing - retrieved module neighbors list: - none -
Z-Wave Syncing - assigning return route to "008 - Routing Slave"
Z-Wave Syncing - assigned return route
Z-Wave Syncing - retrieved manufacture and model names: Vision / Yale - 0109, Routing Slave - 20010106
Z-Wave Syncing - retrieved protocol version 4.05, app version 5.01
Z-Wave Syncing - retrieved class hierarchy: Routing Slave : -- : -- (04 : 07 : 01, base 00)
Z-Wave Syncing - retrieved command classes: 80v1 84v2 85v1 86v1 70v1 71v1 72v1 73v1 98v1 59v1 5Av1 7Av1 5Ev1
Z-Wave Syncing - retrieved wake interval of 60 minutes
Z-Wave Syncing - device "008 - Routing Slave" wake interval changed to 60 minutes
Z-Wave Syncing - retrieved group 1 associations: [1]
Z-Wave Syncing - group 1 association to interface already exists (skipping)
Z-Wave Syncing - retrieved battery level of 90%
Z-Wave Syncing - created device "008 - Routing Slave"
Z-Wave Syncing - complete
Z-Wave received "008 - Routing Slave" status update battery level 90%


When the magnet opens :
Z-Wave Debug RCVD basicSetState: 01 09 00 04 00 08 03 20 01 FF 27
Z-Wave Debug . . basicSetState: node 008, endpoint None, value 255 (no node dispatch)
Z-Wave Debug RCVD requestAlarmSensorStatus: 01 10 00 04 00 08 0A 71 05 06 FF 00 FF 06 16 00 00 8B
Z-Wave Debug . . requestAlarmSensorStatus: node 008, endpoint None, cmdClass 71, type 6, value 255


When the magnet closes :
Z-Wave Debug RCVD basicSetState: 01 09 00 04 00 08 03 20 01 00 D8
Z-Wave Debug . . basicSetState: node 008, endpoint None, value 0 (no node dispatch)
Z-Wave Debug RCVD requestAlarmSensorStatus: 01 10 00 04 00 08 0A 71 05 06 00 00 FF 06 17 00 00 75
Z-Wave Debug . . requestAlarmSensorStatus: node 008, endpoint None, cmdClass 71, type 6, value 0


I have to add that the model number on the box is VIS_ZD2102-5
This is a Zwave plus device, so I think it is slightly different from the one that is currently supported in Indigo

[jay (support)]

Yeah, it's quite annoying that device manufacturers keep the same SKU (or make only a minor change, like appending a -1 or something) but change the Z-Wave device ID. We'll add it to the list, but no ETA given the long list of devices we need to add.

If there is something I can bribe you with, let me know

I'm hoping it is an easy update, since the older version is already in Indigo.

To go on with my newbie questions...
Couldn't I just write a script that looks at the event log for these lines :
Z-Wave Debug . . requestAlarmSensorStatus: node 008, endpoint None, cmdClass 71, type 6, value 255
Z-Wave Debug . . requestAlarmSensorStatus: node 008, endpoint None, cmdClass 71, type 6, value 0

It's obvious that value 255 is magnet open, and value 0 is magnet closed. If this data shows up in the event log, couldn't I just intercept it and build my triggers from there ?
Is this what the virtual devices are for perhaps ?

Unfortunately it's not what the virtual devices are for.

You might be able to develop your idea with the help of the SQL Logger plugin - I've not read it's docs but I saw reference to a similar idea recently. I might be on the wrong track though.


Sent from my iPhone using Tapatalk

Indeed the SQL logger plugin offers something very close.
But it seems the only things that the SQL logger can capture from the event log are errors. So the SQL logger seems to already have a filter applied.
It seems it cannot capture generic events from the event log, or in my case, ZWave debug messages.

It would be awesome if this could be expanded to any type of event log entry though, imagine the possibilities.

To the devs, if adding support for devices is labour intensive (which I can certainly believe) would adding this functionality to the SQL logger be a reasonable request ?

[jay (support)]

If you enable Event log history in the SQL Logger, it will log everything that's written to the event log window.

Jay,
I tried, but I cannot get the SQL Logger to log ZWave Debug messages to the database. (it does log regular event messages fine, but I need the ZWave debug commands since my device is unsupported).

Furthermore, SQL Logger only has a configurable trigger for Errors and not for general event messages
The trigger can be refined with filtering on a specific error type, but it needs to be an error nonetheless for the trigger to function.

What I am trying to accomplish is have an unsupported device, that communicates with the event log through zwave debug commands, capture this communication and have it perform an action.

In my case, the ZD2101 (and Philio PST02-1C) door sensors send messages to the event log. I select which message turns my siren on, and which message turns my sirene off.

If I'm missing something, could you please elaborate, but I can't seem to make this scenario work.
Is there any way I could hack the SQL Logger plugin to do what I want ?

I just entered this in the scripting shell :
indigo.server.getEventLogList(lineCount=5)

and behold !!! it returns the last 5 event log entries including the zwave debug commands.
I am hopefull that what I want to try is possible, but I'd like to hear opinions if this is good practice or not...

I would need to find a way to read and filter the event log every second or so, to see if my door sensor is tripped and then turn my sirene on.
Is there a way to perpetually loop a python script, or will this break functionality or performance in Indigo ?

I got it. Maybe this belongs in the python forum, but I solved it by setting up a Schedule that runs every 10 secs when my alarm is armed, and this as an embedded script :

Code: Select all

alarmArmedVar = indigo.variables[1705593234]
if alarmArmedVar.value == "true":
   indigo.server.log("The alarm is armed, check for door sensor tripped")

   eventEntries = indigo.server.getEventLogList(lineCount=25)
   eventToLookFor = "requestAlarmSensorStatus: node 008, endpoint None, cmdClass 71, type 6, value 255"
   doorTrippedVar = indigo.variables[543692705]

   if eventToLookFor in eventEntries:
      indigo.server.log("Event found in eventLog: Door is tripped\n")
      indigo.variable.updateValue(doorTrippedVar, "true")

I have added this to the Python forum as well looking for general opinions :
http://forums.indigodomo.com/viewtopic.php?f=107&t=14323

[jay (support)]

I tried, but I cannot get the SQL Logger to log ZWave Debug messages to the database.

I just turned on Z-Wave debugging, turned on the SQL Logger, enabled Event Log logging, had a motion sensor update, then used SQLiteManager to run a query against the eventlog_history table:

ss52.png (124.85 KiB) Viewed 4542 times

So, it appears to be logging the Z-Wave Debug lines. Not sure why it wasn't for you.

Strange, I'll have to check again, but anyway my python hack is working, so I don't need the overhead of the SQL logging.

[matt (support)]

Hi Pete,

I'm gathering information on this device, and was hoping that you could also capture the debug log output for when the tamper switch is tripped and reset.

Also, I believe the older version of the module had the ability to wire an external switch to the module. If this newer version of the module supports that as well, then can you use a wire to open/close the circuit for the external switch contacts and capture the debug logging output for it as well?

Thanks!

Certainly.
This is what appears inside the debug log.

Magnet opened :
Z-Wave Debug RCVD requestAlarmSensorStatus: 01 10 00 04 00 0C 0A 71 05 06 FF 00 FF 06 16 00 00 8F
Z-Wave Debug . . requestAlarmSensorStatus: node 012, endpoint None, cmdClass 71, type 6, value 255

Magnet closed :
Z-Wave Debug RCVD requestAlarmSensorStatus: 01 10 00 04 00 0C 0A 71 05 06 00 00 FF 06 17 00 00 71
Z-Wave Debug . . requestAlarmSensorStatus: node 012, endpoint None, cmdClass 71, type 6, value 0

Tamper switch open :
Z-Wave Debug RCVD requestAlarmSensorStatus: 01 10 00 04 00 0C 0A 71 05 07 FF 00 FF 07 03 00 00 9A
Z-Wave Debug . . requestAlarmSensorStatus: node 012, endpoint None, cmdClass 71, type 7, value 255

And after 10 sec tamper switch open:
Z-Wave Debug RCVD nodeAwake: 01 08 00 04 00 0C 02 84 07 7E
Z-Wave Debug . . nodeAwake: node 012
Z-Wave Debug . . . . . . . : skipping battery check (next check in 708 mins)
Z-Wave Debug SENT goToSleep: 01 09 00 13 0C 02 84 08 04 F7 94
Z-Wave Debug RCVD packet: 01 07 00 13 F7 00 00 01 1D (hex)

Tamper switch closed :
Z-Wave Debug RCVD requestAlarmSensorStatus: 01 10 00 04 00 0C 0A 71 05 07 00 00 FF 07 00 00 00 66
Z-Wave Debug . . requestAlarmSensorStatus: node 012, endpoint None, cmdClass 71, type 7, value 0

There is an external switch, but I can't get it to do anything at all (I'm simply shorting the two terminals with a small piece of wire).

The included manual of this sensor is here :
http://www.vesternet.com/downloads/dl/file/id/617/z_wave_vision_door_window_sensor_manual.pdf

I'd like to repeat my previous request to "Please" support the ZD2102 Gen5.
It's been only 8 months since my initial request.
I hope I don't come over as being pushy

[matt (support)]

No need to repeat. It is on our feature request list currently with a pretty high priority (and it definitely requires a new device definition to work correctly).