hxn

Members
  • Content count

    148
  • Joined

  • Last visited

  • Days Won

    13

hxn last won the day on November 13 2016

hxn had the most liked content!

About hxn

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    Virginia
  1. Back in the old days when we were under V1, I had a number of GE switches in each of two houses that I had begun monitoring with Iris. In one house, there was never any trouble. In the other, there were frequent disconnects with the result being there was almost always at least one or two switches offline. Eventually, one day, the hub decided that it would fry itself and never be usable again. I made a trip to Lowe's and got a new hub, and had everything back working in a few days. Never again did I have trouble with any of the GE switches disconnecting again, and I never have in the other house (total devices about 100 each house). Apparently, this was an issue with the Z-Wave controller in the hub. I suspect that any Z-Wave device could have its own problems, to the extent that (if making errant broadcasts) it could easily degrade a network of such devices. My suggestion would be to disconnect half of your Z-Wave devices (however inconvenient, but the GE switches have a kill switch on them), and then observe if the problems go away. If not, then disable the other half and watch. You should be able to narrow the problem down to the offender in just a few tries (in two if it's the hub). In an aside note, I have had trouble getting some devices initially paired, so I set up a jig where I hook up the switch into a complete circuit with a light bulb, plug it in, and hold it right under the hub's nose. The hub always recognizes the switch under these conditions, and then I disconnect and install the switch where I want it. I will further note that one of my houses is commercially wired, so that 100% of the wiring is contained in steel conduit and all of the switch boxes are steel. I have had no issues at that house, ever*, with any of the GE switches, and a couple of them are about 65 feet from the hub. However, one of my two CT-101 thermostats is always disconnecting and reconnecting. *With the exception of about the first month under V2, when nothing was stable at either house.
  2. My system has never reported "who" since the forced V2 upgrade. I just thought that was another V2 "feature". I have done multiple zwave rebuilds since that time for other reasons but the who function has never reappeared.
  3. I have used only the V1 outdoors - they seem tighter and better built. I use them mostly under eaves. For the more exposed ones I use a single layer of white electrical tape and leave a tiny gap at the bottom. The tape is not visible more than a few inches away. These will trigger repeatedly on days where the sun is rapidly going in and out, but most other times they are reasonably stable. I have had no trouble with the units internally getting wet or damp.
  4. I've had this happen on several cameras, and for the most part, they never function properly again as a motion detector. All but one of these were the V1 cameras, both outdoor and indoor. The one V2 that recently succumbed to this behavior is an indoor/outdoor model (and is still in warranty - but no time yet to deal with it). This is the eighth camera to do this, but only two have ever returned to normal behavior. Typically when this happens, I stick up a motion detector and just use that to trigger the cameras. I note that this has now happened (permanently) to a full 40% of my cameras, and all except for the last one being out of warranty at the time of failure. These cameras clog up the log, and I haven't found any way to turn the logging off. Close physical inspection shows no apparent issues. I suspect that something is happening in the MD circuit that may generate noise or make the camera susceptible to noise.
  5. I see a dramatic image quality improvement, particularly in low light levels. Noise levels are significantly lower. The new camera also has a wider field of view, approaching 90 degrees. While I won't be replacing the older ones until they fail, I certainly would not buy any more of them. They are so noisy in low-light conditions as to render them almost useless - at least without some auxiliary lighting. So in terms of recording, V1 and V2 aren't much different, but in other aspects there is a clear difference.
  6. I have my cameras powered through smartplugs. I then have rules to turn off those smartplugs when the alarm is set to off, and to reactivate them when it is armed. Works very well, and additionally allows remote resetting of cameras when they go offline - which they occasionally do.
  7. I'm definitely not holding my breath. The last two or three app updates, under "What's new" said only "Bug fixes and performance enhancements". They had been introducing some "new" features* every month, but no longer. Maybe the development team is doing some backing and filling, but this is really disappointing. No sign of any energy monitor support. *Meaning features that V1 had.
  8. The alarm configuration is a setting, not a rule. You might be able to change that, but I don't know for sure.
  9. I have not found the motion detectors, video camera sensor, or the contact sensors* reliable enough to depend on the single-device-to-trigger setting. I have always set Iris to require two devices - so in my garage I have a contact switch on the door and a motion detector as well - so an intrusion into the garage will still trigger the alarm. After I switched both of my systems to the two-trigger requirement, I have had zero false alarms (for over two years now). That said, I always turn off the motion sensors on the camera, as they are extremely prone to false alarms. *On external doors, high wind (> 60 mph) will trigger contact sensors, even though the contact sensors never visibly move. I haven't figured that one out, but I have at least five that behave that way. I have only noticed this phenomenon in cold weather, so maybe a rapid temperature drop has something to do with it.
  10. Network storms can be initiated by devices that form improper packets (such as "runts" - meaning they are somehow truncated as they are generated). This can cause a receiving device, upon seeing that the packet is improperly formed, to ask the sending device to send it again. If the device is defective, it will likely send another truncated packet in reply, and so on. Depending upon the protocol used, this "what-what" loop could go on until the defective device is disabled or removed from the network. This has the effect of (1) saturating the network with traffic (if such transmissions aren't throttled somehow), and (2) overloading the controller, which now has far less time to spend with normal polling activities, and making it appear unresponsive. Again, this is conjecture on my part, but it sure seems identical to the network storms that I have had to deal with in the past. These storms were fairly common in the nineties, but network card and device manufacturers got a whole lot better by the mid 2000s, and such storms on conventional networks are rare these days. But I suspect that the home wireless device makers haven't gotten to the point that the regular network manufacturers have in terms of quality control and reliability. I remember that one of the biggest storm problems I ever encountered was not the hardware, but the network card driver (top name brand card). In order to fix the problem (hardest part was finding it since every client node was prone) the driver had to be updated. So the problem can be caused by either hardware or software. So, in answer to your question: Sure, if the smart plug was being used as a router or repeater, and its network interface was defective, it would affect all of the traffic attempting to go through it. But if the controller is too busy answering bad packets, all devices on the network may appear not to work, or to have extended response times. So, if the controller isn't overloaded, then the devices might appear to fail in consistent groups, unless there is some dynamic routing going on. But I will admit that I'm mostly clueless as to the Iris network architectures. For example, I gather that the various protocols used by Iris do not share the same physical layer (each form of "wireless" would require its own transceiver and therefore be a different physical layer), so that may be why various groups of like-protocol devices seem to go offline together.
  11. Under my proposed explanatory scenario (above), a system with a high number of devices wouldn't necessarily fail, but the probability of having problems would go up with the number of devices. One thing that I am seeing is that a significant portion of the devices all go offline at about the same time. This is what one would expect if a defective device had started a network storm. This happens several time per day on both of my systems; a manual hub reset almost always fixes things for a while. If I don't do anything, it can take several hours for the problem to go away. Iris support suggested I trade in my range extenders for some V2 SmartPlugs, which I did, but I saw no noticeable improvement. The problems do not occur every day, but on over 50% of days.
  12. There is a Murphy's Law corollary that goes something like this: If everything seems to be going well, it merely means that you have overlooked something... I have two systems, each consisting of over 75 components, and each has devolved into an utterly useless system. Alarms won't fire, sensors won't sense, and smart plugs and lights won't respond, despite the system reporting that it is happy. I am wondering if anyone who has a system with a large number of components can say that their system is reliable. I still have a large majority of V1 components, but the V2 components I have seem to be just as apt to go offline* or not respond. I am wondering this: in my network experience, there were often defective devices that could initiate a network traffic storm (or in some cases a broadcast storm). Problems would continue until the defective device was discovered and removed. This almost always required a network analyzer of some sort to identify the origin of the traffic. I believe that this is essential in any larger system with a significant number of nodes. Therefore, I propose that the design team develop an error rate counter that will show with each device, along with signal strength, battery level, and so forth. This way the offending device could be immediately deactivated when the error rate exceeded a certain threshold, possibly even by the Iris system, along with a notification. I am betting that this is a real issue, considering that Iris users who have a smaller number of devices appear to have fewer problems. I had also noticed somewhere that the Iris team had at one point reduced V2 polling rates in order to reduce error problems, and that it had worked, at least so some degree. -------------------- *These devices (usually several at a time) will go offline but there is no red dot showing in the device list. If one goes to the Lights and Switches card, the devices that are actually offline will shortly (not initially) pop up in red as disconnected, and then may or may not reconnect - as if Iris attempts to force a reconnect. There is usually no corresponding entry in the log that anything has gone offline. It is as if Iris is completely unaware of the disconnect.
  13. Same thing here. Camera didn't record for days at a time (it recorded maybe a dozen times a day on average under V1), and now it's recording every three-five minutes, 24x7. Somebody is messing with sensitivity from "the other side"... When it was recording under V1, it was usually evident what triggered the recording. Nothing in these recordings indicates any reason for the trigger. Now I have to go through hundreds of recordings; drowned in noise, so to speak. On the other hand, I have rules to record for two minutes if the door is opened, or if the doorbell (a smart button) is pressed. Those rules have mostly NOT been triggered the last few days. Note: This original lack of sensitivity and subsequent oversensitivity is the case for both of the locations that I have. Also, I had long ago turned off the motion detection of the indoor cameras because they were completely unreliable; i don't have as many options for the outdoor cameras, however. But I am turning off all motion rules from all cameras as of today.
  14. I just now logged into V1 and it now admonishes me to upgrade before July 31... Yesterday it was June 30. I guess they had too many people (like me) still on the old system. At least it will give me some extra time. Perhaps some pressure from this forum also helped convince the powers that be to extend the life of the old system.
  15. I believe that you can use stacked smart buttons for this - the first one set to turn on and off with the alarm, and the second to respond to the motion detector only when it is powered. You would, of course, be annoyed by the disconnect messages/logs. I haven't tried it with V2 yet, but i don's see any reason it wouldn't work. I use a similar strategy with indoor cameras, as I found it impossible to guess when I'd want the cameras not to record. But it's a pretty safe bet I'd want them to record when the alarm is armed, and otherwise not... And you don't have to mess with scheduling.