[ANSWERED] Wayne Dalton z-wave / car2u bridge

Can't get this WDHA-12R to do anything useful. It is a bridge device that is supposed to convert Car2u commands to z-wave commands, and is a 3-button controller. http://wiki.micasaverde.com/index.php/W ... on_WDHA-12

Car2U is the absolutely terrible and unsupported replacement for the old HomeLink-based garage door / home automation buttons that are built in to cars. HomeLink used the old X10 'security' protocol, which was trivial to receive.

Anyway... I can get the bridge to lync with my z-stick, but it just shows up as a generic portable controller in Indigo (6.0.2) with no info.

Attempting to create a trigger doesn't work ('device state changed' shows it in the list, but there are no states to watch for, and it doesn't show up in the devices list for a 'z-wave event:z-wave command' trigger).

No log entries are generated when pressing any of the 3 scene buttons on the device either.

Code: Select all

Z-Wave                          Indigo Device "005 - Portable Controller" Z-Wave Properties:
Indigo Z-Wave Version: 1.0.124
Node ID: 5
Model: Portable Controller
Model ID: 00000000
Manufacturer: Unknown
Manufacturer ID: 0000
Protocol Version: 0.00
Application Version: 0.00
Model Definition Version: 0
Library Type: 0
Class Name: Portable Controller
Class Hierarchy: 01 : 01 : 00
Command Class Base: 00
Command Versions: 20v1 21v1
Multi-Endpoint Types: - none -
Multi-Endpoint Classes: - none -
Multi-Instance Counts: - none -
Features: - none -
Neighbors: - none -
Associations: - none -
Config Values: - none -


[matt (support)]

Turn on the Debug logging checkbox (via the Interfaces->Z-Wave->Configure... menu item).

Do you then see anything logged in the Event Log when you press the 3 scene buttons? If so, copy/paste it into a reply for me.

I can't get the blasted thing to put anything in to the event log, even with debug on. I even reset my zstick, deleted all my zwave devices, and re-learned everything.

Is the WDHA-12R not supported in Indigo?
I am waiting for mine to come in to transfer the Keychain remote commands to Indigo...

[jay (support)]

It's gonna be hit or miss - Z-Wave scene controllers are all over the place in terms of how they're implemented. Once you get yours in, include it with your Z-Stick then try to do a define and sync in Indigo (you'll have to figure out how to wake it up). If it doesn't work then copy/paste the log lines from the event log window for the define and sync. Then follow Matt's directions above and copy/paste anything that shows up.

Given @DPattee's experiences it doesn't look very promising...

Will do!
By the way, you guys need to update your avatars with the new logo

Any updates on indigo support for the WDHA-12 ? I can't get my WDHA-12 to trigger anything in Indigo as well...

[matt (support)]

It isn't currently supported. From what I can tell the WDHA-12 needs to be made a secondary controller. Indigo doesn't currently have UI to force that state on the WDHA-12, although adding that capability is on our feature request list. At that point it might be possible to receive the scene commands from it and create Triggers in Indigo to catch the events.

Any updates on plans to support this (and other z-wave scene controllers for that matter) ? indigo has been of very limited use for me without secondary scene controller support...

[matt (support)]

No updates on this module at this point – it is still on our wish list. Right now we are concentrating our efforts on the next major release of Indigo Touch.

Any updates on support for this secondary z-wave controller? ...please....? its been years now since the first request....

[jay (support)]

And, sadly, we've had so few requests it's still relatively low on the priority list. But it's still there.

Really? So you are not going to be able more thoughtful about requests than that? No lower priority requests would even get serviced then.

[matt (support)]

Have you tried using this plugin yet? I'm not sure if it will work or not but it is worth trying.

[jay (support)]

Really? So you are not going to be able more thoughtful about requests than that? No lower priority requests would even get serviced then.

Lower priority requests may very well "get serviced" if we happen to be working on an area of code where we can also add those requests without significant effort. Likewise, if the request requires significant code refactoring it may have to wait until we are back into that code to do the refactoring to address multiple requests to add a new class of functionality (for instance).

But demand certainly does play an important role in considering what features to add.