oberkc

This is how I have done a lot of my devices. In a couple of cases, this is the only way I could get it to work. I sometimes update them, and when I check the neighbors for each device, the logical ones seem recognized.

I had a single switch that exhibited this behavior for a few years. I have several of these same brand and model switches yet only one exhibited this behavior but I never did figure out how to make that annoying (switch otherwise worked) green icon go away. Recently, I replaced the switch for unrelated reasons. No more green icon. Was this a bug in the ISY? A bug in the switch? A faulty or marginal device? Not sure there is enough data to reach any conclusions.

Hobby shops or, possibly, automotive repair would be a source of fiberglass cloth. Combine that with the epoxy you have and you should fall well under $10.

I have used most, if not all, of those brands. I have not noticed much difference between them. If you have already tried a couple and both have failed, I doubt that a different brand will work much better. You might try "welding" it together with acetone or heat. I have also seen glues specific to plastic, but cannot offer any experience.

I used to work in the aviation field, including UAVs and airspace access. It has been a while, though, so I am sure things have changed. One of the things that struck me was that the Civil and Military authorities were trying for "perfection". They seemed to have this idea that, unless we could guarantee with absolute certainty that UAVs would NEVER "scratch paint" with another aircraft, such UAVs would not be allowed into the national airspace. Being as good or better than human operators was not good enough. The authorities seemed to be focused on complete sensor coverage in all directions, having enough range to detect collision courses in time to maneuver the aircraft to avoid the collision, and no reliance on ATC. It all sounds good until one realizes that no such ability currently exists in aircraft of any kind. Sensors on existing aircraft (human eyes, mostly) have a very limited field of view, limited range, and tend to be shut down during major portions of flight. In fact, studies showed that a human could NOT detect an approaching aircraft in time to guarantee avoidance of collisions. Unfortunately, there is no such thing as absolute certainty in this world, so it seemed to me that improvement in aviation safety was potentially limited by this quest for the unattainable perfection. My perception, also, was that the constraints for aircraft in the national airspace was primarily NOT a technology limitation. We have unmanned aircraft landing on aircraft carriers. Soon (if not already) aircraft will perform autonomous Air-to-Air refueling. Landings, takeoffs, turns, and cruising are Childs play by comparison. No...I do not believe autonomous flight to be a technology limitation. The limitating factors for "unpiloted" aircraft is more public acceptance and federal airspace regulations based upon the assumption of a pilot in command on board, along with the quest for perfection IMHO. I did not sense a lot of pushback from pilots who risked losing their job, but I suspect that would also be a factor. I also suspect the same limitations apply to cars and trains.

While I do not suspect this to be the problem, it is easy enough to check…. what happens if you try to include one of the buttons into a scene with anothe insteon device, as a controller? Does the scene work?

Yes, "status" works on mine also. If, however, your logic works better with a "control" condition, try the "add/refresh button press node" trick. It might work for you (it does for me.)

The GE smart switch is z-wave!? I have had zero luck using "switched on" with GE switches. "Status" seems to work for me, but not "switched on". There is one trick that I am aware of: right-click on the switch node and choose "zwave>>add/refresh button press node". Once the node is added, see if this new node triggers your program. I understand that other z-wave devices might work better in this regard.

I have found the same thing in my house

Don't think that you will accomplish your goals with a scene. I understand the quicker nature of scenes, and your desire to take advantage of this, but scenes are between devices and cannot be disabled as far as I know. No. I think you are fighting an uphill battle here.

I think they would be in setting mode when activated, such as by motion.

I don't expect that this will do what you want. In general, Insteon scenes cannot be stopped. Unfortunately, I cannot say with certainty that a mixed (z-wave/insteon) scene cannot be halted, but suspect the same is true as for a fully-insteon scene. Controlling when a device reacts to another device is best, in my estimation, done via programs, without scene relationships. Delete the scene and create a program such as: if time is from sunset to sunrise (next day) and motion sensor is switched on then turn on light wait a little bit turn off light else turn off light There are additional possibilities and sophistication that one can add, depending on needs and interests, but this should get you started.

IIRC, adding a program to Alexa will result in the program executing THEN path when Alexa is told to turn it on, and executing the ELSE path if told to turn it off. No condition is needed.

I am only superficially aware of how all this works together. I am not familiar with many of the details. I would try restarting the node server. After that... Open alexa app, see if errors message with individual devices or indication of problems with the ISY skill

Is your portal account still active and connected to your ISY?

I dont believe that a wait statement will force a re-evaluation of the conditions. However, if a triggering event occurs during a wait statement, further execution will halt, and start at the beginning action based upon whether the new condition being true (runs THEN path) or false (runs ELSE path). in your case, if a triggering event (variable changing value is a triggering event) during the 25 minute wait, further execution will halt and, given that the new condition is now false, will run the ELSE path, which has nothing in it.

I hear such predictions regarding apple homekit. We will see, I guess.

It has been a while since I used "tasker" app for this purpose. Unfortunately, my latest phone does not have any of the tasker profiles I had on previous phones so I am going by memory on all this. IIRC, I think mobilinc had a tasker profile that could be used. Mobilinc also had it's own widgets. I have, unfortunately, lost track of mobilinc capabilities since moving to a subscription service. I used to rely on android tablets throughout the house as home control devices but have gotten away from that for reasons that are increasingly unclear. I used tasker widgets along with mobilinc widgets on those tablets and they worked really well. Maybe there is still something there that can be used. Regardless, I think widgets and tasker plug-ins would be a wonderful addition to UD Mobile.

Confirming MrBill...Changing the "and" to "or", all other statements being unchanged, will result in a different result. At 6am, it will trigger and now run TRUE (ran false before.). At sunrise, it will also now run true (ran false before.) In case it was not mentioned before, control conditions are true ONLY at the moment the device (light sensor, in this case) sends the expected command. At all other times, control conditions are false. Compare that to "status" conditions. Status conditions trigger programs whenever a device changes state (for any reason) and will remain true for as long as that device remains in the stated state (off, in this case).

I think bpwwer provided a robust response. I disagree thate ELSE clauses are universally not useful. the reason you get so may emails is, besides the fact that your program is triggered three times ( 5:21, 6:00, 9:30, all false) is that you also have one-minute waits, followed by a second email. From your program, I expect an email at dusk, dusk + one minute, 6:00, 6:01, 9:30, and 9:31.

I forget the menu structure in 4.x, but I thought is was similar in function to 5.x. You may have to right-click on the individual devices within the scene and restore each from there.

I agree that this is strange and, likely, not as it should be (based upon memory of 4.x). There are only four devcies in the scene. If restoring the scene does not work, it would not be that time-consuming to delete the scene and re-create it.

It is, in my estimation, worth clarifying this...”control” is true only when the switch is manually “controlled”. Furthermore, it is true only at that moment it is triggered and false at all other times. Additionally, control triggers a program only when the specified command (on, off, etc...) is initiated, regardless of previous state. status commands trigger a program whenever the status of a device changes state, regardless of how initiated (manually, as part of a scene or program, etc...), is true only when the new state is the one specified, and will remain true until the state changes.

I am unaware of any real difference between the terms “hub” and “controller” if you have the ISY, you would not need a separate zwave controlloer or hub.

It depends upon which problem you refer. I had always hoped that insteon includes methods for avoiding signal collisions such as those discused here, but experience and suggested solutions suggests otherwise. I expect using a scene would be better for aoiding these signal collisions, yes. However, if your problem is general communication problems, I doubt that using a scene will help much. one advantage to using a scene, all other things being equal, is that all you lights will generally respond at the same time.