paulbates

Hi SK As written, it will only execute once. The From/To construct is designed to be used with other logic in the if, example adding this: And Garage light is switched on. That would cause the program to only run in the time boundaries when the garage light is turned on Paul

Yeh that's the downside... the guidance from the link is simple but rooting through programs can be problematic. Also, one last one... if multiple programs kick off from the same event (if .... then)... (or at the same time for other reasons), and those programs control insteon devices.. same effect. Its common for all roads to lead to wireless sensors,, open close and particularly motion sensors. Motions are problematic because, depending how they are configured, they continue to send commands as people/pets move around and motion is sensed in an area. If they are "control" in programs, and those programs control insteon lights, insteon commands and acknowledgements are sent again, and again. Paul

You're welcome, I hope you get it figured out. FWIW its worth I do have programs using control in the IF, where the device referenced is a controller, but there is at least 5 seconds before any insteon comand is sent. Also, creating scenes and using them in programs to control multiple devices is generally preferred over back to back set device on/off commands in ISY programs... both aesthetically and operationally. Back to back insteon commands in ISY programs can also cause collisions Paul

There is this guidance on preventative measures for this problem https://wiki.universal-devices.com/index.php?title=INSTEON_Random_All_On_Events Paul

They would probably need to be nearby too. To the day job point, what happens if it breaks? Also, 4 and 5 are vaporous requirements. What really needs to get done there? Network resources are one-way, outbound... so specific capabilities of the related components and already having skills would be important... or would be some trial and error to get it to work... or maybe not possible after x hours of trying Paul

A suggestion is to disable those programs and see if the problem goes away. Its more than coincidental that its happening at exactly the same time Paul

Ok. If I'm reading the log right, the source for the ons is a program or programs.. log column second from the right. Are there other programs associated with that lamp? Paul

Glad you're working! Ugh. My guess is whoever picked looked and thought, "that'll do". The branding messaging on these is confusing and frustrating Paul

It’d be more like security cameras and ddos attacks a few years ago; a security model is not in the $5 product’s development budget. Some kind of OS is in there, what was involved in securing it?

Sometimes after a lot of time, or brownout/blackouts, Insteon modules lose their settings. I suggest right-click on the device in the admin console and picking "Restore Device". If that doesn't do it, factory reset the device, then Restore Device Paul

To follow up liliyoyo, its happening right here: Plug the device in and hold power button for 5 seconds to put it the mode that allows it to be seen by the app Select the device type on the app (plug) Enter WiFi SSID and password into the app Many appliances work this way, my Venstar remote sensors have the same technique. Pressing the power button resets it and it advertises a specific SSID for Wifi Direct. Its not in the list of steps, but you likely had to pick the device's SSID from a list of access points on your phone that include your home SSID. The app connects directly to the device, one time via WiFi Direct. When you enter your wifi SSID and password into the app, it programs it into the device. The device restarts and from that point it on it authenticates to your WiFi with the credentials you gave it. Anything connected to your LAN that has the API can talk to it It can see anything on your LAN Paul

I remember status being difficult to get to work without a lot of attention and I could get Switched to work consistently. I wanted notification of an event regardless of duration. Fortunately the only time it had to work was periodic testing and I think one kitchen problem that we were home for Paul

Status will look at the sensor status and if its on, the program will execute. Scenarios You are checking status, the status is on in the smoke bridge, and the FA does not have an alert status --- ISY thinks an alarm is raised You are checking Control, the status is on in the smoke bridge, and FA does not have an alert status - --- ISY does not thing there is an alarm You are checking Control, the status is on in the smoke bridge, and FA triggers and alarm- ---ISY believes that there is an alarm The repeat statements needs to be on top of the other statements not under them. However, I'm not sure if the smoke bridge "switches off" when the FA is done in alarm mode. I would skip that part for now Paul

They advertise that this hardwired detector works with the smoke bridge. I only had 3 of the wireless so I've not tried it. The product page is a little vague.. It does get wired in... but it is also considered wireless as it has to be linked (wirelessly) to the other FA sensors / smoke bridge to participate with them. The picture is deceptive too, there shouldn't be a battery door. Its a little quirky and a few things to know based on my experience... meaning don't shoot the messenger: My programs' If statements always used Control (If xxxx is Switched On) instead of Status. The removes worrying about status... if a FA raises one of the items, it will trigger the program regardless of the smoke bridge status value. I believe you have to query each smoke bridge node that's on from the ISY to get it to show a status of off. You can do that manually from the admin console or write a program. As discussed above, I changed my programs' If statements to use Control and didn't worry about the status of the smoke bridge sensors If you have multiple FA smoke/co sensors The smoke bridge only tells the ISY that a Fire or Smoke instance was raised, but not which one... Fortunately the FA sensors talk to each other and you will hear which sensor raised the alarm vocally. But if you are looking to be told remotely outside of the house which sensor raised an alarm, you can't do that with the smoke bridge The smoke bridge only returns battery status for the unit you link to it, the ISY can't tell you about the others. Its been a number of years, but I believe that the battery alert voice messages only come from individual first alerts, not voice broadcast across all of them like smoke and co alerts Paul

Np. The program re-triggering and switched vs status took me some getting used to. You're definitely on the right track. Paul

Hi Its working as designed, if you are checking status. Its hard to tell, however something is wrong here, this line isn't possible with the ISY editor And Status 'Outside / House Front (load)' is switched Off Its either status or control... status and switched can't be in the same program line. Assuming the program is using status, the reason its flashing is that your program is checking the status of the light, and the "then" part turns the same light on and off. As soon as that happens, the "If" is reevaluated the "else" becomes true and the light goes off... and it starts over. This will need to be split into several programs.The best way is to move the contents of the "then" into another program and use the program statement to run it. The second program doesn't have any conditions to become false like the light status, and will run until its done. Get rid of the off statement in the else, its not going to work. Also, I believe one of the triggering conditions is the garage door going up which is sensed by the sensor being switched off... that's how mine works with this kit. Garage Door/Outside Lights If 'Garage / Garage Sensor' is Switched Off And Status 'Outside / House Front (load)' is Off And From Sunset To Sunrise (next day) Then Run Program 'Outside Lights' Else No Actions Outside lights If No Conditions Then Set 'Outside / House Front (load)' On Wait 15 minutes Set 'Outside / House Front (load)' Off Else No Actions I'd start with this but I could be wrong about some assumptions I've made Paul

You need this model

Maybe one of these works: 1- define and save the address in the finder and use that. The Admin Console should attempt to use tcp/ip to find the ISY at the predefined IP address when it’s on the wrong interface and you click on the predefined entry saved in the finder. You might have 2 entries sometimes when the computer is on the on the right subnet and ‘discovers’ the ISY. Inconsistent still, but maybe it will work. 2- can you bind an app on the pc to a specific interface? If the admin console can be bound to the interface for the network the ISY is on, that should do it. Paul

It’s similar, but not identical to, wake on lan or subnet directed broadcast... and the initial discover request to the ISY being limited to the subnet the computer is connected to. in your case, the laptop is very likely on the subnet the ISY is on, and the pc is not consistently broadcasting down the interface that the ISY is on. The router does not recognize the discover packet and drops it... that is the problem. There may be a way to solve it, but I don’t know what it is.

VLANs or wireless networks with distributed wireless nodes with dhcp can have the same effect. The discovery packet is not IP, so IP routers will drop it and the ISY never gets the message.

VLANs can have the same effect. The discovery packet is not IP, so IP routers will drop it.

The purpose of the finder is to locate the ISY by a non IP ethernet frame using a very standard method. For this feature to work, the ISY and the PC using the admin console have to be on the same subnet eg 192.168.0.x. The finder sends the magix , the ISY on the same subnet should see it and respond. If that's not happening, something's not right network wise. If I access the ISY from the outside of my house, I run into needing to manually enter its address in the finder and save it. A couple of things to do: An appliance type device like the ISY should always maintain the same IP address. You can set a static IP address in the ISY under the admin console / configuration. Or... most routers allow you too assign IP addresses to specific devices via DHCP, so they always have the same. I suggest you do the router method, as you have an existing network of IP addresses and there's a change you could pick one that's taken... had to remedy that if it happens You shouldn't have to, but you can save the address of the ISY in the finder. If you set the address (first bullet above), and a blank finder window pops up and you enter the manual address... press the save button right away. Brian's suggestion above, to use the launcher... it pauses when it first comes up making it easier to enter and save your address the first time To your point, its odd that this is happening. If the ISY and pc are on the same subnet, it should not happen, its using a very basic ethernet feature. Paul

If I understand correctly, there are 2 approaches but I think only one will work Make each participant a controller in the scene. I don't think this will work All have to be controller capable... not all older plug in modules are (doesn't look like you have any) Complicated by plug in modules where whatever's plugged in gets physically turned off (again, only if plug in modules were added in the future) A device can only be a controller in one scene.. not workable if devices are shared across the different groups you have Turning any device on turns them all on In summary... its an approach but I don't see it working the way you want, unless there are other ideas suggested Write programs for each group: If DR Pen BF Foyer is switched on or DR Pendant - BF - Din is switched on or ..... (add all the rest of the partcipants) Then Set <keypad key> on This will likely do what you want, again if i understand the requirement. You can also write an additional program that uses Status instead of Switched/Control, also use AND instead of OR for each participant.... it would catch all participants being turned off and turn the keypad key off Paul

Its a warning message, not necessarily a problem. To @jec6613 's point, it shouldn't be a problem if your BD router and internal network devices are safe and properly secured. Two choices: Go into the Admin Console and disable port 80 / http: on the ISY and the warning will go away.... but, as pointed out.. it puts a load on the ISY slowing everything down. Opening the admin console will take a long time and it will operate slowly. For grins and giggles, last year I tried running my V5 nodeservers on SSL inside of my LAN. I got sluggish performance and performance/time out warnings from my nodeservers. I reverted to http port 80 for internal communications. Ignore the warning and be sure not route anything outside of your house on port 80. Route as little a possible outside of your house at all, even on https: port 443. I have zero ports open to the outside and use the ISY Portal for access. Paul

UDI is coming out with a device in the fall, Polisy, that will provide a device ready-to-go as the nodeserver host.. I’d think about that. Paul