I’m a newbie, just trying to setup one device on my VeraPlus, 1.7.2608. It is an Ecolink DW-ZWAVE2.5-ECO. It presents a generic device for off/on, and a linked device for door/window sensor. I can get tamper and power alerts from the generic device (everything possible), but I can’t get any alerts from the linked device. I have it registered to notify for open and for close. I’ve upped my logging to verbose, and nothing is coming from the linked device. In all my searches I’ve found a DWZWAVE2-ECO, but the 2.5 appears to be new. Am I overlooking something simple?
Update: I spent a while looking at LuaUPnP.log, and I eventually spotted indicators that open and close events are reported by the sensor:
The 0x16 and 0x17 are shown in the paperwork that came with the sensor. I used tail -f | grep … to spot these, and they immediately followed open or close with the magnet. HOWEVER, I notice that the device reported is the parent off/on device, not the linked door/window sensor, which is device 8.
I now have it working. It appears that I was too impatient trying to get it setup and between using “configure node right now” and Z-Wave “reload engine” commands it lost many of its variables (NOTE to SUPPORT: I’ve read about general issues with this. It would be nice if this could be fixed so as to not cause problems). After removing and re-adding the device and stopping at that, in a short while it appears to work as I expect, without having to add any notifications.
Ecolink DW sensor is already declared in Vera’s database, so the only reason it might cause issues is if either you have a new revision with a different manufacturer info, or maybe as you mentioned, not given enough time to configure itself.
When using configure not right now, all the parameters, variables and data will be purged, and re-added when configuration is finished.
I got it working a couple days ago, but over time, my VeraPlus has quit sending tripped/untripped notifications. It reliably sends tamper notifications. You mentioned a new revision, and I’m sure this is very new. I popped the circuit board from the housing so I could see the entire internal label:
SZ4F-6351T
ESW1025P-01-007
SZ45-2023S/03 JA 17 - I interpret this as date of manufacture.
ESW1025Z-03-A01
The external label:
Model: DW-ZWAVE2.5-ECO - I see lots of references to ZWAVE2-ECO, but have never seen ZWAVE2.5-ECO referenced.
FCC ID: XQC-DWZ25
IC: 98638-DWZ25
Check the variable pnp, into device settings if it has one. Then it’s already declared.
Actually there’s an easier way, without taking out the board.
Devices are declared in database based on Manufacturerinfo variable, which can be found in Advanced settings of the device.
Can you post this info ?
I’ve performed a little more debugging: With verbose logging enabled, I tail LuaUPnP.log | grep ‘ProcessTripAlarm.*armed’. After I remove and re-add the device, I see these (and I get the alarms…):
After rebooting the VeraPlus, “armed” is ALWAYS 0. I turn the device off and on, disable and enable, change Mode to Home, then back to Away, and nothing I do will cause “armed” to become 1 again, except to remove and re-add the device.
I just don’t know enough about things yet to know if this is a device hardware issue, device configuration issue, or a VeraPlus issue…
Vera cannot, under any circumstances “fake” a sensor to make it tripped. That is a zwave command class sent by the sensor itself, and Vera updates the UI accordingly. And tripped and un-tripped are part of the basic set command class, so there is very little, to impossible chance, for Vera to interpret it incorrectly, as this is a command class common for all z-wave devices, and all devices should be interpreted incorrectly.
However, our support team can validate this is as well, and I encourage you to submit a ticket to our support team. If there is indeed a bug somewhere, support will discover it and report it.
Thanks. I think I have enough useful info report it now.
The issue I see is that ARMED is always 0 after a reboot. TRIPPED is still reported correctly, even this morning, nearly 24 hours after I last rebooted.
I believe fixing that will solve my issue.
A lesser side issue is that the state of TRIPPED/UNTRIPPED is not indicated by any UI change on the Web.
I have another sensor, the Aeotec Dry Contact Sensor, that works correctly in updating the UI.
(I just don’t like that it thinks it’s a Flood Sensor, and when I take it out of automatic configuration, it becomes unreliable. As long as it is automatically configured, it seems reliable, just not the messages I really want…)
I had purchased a pair of the Ecolink DW-ZWAVE2.5-ECO sensors and today when I try to include them I get the same two icons that kenhagin described: “…a generic device for off/on, and a linked device for door/window sensor.” The log for the linked device shows nothing while the log for the generic device indicates tripping activity had occurred. But trying to incorporate the generic device into a scene appears nonsensical as the scene builder asks “A device is turned on or off”.
The other GoControl D/W sensors I have (not ZWave Plus devices) do not behave this way. With those sensors the linked device is all that I have access to and in the scene builder it prompts the author with the same selections as the ECO linked device. However, if I try to use the ECO linked device in a scene that is not working because there are no triggers sensed by the ECO linked device. So to my limited knowledge it seems there are two devices that need to be merged into a single device in the VeraPlus, maybe???
Hope a fix is found soon. I thought ZWave Plus was supposed to make the inclusion process easier. Not for me anyway.
Support fixed my issue with this device on Friday, 4/21. Works exactly as you’d expect now. Will provide an update to this forum when I hear back from them about general availability of the fix.
On Monday, 4/24, I received a response from support regarding general availability:
I?ve applied an workaround on your unit and the sensor should be well paired every time when you want to re-add it or to add other devices like this. This matter has been already reported to our development team. I have prioritized this issue on our bug tracking system and hopefully it will not take too long until we will get this sorted out.
I do not have an ETA for it, but I suggest you keep an eye on our Release Notes page that I?ve attached below.
It works! ;D This after Vera Support applied a “Remote Access Workaround” to my VeraPlus Controller (v1.7.2608).
As explained by Vera Support: A “Remote Access Workaround” for an individual’s controller unit is currently (April 30, 2017) required for correct pairing of the Ecolink DW-ZWAVE2.5-ECO Door/Window Sensor to Vera Controllers, and to have the device work properly, until a soon-to-be-released Official Full Support is provided (presumably via a firmware update).
(Thank you, kenhagin, for bringing this concern to light, and Vera Support, for a timely and effective resolution!)
The latest beta version has fix for Ecolink Z-Wave Plus Door/Window sensor and Motion sensor.
If you don’t want to wait, here is the manual fix from tech support:
[code]To properly configure the Ecolink Door/Window Sensor please follow the steps below:
→ on the Vera web interface go to Devices > click on the arrow next to the parent device (the one that displays the battery level) > go to Advanced and change the following values:
on device file: D_DoorSensor1.xml
on device json: D_DoorSensor1.json
on category: 4
on subcategory: 1
→ click on Settings > Z-Wave settings > Advanced > Reload Engine > GO
→ then, in order to hide the child device from the interface, you will need to go to Apps > Develop apps > Test luup code > run the code below after you replace ?XX? with the ID of the child device which you can find by clicking on the ?>? of the device and go to Advanced:
I used the directions to help get an Ecolink Tilt sensor working, but I could not get the Luup code working to hide the child device. Help? I put the child’s ID in the box.
Thanks!
Best Home Automation shopping experience. Shop at Ezlo!