Insteon Open/Close sensor status

[BGinmobile]

My apologies if this has already been discussed. I have reviewed the forum and could not find this topic. I am using the Insteon Open/Close sensor model 2843-222 to monitor doors and windows. The sensors work great but the problem that I have is getting the status to update following a power cycle to the ISY. Naturally, if the door or window changes position, the status will update, but I need them to update on their own following a loss of power. Performing a query doesn’t return a status as well as re-writing to the device. It was my understanding that when the heartbeat was received that the status would update along with the heartbeat but this does not seem to be the case and subsequently the device in the MobiLinc app never updates to show a Open or close position...only a “-“ symbol indicating status is unknown. Any suggestions on how I can get these sensors to update their actual positions without having to physically change the position of the door or windows? Thanks in advance for anybody’s time and input

[Teken]

When the heart beat is received only that node will be updated. The only way to see the other nodes true state of open / closed is to open / close the window or by pressing the white set button.

 

The only stop gap measure is to place the ISY Series Controller on a UPS during brief power outages. Obviously that doesn't help you when you cycle power manually via soft boot.

 

So your only alternative is to create a Integer Variable that tracks the last state which a program can track to reference the *Last True State*.

 

 

Sent from my iPhone using Tapatalk

Edited October 10, 2017 by Teken

[PhanTomiZ]

Hello,

 

I use a State Variable and trigger my specific programs from this variable instead of the Open/Close Sensor Node.  I asked this question not too long ago.  

 

Here it is:

https://forum.universal-devices.com/topic/22368-openclose-sensor-status-after-power-outage/?hl=%2Bopen+%2Bclose+%2Bsensor+%2Bstatus

 

And if you have the Z-Wave here is a little more info:

 

https://forum.universal-devices.com/topic/22394-z-wave-openclose-sensor-query/?hl=%2Bopen+%2Bclose+%2Bsensor+%2Bstatus

Edited October 10, 2017 by PhanTomiZ

[BGinmobile]

Thanks for the responses. I will use the state variable approach, Although I’m surprised that the open/closed status is not sent along with the heartbeat. I understand that it’s for power saving purposes but in my humble opinion, an automated device is not very “automated” if in some cases it requires physical interaction to get it to indicate correctly.

[Teken]

Thanks for the responses. I will use the state variable approach, Although I’m surprised that the open/closed status is not sent along with the heartbeat. I understand that it’s for power saving purposes but in my humble opinion, an automated device is not very “automated” if in some cases it requires physical interaction to get it to indicate correctly.

 

If this is something you feel strongly about and offers value to the product. Please consider adding your voice to this Formal Insteon Wish List: http://forum.insteon.com/forum/main-category/new-insteon-device-wish-list

 

You will need to sign up with a new account to add the new feature request ~ You have my vote and support! 

[daveslc]

I am just now running into this same problem.  I cannot believe an open/close sensor, for which security is an obvious application, does not have affirmative reporting of its status without manual actuation.  Thankfully, most of my open/close sensors are standard, wired mag switch inputs to an Opto22 PAC-R1 controller that always report the status (and even have a confirming LED on the I/O rack), but I have three places where there is no wiring so my thought was to add these open/close sensors in those locations and have the Opto22 controller read the status from the ISY via REST-API calls...when I got the JSON data, it had value=" ".  Of course, manually actuating the sensor caused it to set value="0" or value="255" accordingly.

 

Same for the SmokeBridge too, Fire and C02 both report value=" "...do I have to have an actual fire before it will report it's value?

 

My ISY (and PAC-R1, and Windows Server) are all on a UPS - but going around to reset these devices every time there's a reboot is a bad workaround for an even worse design. 

 

 

[Teken]

I am just now running into this same problem.  I cannot believe an open/close sensor, for which security is an obvious application, does not have affirmative reporting of its status without manual actuation.  Thankfully, most of my open/close sensors are standard, wired mag switch inputs to an Opto22 PAC-R1 controller that always report the status (and even have a confirming LED on the I/O rack), but I have three places where there is no wiring so my thought was to add these open/close sensors in those locations and have the Opto22 controller read the status from the ISY via REST-API calls...when I got the JSON data, it had value=" ".  Of course, manually actuating the sensor caused it to set value="0" or value="255" accordingly.

 

Same for the SmokeBridge too, Fire and C02 both report value=" "...do I have to have an actual fire before it will report it's value?

 

My ISY (and PAC-R1, and Windows Server) are all on a UPS - but going around to reset these devices every time there's a reboot is a bad workaround for an even worse design. 

 

Insteon or any home automation system is not intended for true security. It can be an added layer that incorporates with a true security alarm system. Insteon does not comply with any UL / cUL burglary alarm standards which there are many.

 

I know its all the rage to integrate with X & Y.

 

Don't . . .

[Techman]

I am just now running into this same problem.  I cannot believe an open/close sensor, for which security is an obvious application, does not have affirmative reporting of its status without manual actuation.  Thankfully, most of my open/close sensors are standard, wired mag switch inputs to an Opto22 PAC-R1 controller that always report the status (and even have a confirming LED on the I/O rack), but I have three places where there is no wiring so my thought was to add these open/close sensors in those locations and have the Opto22 controller read the status from the ISY via REST-API calls...when I got the JSON data, it had value=" ".  Of course, manually actuating the sensor caused it to set value="0" or value="255" accordingly.

 

Same for the SmokeBridge too, Fire and C02 both report value=" "...do I have to have an actual fire before it will report it's value?

 

My ISY (and PAC-R1, and Windows Server) are all on a UPS - but going around to reset these devices every time there's a reboot is a bad workaround for an even worse design. 

All battery operated devices go into sleep mode when not activated to preserve battery life. The open/close sensor sends out a hearbeat signal which could be used to verify communication between the device and the ISY

 

To test the smoke bridge press the TEST button on the smoke alarm, which they reco0mmend you do on a regular basis.

[daveslc]

Well that's not quite true...I'm working on a project currently, where we have battery operated sensors that mount to the discharge of particle size separation equipment (mining industry).  These sensors use XBee chips for wireless transmission and transmit 34 bytes every five seconds.  We get four to six months of battery life before they need to be replaced.  What we are talking about with an open close sensor is less than one byte of "data" ...pack the heartbeat and sensor status all into one transmission, send it every 30 seconds (and of course send it immediately on a state change).  It is simply bad design on their part.

 

There is even less of an excuse for the SmokeBridge - it doesn't use batteries. And while I agree testing, things on a regular basis is a good idea - it shouldn't be required on after reboot.

Edited October 17, 2017 by daveslc

[Teken]

Well that's not quite true...I'm working on a project currently, where we have battery operated sensors that mount to the discharge of particle size separation equipment (mining industry).  These sensors use XBee chips for wireless transmission and transmit 34 bytes every five seconds.  We get four to six months of battery life before they need to be replaced.  What we are talking about with an open close sensor is less than one byte of "data" ...pack the heartbeat and sensor status all into one transmission, send it every 30 seconds (and of course send it immediately on a state change).  It is simply bad design on their part.

 

You're comparing apples to oranges where one is a consumer grade vs commercial grade. Most commercial grade ZigBee sensors also don't cost under $34.99 either. Lastly, in post 5 I encourage anyone who truly cares about the advancement of Insteon products to lend their voice here: http://forum.insteon.com/forum/main-category/new-insteon-device-wish-list

 

I can tell you from personal experience and historic perspective the bulk of the people complaining never do a damn thing to further the cause. One only needs to look at the 2413S PLM Pro *Wish List* idea. As of this writing there are 3553 views yet there are only 51 likes?!?

 

What does that say about the average Insteon user???

 

They don't care . . . 

[lilyoyo1]

I agree with Teken. The open/close sensor was not designed for security and should not be used for such. If a person wants security they should get a security system. Use the proper tools for the job at hand.

 

Just like Teken says, commercial and residential are 2 different beasts. The avg consumer would rip their sensors out if they were changing batteries every 6 months.

[Teken]

There is even less of an excuse for the SmokeBridge - it doesn't use batteries. And while I agree testing, things on a regular basis is a good idea - it shouldn't be required on after reboot.

 

I didn't see your edit until now but what exactly is your concern about the Smoke Bridge? 

[daveslc]

Yes, I won't even mention the price we sell the sensors for LOL (and no, I wouldn't pay that for a home sensor - but they do a lot more than an NC/NO operation). 

 

You are right about the PLM (I did write my wishlist but forgot to "Like" it - I'll go back and do that).  With 46 Insteon dimmers, switches, and keypads (and more to come as I work on the basement), I really don't want them to just "go away."

 

I am rolling my own security system (and HVAC, Irrigation) primarily with Opto22 PAC-R1 controllers, so other than the devices being UL/CE/cUL/CSA rated electrically, the system won't be certified as such as an alarm system - that's okay. Fortunately, this house had an old late 70s/early 80s Honeywell security system in it...so there are wire runs to virtually every door and window except a few in the basement (hence the thought of using the wireless devices - which really go against my grain, one of my mantras for my HA system "if it's not meant to be moved, it's not meant to be wireless")

[daveslc]

The SmokeBridge, like the Open/Close sensors, does not send the current status of the smoke or CO sensors.  It updates the status on a state change, but does not report without a change.  I'm reading these states via REST calls from the Opto22 controllers to the ISY....and it comes back as value=" "

[Teken]

Yes, I won't even mention the price we sell the sensors for LOL (and no, I wouldn't pay that for a home sensor - but they do a lot more than an NC/NO operation). 

 

You are right about the PLM (I did write my wishlist but forgot to "Like" it - I'll go back and do that).  With 46 Insteon dimmers, switches, and keypads (and more to come as I work on the basement), I really don't want them to just "go away."

 

I am rolling my own security system (and HVAC, Irrigation) primarily with Opto22 PAC-R1 controllers, so other than the devices being UL/CE/cUL/CSA rated electrically, the system won't be certified as such as an alarm system - that's okay. Fortunately, this house had an old late 70s/early 80s Honeywell security system in it...so there are wire runs to virtually every door and window except a few in the basement (hence the thought of using the wireless devices - which really go against my grain, one of my mantras for my HA system "if it's not meant to be moved, it's not meant to be wireless")

 

I believe most of us can agree the bulk of us are on this forum and home automation industry because we like to tinker, learn, and make things work. But when life and safety is the primary goal it makes little to no sense in going the DIY route. As you stated the home is already prewired so all you need to do is purchase and install what ever flavor of security alarm system you desire that meets your budget and needs.

 

At some point DIY security alarm projects make little sense when an off the shelf certified piece of hardware is so cheap to buy. When I see, read, hear about people who go the DIY route of security 9 times out of ten these are the same people who also self monitor.

 

That is a recipe for disaster and fail waiting to happen . . .

[Teken]

The SmokeBridge, like the Open/Close sensors, does not send the current status of the smoke or CO sensors.  It updates the status on a state change, but does not report without a change.  I'm reading these states via REST calls from the Opto22 controllers to the ISY....and it comes back as value=" "

 

I would agree if the Insteon Smoke Bridge product was continually improved upon say having a back up battery. Upon power loss the hardware should send out its last known state. Unfortunately there seems to be certain products for what ever reason they are created and left to die in the public domain. I'm not sure why any multi-million dollar company would come up with a product and never try to improve upon it.

 

From reading and talking to some of the developers and engineers of the past it was simply the direction they were told to take. Whether or not the new guy who owns Smartlabs / Insteon will do the same who knows . . .

 

Lastly, it should be made clear the Smoke Bridge was one of the first Home Automation product that enabled a person to make a dumb smoke detector ~ smart. Since its initial release there has been no less than five companies offering similar *Smart Features*.

 

Some are very much Plug & Play and offer basic notification while others offer some incredible features but the price vs value starts to fade. If people take the Smoke Bridge for what it is and that is having the ability to link to their Insteon network to activate their lights during an emergency that purpose has been met and works as intended.

 

Anything else is just gravy . . .

[daveslc]

Probably if I was really concerned about security, I would go with an off-the-shelf system.  But considering I've lived in Salt Lake City for 25+ years and three different houses and never had a security system in any of them - this is more of a tinker project than life or death.  And of course I'm going to self monitor   My house can send me text messages if the fire or security alarm go off.  FWIW...I did not roll-my-own fire alarm....that I am concerned about!

[Teken]

Probably if I was really concerned about security, I would go with an off-the-shelf system.  But considering I've lived in Salt Lake City for 25+ years and three different houses and never had a security system in any of them - this is more of a tinker project than life or death.  And of course I'm going to self monitor   My house can send me text messages if the fire or security alarm go off.  FWIW...I did not roll-my-own fire alarm....that I am concerned about!

 

LOL ~ Everyone needs to weigh out the Risks vs Rewards. 

[daveslc]

Interesting to know a bit about the history of the SmokeBridge...it makes a lot of sense to me, particularly for cell phone notification.

 

What I absolutely despise about most current HA offerings (including things like the Nest smoke alarm) is everything wants to be tied to a web/cloud service - it makes absolutely no sense to me that devices should rely on an internet connection (this is the reason I tossed the Insteon Hub and went to the ISY).  Give me an internet connection and a DDNS entry so my phone can go directly to my house and not be based on some web service. I bought a Honeywell thermostat awhile back that was supposed to support WiFi...it wouldn't connect to local WiFi without a web service account - it subsequently got tossed into the garbage too. 

[Teken]

Interesting to know a bit about the history of the SmokeBridge...it makes a lot of sense to me, particularly for cell phone notification.

 

What I absolutely despise about most current HA offerings (including things like the Nest smoke alarm) is everything wants to be tied to a web/cloud service - it makes absolutely no sense to me that devices should rely on an internet connection (this is the reason I tossed the Insteon Hub and went to the ISY).  Give me an internet connection and a DDNS entry so my phone can go directly to my house and not be based on some web service. I bought a Honeywell thermostat awhile back that was supposed to support WiFi...it wouldn't connect to local WiFi without a web service account - it subsequently got tossed into the garbage too. 

 

You will get no argument from me about *Local First vs Cloud First*.

 

There is a time and place for cloud hosted services and that isn't in the home where you own and use a product daily. Makes zero sense in tying in a product you purchased to someone else's network which you have no control over its uptime, security, and privacy. The only reason *Cloud First* exists is because it caters to the stupid and cheap from companies & consumers.

 

I've said this probably hundreds of times over the years but I can assure you in the not too distant future. The *Cloud* will crumble and those using said cloud will be holding the virtual empty bag.

 

Think Amazon AWS ~ Fail . . . Think hurricane Irma: Texas, Florida, Puerto Rico ~ Fail . . . Think DDOS DNS ~ Fail . . . Think North Korea: 4 major Internet hacking disruptions ~ Fail . . .

[lilyoyo1]

I use the nest protect. I like them. They still work locally if servers are down. While I'd prefer locally based alerts, the ease of use vs server fails Trump's it being cloud based