shannong

Right. So when it's Off there is light. The intention is to detect daylight in the morning. The sensor is changing. Today it changed 5 min outside of the From-To so it couldn't evaluate as True. That's simply a matter of adjusting my light sensitivity on my sensor. For now I'm ignoring the use of the luminance. My real question is why doesn't the Or with Sunrise+30min trigger the program?

It was intentional. My preference is for the luminance sensor to decide it's light enough. However, I wanted to manually trigger it based on sunrise in case the status message was lost, , dead battery, sensor quit working, etc. There is an Or. So Then should execute with either one evaluating True. If one evaluates True and it starts running and then the other becomes False during that wait the expression should still evaluate True start over rather than go to Else. BTW. The Summary tab showed that the program didn't execute at all so I now it didn't trigger and get derailed during the 5 min wait. The 5 min is meant to act as a de-bouncer. However, I now remember that the MS has a 3.5 min de-bouncer for luminance built in so it's probably not necessary.

The luminance node of the MS changing state during that period would provide the trigger. But why wouldn't the Or clause of Sunrise+30min not evaluate True and run at 8am?

The program is enabled. The folder has no conditions. Oddly, the program is now evaluating as True and it wasn't earlier.

I revamped my programs that set day/night variables that affect various lighting functions. I have an Insteon Motion Sensor which has a luminance sensor. I use one of those combined with sunrise/sunset. The new program I wrote below never evaluates as True to fire. I don't understand how at least the Sunrise+30min doesn't evaluate to True every morning regardless of the status of the luminance node of the MS. Locally my ISY has sunrise posted as 7:30:30 AM and the time was 9:00 AM when I checked this again this morning to find it didn't run. Arrg! If ( From Sunrise - 1 hour To Sunrise + 1 hour (same day) And Status 'Luminance Sensor' is Off ) Or Time is Sunrise + 30 minutes Then Wait 5 minutes $s.Dark = 0 $s.Dark Init To $s.Dark $i.Dark Init To $s.Dark $i.Dark = $s.Dark Else - No Actions - (To add one, press 'Action')

The Owner's Manual says it "broadcasts its status" in the description for the heartbeat. So I agree with your assumption the Off vs On heartbeat message is the current state of the sensor. So any programs written for the heartbeat would need to watch for both events, much like the leak sensors. When I updated it from 5 min to 21 hrs it sent one more update and went silent. Looks like the mystery is solved about no messages and the Off status. Thanks for your help.

The two sensors that formerly were blank now show as "Off". For some reason, it started sending them at 530pm today and has been sending an '"Off' every 5 minutes since. I'm guessing that the sensor doesn't use the new heartbeat interval until the next scheduled time based on the current setting. It defaults to 21 hours so it waited 21 hours until it started using the new 5 min interval. I'm guessing if I increase it now it will begin using the interval in 5 min.

So does "On" indicate a heartbeat was received? What if anything does "Off" indicate? Two of the sensors have no status, which I would expect since the ISY has never heard from them. The third says "Off".

One of my sensors heartbeat was set to 21 hrs and has been that way for weeks. The heartbeat node has no status (blank) in ISY.

I have three 2845-222 Hidden Door Sensors. I'm running v4.2.16. I removed all three of them and added them back to the ISY so I could gain the Low Battery and Hearbeat nodes. They did appear. I set the Heartbeat interval to 5 min to test it and the programs I was going to write for them. However, none of the sensors have registered a Heartbeat. All On/Off events are seen by the ISY so it's unlikely a comm issue. Also, I pulled one and put it near a dual-band device on the same circuit as the ISY. Nada. I searched the forums and didn't see anyone else complaining about the Heartbeats missing or not working for these sensors. Thoughts?

My main concern was additional opportunities for collisions since the coupler is passing the attenuated signal from one leg to the other while all the dual-band devices are also attempting to transmit the new copies of the message. With the passive coupler connecting both legs I have one wired collision domain and thus half the bandwidth vs two wired collision domains without it. I wasn't expecting a clear black and white answer as there are many things to consider that are difficult to theorize correctly especially since the discussion needs to include behaviors of collisions and retransmits on a real world network. If only there was a protocol analyzer for Insteon. One thing I forgot to mention is that my PLM is NOT connected on the main panel but instead is on a sub-panel. Based on the thoughts and discussions here, I've definitely decided to leave only one SignaLinc in my network. I think it seems to make the most sense to have the sole SignaLinc installed on the sub-panel where the PLM is connected.

Hmm... Interesting thought. Ha. Nah. With the dual-breaker "mini's" available now it's easy to expand if you've got the juice to the panel.

None of those have "diagnostics", the ability to measure signal quality, signal strength or be protocol analyzers. They're actually just statistics about how often a message was received and ACK'd or lost. Very useful. But not quite the same as signal "STRENGTH", quality,measuring noise, etc. They can't provide that. Instead, you infer things about those characteristics based on message reception statistics. But if a message isn't received or ACK'd is it because of weak signal strength or noise that happened to be on the line at that point? No way to know. I've used Homelinc for that purpose in the past as I have a separate USB PLM and spare LampLincs that I can plug into various spots in the house. I might do some methodical testing with that for this current question.

One thing that had occurred to me in pondering this is that if there is a noise/interference on one leg in the frequency range of Insteon signals the phase coupler would be directly transmitting it onto the other leg. However, my dual-band devices that act as repeaters between the two legs would not be doing so. That could potentially be one drawback to the hardwired couplers.

I already have a SignaLinc on all three that have been there from the beginning back when I only had a few devices. Now I have over 130 across all 3 panels with most being dual-band. The problem is there isn't really a way to see how things are different since there aren't any protocol analyzers for Insteon. There were some for X10 which are marginally useful in an Insteon environment from a noise perspective.

Sounds reasonable. But I have about 90 dual-band devices and thus each is an access point as in your scenario. My discussion is about a hardwire phase coupler directly between legs and not access points acting as couplers.

Without disagreement.... Is it actually better since my many dual-band devices on the other leg will be receiving it via RF and then transmit a locally sourced (and thus stronger) signal locally on that leg? Rather than letting the original attenuated signal cross through the Signallinc?

BTW. I took out the Wait and did some more testing today. It worked 100% of the time with approximately 50 attempts whereas before it was only 50% reliable. The only difference and I can identify was my upgrade to 4.2.16. I walked the entire house looking for something that might have been plugged in or On that that has changed and couldn't identify anything. The problem usually was usually noticeable in the evening most since it's gets used most often then. I turned on everything that is normally on in the evening including the upstairs HVAC which isn't on a filter like the downstairs unit, although on a different panel. Dunno. I'm going to leave it operating without the Wait for a while and see if it resurfaces for further testing and root cause analysis.

Greetings. Like many, I started off slowly with my Insteon/ISY installation which has now expanded to about 130 devices of which most are dual-band. I have a main panel and two sub-panels. In the beginning, I purchased the SignaLincs and installed one in each panel to ensure good connectivity across both legs in all three panels. Now that both legs in each panel and as well every room of the house has at least two dual-band devices I'm questioning the value of the SignalLincs. My question isn't so much are they needed but rather do they potentially pose any signal degradation issues of any kind. In other words, would I be better off without hardwired connections on the legs in each panels creating additional traffic on the wire? There are installed on breakers so it's easy enough to disable them but without a protocol analyzer of any kind of available, it's difficult to test in the real world and quantify this objectively. I wouldn't say I have comm issues but I do have the occasional problem of a KPL not correctly updating or not all lights in a scene turning on/off. Thoughts?

I decided against an "auto-close" function for safety purposes. There are rare instances where my motion is limited if I am working on a small item and/or working near the corner of the same wall as the MS where the motion sensor might not fire. Perhaps you should consider two motion sensors to ensure coverage. There's a good chance your auto-close function violates local building codes as well. Most building codes require the laser eyes to be 6 in off the ground which means my car of other item can be in the path of the door but not breaking the laser eyes and I wouldn't want the door to close on it. I've considered installing a separate pair connected to an IOLinc to deal with this but haven't done so yet. You can read about my adventures with garage door programs here. http://forum.universal-devices.com/topic/12693-secondary-garage-door-sensor-and-helpful-programs/

DMP does have an HoneywellAdemco receiver interface module that works with a handful of the Honeywell transmitters of which the 5816 is one. Like most security systems, the Elk needs a wireless receiver attached to use wireless devices including the transmitters made by Elk. My Elk has a Honeywell receiver module attached. The 5816s communicate directly to the Elk with that. My Elk can send emails, texts, etc and can even integrate with some home automation products but I don't use it for that. All alerts, messaging, home automation tasks are done on my ISY using the Elk integration module available for purchase on your ISY. Then ISY can see that state of all zones and outputs on my Elk and even control them. I have some programs on my ISY that will trigger the Elk to close the valve or even open it. For example, I don't let the Elk shutoff the valve when I leave if my dishwasher or washing machine is active. The valve is not shutoff until they finish. However, the Elk handles most situations to operate the valve based on Alarm state and if one of the 5816s is triggered since it's more reliable than Insteon and has a long batter backup.

Mixed bag for me. Good that my issue is resolved. Bad that the Insteon protocol and implementation is designed such that the simple scenario presented here does not function properly without resorting to workarounds and hacks. It's also puzzling how this was an non-issue until now. Thanks so much for your help in understanding the logs, the protocol, and interactions of various components.

Thanks for the deconstruction and notation. Very helpful to understand the logs for future troubleshooting. In the first failed attempt, I see traffic like this associated with the two On devices during the second Scene. Sun 10/05/2014 11:03:43 AM : [ 28 F8 63 1] ST 0 I assume that means the device stated it's level is now zero. Hence the ISY updating the status to be Off. After the first unsuccessful attempt they are shown as Off in ISY though in reality On. The second successful attempt resulted in them turning Off but I don't see any traffic with those addresses. Why not? I discovered in my testing that I can alleviate the problem by adding a one second delay at the beginning of the Then clause. But I'd like to understand the mechanics for future troubleshooting using the logs.

Looking in the log, my second attempt after the first failure started at 11:04:09. The lights were successfully turned off with that attempt. But I don't actually see any 'Off' commands sent to them. ??