Elk Rules for Thermostat.. Is there a more efficient way to program this?
- Thread starter SIMKO
- Start date
Maybe it is just the RCS thermostats mentioned above that miss commands.d.dennerline said:
I did verify that the M1XSLZW sometimes does not send the commands. The other issue is that the Elk does not look at the response from the VRC0P+3. The VRC0P+3 will send a <X000 if the command is successfully delivered to the target device and a <X001 if the command failed. Like with other things Elk did not do a complete implementation and does not do any kind of command verification. So any commands that are lost in the network will also never be resent or any notification given that the command failed.
So we are stuck with having to query the thermostat after sending commands to make sure they are sent. This is the case with all Z-Wave commands from the Elk.
That I can find the Elk will only interface directly to the Jetstream lighting controller (via a Serial Expander) which uses ZigBee but this would not be a ZigBee interface for the Elk to control other ZigBee devices. The other options I see are just interfacing the Elk to an external controller like the RTI to control thermostats and locks, etc. But this is no different than having an actual stand alone automation controller that interfaces with the ELK of which there are many (Homeseer, Control4, Vera CQC, ISY, etc.). I have now, as many others here already have, come to the conclusion the M1 should just be the security component of a true automation controller leaving the automation to the automation controller. For the $200+ that the M1XSLZW & VRC0P cost just to get a minimal Z-wave interface to the Elk you are much better off getting an automation controller with a fully implemented, Z-wave interface and interface that with the Elk. Then you can get an actual ZigBee interface as well.DELInstallations said:
It is interesting to see that many of the controllers these days have both Z-wave and ZigBee interfaces. It appears the reason for this is the price and lack of ZigBee control modules and the lack of Z-wave sensors (although there is still a much larger base of Z-wave devices in general).
I think ZigBee is a superior network protocol in general (of course Z-Wave does have some advantages). I think once there are sufficient ZigBee devices available at a reasonable price we may see ZigBee become more dominant but just like with Beta/VHS the superior technology does not always win. I think we may just see a mix of both technologies for a while.vc1234 said:
Since ZigBee is an open standard there should be many more development and anayizer tools available.
The biggest issue is always the implementation of the Technology in the devices. I think properly implemented Z-Wave or ZigBee network devices can be very reliable but unfortunately we get a lot of poorly implemented devices and systems to work with.
Dean Roddey
Senior Member
It's probably pretty difficult for something like the Elk to deal with systems like Z-Wave, which can be really slow to respond. I'm not sure how fancy the operating system of the Elk is, but unless it supports real multi-threading/multi-tasking, it would be really hard to do really tightly. It's tough to do a good Z-Wave driver in a PC based system like CQC, because it's so complicated and responses are often quite delayed. If there are performance issues, I think that the transmitter will try up to three times to send the message and get and acknowledgement, and it has to wait some reasonable amount of time for the reply each time. And of course if multiple hops are required, it could be more I guess.
And of course the ack only means the message got there, not that it was processed or what changes resulted from that processing. That will have to come back as a separate message (or may have to in turn be polled if the unit doesn't report those changes async.) Otherwise you'd just have to assume that what you asked to happen happened as you expect. If not, you get out of sync. But having to positively poll it back just makes the whole process take even longer. Even if it reports async, the time until it does report may be longer than you can wait and you have to remember you are waiting for something from any given module and deal with it never showing up and so forth.
So it's pretty messy.
And of course the ack only means the message got there, not that it was processed or what changes resulted from that processing. That will have to come back as a separate message (or may have to in turn be polled if the unit doesn't report those changes async.) Otherwise you'd just have to assume that what you asked to happen happened as you expect. If not, you get out of sync. But having to positively poll it back just makes the whole process take even longer. Even if it reports async, the time until it does report may be longer than you can wait and you have to remember you are waiting for something from any given module and deal with it never showing up and so forth.
So it's pretty messy.
I've come the the same unfortunate conclusion myself, although I'd very much prefer to have a single box rather than having two, obviously.
Even if I do decide to use two boxes, the problem is what specific box can manage thermostats and locks more reliably than elk does now ? I do not believe that either vera or isy994i are any better in the sense of reliability than the existing elk equipment.
Even if I do decide to use two boxes, the problem is what specific box can manage thermostats and locks more reliably than elk does now ? I do not believe that either vera or isy994i are any better in the sense of reliability than the existing elk equipment.
crossbar said:
By looking at the serial communication between the M1XSLZW and VRC0P+3.vc1234 said:
You can look up discussions of the two for details but in general ZigBee is just a much better defined standard. It was designed for industrial networks and is much more robust for large networks. It took a lot longer to design and that is why it fell behind Z-wave. Z-Wave was defined by a company that wanted to get a product to market ASAP and make money so they implemented what they needed to get the job done at the time. It has since morphed into what Z-Wave is now.vc1234 said:
As I stated both should work well for small HA systems when using well implemented devices. As you can hear around here Z-wave has issues as networks get larger or when using poorly implemented devices. ZigBee is starting to get a hold on the HA market we will see what happens in the future. Now that Apple is getting into this market it will be interesting to see what happens with the entire HA market and products.
What device did you use to look at the serial communication between the M1XSLZW and VRC0P+3. ? Did you see a zwave command being sent from elk appearing on the serial port between elk and m1xszlw but missing on the serial connection between m1xslzw and vrc0p+3 ? You had to use two hardware probes on two serial ports collecting at the same time to come to that conclusion, surely.crossbar said:
So, the loss took place before vrc0p+3 ?crossbar said:
What kind of zwave device and with what command did you try to control when the packet loss occurred ? Was it a lighting device or a lock or something else ?
What kind of cable did you use ? I would like to repeat your experiment.