larryllix

You might try uninstalling all remnants of Java and old versions. Reboot the PC and reinstall a fresh d/l version of Java. I believe the Oracle website has cleaners to do this so they may have previously encountered many complaints for the same thing.

We like them a little stiffer Used from the bottom there should be less chance to wander out the side of the drywall cavity. Make sure the attachment points are very secure. They can be really hard to retrieve inside a joist cavity covered in drywall. (closet hole time!) When the Irwin Speedbore gets stuck and you pull back it can come loose easily. http://www.homedepot.com/p/Milwaukee-24-in-Bit-Extension-for-Selfeed-Bits-Auger-Bits-and-Hole-Saws-DISCONTINUED-48-28-4016/100007181 The other way is to get a snap in aftermarket 2x3 electrical box. Cut your hole and drill through your invisible 2x4 from there, using a long extension bit to get the steep angle. Drill your hole up through the bottom 2x4 plate and floor sheeting and then use the "weight on a string" method to dance a weight through both holes from the top. After you get the cable pulled up thread on the receptacle box (tie a knot) and mount it into the drywall hole. Mount your thermostat on the 2x3 box. Some adapter plate may be needed but probably not. You may want to stuff the box with insulation to avoid inside wall draughts affecting the operation.

I assume you have rebooted your computer at some point in there too. I find Java has been acting very strange for the last few months and sometimes that help clear up some of the quirks. Java seems to act up particularly after my computer sleeps. The Admin Console hardly ever works after being left alone for more than 15 minutes. I believe this is mostly some sloppy behaviour introduced in Java in the last 6-8 months. The Java 8 on my Win7 x64 machine seems to behave better most of the time.

You have different ISY firmware for sure. The Java cache and applets needs to be flushed out and the fresh versions of the Admin Console reloaded to match the ISY994i firmware. See the thread on the new firmware announcements (I would link to it but using a new browser and I don't know how to use multiple tabs) In Windows goto the control panel and then select Java and you should see a tab to delete your files and applets, Edit: http://forum.universal-devices.com/topic/14136-release-4215-rc5-is-now-available/ There are links there to install new applets etc.

On the 2444ZTH unit (I have two but no wired units) the humidity reading updates on a clock basis. On batteries it updates every 5 minutes and on PS it updates every 1 minute. Silly to pick a secondary humidity value to do that but it acts like a heartbeat to indicate life. The temperature only updates by exception (on changes outside of the set bandwidth allowance from the last value sent). Temprature is NOT queriable unless the 244ZTH is in linking mode. My older firmware unit can be set from the ISY but the newer firmware unit cannot be set from ISY. Yes Insteon has been having problems or they wouldn't keep getting more 10 year olds to change their firmware. Again my experience only applies to the wireless 2441ZTH units. YMMV

No, Network Module not required. The whole thing is set up inside the WC8 board admin console. The instructions are so poorly written in Chinlish that some of them are just wrong and may be completely opposite of what you need to do. Put your ISY IP in the IP address (first column) (no "http://") Put your ISY rest command and variable access address in the get URL (second column) eg. "/rest/vars/set/2/6/" Put your ISY admin console user name and password encrypted with Hash64 method found online. Silly method but it just works that way. When you encrypt this makes sure the format is exactly as shown. "Joe:MyPassword" Now in your PLC code when you do a "WEBSET URL1 RAM5" the ISY variable will suddenly update to whatever is in RAM5. Keep in mind this WC8 board does not support 1wire devices well. If you use longer cables the board may stall PLC code for chunks of time and sometimes reboot. This means you really can't have an initialisation setup if you mind it being run at random intervals. From what I can gather the WC8 shares memory between the 1wire bit-banger interface, the WEBSET commands and a few other processes. When the 1wire has errors or retries everything suffers. After about 8-9 firmware updates to make a DS2438 sensor work (sheepwalk SWE3) I gave up on humidity sensing. The WC8 designer has since removed support of the DS2438 on the newer versions of firmware for the WC8 board.

Did you delete it in the ISY, factory reset the 2441TH, and then re-find and link it in the ISY?

Insteon devices use a completely different network using radio frequencies and powerline codes to connect with fellow Insteon devices in your home. This "Insteon Network" is not related or dependant on your home network (LAN) or the Internet in any way. However, As LeeG stated above, your LAN (home network) handles the communications between the Admin Console and your ISY box.

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