Linear WD500Z-1 dimmer switch: openHAB not seeing results of physical button presses #1321
Comments
|
What type of dimmer is it? Have you configured an association? Chris Sent from Samsung Mobile -------- Original message -------- From: Bob Igo [email protected] Date:04/08/2014 21:20 (GMT+00:00) To: openhab/openhab [email protected] Subject: [openhab] Z Wave Dimmer: openHAB not seeing results of physical
button presses (#1321) Switch Fan_SF "Fan" (SF, Fans) {zwave="4:command=switch_binary"} However, it does not see or react to physical button presses on multilevel (dimmer) switches. Non-working example: Dimmer Light_SF "Ceiling Light [%d %%]" (SF, Lights) {zwave="5:restore_last_value=true"} It does, however, work when using a GUI like the web UI or the Android client, so it can successfully feed changes forward to the physical dimmer switch, but it seems to be unable to notice any changes from the physical dimmer switch. — |
|
The switch is a Linear WD500Z-1. I only added it to my z wave network (registered it with my Z Stick) and didn't associate it with any groups, if that's what you're asking. In openHAB, it's part of the SF (Second Floor) group, but I don't see any indication that it's grouped as far as the Z Wave network is concerned. If that's not what you're asking, please let me know. |
|
http://www.vesternet.com/knowledgebase/technical/kb-3 Although slightly different symtoms, I've experienced this myself with the fibaro dimmer. The controller needs to be in association group 3 to function correctly and receive updates from the dimmer. Other options are non working return routes. If you have incorrect return routes in the dimmer, it will not be able to reach the controller on it's own. |
|
Is it possible to tell the z stick (my controller) to be in "association group 3" using habmin or any tools in openhab? |
|
I’m not sure what the Fibaro has to do with this? The switch is a different one… For Fibaro, then yes, for most Fibaro switches you need to set an association with group 3, but this switch is a different product so it’s likely to be a different group (assuming of course that it handles associations at all). If this device is recognised in HABmin (I don’t see Linear as a known manufacturer), then you can set up the associations easily by going to the associations folder. If the device isn’t recognised, then you need to find the information - either the manufacturers instructions if they provide the configuration/association information, or preferably, in the pepper1 database. If you can find this, then I’ll add it to the database. The next question will be if it supports associations. Chris |
|
I installed the latest HABmin master HEAD and deployed the 1.6.0 snapshot jars for both habmin and zwave (and removed the 1.5.0 jars). I looked for Association Groups for all my z wave devices, as shown here but I don't have that field for my z wave devices. Is Association Groups what you mean by the "associations folder" or is that a separate thing? HABmin does see the device, but it just reports its HEX IDs and not human-readable names, so I don't know if that counts as it recognizing it. Here's how it looks: |
|
Perfect - thanks for the info. I’ll add this to the database - probably tomorrow. One more question though - can you also send the node5.xml file from /etc/zwave/1.6 folder. I just want to check that associations are supported - pepper says there are 2 association groups, but it also says that association command class isn’t supported, so one much be wrong. The XML file should show what the device actually reports. Cheers |
|
node5.xml (it wouldn't let me attach it) |
|
Thanks. It doesn’t seem to include associations, but then there are a number of other classes that aren’t reported here either. I think I’ll make a version that includes associations, and you can see if it works. Alternatively, maybe you can see if there’s any other info on the web anywhere that supports (or not) that the device has associations? Chris On 6 Aug 2014, at 17:56, Bob Igo [email protected] wrote:
|
|
I'd be happy to test any potential fixes :) It looks like the WD500Z-1 does support assocations: The behavior is slightly confusing to me, though. According to the manual, it will only send to groups 2 or 3 if you double or triple tap the switch, so it shouldn't be sending any association/group commands on single taps. |
|
I note on the pepper database it shows groups 2 and 3 - maybe there’s also a group 1 for 1 press? I’ll add 3 groups and you can give it a go - I don’t think it can down harm (!). |
|
I would hope that they'd document it being part of group 1 if it were designed to send something to group 1. Would you be willing to try it with just groups 2 and 3 first? Then I can try it again with it added to group 1. To me, it just seems odd that a single tap would send commands to a group. |
|
I also wanted to add this observation from another angle of the problem: If I, say, adjust the light to 60% via the web UI or Android GUI, the light changes as expected. Then, if I tap the OFF button on the device, it shuts off, but in either UI, it still shows as 60%. openHAB ends up with a different idea of what state the device is in. That may have been clear, but I wanted to make sure. |
|
If I add all 3 groups, you don’t need to use group 1 and I can always remove it. The Fibaro devices do send association commands on a single press - it allows you to (for example) have the switch turn on a separate light at the same time as the connected load. It’s also used to send notifications to a controller - this is the purpose of group 3 in the Fibaro devices (and this is what you need). |
|
That’s clear - this is the purpose of the association. Without the association, the device doesn’t send its status to the controller… There are other ways to do this if we find that the association route doesn’t work, but associations are the most common way to provide updates to the controller. |
|
Cool. Thanks for looking into this! I'll be able to test at your convenience. (Will you be making the changes on a public branch that I can get to?) |
|
I’ve pushed the changes to the main OH repo. You can either wait for Thomas to merge this, or if you want to pull it from my branch and compile yourself that should also be possible - I think you should be able to follow the reference to the PR that’s hopefully shown above. |
|
I updated my copy of the master branch and manually imported your changes (I wasn't sure how to merge your fork's commit, since I didn't fork the project.) In any case, the metadata is now present, making me confident that my manual merge was successful, but I still don't see anything about associations in the UI or the logs. The behavior is the same as well (which may or may not be expected without the ability to configure associations). I also checked that I'm using all the jars and other files from the build I made from master. (So, all 1.6.0 snapshot versions.) |
|
Try grabbing it again - I forgot to add something... |
|
I rebuilt with your change to wdz500-1.xml but I see similar behavior as before. |
|
Yes - it’s just the zwave. What do you see if you look in the product explorer - does it show associations there? I’m guessing not, but if not, this is likely an issue with the static definition - the thing I added was to put command class 85 (associations) into the XML and this should have been enough to add it in the GUI… |
|
I don't see associations in the product explorer. |
|
Sorry - big oops on my part - I forgot to reference the file! |
|
I see Association Groups in the product explorer now. The devices view now has Association Groups, but there's nothing under it.
|
|
Is there any error logged in the log file? Also, is there anything under Configuration Parameters? I think some time soon we’re going to strike a problem we can’t solve - and that is that the device doesn’t appear to want to own up to supporting associations. This means once we get one more step (I think) it won’t allow us to actually do anything since the command class doesn’t exist. You could try deleting the XML file (in the etc folder) to see if it changes next time it initialises... |
|
From startup to full readiness: After tapping the dimmer's ON button at ~21:02, there was no additional logging. |
|
Also, I have been deleting the XML files for nodes 3-5 each time I've tried a new build. Should I try deleting all of them? |
|
No - deleting the other XMLs won’t make any difference. I assume each time they come back they don’t show the associations class? I don’t see anything wrong in the log either. I had a scan around the web and it seems other controllers have this problem as well with this device (i.e. the device seems to report that it doesn’t support the association command class, so it doesn’t allow associations). (http://forum.micasaverde.com/index.php?topic=23122.0). I think this link also indicates that there is a group 1, and that it’s used in Vera to report the device status, so I think this confirms my suspicions on how to se this up (i.e. group 1 is likely to be the “1 click” group. Something to try - don’t delete the XML files, but add the following into the supportedCommandClasses part -: This should fool the binding into thinking the device has reported this command class, and it should (hopefully!) allow you to set up the associations. Let me know how this goes... |
|
I forgot to add that there is content under Configuration Parameters.
|
|
Debug log from startup, hope it helps. openhab_linear_dimmers_nodes235.txt Big thanks, Chris, really appreciate your diligence! If you think I should upgrade my entire tree to the 1.9.0 snapshot I can give that a try too, I guess -- probably tomorrow, need to get some sleep shortly. Thanks again! |
|
Sorry - one more important step I forgot to add - you need to delete the XML file for the node. This will ensure that OH does a full discovery of the device and we get all the information logged. |
|
OK, done. Removed the XML files first. New log and node2.xml attached: Thanks again. EDIT: Oh and also, still no association groups in habmin for those nodes. Seems like they should match up with the DB entry in file "database/linear/wdz500-1.xml", but...?? |
|
Thanks. So the device doesn’t report that it supports association command class which is why it’s not showing up. This is also shown in the pepper1 database (http://www.pepper1.net/zwavedb/device/482 http://www.pepper1.net/zwavedb/device/482). Please email me directly at chris -at- cd-jackson.com and I’ll create a version that forces this class into the configuration and we can see what happens then... |
|
I am also interested in the outcome of this thread. I have found that only the Linear dimmers work satisfactorily with LED bulbs so I would like to see this working without having to turn on so much polling. I have forced the appearance of associations through hacking up the XML file but adding an association back to the controller through any of these makes no difference, which is the same outcome as Human saw. I have not yet poked around at any log files, as I just got started with this not too long ago. Thanks! |
|
I believe we concluded that the device doesn't support associations. |
|
Oh ok. For group 1 or for all groups? The manual says it supports associations for groups 2 and 3. When I use habmin to add a device into these groups it doesn't seem to stick. |
|
The reason why I am asking is because I want to program this switch so that if I double tap on the up position I want the light to go to 100% instead of the last remembered position. Figured I could use association group #2 for that. |
|
I also got a couple of these: http://www.thesmartesthouse.com/products/zooz-z-wave-plus-dimmer-light-switch-zen22. They are still in the box so I haven't tested them yet. They say they support group 1 associations. Is there a device configuration in OpenHAB for this device? I couldn't find it at cd-jackson.com under "zen22" but perhaps it's under a different name. If these happen to work with my LED bulbs then I will likely move forward with more purchases of these. |
|
I think all groups didn’t work. Note that starting association numbers from 2 is not allowed, so if the device did do this, it would be non compliant to the zwave protocol. |
|
Wow @djarvis , those Zooz dimmers look kind of awesome for the $ -- actual screw/push terminals, screwless faceplate, and Zwave+ for $27? Makes me want to replace some of my Linears if they work well with LEDs (says min 15W load, I don't have that everywhere, sadly). Please report back if you got them working, and with associations, etc. Also, btw, the Linears claim to have "shade control" via double(+)-tap on top and bottom. I haven't had a chance to try and configure this, I think (sincerely hope) it means it'll send out UP/DOWN events to associated devices in those cases. Manual: http://www.nortekcontrol.com/pdf/manuals/WD500Z1_manual.pdf (Note that yes, it also claims they do association with group 2 & 3, not sure if this works or not, I understand if it wouldn't meet zwave spec). |
|
Yes, @benmargolin , I was happy to see what appeared to be a quality LED dimmer at a decent price. I still have two of these in their boxes- I haven't tried them yet. However, naturally there is no silver bullet with any of this. There can't just exist a nice quality LED dimmer with all the Z-wave support to satisfy, it's against some sort of law that we can't quite understand yet- like gravity, or dark matter, or something. I got an email from thesmartesthouse.com about these ZEN22's that I bought. Apparently there is a minor annoyance issue with these in that the paddle-up turns the light off and paddle-down turns the paddle on. AND, these do not support the configuration command class at all so there is no command available to reverse the polarity on these (like you see with a lot of other switches). They are working on resolving the issue somehow, and asked if I wanted to just return them or keep them for a few days until they work something out. I told her I was going to keep them. So, I'm waiting to hear back from her with what they come up with. There is also no companion auxiliary switch available for these for a traditional 3-way wired installation (using the traveler terminal). One can, however, use a standalone switch to do it through zwave/software. |
|
@djarvis ho ho ho you must be kidding about the flipped on/off... that is crazy! That would be a dealbreaker for my wife. Hard to believe they both got the default wrong and didn't include a config to flip it. Sigh. Maybe "Zooz" is about the quality you'd expect based on the name :) Seeing how the instant-update patent seems to be expired, I'm hopeful for an update to the Linear switches that: As usual, we get bitten for being any kind of early adopter, but such is life! |
|
Yes, I got an update with regard to their faulty inventory:
So unless I want to install the switches upside-down I suppose I'll just get a refund. Here's hoping they can work it out in their next batch. |
|
Anyway, back the linear WD500Z switch topic. @cdjackson was it really determined that association groups 2 and 3 completely just did not work? I was hoping to include my controller in the group 2 association such that I can respond to the double-tap event and do something with it. @Human : did you try getting groups 2 or 3 to work with any success? When I include my controller in group 2, I get this in the logs: Still a beginner with this stuff, I'm not sure with a NIF event is, nor can I really verify if anything is being sent to the controller, nor would I really understand how I could create a rule to respond to this event if indeed all is correct up to this point. Any help or recommendations on how to instigate/troubleshoot and/or follow the thread of events to figure this out would be super awesome. I hope to learn enough to reduce the need to ask around. Thanks! |
|
I don’t think we tried groups 2 and 3, but it would be invalid for the device to support groups 2 and 3 and not support group 1. The protocol states that groups must start from 1.
This doesn’t really mean anything. What are you actually doing to include it in group 2? |
|
Hmm. Then I suppose I likely lack complete understanding. By that, I [image: Inline image 1] For the Double Tap association group, I included my zwave controller as On Sat, Sep 10, 2016 at 12:55 PM, Chris Jackson [email protected]
|
|
I guess my inline image didn't show. I have this in my node13.xml: So I have my controller, node 1, in the group. |
|
Please reply using Github, otherwise you can't send images. |
|
Maybe groups 2 and 3 are supported then, which would mean the device violates the protocol and shouldn't have been approved... If you already have it associated in your device, then you should be able to test what happens? I don't have this device, so I can't do any testing. |
|
Ok well, I guess that was my question... if on a double tap on the device I only see this in the logs: ...what would be an example, in terms of items and rules, that I could set up in order to try to receive this event in a rule? |
|
You can’t receive this event in a rule at all. It’s an internal event only. This really can’t be all that is in the log as there is no receive frame logged here. However, if the device is only sending a NIF, then this isn’t something you can detect directly in a rule either since it’s a low level frame. Please provide more information in the log. |
|
Yep, you're right. When I associate my controller in "group 2" and double-tap UP I get this: Same exact log data for a double-tap down. |
|
Really, at the end of the day, I was hoping to automatically dim the lights to 100% immediately on a double-tap up and to 0% immediately on a double-tap down. Perhaps I can just ignore these wonky association groups and write a rule that counts single taps in a short range of time and send the dim commands accordingly. |
|
Ok - so this is the device NIF frame - kind of like a ‘I’m here’ message. We can use this to initiate polling, but that will just give you the device state - it won’t detect button presses. |
|
There’s no real way to detect ‘taps’ though, so I don’t see how you can write a rule to do this. Using the NIF frame will be very unreliable. I’m also not sure it will send multiple NIFs if you press the button multiple times quickly - that’s not the purpose of the NIF. |
|
The NIF is for inclusion, removal etc and is indeed sent on double tap of the bottom paddle (from the manual):
It could be that the Dimmer detects that the controller is not a dimmable device and refuses to either include it in Group 2, or ignores it when sending the appropriate commands. There is a solution for this: Creating a virtual device on the Z-Wave controller and associating and catching the commands sent to this device. The binding does not implement this however. You could try and enable parameter 14 on the device (and keep the controller associated in group 2): This enables shade control for group 2 and could trigger another path in the firmware of the device. This is all speculation however, so please send a log again if you try this, success by no means guaranteed. Manual is here: http://www.nortekcontrol.com/pdf/manuals/WD500Z1_manual.pdf |
…penhab#1321) Signed-off-by: Kai Kreuzer <[email protected]>
|
Just wanted to add to this thread that using HABMIN with OH2 you can go to the "Device Configuration" and update the "Polling Period" to 10 which solved the issue for me. Obviously a workaround... I am using OH2.0. Prior to this, I tried adding my controller to Association Group 1, but this seemed to have no effect. I won't be buying another one of these switches ;-) I have a GE and HomeSeer and both of them report their status almost immediately. Attaching my node.xml file just in case |
In Z Wave binding version 1.5.0.201403252204, openHAB sees and reacts to the results of physical button presses on binary switches, both in terms of updating its UI and firing rules. Working example:
Switch Fan_SF "Fan" (SF, Fans) {zwave="4:command=switch_binary"}However, it does not see or react to physical button presses on multilevel (dimmer) switches. Non-working example:
Dimmer Light_SF "Ceiling Light [%d %%]" (SF, Lights) {zwave="5:restore_last_value=true"}It does, however, work when using a GUI like the web UI or the Android client, so it can successfully feed changes forward to the physical dimmer switch, but it seems to be unable to notice any changes from the physical dimmer switch.
The text was updated successfully, but these errors were encountered: