• Content count

  • Joined

  • Last visited

  • Days Won


hxn last won the day on November 13 2016

hxn had the most liked content!

About hxn

  • Rank
    Advanced Member

Profile Information

  • Gender
  • Location
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. The alarm configuration is a setting, not a rule. You might be able to change that, but I don't know for sure.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. Are you saying that the Iris V2 hub bricks your cameras? If so, that's good to know, since I'll remove them from the V1 system before doing the migration. Has anyone tested whether if you remove an Iris camera from a V2 system, can you then talk to it again with the 3rd party software? I was strongly considering NOT migrating the cameras, since V2 apparently doesn't allow saving, and the video portion of Iris has been the most unreliable part of the system by far.