Well, just like several of us did, you're suffering from a case of old M1G firmware. The bounce was fixed in 4.5.4 / 5.1.4. Update your M1G firmware and try again. It definitely fixed it for me.
Laurent
Elk + Vizia - When?
- Thread starter pgray007
- Start date
Well, just like several of us did, you're suffering from a case of old M1G firmware. The bounce was fixed in 4.5.4 / 5.1.4. Update your M1G firmware and try again. It definitely fixed it for me.
Laurent
On your FAQ page
http://johnnynine.com/wiki/LumenLink%20FAQ.ashx
"How does it interface with ElkRP?
You can export your node and group information to a file that can then be imported into a future release of ElkRP."
With "future release" in italics (!).
Keep up the good work!
BTW, are you maintaining your CQC interface? I just purchased CQC and I am planning to use a lot of your screens (which are great) as a starting point.
Laurent
johnnynine
Active Member
I should have been more specific. Actually I meant do you have a screenshot or link or anything explaining how to import with ElkRP so that I can update my site with that information.
I don't actually use the CQC interface that I created. I've had a lot of excellent feedback from it and I'm glad you like it. I was hoping to use it as well but the costs for getting a touch screen and media components were undesirable.
I have actually been working on my own home automation system recently. It happened by accident as I was just trying to get something that talk to the ElkM1 and the Vizia RF... so I wrote my own application. Unfortunately I have a hard time doing software half way so I designed it from the ground up to be a fully network distributed system that allows plug in drivers to be added. I should have an alpha release for it as soon as next week if you are interested in checking it out. You can get the details at http://johnnynine.com/wiki/Automation%20En...20Concepts.ashx
Here is a mini-tutorial. You're welcome to use any part of it on your web site.
This requires ElkRP 1.6.22 or later, a M1G with firmware 4.5.4/5.1.4 or later (to avoid the light bounce issue), a M1XSP with the special Zwave firmware (this was tested with beta 20.0.1), a RZC0P, a RZCPG remote (most likely), a PC with a serial port (for the RZC0P) and Johnnynine's LumenLink.
Recommendations on Zwave and LumenLink:
- Use the "update controller" function of the RZCPG remote to update the RZC0P whenever you add nodes.
- On the RZCPG remote, use the HAI setup option, choose RZC0P and add "+" all the devices you want to get notification for. You can use the "4 ON" key to add all (typical). Then press the (.) button, which will start the associations. Finally, when using "back", all the routes will get calculated. Note that I have had intermittent issues for both the association and the routes steps and usually, it is better to leave the remote in the middle of the network, not at the edge (which is where my RZC0P is).
- In LumenLink, especially if you added nodes recently, hit "Rediscover the Network", otherwise it'll use the old list of nodes it has saved.
Now, in ElkRP:
In the main window, on the left pane (Folder Items), go to Automation/Lighting. Right click on Lighting and choose Import Lighting Data...
An Import Lighting Data dialog box appears.
- Keep Export File Format to the first choice Universal Devices...
- Browse to find the file written by LumenLink (normally called ElkLightImport.xml)
- In Handling of Existing Data, choose the appropriate option depending on whether you want to nuke previous data or not.
- In Handling of the "Opt" Flag, always use Set (enable)... if you want your Zwave lights to work properly. You can always fix that later in the Lighting section of ElkRP, but you have to do it for proper Zwave operation.
- In Handling of the "Show" Flag, the best option is usually Set (enable)... if you want all lights to appear in ElkRM. You can always pick and choose later in the Lighting section of ElkRP.
- In Handling of Voice Descriptions, choose as needed. LumenLink will not fill these for you, so you'll have to manually assign voice descriptions to the lights later.
Now clean up the new entries in Lighting to your liking, Send to Control, then Save.
You're done!
Now open ElkRM or the M1XEP applet and watch Elk update the light status when you flip a switch...
Spanky,
it looks like I may have found another issue (in addition to, AFAIK, the TURN ON FOR... issue and lack of polling).
It may be related to the TURN ON FOR... rule but there is more.
I have a rule that does:
WHENEVER SUNSET
THEN TURN Light0 ON, FADE RATE=0
THEN TURN Light1 ON, FADE RATE=0
THEN TURN Light2 ON, FADE RATE=0
THEN TURN Light3 ON, FADE RATE=0
The result is very unpredictable. I get anywhere between 1 and 4 lights turning on. Mostly just 1-2. If I use the "test" feature in RP and press the button a bunch of time, I usually manage to eventually get all 4 ON.
Now for the potentially more interesting part. If I do the above (i.e. press test a bunch of times), it looks like the RZC0P gets confused. I haven't fully isolated the failure, so I am not sure whether 1 rule execution is enough or if it's the many.
The failure is that I mostly lose 2-way from the RZC0P, i.e. if I manually flip a switch, the update in the M1XEP applet happens veeeery slowly (usually, it's 1-2secs), and that's a fraction of the time. The rest of the time, I get no update at all. Updating the other way by clicking on the applet take effect immediately on the light, so it's really a feedback issue, not control.
AFAICT, this gets fixed by power cycling the RZC0P (pulling it off the wall and back on, RS232 stays connected). Once again, I need more work on isolating the issue.
I haven't tried yet, but I assume that if I try to throttle the 4 "TURN ON" and insert pauses between each, it'll work better, but I am not sure how to do that easily (except by using a fake output that you turn ON FOR 1sec and use the deasserting edge as a trigger for the next light).. UPDATE: that works fine, although it would be great to avoid having to write all these rules.
Note: I haven't tried RZC0P "groups".
Laurent
it looks like I may have found another issue (in addition to, AFAIK, the TURN ON FOR... issue and lack of polling).
It may be related to the TURN ON FOR... rule but there is more.
I have a rule that does:
WHENEVER SUNSET
THEN TURN Light0 ON, FADE RATE=0
THEN TURN Light1 ON, FADE RATE=0
THEN TURN Light2 ON, FADE RATE=0
THEN TURN Light3 ON, FADE RATE=0
The result is very unpredictable. I get anywhere between 1 and 4 lights turning on. Mostly just 1-2. If I use the "test" feature in RP and press the button a bunch of time, I usually manage to eventually get all 4 ON.
Now for the potentially more interesting part. If I do the above (i.e. press test a bunch of times), it looks like the RZC0P gets confused. I haven't fully isolated the failure, so I am not sure whether 1 rule execution is enough or if it's the many.
The failure is that I mostly lose 2-way from the RZC0P, i.e. if I manually flip a switch, the update in the M1XEP applet happens veeeery slowly (usually, it's 1-2secs), and that's a fraction of the time. The rest of the time, I get no update at all. Updating the other way by clicking on the applet take effect immediately on the light, so it's really a feedback issue, not control.
AFAICT, this gets fixed by power cycling the RZC0P (pulling it off the wall and back on, RS232 stays connected). Once again, I need more work on isolating the issue.
I haven't tried yet, but I assume that if I try to throttle the 4 "TURN ON" and insert pauses between each, it'll work better, but I am not sure how to do that easily (except by using a fake output that you turn ON FOR 1sec and use the deasserting edge as a trigger for the next light).. UPDATE: that works fine, although it would be great to avoid having to write all these rules.
Note: I haven't tried RZC0P "groups".
Laurent
Spanky
Senior Member
The problem could be in that if Zwave misses a transmission and must retry, the next light command is overwritten. Try experimenting with putting a delay between the light command using output timers and see if all the lights then work.
I have seen similiar problems when numerous lights are turned on with one Rule. If any light fails and retries are sent, other lights might not work.
A group command should control all the lights in a group, provided the light switch can hear the command.
I have seen similiar problems when numerous lights are turned on with one Rule. If any light fails and retries are sent, other lights might not work.
A group command should control all the lights in a group, provided the light switch can hear the command.
Spanky,
as mentioned at the bottom of my post, if I use a chain of 1sec delays, it works fine, but it's a bit worrying. Even with a 1sec delay, if the zwave network is slow (does happen: a light bulb goes out, 3-yr-old unplugs a plug-in...), I don't want to risk having a collision. Is there no way the Elk can make sure it doesn't send another command before the previous one has acked properly, or whatever the protocol requires? It is worrying that the RZC0P need a reboot to deal with it. It would be better not to get in that situation to begin with.
Of course, having to code in delays is pretty inconvenient too, but that's secondary to half-hanging the RZC0P.
Laurent
as mentioned at the bottom of my post, if I use a chain of 1sec delays, it works fine, but it's a bit worrying. Even with a 1sec delay, if the zwave network is slow (does happen: a light bulb goes out, 3-yr-old unplugs a plug-in...), I don't want to risk having a collision. Is there no way the Elk can make sure it doesn't send another command before the previous one has acked properly, or whatever the protocol requires? It is worrying that the RZC0P need a reboot to deal with it. It would be better not to get in that situation to begin with.
Of course, having to code in delays is pretty inconvenient too, but that's secondary to half-hanging the RZC0P.
Laurent
johnnynine
Active Member
Thanks Laurent, I finally updated the web site with the instructions.
johnnynine
Active Member
The beta firmware that supports ViziaRF requires a Leviton ViziaRF RZC0P, which DOES work with other zwave devices however you will only get the 2 way notification from the ViziaRF devices.
I'm not sure if you need the ViziaRF primary remote or not?
Sandpiper
Active Member
Johnnynine, Johnnynine,
What is the status and current timeline?
I am just about to setup an Elk with Z-Wave. I also don't see this capability in the official release. The release I see on the Elk website is dated in June. So where can we get the version that supports the RZCOP? Do we still need to use the beta direct from Spanky?
Dave G.
Similar threads
