Jump to content

daveslc

Members
  • Posts

    7
  • Joined

  • Last visited

daveslc's Achievements

Newbie

Newbie (1/6)

0

Reputation

  1. 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.
  2. 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!
  3. 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=" "
  4. 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")
  5. 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.
  6. 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.
×
×
  • Create New...