How can i trust this? Missing sensor showing fine!

[madcodger]

I've had an ISY in 3 houses now, and while I've always complained about the UI, I always felt I could trust the device. That is now shaken a bit, as I try zwave.

I disconnected a MIMO lite from power, so it would have lost all connectivity to the zwave network, to make some connections to a digital logger AC  monitoring relay, and left it unplugged for about 9 hours. I then logged onto the ISY to check something else, and the MIMO was showing as hooked up and fine.

WHAT THE _____??!!

That is just ridiculous. A disconnected sensor - especially one that is plugged into AC and not on battery - should show as disconnected when that is the case. Otherwise, how can the status of that device be trusted?

To be frank, I'm not thrilled with the ISY as a zwave controller. I went with zwave at this remote location because I didn’t want to have to worry about a PLM failure when I’m 500 miles away, but so far I’m finding it much less reliable and more difficult than my old Insteon equipment at the property I just sold. Anyway, any ideas about how this could happen, and how one can discover if a zwave device has died or become disconnected? The role of this MIMO was to report on power failures, so that's rather important. Thanks in advance for any solutions - or even ideas.

 

 

 

 

 

 

Edited October 7, 2019 by madcodger

[Techman]

If you physically disconnect a device you need to right click on that device in the ISY and then click on disable, otherwise there's no way for the ISY to know when a device has been disconnected.

[lilyoyo1]

14 hours ago, madcodger said:

I've had an ISY in 3 houses now, and while I've always complained about the UI, I always felt I could trust the device. That is now shaken a bit, as I try zwave.

I disconnected a MIMO lite from power, so it would have lost all connectivity to the zwave network, to make some connections to a digital logger AC  monitoring relay, and left it unplugged for about 9 hours. I then logged onto the ISY to check something else, and the MIMO was showing as hooked up and fine.

WHAT THE _____??!!

That is just ridiculous. A disconnected sensor - especially one that is plugged into AC and not on battery - should show as disconnected when that is the case. Otherwise, how can the status of that device be trusted?

To be frank, I'm not thrilled with the ISY as a zwave controller. I went with zwave at this remote location because I didn’t want to have to worry about a PLM failure when I’m 500 miles away, but so far I’m finding it much less reliable and more difficult than my old Insteon equipment at the property I just sold. Anyway, any ideas about how this could happen, and how one can discover if a zwave device has died or become disconnected? The role of this MIMO was to report on power failures, so that's rather important. Thanks in advance for any solutions - or even ideas.

 

 

 

 

 

 

This isn't an isy issue it's how you used your system issue. Its akin to me removing your car battery without telling you. In your mind it's still there until you go to start your car and find out that it's not 

Edited October 7, 2019 by lilyoyo1

[Mustang65]

36 minutes ago, larryllix said:

How much do you want for it? Good shape?

 

This useless post will be deleted shortly.

What is your definition of shortly?

[madcodger]

Well, with respect to your opinions, I disagree.

If two-way communication between a sensor and a controller, is possible - and it is, for a sensor that is running on AC power - the controller can (and, I maintain, should) check periodically to see if the sensor is still alive and monitoring. If the controller "pings" and gets no response, then the controller should report that. This is NOT like someone removing a car battery, as the battery is the power source for the car.

I'm not an expert in sensors or security, but I believe an alarm system reports the loss of a wireless sensor, and does so promptly. Perhaps this is the reason I never noticed this type of issue in the past, as I've always used my Elk's sensors instead of relying on Insteon or Zwave sensors. I don't have an Elk installed (yet) here as we just purchased this property. But if/when I do, I would be rather disappointed if a wireless sensor just quit working, and I never knew it. So, if we are to rely on our automation devices, how is this not a valid expectation? I "get" that this is not a security system, but having a dropped sensor that you think is active is sometimes worse than no sensor at all. I'll ignore the "I'll buy it" comments. I can always convert the ISY to Insteon and use the MIMO as a relay, but thanks for your comments, if not your solutions.

 

[larryllix]

ISY does show disconnected devices. You need to have the 3:00 AM query running that your ISY came with.

Other than that Insteon does not work like that. Insteon is a push event triggered system. End devices are responsible to keep ISY or central device hub up to date. UDI went above and beyond that system and installed a 3:00 AM program to query devices that the user can totally control.

Edited October 8, 2019 by larryllix

[lilyoyo1]

1 hour ago, madcodger said:

Well, with respect to your opinions, I disagree.

If two-way communication between a sensor and a controller, is possible - and it is, for a sensor that is running on AC power - the controller can (and, I maintain, should) check periodically to see if the sensor is still alive and monitoring. If the controller "pings" and gets no response, then the controller should report that. This is NOT like someone removing a car battery, as the battery is the power source for the car.

I'm not an expert in sensors or security, but I believe an alarm system reports the loss of a wireless sensor, and does so promptly. Perhaps this is the reason I never noticed this type of issue in the past, as I've always used my Elk's sensors instead of relying on Insteon or Zwave sensors. I don't have an Elk installed (yet) here as we just purchased this property. But if/when I do, I would be rather disappointed if a wireless sensor just quit working, and I never knew it. So, if we are to rely on our automation devices, how is this not a valid expectation? I "get" that this is not a security system, but having a dropped sensor that you think is active is sometimes worse than no sensor at all. I'll ignore the "I'll buy it" comments. I can always convert the ISY to Insteon and use the MIMO as a relay, but thanks for your comments, if not your solutions.

 

For starters, the isy (and other controllers) and zwave devices aren't alarm systems. Both serve different functions and respond/behave as such. Even then should you remove a sensor from an alarm sensor, it will not alert you unless you A) run a test or arm the system. For some systems, periodically it will ping a device (once per 24 hrs). 

Since you mentioned Elk. Go ahead and test this for yourself. You'll be shocked to learn the truth. Try it with any alarm system

Automation works differently. If a person has many devices periodic checks can bog down your system. For example, I have over 130 devices in my isy. If the isy were to run periodic checks, how long do you think it would take? What if I'm trying to control something during that time? The delay for something to happen wouldn't be worth it. 

You can write a program to query devices at regular times of it's that important. However a generic query all will hurt more than it helps. This is why the 3am query happens at that time. Less chance of interference

BTW- this is a protocol limitation. Both insteon and zwave devices have the same limitation. Before complaining and blaming someone else, you should at least get to know HOW your products work. 

Edited October 8, 2019 by lilyoyo1

[madcodger]

Well, lilyoyo1, every manufacturer benefits from a fanbase so loyal that the fan thinks they can do no wrong. I feel confident your loyalty is appreciated.

On the other hand, improvement generally happens when enough people say, “Hey, I think there might (should be?) a better way.” I don’t think the current system is ideal, or even terribly reliable, and have noted that. So, we differ. I sold the property with an Elk, so testing personally is not possible at the moment (but I am all but certain you are basically wrong). And the horrible, arduous impact on these systems that you describe is not likely to be as horrible and arduous as you make it seem, which is why systems improve. I just think having a system automatically detect that a wired, powered sensor has disappeared is not unreasonable as an expectation. I sure as heck get enough “cannot communicate” notices about wireless sensors that are, in fact, operating normally. So maybe some improvement in these areas is both possible, and needed.

Sadly, these forums are frequented primarily by the uber-loyal fan, which is why many of us, who like the system but see room for improvement, come here less often. We can’t call out problems without being shouted down. Have a nice day. 

[simplextech]

3 hours ago, madcodger said:

I just think having a system automatically detect that a wired, powered sensor has disappeared is not unreasonable as an expectation. I sure as heck get enough “cannot communicate” notices about wireless sensors that are, in fact, operating normally. So maybe some improvement in these areas is both possible, and needed.

Something to note about this "issue".

1. This is a powered device

2. This is Z-Wave

Powered devices DO NOT send any pings to the controller like a battery powered device.  A powered device is expected to be well, powered and available all of the time.  The historical process with Z-Wave devices was to use polling to determine device status.  This was because of the Lutron patent that prevented widespread use of Instant Status for Z-Wave devices.  Many controllers did implement a polling service or a routine to periodically check for devices that did not provide instant status.  HomeSeer uses polling as does SmartThings and Vera and many other controllers.  This is a legacy thing that coupled with dozens of Z-Wave devices will cripple a system very quickly due to the amount of traffic.  Now we fast forward several years into Z-Wave Plus and the expiration of the Lutron patent.  Many (not all) newer Z-Wave Plus devices support Instant Status.  It's actually rare to find one that doesn't but they do exist and should not be labeled "Plus" but they are.  None the less this Instant Status removed the need for the controller to poll the devices to get their status.

However this polling in the past turned into a "Heartbeat" type use for many and I think yourself included.  It was never intended to be a heartbeat and check if a device was present or alive.  It was a work around for getting status on/off so that the controller would automate the environment correctly.  I have many controllers in use and testing and have used many for my own home.  None of them with polling disabled will "alert" you that a powered device is present or not.  This is always implemented from a user stand point usually through polling or other scripts to periodically poll the device to verify it's alive.  ISY ships with a 3AM program to perform this on a daily basis.  Once you get more than a few dozen devices especially sensors (battery) devices this polling because unbearably slow and no longer has any benefit.

If you are thinking this is a limitation or weakness in the ISY then I think you should check your HomeSeer install and turn off polling and see if it notifies you that the devices is or is not available.  Without polling HS doesn't know anything more than ISY about a powered device until the device sends an update or the controller sends a command.

[madcodger]

Thanks, Simplextech. Very helpful.

 

[lilyoyo1]

4 hours ago, madcodger said:

Well, lilyoyo1, every manufacturer benefits from a fanbase so loyal that the fan thinks they can do no wrong. I feel confident your loyalty is appreciated.

On the other hand, improvement generally happens when enough people say, “Hey, I think there might (should be?) a better way.” I don’t think the current system is ideal, or even terribly reliable, and have noted that. So, we differ. I sold the property with an Elk, so testing personally is not possible at the moment (but I am all but certain you are basically wrong). And the horrible, arduous impact on these systems that you describe is not likely to be as horrible and arduous as you make it seem, which is why systems improve. I just think having a system automatically detect that a wired, powered sensor has disappeared is not unreasonable as an expectation. I sure as heck get enough “cannot communicate” notices about wireless sensors that are, in fact, operating normally. So maybe some improvement in these areas is both possible, and needed.

Sadly, these forums are frequented primarily by the uber-loyal fan, which is why many of us, who like the system but see room for improvement, come here less often. We can’t call out problems without being shouted down. Have a nice day. 

I'm not speaking out of loyalty but experience. As someone who has done over 100 installs, used multiple systems over the years etc. I've researched and learned what works and how. Even now I'm still learning. 

Simply dismissing what a person says because you think they are a fan can prevent you from learning about how things work. Go ahead and purchase a smartthings hub and see what happens when you do the same. Hell set up a query to check all your devices and then try to use a device during that time. You'll see then why it doesn't constantly query. Now imagine a large install. 

Is the isy perfect....no. however no system is. It's pros far outweighs it's cons. When I look at how the isy works, UDI's responsiveness etc. I see a great system. With that said, they can't fix stuff that isn't inherent in a device. 

 In regards to elk, I personally use one myself. While my alarm was unarmed, I disconnected a sensor and lo and behold. No alert. When I tried to arm the sensor I received an alert. This is why I made the statement I did. 

Your system may not be reliable but mine and many others are. Thats why we continue to invest in them. 

[Michel Kohanim]

@lilyoyo1, thank you and well said (regardless of your fan-status).

@madcodger, it's not up to ISY to figure out a sensor has been unplugged. If this is SO important to you, and as @lilyoyo1 suggested, the solution is very simple:

1. Make a query that queries your sensors (making sure you know that you are going to drain its battery)
2. Make a program with Responding condition such as
If

      Control 'My very important sensor' is not responding

Then

     Whatever you think it's important 

 

With kind regards,
Michel

[madcodger]

@Michel Kohanim Thanks for your reply. To a large degree, this goes back to a “user interface”  modest disagreement we have had for years. I really like the ISY and have found it rock solid, recommending it to many people for years (and I just bought my 3rd or 4th one, in the current unit, as I’ve always left them with the previous owner when we sold a house). But unless a person is very tech-saavy, it’s not an exceptionally user-friendly device. That’s not as much of a criticism as it sounds, as the device and company have found a loyal following and if it’s working for you, then that’s all that counts. I think it should be easier to know/understand that you need to build in a periodic query (as an example), but you and others seem fine with the situation as is, so again, the device as it currently stands serves its selected market.

I was shocked to find that a device could be taken offline and still show up as a healthy device hours later, but I now understand why. I don’t love it, but I understand. So, if you folks want to just delete this thread, I’m fine with that. But I think many users don’t understand the whole “query” situation, and could benefit from understanding the implications of it in terms of being able to “trust” a sensor and their ISY, as a lot can happen in 24 hours. But thanks for your advice, and for building a very solid little device.

[lilyoyo1]

28 minutes ago, madcodger said:

@Michel Kohanim Thanks for your reply. To a large degree, this goes back to a “user interface”  modest disagreement we have had for years. I really like the ISY and have found it rock solid, recommending it to many people for years (and I just bought my 3rd or 4th one, in the current unit, as I’ve always left them with the previous owner when we sold a house). But unless a person is very tech-saavy, it’s not an exceptionally user-friendly device. That’s not as much of a criticism as it sounds, as the device and company have found a loyal following and if it’s working for you, then that’s all that counts. I think it should be easier to know/understand that you need to build in a periodic query (as an example), but you and others seem fine with the situation as is, so again, the device as it currently stands serves its selected market.

I was shocked to find that a device could be taken offline and still show up as a healthy device hours later, but I now understand why. I don’t love it, but I understand. So, if you folks want to just delete this thread, I’m fine with that. But I think many users don’t understand the whole “query” situation, and could benefit from understanding the implications of it in terms of being able to “trust” a sensor and their ISY, as a lot can happen in 24 hours. But thanks for your advice, and for building a very solid little device.

I don't think the post should be deleted as it's educational for those looking to learn something. Varying thoughts and debates are a good thing as it gives more than 1 perspective regardless of right/wrong/indifference.

There are merits to both sides and having debates such as this allows others to learn the why's and how to work around to certain problems. As you said, someone may not be tech savvy. The benefits to one is a detriment to another. Since UDI can't please everyone, I think they pick a happy medium by giving a person a way to query a device without bogging down the system unneccessarily. 

[madcodger]

@lilyoyo1 Thanks. Well said.