larryllix

Does your humidity update regularly?

Nice! Happy programming!

I assume we are discussing the Insteon 2842-222 model. Many of us use the MS units with the 'Off' disabled as it makes it easier to manage time-offs in ISY through decision making logic. This may be set that way in your unit but I can't explain the "off" if you have ever seen one. There is a jumper that sets this preference and if the rightmost jumper is on the two p[ins then the software in ISY options at the bottom of the device page sets that option in software. Note the Linking mode must be set on the MS first. The downside is the MS will never indicate "Off" in the ISY and "status" based logic cannot be used. A peel at your Events in level 3 may be usefull to observe the consistency of how many "hops left" are involved in it's communications. This may give an indication of flakey communications with the PLM.

I tried setting Retries=0 and then I tried setting the MS sleep after detection for 0.5 minutes in order to stop multiple motion triggers with no detectable changes in events recorded for either setting. Next I recorded events with the MS linked to the Switchlinc in a direct link scene. Only one program trigger event happens using this method. It seems the MS sends a different pattern to the ISY in this case and only causes a single event trigger. I am surprised the PLM and the MS don't have a similar link to make the MS act the same as when linked to a Switchlinc. This could avoid a lot of ISY CPU time processing useless repeated signals. This also doesn't happen with the RemoteLinc keypads or X10 keypads. Note: Time lines were removed. Wed 10/01/2014 05:29:46 PM : [iNST-SRX ] 02 50 2D.67.81 00.00.01 C7 11 01 LTONRR (01) Wed 10/01/2014 05:29:46 PM : [std-Group ] 2D.67.81-->Group=1, Max Hops=3, Hops Left=1 Wed 10/01/2014 05:29:46 PM : [D2D EVENT ] Event [2D 67 81 1] [DON] [1] uom=0 prec=-1 Wed 10/01/2014 05:29:46 PM : [ 2D 67 81 1] DON 1 Wed 10/01/2014 05:29:46 PM : [D2D-CMP 0067] CTL [2D 67 81 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Wed 10/01/2014 05:29:46 PM : [D2D-CMP 006F] CTL [2D 67 81 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Wed 10/01/2014 05:29:46 PM : [D2D-CMP 0023] CTL [2D 67 81 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Wed 10/01/2014 05:29:46 PM : [D2D-CMP 007E] CTL [2D 67 81 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Wed 10/01/2014 05:29:46 PM : [D2D EVENT ] Event [29 C3 DB 1] [sT] [255] uom=0 prec=-1 Wed 10/01/2014 05:29:46 PM : [ 29 C3 DB 1] ST 255 Wed 10/01/2014 05:29:46 PM : [D2D EVENT ] Event [2D 67 81 1] [sT] [255] uom=0 prec=-1 Wed 10/01/2014 05:29:46 PM : [ 2D 67 81 1] ST 255 Wed 10/01/2014 05:29:47 PM : [iNST-SRX ] 02 50 2D.67.81 00.00.01 C7 11 01 LTONRR (01) Wed 10/01/2014 05:29:47 PM : [std-Group ] 2D.67.81-->Group=1, Max Hops=3, Hops Left=1 Wed 10/01/2014 05:29:47 PM : [iNST-DUP ] Previous message ignored. Wed 10/01/2014 05:29:48 PM : [iNST-SRX ] 02 50 2D.67.81 2A.1C.95 41 11 01 LTONRR (01) Wed 10/01/2014 05:29:48 PM : [std-Cleanup ] 2D.67.81-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Wed 10/01/2014 05:29:48 PM : [iNST-DUP ] Previous message ignored. Wed 10/01/2014 05:29:49 PM : [iNST-SRX ] 02 50 2D.67.81 11.02.01 C7 06 00 (00) Wed 10/01/2014 05:29:49 PM : [std-Group ] 2D.67.81-->11.02.01, Max Hops=3, Hops Left=1 Wed 10/01/2014 05:29:49 PM : [iNST-INFO ] Previous message ignored. Wed 10/01/2014 05:29:50 PM : [iNST-SRX ] 02 50 2D.67.81 11.02.01 C7 06 00 (00) Wed 10/01/2014 05:29:50 PM : [std-Group ] 2D.67.81-->11.02.01, Max Hops=3, Hops Left=1 Wed 10/01/2014 05:29:50 PM : [iNST-INFO ] Previous message ignored.

I haven't noticed a detectable brightness change from a straight switch to a SwitchLinc at full brightness. Big differences can be noted with many other dimmers and since most don't have any smarter circuitry powered up 24/7 so that is understandable. Other dimmers need to start timing from the waveform zero crossing, charge some capacitor-based variable delay circuit and then fire the Triac ASAP. Smarter dimmer circuits can fire the triac right at the zero crossing and have no waveform rise time missing and thus less switching high-frequency harmonics generated. Easier on the bulb ballasts. I haven't experienced any shorter life with my SwitchLincs and CFL bulbs. OTOH, I populated my new house with all new CFL bulbs and most of them blew within a year the first round . This was all before I had any dimmers. The upside down, potlight, construction was never a good idea for CFL bulbs. The ballast overheated. I had one that lasted a week and the second one from the pair, less than an hour. Most are replaced with LED bulbs now.

Does my Retries=0 file not show that the MS is not sending the commands more than once? I thought it hadn't resent the On and Cleanup a second time? http://forum.universal-devices.com/index.php?app=core&module=attach&section=attach&attach_id=3558

Have you also noticed the 'beep duration' doesn't affect the length of beep? Mine aren't worth beeping as they can't be heard more than 10 feet away (3m) if there is even wind outside.

This was only a test program to understand Insteon congestion vs ISY program decision speed. Normally an Off would not be sent this fast and the On-Off-On-Off sequence would not be seen. My question was about methods to eliminate some of this Insteon traffic for events like MS to lights that don't need to be that secure. The extra transmission ever time 2 seconds later seems like a waste of bandwidth and I have events that take up to 20 seconds to respond at times. That's annoying when a beeper is alerting me to perform a certain device Off scene and it takes that long or never seems to complete. It's real weird to trigger a SwitchLinc and have the first line of a program code function 20 or 30 seconds later. Now I do have an X10 beeper and I had several programs that are all trying to turn off that beeper simultaneously. In view of this delay I have tried a status check program to avoid multiple X10 Off signals but it occasionally thinks the beeper is already off and won't send the Off command. Sometimes the X10 beeper just won't turn off for some reason but it seems that X10 doesn't play well with Insteon on the PLM. It seems X10 transmissions can clobber Insteon and vice versa. I have since incorporated a 2 second delay after every X10 command and sequenced them to make allowances for the clash. This definitely helps things work more reliably. Rethinking some of this, with your inputs, my question is; will linking a MS with a device give an ACK to stop the retry of MS transmission and relieve some of the Insteon congestion?

You could also make the switch beep a few times to teach that snoop a lesson!

You can't stop the SwitchLinc Dimmer from dimming the lights wired to it (locally) but you can insure they don't stay that way long with a program that monitors it.

Thank you LeeG! If I understand this correctly, every Insteon device I have will send two complete sets of status updates unless: - I install one or more scene links in each device to cause another device to ACK the message. or - I set Retries=0 for each possible status that can transmit updates. If this is the case why would the PLM not ACK any message that is received by it as a responder? This sounds like a good way to bog down Insteon communications.

Another thing most of us learn the hard way is to Factory Rest every new device before even attempting to link them into our ISY. These devices come out of the factory with some weird responses that aren't even possible in the manuals.

Sure Write programs that trigger on the dimming and On/Off events and send a Fast On or Fast Off. These commands have no ramping or dimming involved. Their could be slight delay before correction if somebody holds the paddle down too long and a dim selection is actually made. These command signals are the ones the SwitchLinc Dimmer would send if you double tap the paddle. I use all SwitchLinc Dimmers in my system but have never bothered with this but my ISY programs always use Fast On/Off to avoid partial brightness where non-dimmable lamps are involved. If control switchlinc is Fade Up or control switchlinc is On Then set switchlinc to Fast On Else -- Then write one for the reciprocal Off/Fade Down and dimming triggers.

Attempting to reduce some of the background Insteon traffic congestion I set up a test program and used an Insteon MS for a trigger. I found my test lamp turning On-Off-On-Off with each test wave of my hand in front of the MS so figuring the MS needed another factory reset or another one has gone defective I switched to a Remote KeyPad and the multiple trigger problem stopped. Now I brought another MS into the equation to determine if I had a bad MS. The second MS did the same thing On-Off and then repeat. Next I set the retries, in the PLM Communications settings, to 0. Now I get only one test light On-Off as one would expect. I have recorded the traffic in the events(3) logger and saved it for analysis here. I can read some of it but something strikes me as wrong here and I don't have enough decoding skills to understand what it is so would appreciate somebody having a look. - why am I getting two MS On commands and about 2 seconds apart. - does this mean the communications back to the ISY are bad so that it cannot ACK, but I am getting the trigger activating my test program and output responses??? - Are these Insteon MS units displaying bad engineering or defects? I didn't test any of my other two units yet. - Does this seem right? or is there something else going on? Thanks. ISY-Events-Log.v4.2.15_retries=2.txt ISY-Events-Log.v4.2.15__Retries=0.txt

Welcome! This sounds like you have your jumpers in the MS set to send 'Off' commands also. Most of us find that doesn't work well and move the jumper to not send any 'off' commands. The Off cycle is looked after by our ISY program logic. The downside? The MS device will never show off status on it's device page or in Mobilinc etc.. Comment You are using 'status' to trigger your program. Status only triggers when the device state changes. 'Switch' triggers every time motion is sensed and can retrigger timers in the program to start over. This is usually used for lights so they never go off when people keep moving. Now if you disable the 'off' in your MS units and your MS status is always true it will never trigger your program, but 'switches' will. Your 'from time' can trigger it if your $iEnable_Motion_Detectors_Night is 1 though. I doubt this is what you wanted. Perhaps explain what you are trying to accomplish and some of the amazing logic brains here will help you out with things you never thought of. Better yet start a new thread, post your program with your explanation of what you are trying to accomplish so you get the full attention for it.

Yes. I have a few that will not see the light of day or motion for possibly a week at a time. I have adjusted those heartbeat allowances to about a week plus 20%. Hopefully a visit to the room will reset the beast without ISY twiddling from the human infestation. Thanks for looking. As I stated these negative condition triggers break my DeMorgan heart.

When I want different ON durations based on time or other criteria I use another program too. I like to turn the light on immediately and then decide when to turn if off when the human can't detect more on delay. You have have the TimeOfDay program make one decision and use the else to call another program to make a further time slice decision. Program 1 -------------- If automatic trigger Then turn light on call Program 1.TimeOfDay Else -- Program 1.TimeOfDay (disabled OK) ----------------------------- If time is from 8 AM - 6 PM (or room brightness or guests sensor or bathroom break) Then Wait short time Turn lights off Else Wait long time Turn light off

You could try something like this. I find this algorithm works very well. Program 1 -------------- If automatic trigger Then turn light on wait xx minutes turn light off Else -- Program 2 -------------- If Manual switch on And Manual switch is not off (runs else and cancels then timers) Then disable program 1 turn light on wait 2 hours (just in case) call program 2 (else) Else turn light off enable Program 1

Trigger Program = Kitchen Light motion. Kitchen motion is the motion sensor in the kitchen. If Control 'Kitchen motion' is switched On And From Sunrise - 14 minutes To Sunset + 20 minutes and 20 seconds (same day) Then Run Program 'kitchen day light action' (Then Path) Else Run Program 'kitchen night action' (Then Path) Program = Kitchen night action If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Set 'Kitchen lights' On Wait 10 minutes Set 'Kitchen lights' 1 (Beep Duration) Set 'Kitchen lights' 1 (Beep Duration) Set 'Kitchen lights' 2 (Beep Duration) Wait 1 minute Set 'Kitchen lights' 2 (Beep Duration) Set 'Kitchen lights' Off Else - No Actions - (To add one, press 'Action') Have you noticed that your kitchen lights turn on at "Sunset + 20 minutes and 20 seconds (same day)" every night? When the whole If section is false the "else" runs and that calls your Kitchen Night Action (then) program. The "else" clauses have to be propulated very cautiously, especially with multiple condition triggers. If an event happens and any one of them are false (under the logic "and" definition,, else runs. This is a common gottcha' using the time frame conditions. At the "to" time else will run.

In view of the frequent complaints I see here about the Insteon motion sensor, model 2842-222, I devised this program to monitor my MS units a little closer. Hopefully this will work to detect general failures, as well as low batteries, with improved reliability from just detecting the LowBatt signal that seems to get missed by others. I have not experience that yet. I hope the program should be self explanatory. - I have reversed the usual logic for the program name to make it less human confusing for Mobilinc viewing etc. - $MS_Battery_Status is a State variable that triggers notifications, - $cUTILITY_ROOM is one of a set of defined constants for passing room definitions and used by notification above, - The heartbeat style check-in is an easy logic for me but this negative "is not" tests my old logic brain, Anybody foresee problems with this?? Program MudRm MS.OK --------------------------------- If Control 'Mudroom / Motion.MudRm / LowBatt.MudRm' is not switched On Or Control 'Mudroom / Motion.MudRm / LowBatt.MudRm' is switched Off Or Control 'Mudroom / Motion.MudRm' is switched On Or Control 'Mudroom / Motion.MudRm / Dark.MudRm' is switched On Or Control 'Mudroom / Motion.MudRm / Dark.MudRm' is switched Off Then Wait 26 hours Run Program 'MudRm MS.OK' (Else Path) Else Wait 5 minutes $MS_Battery_Status = $cUTILITY_ROOM -------------------- Thanks!

We had many systems run on RF signals in our Electrical Energy Grid stations but the controls had 360 degree feedback from finish back to start so that measures could be taken if the control was not successful. Retries could be done and even right down to a Lineman taking a truck to the remote location and operating the device by hand. This was for manual operations though. Some cross province protection systems are operated by radio signals but always have duplicate or backup systems in place for a second line of defence. Inside a station only hard wiring was used even with a complete comm bus (Ethernet, RS485 or RS232) for information paralleling it.

More research is required but a few years ago there was no video decoding hardware and the first time a new method comes out (that never happens more than every month) the video hardware is obsolete again. It will probably be CPU only for a few more years yet.

Here is a way some use to cancel the whole thing without leaving the light on. If Status Kitchen Light is On And Status Laundry Light is On And Status Bathroom Light is On Then Set Living Room Light On Wait 30 minutes Run This_Program (else) Else Set Living Room Light Off

The first program can still re-initiate the second program's then will redo everything. IMHO this would be better. Use the "one and only one" technique. Program 1 --------------- If trigger event Then Run Program 2 Else --- Program 2 (disabled) -------------- If -- Then Disable Program 1 do stuff..... Enable Program 1 Else --

Have to second that one. SWMBO will not like it when you use the family TV for a monitor to setup the HA. Two RPis would probably be cheaper and you wouldn't listen to a computer fan while watching a quiet movie. I have an Antec case media PC running XBMC. It has two very large and quiet fans running on a slow setting. Video hardware is usually useless for media PC's. Good for 3D rendering but not video decoding. The encoding has always been in such a state of flux that hardware had never supported video decoding methods. Multiple cores never really helped XBMC either. You either watch a movie or run the GUI and access databases with the same core. In the past most experienced users agreed that one 2.0 GHz core was necessary for XBMC to run without any jitters on a Windows system. RPi is breaking this rule somewhat with it's 700MHz core running on a Unix-like OS.