oberkc

I am certainly interested if further experimentation, but may not have the opportunity soon. Yes, I reset the device before removing from the ISY. I saw no errors displayed, but the process appeared to be performing some write action without the sensor being in linking mode. Perhaps this contributes to the mystery. Yes, the sensor was in linking mode when initiating new insteon device. Next chance I get, I will try a few more options and report back.

Well, I tried a couple of different approaches. After a factory reset of the sensor, and removing it from the ISY, I chose link management>>>New Insteon Device. Set to autodiscover, nothing happened. I then tried link management>>>:Link a sensor>>>Open/Close sensor. I entered the address, found the autodiscover option, and chose it. The link process failed. I then went back to link management>>>:Link a sensor>>>Open/Close sensor and added the device, keeping default settings. Link worked, but I am back to v0.0. Teken...throughout this process, I never had to rebuild any programs. The one program I had with this sensor as a condition came back as good as before, without any intervention on my part.

Perhaps "not viable" is a little too strong, but mike ippolito suggested that having v0.0 (which is the consistent result when my approach is taken) is an indication of a device "not added properly". If this is true, this sounds to me not to be viable. At this point, however, your point is taken and I suspect I am arguing semantics with myself.

I will try your approach. I have been using the "link sensor" method as asked by Michel. Perhaps this is why I have not noticed the "autodiscover" option? Interestingly, I recall the open/close sensor being a specific sensor choice when my approach was taken, suggesting (in my mind) that this is a viable approach. I also recall a different method for versions prior to 1.9. Perhaps, also, I took the wrong route here. Will try again and report back.

Indeed, I am using link management>>>link sensor option from the dropdown menus across the top. I do not recall an "autodiscover" option, and I have always had to manually input the address, but I will check again soon, trying to pay a little more attention.

Yes, you make good points. As to my own experience, I never had ANY all-on events until recently. I never had any door sensors, until recently. Yes, this could very well be a coincidence. In my most recent event, it appeared that Keypads were not affected. I don't know what one can conclude from that. I suspect if anyone knew with certainty what is causing it, it would be fixed by now.

Up until yesterday, I was not worried (ignorance). My only concern right now is what effect, if any, this may have on the ALL-ON events. If none, I probably won't spend a lot of time trying to figure this out, as all seems to be working fine otherwise. I can accept that this may be one of those devices that doesn't show version number (though these are relatively new for me...perhaps less than a year old installed). It is comforting to know that I am not the only one with sensors in this condition, though. Thanks. The only reason I wonder about the relationship between these sensors and the ALL ON events is that one (but not all) of my events occurred simultaneously with this door sensor changing state.

I understand. In fact, this is the first time that I specifically looked at the version number an noticed this. Full disclosure: I have two of these door sensors. Multiple retries, resets, etc. have resulted the same...version 0.0 for both sensors Three nodes. Status changes to ON and OFF in response to the door opening and closing. Each attempt at linking required me to manually enter the address. I am unsure if this is normal, but it works (if one ignores the v0.0 problem). Given that the sensor is attached to the door, and that I did not want to remount, I tried different locations for access points. None of this seemed to matter. Functionally, both sensors appear to be working without fault. I begin to wonder, however, if this could be a contributor to those ALL ON events.

Mine shows up as a (2843-222) Open/Close sensor v0.0

Nice! Persistance is everything.

Is the switch a CONTROLLER or RESPONDER in the scene definition? You may need to remove it from the scene, and re-add it as CONTROLLER. Given that your remotelinc button is a controller in that scene, do you also want the ON levels to change when activated by this button?

I believe this is your problem. You need to select the switch in both cases, "in scene", and "set" (as in my original suggestion). I assume that the fixture is powered by this switch? I am curious how many devices, besides the switch, are in this scene?

" I don't believe that this is a problem. Make sure, however, that when you are picking the device for IN SCENE part of your action, choose the specific controller device, rather than the scene, itself. The way your program is written, I suspect you picked the scene, rather than device, itself. I believe the point is that you should not forget to "save" the changes to your program, and that the program should NOT be disabled. This must all be done prior to the FROM time, or you will have to wait until next day for the program to execute TRUE/THEN path.

Same question I have...is "bedroom lights" a scene, or a controller within a scene, or a single device which has no scene relationships?

With a program. The condition is straight forward. It would be something like: if time is from 10p to 9a (next day) Then- and Else-path is a bit more obscure. When you create the action for the THEN path, choose "adjust scene". Within the "In Scene" field, choose the controller device from the scene in question. In your case, choose the switch from the bedroom lights scene. In the "set" field choose the responder device. If the lights, themselves, are powered by the same switch, choose it. In the responder levels, set it to 5% when in the THEN path. Take the same steps for the ELSE path, except responder levels would be whatever you want during the normal hours. Keep in mind that if you have multiple controllers or responders, you will need to create multiple actions, one action for each combination of controller/responder.

I have a home theater reciever that consumes nearly 40 watts when powered down. I find out that this is due to enabling HDMI-CEC. Once disabled, the receiver uses very little power. Perhaps the cisco set top box has a similar aflliction. Does it have HDMI-CEC capability? Do you use this capability? Can it be disabled?

I use MobiLinc. Yes, scece levels are accessed through the admin console. It is not an alternative to access through MobiLinc. I agree that scenes are best in this case rather than a program.

A single button to turn lights on and off is a natural, and most basic, function of a keypad button. It sounds to me like a simple scene would work (and I would consider the optimum solution). It is possible, however, that I don't fully understand what devices you are trying to "link" together. I know that you have a keypad, and want to use "a single switch" to control a light. Is the light connected to the keypad, or the "single switch", or another device? If you have two or more devices, both (all) of which you want to control each other, simply create a single scene, with both (all) as controllers. If, however, you have devices that turn on, but not off, you may be fighting comms issues as suggested by LeeG. If so, this won't be solved programmatically or via scenes.

Yes...find and replace...though you don't actually have to replace anything.

not that I know of, but one can perform a search within all programs for specific scenes, devices, other programs, etc...

How about the most basic of automation tasks: if time is from sunset to sunrise (next day) then turn lights on else turn lights off Agreed. There may be a couple of others who get an honorable mention, however. I would guess more like 95%

I am not, either. In fact, I find greater pleasure in getting the job done with fewer numbers of programs. I enjoy finding the simplest solution to the problem. I also have enough trouble keeping track of my limited number of programs that I cannot even imagine having hundreds of programs. Clearly, however, I do not even attempt much of what the real hard-core automators do.

I am not worthy to even be in the presence of this group. All have not counted, but believe I am WELL below 50 programs and can count my variables on one hand with enough fingers remaining to play a little Scott Joplin on the piano.

The addition of slight delays in key programs seems to be one of the recommended steps one can take to mitigate the effect. Pay attention, apparently, to programs with triggers by devices which are also scene controllers/responders, or programs that command those devices to do something. I remain a little fuzzy about these combinations, but it seems to be about avoiding signal "collisions". I had always assumed that the PLM would naturally handle such things, but this is not the case, apparently.

It is all about triggers. The first program will trigger (self initiate) upon ANY CHANGE OF STATE of the sensor. The next program will filter those, however, eliminating any not between the specified time period. The second program will NOT trigger at 0255 or 0305, however, since it is disabled. It is this last point that marks the difference between the approach I suggested and your original program. Your program was triggering at the two points in time defining your time range. Once triggered (at 0305, for example), it was, I suggest, evaluating true, and sending your dreaded notification. You may also want to consider CONTROL, rather than STATUS, of your sensor node as a program condition. Since the query returns an ON/OPEN when, in fact, the door is closed, the first time after the query that the door is truly opened, there will be no change in status. Using CONTROL condition should help solve that problem. Having said this, I believe you are still relying on a trigger reverse setting of the IOLinc, no? This may get reset from time-to-time, such as power outages. Once reset, sensor ON will equal door closed.