larryllix

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.

How would commands for house get to the other house?

KPL buttons and the LEDs behind the buttons are separate Insteon devices. One is a controller and one is a responder.

No Network Module required for ISYLogger to grab variables on a regular clock schedule and log them in CSV format. http://forum.universal-devices.com/topic/7293-isylogger-latest-version-v067/

Only to link to other Insteon modules. The user manual does not address ISY linking. ISY doesn't require that technique.

There is no linking mode needed on newer LampLincs. Pressing the link button may lock it out of co-operating??

You have a PLM manufactured in the 3rd week of 2014 so it may be about the right time for the PS caps to give out. I guess I would try factory resetting the PLM and then use the PLM restore command and let it rebuild all the links. Of course make sure you have a good backup of the whole ISY before doing anything this radical. This may fix the issue (temporarily) or make it better but I think I would order a new PLM as a longer term solution making sure you get a version 2.1 or better. Then I would think about the cap replacement for the old unit as per Brian H posts. if you aren't electronics soldering savy find somebody who is and buy them a case of beer.

I have no Weather Module for ISY but can the values not be stuffed into variables? Maybe in V5? Is so then the variable values can be logged using io_guy's ISYLink to poll them and log them in a format loadable into Excel.

Yes, true. I have forgotten about those ones coming out. Unfortunately I would require a BT access point from my WiFi to access them, as a bridge/hub to work with HA. . I have an old DLink? BT access point, from years back, but since it never became popular to do things that way, and was never supported with software it became expensive garbage.

AFAIK all smart bulbs require a hub. OTOH IIRC there was a bulb that came out recently that connects Wi-Fi directly. You can overflow your protocol with more than 32 devices on a Wi-Fi network, so I have been told, where the overhead in the protocol swamps the actual data, so Wi-Fi for HA may not be a good thing. I have four Hues, require a hub and the ISY network module can talk to the hub just fine. No feedback though. Hues have a great interface but colours are lacking. Whites are colour temperature adjustable but low brilliance. RGBW are reported to be somewhat better. I have three MiLight bulbs and five MiLight RGBWW strips and the ISY network module can talk to the two hubs (4 unit addresses per hub) just fine. MiLight bulbs and RGBWW strips have really nice and rich colour, single white, a sloppy protocol interface, very cheap, and do not report status either. When you install smart bulbs how will you turn them on? How will your wife and kids turn them on? Guests? ISY can do it well mixed with Insteon modules/bulbs but you still need a piece of hardware on the wall or MSes etc.. My PLM is on a special short circuit right beside my main panel for powerline signal spread. It is the centre of your house wiring.

Which UDI model do you have?

HA systems run on the last change of status sent by devices. That is all they know. ISY will only reflect the last thing it has been told by the MS. If the device is new, or ISY has just rebooted, the field will be shown blank (as an indicator) as ISY cannot know the information. You cannot query Insteon battery operated devices without putting them into linking mode first. This is a battery saving thing. Also they do not repeat messages in the usual multiple hop style of the protocol for the same reasonl.