Jump to content
AT&T to end email-to-text ×

mattc

Members
  • Posts

    8
  • Joined

  • Last visited

mattc's Achievements

Newbie

Newbie (1/6)

1

Reputation

  1. There's actually a temporary workaround that should work until September 2015: chrome://flags/#enable-npapi See: http://homeautomationguru.com/isy994i-google-chrome-java/for more details
  2. Thanks LeeG!
  3. Lee/Michel, I realize this thread is old, but I was writing a post on the leak sensor for my blog (http://homeautomationguru.com/), and went down the rabbit hole on what the "heartbeat" node actually meant. This thread came the closest to explaining what it was and the thought process that went into the implementation, but I wanted to make sure my understanding is correct. As of the 4.0.1 release, the "heartbeat" signal is a "node" in the ISY, but it will NEVER be OFF, right? All that really happens is the device sends an ON signal every 24 hours that an end user can programmatically detect and alert on if another one doesn't come in within the next 24 hours (using the "wait" command in a custom program)? As a programming end user, in a perfect world I'd write a program that alerts me when WET changes to ON (indicating a leak) and when HEARTBEAT changes to OFF (indicating that it's been more than 24 hours since the last heartbeat signal was received and the device is no longer "online"). The current implementation is very similar, but I can't check for OFF on the heartbeat - I have to "start the clock" myself, right? Here's the raw text from my blog post draft going out next week - I'm not asking for any proofreading or anything, but I'm interested in fact-checking before it's officially published: When added the to the ISY-994i, 3 distinct nodes show up: “Dryâ€, “Wetâ€, and “Heartbeatâ€. The first two are pretty much redundant – when the state of “Dry†is “Onâ€, the state of “Wet†is off – and vice-versa. So any program you could write (such as “send me a text message when a leak is detectedâ€) would work with either of them. The “Heartbeat†node is a bit more complicated – as the much-smarter-than-me folks on the Universal Devices Forums have extensively discussed during the implementation phase. The problem (as I perceive it) is that in the past, wireless Insteon devices such as the motion detector or smoke detector bridge sent a signal for “low battery†when the device’s battery was low. This is great because you as an end user can write a program to alert you via email or text message when the battery for these devices gets low. But, what if for some reason one of the following conditions occur: * the battery goes POOF! and dies very quickly, preventing the device from sending a signal that it has a low battery in the first place * the device goes out of range for some reason before the battery dies and it’s able to send the “low battery†signal * power is lost to the dual-band device that’s receiving these RF signals for an extended period * the battery is removed from the device The above reasons are, I believe, why Insteon made this fundamental change from actively sending a "low battery" event to regularly to sending daily "heartbeat" events. Now, instead of the wireless device being responsible for notifying the central controller (ISY) when it’s about to go dead, the Insteon engineering team have shifted that burden to the central controller itself. In other words, I believe the Insteon engineers intended for the ISY “Heartbeat†node to go OFF if a “heartbeat†signal was not received within 24 hours, and stay ON the rest of the time. This would enable end users to write a program that said “if the heartbeat for the leak sensor goes OFF, send me a message to check on the device because the ISY hasn't heard from it in the past day for whatever reasonâ€. Instead, it appears that the current implementation is to simply raise a "control" state for a "heartbeat" message that end users can detect and alert on in their programs using a "wait" statement. This approach makes sense because it would be a paradigm shift for the ISY to set the heartbeat flag to OFF after 24 hours without actually getting an OFF message on the Insteon network. But, this means it's the responsibility of the end user's program to confirm that a heartbeat is received every day rather than the ISY's...
×
×
  • Create New...