larryllix

As previously noted the Tag manager seems to have to check in with the cloud service to do local notifications???? sux! Price? Christmas present but I have noted the prices has jumped massively in the last year or so. CAO seems to be the only ones selling them, even if Google shows SH selling them. There may have been some marketing path flop there.

95% of these problems are solved with a vacuum cleaner to clean the filters at the bottom where the frost free drip pan and cooling coils are found. This happens to commercial A/C also. Block the air, the humidity builds up on everything. The CAO Tags are awesome and so easy to use.. Here is my two tags reported on one chart. IIRC the sample time was every 15 minutes. Also ISY is aware of their temperature, humidity, X, Y, Z angles, movement, and battery level to 0.001 volts. I put one in a sealed cookie tin box about 30 feet from the manager and could not simulate signal lost condition. The signal went to -99 dBm but still has a lot of headroom to be reliable. The power strength and all parameters are adjustable. The Pro version keeps thousands of samples that "catch-up" should the comms be lost temporarily and is accurate to 0.4C. All parameters are calibratable if desired,

As jon posted above use the Restore command on the device. Right click on the device in the device tree in the Admin Console and select restore from the fall down menu. No need to Factory restore it to do this but I would anyway.... after much advise and bad times I always do a Factory restore on any device I bring home before adding to ISY. You can do a Factory Restore on a device any time and then do a Restore from the Admin Console and it will repair and replace ll the links that ISY knows about. In the future it is best to let the Admin Console manage all the links used by creating them there.

If and once the ISY looping linking mode gives up you can put one devuce in linking mode and do a restore. This will start the linking loop once again but one less device will be included to fix. The loop will get shorter and faster and your chance of success at catching a device in the loop atvthe same time it is in linking mode gets bettet with each success in a reverse exponential loop time.

With about fifteen battery operated devices, when I swapped my PLM I found ISY just locked me right out. The process was so busy trying to link to battery devices not much worked in the admin console. When I click on a device or another page it would take 5-10 minutes to display the page. If I clicked on multiple pages in desperation it hung it up for 30 minutes at a time. After my 12-14 hours of frustration (over night too) I concluded that battery devices are the problem with the UDI algorithm. If I had about 20 battery devices or more my ISY would have been hung permanently and never recovered without a reset. Linking a battery device was a painful process as you had to guess when the linking process for that device came around on the ISY list of unlinked devices it tried infinitum. Mostly the linking time on the battery devices times out and you had to wait for about 15 minutes for ISY to come around again. The ISY algorithm to change a PLM needs some work to not cause this user lockout. One try for each battery operated device should be the maximum number of tries with a message that they have to be linked manually by the user. As a work-around all battery devices need to be disabled before attempting the PLM swap. After ISY settles down and user response is resumes each device can be linked manually one at a time. http://forum.universal-devices.com/topic/17473-replace-plm/

Did you delete the Admin Console applet along with the java cache/file clearing? I always move my installed Admin Console applet to another directory on my desktop. When the java cache is cleared, with all three checkboxes filled, it doesn't delete the moved applet as it doesn't know where it has gone. I figure the applet must have some specific setup information inside, or associated with it, from the bad installation and it needs to be deleted also so that a fresh initialisation will be done and possibly work correctly this time.

I had some problems with this java version also. The system with the problems is Win 10 x32. I had programs missing at random throughout the admin console. Other programs linking to the missing ones showed the <undefined> text in the program lines. I almost started patching programs to make things work but the job would have been massive and taken months to patch together. I went to another PC Win 10 x64 and ran admin console...everything was still there so I knew ISY was OK....backed up again. ...back to the Netbook x32, I did the 'java delete everything' one more time, and after finally reloading the Admin Console java file everything loaded fine again. I have to conclude some admin console setup is based on the java version and wouldn't run with the java upgrade. So much for package independence and standard hooks!

The point was about calling lines of code that are not conditions and only triggers. These are lines containing 'switched'. They always test false. Your programs, being called, are all status conditions. Those test True or false depending on the state.

I think you missed that point. It doesn't matter if the program is called from another program. 'switched' triggers never present a true result from a conditional test. My guess would be the ISY engine doesn't even run those lines of code to test them. The program can not function.

The search phrase should have been "silicone clips" Careful of the prices as they vary greatly. You will need a box of #4 or #5 screws with the largest head you can find or a washer http://www.ebay.com/sch/sis.html?_nkw=100pc+Silicon+Clip+F+Fixing+10mm+3528+5050+5630+RGB+Single+Color+LED+Strip+Light&_id=251517403010&&_trksid=p2057872.m2749.l2658

I doubt determining a difference between a dotting squirrel hauling his nuts and human things is not possible with an MS not focused to eliminate certain motion levels. Security MS units have pet, blinding techniques to not see below a certain vertical level.

The second program will never test True. Notifications will never be sent while the program is disabled, Switched triggers can be enabled and trigger from signals, but not tested for, as conditions. They always test false in the ISY logic engine, and will always run the Else section.

Thanks oberkc.! That is what I had in mind but missed the If section copy over. A simple Wait 1 minute before the program enable would delay the "watching" for the second event but this may introduce retrigger problems. IMHO, This is going to take three programs. - a trigger program, - a lock out the trigger program (for one, and only one, logic), also enables second trigger detection program, - a second trigger detection program.

Your Else section does nothing. Repeat is a construct that is found before the program lines to be repeated....like this Repeat Every 12 hours do something do something more do anything <----nothing can execute after an infinitely running loop ---------------------------------------------- For the second motion detection I would do tt with two programs. The first one would be the control program that sets the timing and enables a second program that can detect a second motion operation as well as sends the notifications. Motion Emails - [iD 000B][Parent 0001] If From 11:00:00PM To Sunrise (next day) And ( Control 'Motion Driveway - Sensor' is switched On Or Control 'Motion Patio - Sensor' is switched On Or Control 'Motion Front - Sensor' is switched On ) Then Enable program 'Motion Notify' <-----allow notifications on motion detection Wait 1 minute <----- your MS has t have the all motion option enabled Disable program 'Motion Notify' <-----time frame over Else Disable program 'Motion Notify' <--- necessary for Sunrise (next day) which could interrupt Wait 1 min Motion Notify (disabled) If Then Send Notification to 'xxxxxxx@gmail.com' Else ----- Now this setup may notify you several times if motion ceases for over a minute so a further disable of program 1 may become necessary. At the moment this appears to require three programs. Some logical thinking may make two programs possible.

Get the Waterproof units for $2 more. You can't even wipe the accumulated grease and dust off the non-waterproof units. They are an exposed PCB. This guy has almost everything. The last IP67 strips are encased ina silicone tube. The double sided tape on the back of some does NOT work. First time they get warm they all fall off. Get the two screw silicone clamps, about $4 per 100. http://stores.ebay.com/joydeal/_i.html?_dmd=2&_nkw=5050 WARNING: Do not buy the solderless slip in 5 pin flat connectors! They are the wrong spacing for these RGBWW strips. The guys knows it and just repeats the complaint. However he did give me a credit for a RGBWW strip that had a bad section. I told him I wanted 2m replaced and he just shoved me a prorated sum.

Trying to recreate and guess what has operated a scene is not a reliable way to do this. Other devices could operate the same devices to the levels and trigger your detection program falsely. One technique I use is to capture all the command combinations and set a state variable to different values like this. If SwitchLinc is switched 'FastON' Then $sVariable = $cLEVEL.FULLON (permanently contains XX value) If SwitchLinc is switched 'ON' Then $sVariable = $cLEVEL.ON (permanently contains YY value) If SwitchLinc is switched 'Dim'' Then $sVariable = $cLEVEL.DIM (permanently contains ZZ value) Then I use a bank of programs to detect these levels and operate scenes, Hue bulbs, and RGBWW strips etc. If $sVariable = $cLEVEL.DIM Then set sceneXXX on if $sVariable = $cLEVEL.ON Then set sceneYYY on run Resource 'Turn Hues on Red' etc.... Advantages? - any program can look at the level of settings by examining $sVariable - any program can borrow a light in the scenes (make bright to work on that side of the room) and then restore it by shoving the value back in the variable when you are done. - multiple programs can trigger from the same $sVariable. The initiate logic can alternate from scene from the same button push style. Here's one to alternate two levels of lighting from each tap on the switch. If SwichLinc is switched 'FastOn' AND $sVariable = $cLEVEL.FASTON Then $sVariable = $cLEVEL.TVMODE Else $sVariable = $cLEVEL.FASTON Making sense?

Maybe I have missed something here but you don't need to know when a scene has operated, only when the devices that could operate a scene have commanded it to operate. This may mean duplicating some logic done in programs, from controlling source devices, but the logic is already done or can be cloned for a more modular programming style.

I like to have all my Rest command inputs control variables only. Then I can do logic easier and control things from there. It is more apparent, when reading programs, not to have them operated by an invisible trigger. The same thing would apply to a scene. Hidden is always bad programming form. Months or years later how will you know what operates the method and where is the documentation to tell you? Since scenes can contain no logic it's very easy to clone the trigger device input in programs as many times as needed,

You talk like an electrician. They always use the name of a popular fuse company for the phrase "neutral bus" This is very common in the trade and always gives me a giggle how it developed.

I don't think I want to open the "glow in the dark balls" discussion.

After the second time it happens, just replace the PLM. I have never had an All On/Off event but ordered a new one. Then the question comes what to do. If you do not install the new one you could find out it is bad a year down the road when you need it, or worse after the warranty is over. Switch to the new one and keep my old one as a backup. They bot are tested now. In your case I would rebuild it replacing the caps, as per Brian H. Then I would switch them back after a month or two. Now you will have two tested PLM's you can rely on.

My latest two Leak sensors send Wet On or Wet Off (may have been Dry On, or both) depending on how long you hold the button.

ISY has never been aware that an All On has happened. This should mean that ISY doesn't issue the problem. The feeling is that Insteon signal get confused somewhere and get interpreted as this All On signal in the RF, PLM, or PLM interface to ISY. ISY to Elk, ISY and Elk communications have proven very reliable.

In V5 there is no "control" as the word has been removed. We will all have to start using the verbs "switched" and "status" to be compatible with pre and post v5.

I was more attempting to resolve the crossover complaint by asking questions in order to understand how it could happen in the first place and help the OP's awareness, and mine. If the mechanism is known there should be an apparent resolution to it. It sounds like it is but would sacrifice some other shared features that may be wanted.