smokegrub Posted December 3, 2016 Share Posted December 3, 2016 A few days ago I replaced the batteries in 3 hidden door sensors and an open/close sensor. Devices were placed in linking mode and their performance was assessed. That is, the doors were opened and closed to ensure they were correctly showing their status in an ISY 994i and MobiLinc Pro. I have since left that location and now none of those devices are reporting their status in an ISY 994i IR/Pro or in MobiLinc. Since I am 325 miles from that location troubleshooting is going to be very problematic. Any thoughts as to what might have happened? I am considering asking someone to open a door there and see if the event is reported. Other than that, asking an untrained person to put each device into linking mode is going to be a pain. Link to comment
larryllix Posted December 3, 2016 Share Posted December 3, 2016 (edited) Possibly a power blink with ISY reboot and no door sensors have since reported any status change? Check the last time the program has operated in the summary, or there must be another way to ascertain when ISY last booted up. Do the HDS have a heartbeat? Heartbeat program? Edited December 3, 2016 by larryllix Link to comment
Teken Posted December 3, 2016 Share Posted December 3, 2016 (edited) Ideally you should create a heart beat detection program along with the low battery alert this would tell you if the device was in range and still alive. The low battery threshold can be adjusted for best use case and threshold level you feel comfortable. It's quite unfortunate you seem to be on site to complete these HA tasks only to be blind sided by a few gotchas. ☹️ You can still remote in and craft the programs now however so all is not lost! ========================= The highest calling in life is to serve ones country faithfully - Teach others what can be. Do what is right and not what is popular. Edited December 3, 2016 by Teken Link to comment
smokegrub Posted December 3, 2016 Author Share Posted December 3, 2016 Teken: I have those programs in place. In fact, the open/close sensor just reported a heartbeat. Perhaps I have called for help too soon. I will wait and see what the hidden door sensors do over the next 12 or so hours. Link to comment
larryllix Posted December 3, 2016 Share Posted December 3, 2016 Teken: I have those programs in place. In fact, the open/close sensor just reported a heartbeat. Perhaps I have called for help too soon. I will wait and see what the hidden door sensors do over the next 12 or so hours.If those heartbeat detction programs are in place and haven't reported a failure then your HDSes are functioning as well as you trusted them when you crafted the programs. I think you had a power blink. Link to comment
G W Posted December 3, 2016 Share Posted December 3, 2016 If those heartbeat detction programs are in place and haven't reported a failure then your HDSes are functioning as well as you trusted them when you crafted the programs. I think you had a power blink. You talk funny. I'm Gary Funk and I approved this message. Link to comment
Teken Posted December 3, 2016 Share Posted December 3, 2016 (edited) Teken: I have those programs in place. In fact, the open/close sensor just reported a heartbeat. Perhaps I have called for help too soon. I will wait and see what the hidden door sensors do over the next 12 or so hours.Sounds good, how far is the HDS from the closest dual band hardware device? Also what kind of door (skin) material is being used? Wood, fiberglass, metal? To state the obvious if the door skin is metal expect reduced signaling from the HDS. Edited December 3, 2016 by Teken Link to comment
smokegrub Posted December 3, 2016 Author Share Posted December 3, 2016 The sensors were working perfectly until I replaced the batteries. They failed in unison after first being tested by opening/closing and monitoring their reporting. I will wait a bit, have someone open a door and see what happens. As I noted previously, the open/close sensor has now reported a heartbeat. Link to comment
Teken Posted December 3, 2016 Share Posted December 3, 2016 Sounds good, how far is the HDS from the closest dual band hardware device? Also what kind of door (skin) material is being used? Wood, fiberglass, metal? To state the obvious if the door skin is metal expect reduced signaling from the HDS. The sensors were working perfectly until I replaced the batteries. They failed in unison after first being tested by opening/closing and monitoring their reporting. I will wait a bit, have someone open a door and see what happens. As I noted previously, the open/close sensor has now reported a heartbeat. ?? Link to comment
smokegrub Posted December 4, 2016 Author Share Posted December 4, 2016 Sorry about the false alarm. The door sensors are now reporting correctly. Apparently, they must exceed the programmed time for reporting battery level before they show their on/off status as well. Live and learn. At any rate, thanks for the prompt feedback. Link to comment
Techman Posted December 4, 2016 Share Posted December 4, 2016 Sorry about the false alarm. The door sensors are now reporting correctly. Apparently, they must exceed the programmed time for reporting battery level before they show their on/off status as well. Live and learn. At any rate, thanks for the prompt feedback. The battery signal and the on/off signal are totally independent of one another. It must have been something else. Link to comment
smokegrub Posted December 4, 2016 Author Share Posted December 4, 2016 The battery signal and the on/off signal are totally independent of one another. It must have been something else. A closer examination on my part shows you are correct. I will wait until I can have someone enter and see what happens. This sort of issue is why I feel these devices need some way to be linked and accessed remotely. I know it is a battery issue but perhaps owner programming could be done to permit access during the brief interval when the device is reporting its heartbeat. Link to comment
Techman Posted December 4, 2016 Share Posted December 4, 2016 A closer examination on my part shows you are correct. I will wait until I can have someone enter and see what happens. This sort of issue is why I feel these devices need some way to be linked and accessed remotely. I know it is a battery issue but perhaps owner programming could be done to permit access during the brief interval when the device is reporting its heartbeat. There's no way to program or query a battery operated device remotely. They're always in the sleep mode to preserve battery life. The only other option is to use a magnetic contact switch coupled to an IOLinc Link to comment
smokegrub Posted December 5, 2016 Author Share Posted December 5, 2016 There's no way to program or query a battery operated device remotely. They're always in the sleep mode to preserve battery life. The only other option is to use a magnetic contact switch coupled to an IOLinc Yes, I am aware of that. But, on a specified frequency, the device reports its heartbeat. I would think that at that moment it could be made possible for the device to be designed so that a program could trigger a link. It would cost a bit more, perhaps, and you would use a bit more battery when you linked but you do that anyway when you have to remove these devices, etc. to link. A question for some of you who are accomplished in this field, is this technically possible? Link to comment
larryllix Posted December 5, 2016 Share Posted December 5, 2016 Yes, I am aware of that. But, on a specified frequency, the device reports its heartbeat. I would think that at that moment it could be made possible for the device to be designed so that a program could trigger a link. It would cost a bit more, perhaps, and you would use a bit more battery when you linked but you do that anyway when you have to remove these devices, etc. to link. A question for some of you who are accomplished in this field, is this technically possible?Yes, but the quest lies with SH, probably. I watched SCADA systems protocols grow over the years. The one I worked on started with reporting by exception when asked on a regular basis, and a master All data Poll on a periodic timed basis and/or after a bootup. This idea is very similar to the Insteon protocol idea. Device only report when something changes but the master (ISY) can do a all device query when needed to get back in sync. Years later that protocol evolved so that everytime the remote terminal was polled, any changes to devices were report, the same but each response (even if no change reported) one addition piece of data was added to the response in a Round Robin fashion. After enough polls for changes, everything was updated and always up to date with no massive flood of data coming back. ISY could do this where devices are not battery operated. Let's say ISY detects there are no impending operations and all programs are sleeping (not running or in a Wait line). Now ISY could query one device and update it's database. Next time the next device in the list could be queried. This could be on 5 minute, or setting, basis. The Query All would still be required after power up as ISY knows nothing yet. The Query All at 3:00 AM would become redundant. Several times per day all device statuses would be updated and devices not reporting failing in their reporting may get corrected. Device failures could be detected earlier. Comm problems could be detected before devices are needed. Link to comment
smokegrub Posted December 5, 2016 Author Share Posted December 5, 2016 Thanks, Larry. Such capability would be a tremendous advantage/selling point. Link to comment
smokegrub Posted December 9, 2016 Author Share Posted December 9, 2016 (edited) A neighbor entered the remote location a short time ago and the door sensor reported the entry and now displays as OFF. Seems the status will not be displayed until the sensor is first activated. All is well. Edited December 9, 2016 by smokegrub Link to comment
Recommended Posts