My new Z-Net performs worse than X-10!

[racerfern]

If you continue to have "Failed sending..." then in all likelihood you have more polling than you realize. The other possibility is that for powered devices, the reporting rate is rather quick. Look at your log and pick a device that's reporting, then search for those words. I'm running a test on my line voltage right now so I have reporting set to once a minute on purpose but normally something like this would be once every 5 minutes. Some child devices might be set to every 5 seconds. Check everything.


I found the culprits by searching for certain key words, example below.

Feb-26 14:22:50

Z-Wave

Device: Energy Sunroom Volts Set to 247.342 (247.342 Volts)

Feb-26 14:21:50

Z-Wave

Device: Energy Sunroom Volts Set to 247.189 (247.189 Volts)

Feb-26 14:20:50

Z-Wave

Device: Energy Sunroom Volts Set to 247.59 (247.59 Volts)

Feb-26 14:19:50

Z-Wave

Device: Energy Sunroom Volts Set to 247.436 (247.436 Volts)

Feb-26 14:18:50

Z-Wave

Device: Energy Sunroom Volts Set to 247.597 (247.597 Volts)

Feb-26 14:17:50

Z-Wave

Device: Energy Sunroom Volts Set to 247.491 (247.491 Volts)

Feb-26 14:16:50

Z-Wave

Device: Energy Sunroom Volts Set to 247.565 (247.565 Volts)

Feb-26 14:15:50

Z-Wave

Device: Energy Sunroom Volts Set to 248.183 (248.183 Volts)

Feb-26 14:14:50

Z-Wave

Device: Energy Sunroom Volts Set to 248.054 (248.054 Volts)

Feb-26 14:13:50

Z-Wave

Device: Energy Sunroom Volts Set to 247.464 (247.464 Volts)

Feb-26 14:12:50

Z-Wave

Device: Energy Sunroom Volts Set to 248.058 (248.058 Volts)

Feb-26 14:11:50

Z-Wave

Device: Energy Sunroom Volts Set to 247.937 (247.937 Volts)

Feb-26 14:10:50

Z-Wave

Device: Energy Sunroom Volts Set to 247.759 (247.759 Volts)

Feb-26 14:09:50

Z-Wave

Device: Energy Sunroom Volts Set to 248.108 (248.108 Volts)

Feb-26 14:08:50

Z-Wave

Device: Energy Sunroom Volts Set to 247.745 (247.745 Volts)

Feb-26 14:07:50

Z-Wave

Device: Energy Sunroom Volts Set to 247.81 (247.81 Volts)

Feb-26 14:06:50

Z-Wave

Device: Energy Sunroom Volts Set to 247.892 (247.892 Volts)

Feb-26 14:05:50

Z-Wave

Device: Energy Sunroom Volts Set to 247.934 (247.934 Volts)

[tahl]

Well, I guess I spoke too soon. Still getting more than an error a day. Had a z-wave failure at 1:15am and according to the log there was nothing else going on. That particular light has never failed before.

Actions I took:
-Set polling of _all_ devices to 0h 0m 0s
-Minimized the reporting period of all devices (e.g., sensors) that report into z-wave
-Checked the routes every z-wave device, modifying a couple to be no more than 1 hop
-Upgraded most Zwave devices to Zwave Plus; regular Zwave is less than 5

Any suggestions?? sparkman AllHailJ racerfern

Is the z-net product the problem? The plug-in? Or the z-wave technology? I don't think it's the latter since I had z-troller working for _years_ without a single error. I can't go back to X-10 bugginess. Any thoughts or suggestions welcomed! (I'm also talking to HS support.)

[tahl]

Hi, racerfern, "Failed sending..." is exactly what I'm getting. This is preceded by "Zwave Error". All polling is set to zero. All reporting is minimized but I cannot eliminate it or I lose needed functionality which kind of defeats the point.

I'm guessing that I'm getting "failed sending..." because the Z-net interface to trying to initiate an outbound operation and the network is somehow jammed? Why doesn't it retry if that's the case? Can I bump up the retries? If I look at my HS log, I often (but not always) don't see any inbound traffic just prior to the failure so I'm not sure what is going on.

[racerfern]

It was quite a few months ago so I don't remember the particulars.

https://forums.homeseer.com/forum/ho...mand-to-device

Here's my original post and a lot of discussion about this same issue. It's worth reading, especially posts by rprade

[tahl]

Thanks for the info. It'll take me a while to go through all of his experiences. Couple of quick comments are that I've assumed that my Schlag locks will miss z-wave to and fro. So I'm not thinking of them as the heart of the issue. It's the hardwired, they-must-be-reliable devices that I'm concerned about. Like a video display that doesn't come on when the room is full of people ready to see a movie!

And although I didn't read everything, one phrase stuck out:

I have always felt that Z-Wave (at least with HomeSeer) is fragile

I'm not feeling optimistic.

[racerfern]

Here's an example of how a device that has polling OFF still reports at selected intervals if enabled. This is from the Zooz RGBW dimmer that I own. Imagine having reports from lots of devices on a fairly regular basis. There are at more parameters for this device that also report so this too can contribute to the problem.

Power Report Frequency Parameter 62:
Choose how often you want your RGBW Dimmer to report power consumption (W) to your controller.
The number entered as value corresponds to the number of seconds.
So if 3600 is entered by default, the RGBW Dimmer will report power consumption every hour.
Power reports are sent in at least 30-second intervals. Values:
0 – disabled (it will not report power consumption based on the frequency setting);
30 – 32400 (seconds); default: 3600 Size: 2 byte dec.

[Tomgru]

And although I didn't read everything, one phrase stuck out:


I'm not feeling optimistic.

I personally think this is a strength and one of the reasons I moved to homeseer to from vera years ago. I have well over a hundred devices and never have a problem like you do. I do have polling turned off but I also have quite a few battery devices and locks and things seem to work respectable and always on time as expected.

[tahl]

Tomgru , I didn't have a single error for years with the Z-troller. It's only been since the Z-net change that the problems started to appear. Do you have the Z-Net device? You're sure you don't get errors? Do you scan all your logs? I get one or two errors a day and with 50+ physical devices (more if you count children), I could go weeks without noticing an error if its not consequential. My failures, unfortunately happen on the wrong device at the wrong time.

[P Dawson]

I'd like to ask a simple question about my zwave nework/ devices. I'm in New Hampshire with no local interference (that I know of) on my power lines. My S6 Pro has operated flawlessly for over a year with both insteon, zwave, and x10 devices all over the house.
My question is about zwave network reliability. I have several "zwave multi-colored light bulbs" that are located at various distances from my zwave antenna (on the controller). I have one zwave repeater approximately equi-distant from some of the zwave devices (motion sensors, bulbs, and wall switches). The IR motion sensors are both battery and plug-in, and all bulbs / wall switches are obviously 120v powered.
I'm finding that several of the plugged in multi-colored bulbs either fail to light (at all), or fail to communicate to all 3 color channels. The S6 log indicates "communication error" when this happens. These failures occur randomly. The motion sensors seem to work flawlessly.
Is there a method to fine tune or fix the failing channels other than "optimize" via the zwave tab on the S6? Should I put a hard-wire USB extender on the zwave plug-in (on the S6 box itself) to physically move it to a better location for increased RF transmission (away from any electrical interference from PC, television, ham radio, etc)?
Additionally, I thought that battery operated devices (motion sensors which include temperature, humidity, light level) couldn't respond to zwave polling settings as they are not bi-directional communications capable). Aerotec "plugged-in units using a wall transformer" devices seem to be bi-directional, but I'm not exactly sure.
Any input about reliabiliy and polling is very much appreciated. Location of physical S6 stick, Z-wave communication, distance from repeater or zstick, interference, polling settings, etc.
Thanks very much,
--Peter--
(Portsmouth, NH)

[Tomgru]

Tomgru , I didn't have a single error for years with the Z-troller. It's only been since the Z-net change that the problems started to appear. Do you have the Z-Net device? You're sure you don't get errors? Do you scan all your logs? I get one or two errors a day and with 50+ physical devices (more if you count children), I could go weeks without noticing an error if its not consequential. My failures, unfortunately happen on the wrong device at the wrong time.

I do have a znet, and look at loklogs frequently, although not every day. I set up an event that mails me if there is an error...maybe see a few of these a week, but the device is still working. These are always during heavy events, like turning all the lights off at bedtime, ans usually just means that HS3 didn't get a confirmation back that the device turn off (which it did)

lots of my devices are Hd200s and I went thru and set all of them to direct connection to the znet...that did seem to help. And I also looked for devices (Per above) that work excessively communicating thing like power and turned that off.

assuming the znet is in the same place as the ztroller was and you optimized to rebuild the network....maybe your znet is bad?

[drhtmal]

Well, I guess I spoke too soon. Still getting more than an error a day. Had a z-wave failure at 1:15am and according to the log there was nothing else going on. That particular light has never failed before...

Are these errors drastically effecting your system? In your initial post you said you had 2 errors in one day and then another day had an error at 1:15 AM. Networks have errors all the time. Retransmissions happen and all is well.

[tahl]

P Dawson, in terms of z-wave RGB bulbs, I don't think they are ready for prime time. I've taken all of mine out of my system entirely. I've tried three different makes -- Monoprice, Hank and Ilumin -- in multiple fixtures in multiple locations that they seem to have about a 10% error rate. They might all be based on the same Z-wave radio / module which could explain why they are equally poor. I've given up on them and instead have gone to RGB light strips. The Aeotec one works great.

Tomgru, I understand the heavy traffic times. I try and get my events as tight as possible (e.g., not turn off something if it's already off) and minimized reporting. I've hand built routes for any device over two hops, etc. I still have too high an error rate for a "professional" system. "Back in the day" we just accepted flakey systems. I'm working with HS support but I'm not sure we will find a defective unit. Maybe. If an outbound message is not successful, seems to me that you should just keep retrying it.

drhtmal, yes they have errors all the time but a proper protocol should never let an error through and unless it is a dire situation (e.g., the device has been unplugged), should be a very long time before it gives up trying. If the Internet was based on UDP (which does not guarantee delivery) instead of TCP (which guarantees the delivery of packets), the web, email, etc. probably would have never happened. I'm probably getting a 2% error rate on Z-wave which is ridiculously high. In a professional system (not a "hobbyist" system), it should be <0.1%. If I was sending a radio signal to Neptune, 2% is pretty good. I'm sending a radio wave 10 feet, at relatively low speed and in a mesh network and not battery powered, so there's no excuse for failure, IMHO.

[drhtmal]

drhtmal, yes they have errors all the time but a proper protocol should never let an error through and unless it is a dire situation (e.g., the device has been unplugged), should be a very long time before it gives up trying. If the Internet was based on UDP (which does not guarantee delivery) instead of TCP (which guarantees the delivery of packets), the web, email, etc. probably would have never happened. I'm probably getting a 2% error rate on Z-wave which is ridiculously high. In a professional system (not a "hobbyist" system), it should be <0.1%. If I was sending a radio signal to Neptune, 2% is pretty good. I'm sending a radio wave 10 feet, at relatively low speed and in a mesh network and not battery powered, so there's no excuse for failure, IMHO.

You did not answer my question as to these errors affecting your system. The reason I asked is that other than obsessing over the fact that there are errors -which could be corrected for and cause no issues- why would one care? It is your system so you are of course entitled to use and maintain it any way you see fit.

What do you mean by a proper protocol? A protocol will correct for errors if that protocol is designed to do so and log the error if configured to do so. Are you saying that a connectionless protocol like UDP which is designed for a specific purpose and use is any less a proper protocol than a connection based protocol like TCP? UDP and TCP each have their uses. The Internet would not function well without both.

To say that the Internet is based on TCP is nowhere near true. Both UDP and TCP were and are critical to the development and success of the Internet.

Indeed things like email and what people call "the web" use TCP to push error checking and packet retransmission down the network stack. Using TCP vs UDP for email was a design issue. Email needs reliable data transmission so it makes sense to use a protocol that has error checking and recovery built in rather than include that function in the higher level application layer protocol. If an email or web page loses packets the email or web page is basically useless.

UDP was every bit as important a protocol to the success of the Internet as was TCP. Some of the most important application layer protocols used on the Internet are UDP based. DNS is primarily UDP based. DNS can use TCP but the majority of DNS queries -over 90%- are UDP based. Audio and video streaming would not work well if based on UDP. Imagine what a VoIP call would sound like if RTP were UDP based. For applications like DNS it makes total sense to drop the overhead of TCP. It is better to allow the DNS protocol to do its' own error recovery since the packets are usually so small the overhead of TCP would use more data than the tiny DNS query.

I can't say if a 2% error rate is ridiculously high for a protocol like zwave. How are you calculating the 2% value?
What is HomeSeer support telling you?

As I said if a 2% error rate is causing issues then I would say it is a problem. If a 2% error rate is not causing issues it might not be a problem.

[tahl]

A lot to unravel here....

You did not answer my question as to these errors affecting your system. The reason I asked is that other than obsessing over the fact that there are errors -which could be corrected for and cause no issues- why would one care? It is your system so you are of course entitled to use and maintain it any way you see fit.

Perhaps you have a strategy I haven't thought about. The failures are essentially random. If a video display or light or what not fails to come on as the event instructs, what is a good strategy for "correcting for it"? I would be interested in your suggestion. I could send every command twice or three times with the idea that at least one should get through. I could create a program that scans the HS log looking for "error" and try again. That adds several _hundred_ events. Or ??? Seriously, what do you suggest if a z-wave device doesn't come on as instructed?

To say that the Internet is based on TCP is nowhere near true.

I guess we will just disagree. I'm very familiar with the ISO protocol stack and the history of the Net. The World Wide Web and email were the two applications that made the Internet the success it is today. Full stop. Maybe I should have said it that way. Those upper-level protocols (HTTP, SMTP, POP3) sit on top of layer 4 TCP for reliable delivery. UDP also plays a key role in the Internet today especially with streaming protocols, but my point was that if information delivery was hit-or-miss, history would have taken a different direction.

I can't say if a 2% error rate is ridiculously high for a protocol like zwave. How are you calculating the 2% value?
What is HomeSeer support telling you?

As I said if a 2% error rate is causing issues then I would say it is a problem. If a 2% error rate is not causing issues it might not be a problem.

From my perspective and for my system, 2% is ridiculous, although I was bringing up that number as an example. My failure rate is more like 1% to 1.5%. It is causing issues or I wouldn't have started the thread. If I ever designed a system that was just 3-9s (99.9%), I would have be fired, let alone 2-9s. Given the events in my system and number of devices in use, 1% translates to about a z-wave failure about 4 times a day. I don't know your system or you. That level of failure might be okay for you. It isn't for me. Not even a once daily failure.