oberkc

"What is the reason for this?" I might do that from time-to-time if I were using the TRUE or FALSE status of that program as a condition of another program. For example, if I wanted a program to be true only while executing a THEN clause, then turn false immediate after completion of the THEN clause. Then I could use the status of that program to know whether it was currently executing.

Xathros...do you have any experience changing properties of a scene specifically including a battery powered device? I was wondering if the motion sensor need be put into linking mode for the changes to take effect.

The only difference that I understand between direct linked devices and those created by the ISY would be the presence of the PLM in the device link records. If you have a device that was otherwise added to the ISY, I cannot imagine why a scene that was later created directly would be any faster. If you noticea difference in scene responses, I would dig a little deeper into that problem. Something strange is going on here beyond the scene creation mechanics, in my estimation. Like the others, I find it bad practice to have scenes created outside the ISY.

What is a "direct linked scene"? Are you creating scenes directly from the devices, themselves? For the ISY to work best, all scenes should be created through the ISY. I expect xathros suggestion to be doable, but until we see your programs and scenes, generalities are all we have to discuss.

The options can be a bit broader than this, but if you have a program condition who's status will be changed by the program execution, then, yes, it is often best and easiest to break these into two programs. If your execution has no WAIT statements or REPEATs, then it matters less to break them into two programs.

That is, in the end, how I see it as well. I remain very satisfied with my insteon house. The continued introduction of new-and-improved insteon devices makes me think that things are working out for smarthome. I have no intention of wholesale changes to z-wave, but if I see a z-wave device on a clearance table somewhere, it is nice being able to take advantage of that savings. Other than that, it will be insteon for me.

You are correct. If an IF condition changes during a WAIT or REPEAT state during execution, the program will be halted, condition reevaluated, and program executed based upon the new condition. Please note that you have two conditions. The second condtion (Front Entry Light is OFF) is changed immediately when the program executes. Since your program has a WAIT statement, the program will halt because the IF condition has now changed (Front Entry Light is now ON). For reasons that are probably a simple preference, I tend to program such things without variables when possible (nearly always). If control front door sensor is turned ON and status front door light is OFF then run second program (then path) second program: if nothing then turn on front door light wait 5 minutes turn off front door light I can see no reason why your second program is less reliable in turning on the light. The conditions are near-identical.

There is another sole-source provider that seems to be doing well. Named after a fruit beginning with the letter "A".

OK. I understand having scenes with buttons as responders for the purpose of initiating via program. Yes, this works as you know. I was attempting (poorly I guess) to point out that if a given device is both controller of one scene and responder of another, when that button responds to one scene, it will NOT act as controller for another. Devices behave as controller only when they re acted upon directly.

And, never mind any of the sensors or electronics.

It sounds to me as if you are doing things properly. Clearly, the communication error is a concern, however. Many of the inconsistencies you describe are also consistent with communication issues. Still, I am reminded of my experience the other day. I became aware that I had failed to rename and organize a couple of devices I had swapped around, and lost track of which device was which. Do make sure you are confident in the devices you are programming. If you are confident in devices, my suggestion is to solve the communication problems before doing any more scene creation or adjustments.

clearly, based upon the tag, one would not want to connect it to a voltage other than 120V. Definitely not something to put on a dimmer.

Check the load ratings for the various devices. I think you will find that dimmers cannot be used for much more than incandescent lighting. Some may now say useable with LED lighting. Most inductive loads such as a dehumidifier cannot be used with a dimmer. A relay device....well....that would be a different answer. You could control your dehumidifier with a relay device. Yes.

Agree. Linking and creation of basic scenes can be learned by most pretty quickly.

I believe most people will be able to learn to use it, regardless of computer programming background. Ironically, the ones who have computer background and assume that the ISY statements and programming are identical to background are some of the ones who seem to have the most trouble. While there are some that complain it is too hard for the average person, my conclusion is that such complaints are more about the time that it takes to learn, rather than not having enough brain power. Yes, it will take more than a few minute or an hour to set up. Yes, it is more complicated than setting the time on a VCR. Yes, it can take time to become proficient. If, however, you have a few hours for a few evenings, I expect you will be fine.

Green is good. I believe it also good to check the opposite direction. Initiate the test from the first floor lamplinc and see if your PLM shows green. The KPLs and IOLinc may not be dual-band, so no indication expected.

I suspect you will find this not to be true. Having your keypad as a responder in one scene and controller in another is fine. Responding to one scene will not cause the scene in which is controller to trigger.

No need to guess. Furthermore, even if you correctly identify the legs of you electrical system and confirm devices on both, how do you know they are communicating prerly to perform this function. Better is to break out the manuals for your devices and look for instructions on performing the phase bridging test. This will give you a positive confirmation (or not). As far as I know, it is the only way to have near certainty that your devices are communicating across legs of your electrical system.

Sure sounds like some type of interference to me. Hopefully, it won't come back. Were this me, I would be trying to identify the cause and eliminating.

I used the insteon morninglinc with the matching lock set. I now have a z-wave lock. I prefer how my z-wave lock, unlike the morning lock, sends out status changes. I also find the z-wave lock to respond more reliably (near 100%).

very odd. I wonder if, during the two-second ramping, that the dimmed load was causing some type of interference. If you are up for an experiment, you could temporarily remove the loads, re-apply the 2-second ramp rate, and see if the problem remains gone.

It works because when a device is in a scene as a "controller", it is, by definition, also a responder to any other controller in that scene. When you have two devices as controllers in a scene, each device controls the other, and each device responds to the other. Also, when a scene is created in the ISY, there is an unidentified controller in every scene...the ISY, itself. So, when you activate the scene from mobilinc, it is as if the ISY is the controller and every other device responds.

Latest version is 4.18. I thought you had v4.0.5?

Yes, indeed, a program can activate a scene. I see no reason the ISY cannot do what you want. Write a program: if status "insteon bulblinc" is not off set "scene" on else set "scene" off

The oven being on is not conclusive, unfortunately. It was a good thought, however. (especially true if your oven is not electric) My suspicion remains a lack of insteon communication across electrical "phases". How many insteon devices do you have, and how many are dual-band? Is your PLM dual-band? How new is your 2477D switch? You may want also to update your ISY software to the latest version. Perhaps the switch is too new for your current software to recognize.