larryllix

Just receiving two new Leak sensors and having two previous I have found they operate quite differently. On the two newer units (v.41) the pushbutton sends out Dry On, every time. On the two older units (v.43) the pushbutton sends out Wet On for a quick tap each time and Dry On for a longer push each time.

Here is a series of programs I use that do it all. I use a timer override for manual On/Off just in case you forget the automatic lights are locked on in manual. http://forum.universal-devices.com/topic/16694-50-latency-question/

With most of my auto lights I just let them turn on during the day. It may a dark area and I can't be bothered to inflict a third brightness level program switch. With LED bulbs running all day would not be a financial hardship and pointless for energy saving. I just want my 100w equiv. beside my bed dimmed in the middle of the night .

I link all my MSes to the lights for faster response. This requires different methods to control all the aspects of dimming and manual override..

Very Odd. Did you measure the output of the NPN transistor? Silicon transistor open collector can pull down to almost 0 volts. This was a hard concept for many to swallow when the base to emitter voltage is pegged at aprox 0.7v. Perhaps a darlington pair output.

I am glad this resulted in a solution for you. Agreed the I/OLinc is a bit screwy and if Insteon does change this setup I am sure nobody will find out until it doesn't work that way anymore. I am a little sore right now as I just received two new DampLincs = leak sensors and on the two new units the linking button sends Dry signals whereas my older two units send Wet signals sending my wife notifications about leaks while she was away. I was testing with the two new units and it seemed safe to continue on the old units. She is very sensitive to this right now, after two washing machine spills last week, and started shopping for a newer and improved mop.

This sounds like a call to UDI Tech support.

That usually indicates your Java cache needs to be cleared of duplicate files. Use the Control panel, Java and make sure you select all options before delete.

MS units work fine in scenes with lighting modules. As above, the Off has to be disabled from the MS then ISY can control that. Response is immediate. There is a way to control dimming also on a preset the scene basis.

No. However I have tried linking two I/OLincs into a scene successfully. I used my doorbell pushbutton detector as an controller and my BuzzLinc as a responder and tested just fine. The problem, as mentioned by LeeG is that the responder cannot be an extended time and the contact opens as soon as the PB is released. The scene is also not retriggerable to extend the time on as long as triggers keep happening. While scenes are fast with direct links between devices, control and logic is lost. No timing can be created and this is why most of us disable the Off signal from MS units, so that ISY can control the time off time.

Yes, but too late tonight to get one down for linking. The I/OLinc output dropped into the scene no problem but the sensor wouldn't. I assume this is because it has internal linking, same as any other module. Perhaps duplexing it was an afterthought?

Yeah but which one of you is correct? I attempted to create a scene with the input and output of the I/O Linc but something doesn't allow it. Funny ISY thinks it has all the statuses and responds as if it works with On/On for In/Out but it isn't happenning. Next I went to a standard light program with time off and yes, it is way too slow. It seemed the I/O Linc is slower than other controllers. Maybe only a visual effect as I can see exactly when I short the wires to cause an input. contact closure. I/O Linc is not going to work for both input and output with a decent speed. Input needs to be something different (MS or On/Of as was) with a direct linked scene and ISY time off, or output needs to be something different with a directlinked scene between devices.

Have one wired up here at my desk now I have an IOLinc wired up at my desk now. These things have some weird modes. In short the I/O Linc isn't going to work as the timer inside cannot be retriggered and this appears to be key factor for this scheme. I tried several things to fool the timer by ISY triggering the output while it is activated by the sensor follow input option. Not happening. When the sensing input changes back to the quiescent state the output turns off again. A possibility is the contact follows sensing and trigger reverse. Now the timer (monostable) activates and keeps thecontact clsed the whole time of the timer setting. Two problems. This would be at the release of the sensing, when the foot goes away = delay, and if activated again the output turns off again. A second person or foot would cancel the lights On A positive the timer starts again after the blink necessary to retrigger. Have to agree, not going to work. A direct link scene with a motion sensor could do this. I believe the I/O Linc has to stay for ease of controlling the 12v lighting.

That's what I read on the options box also but it makes no sense to me as both A and B state the same thing "either the On command or the Off command". Can you explain the follow up "But only one". What defines which one?

I/O Linc modules have options that can be accessed from the device's status page in Admin Console. There you can set whether the sensor is hard connected to the output contact or not, as well, there are options to set the contact to momentary and/or continuous. as well as to initiate it on various logic triggers. Without looking closer at my own you may be able to set the momentary timeout to do what you want on a self trigger on only have ISY monitor the action. No scene required. Another possibility for more control would be to remove any scene you have created inside it and just use a program with the sensor as the trigger and the output as the light control. Expect a slight communication and ISY delay for the light though. Program examples can be supplied if needed. It seems fairly straightforward using that technique.

I have about 40 Insteon devices, no boosters, access points or repeaters. I don't seem to need any. I do have an old passive X10 phase coupler close to my distribution panel. I do get some slow Insteon communication occasionally on the next floor just above my PLM and my four solar inverters beside it.

How is the open/close module mounted and what does it detect?

2443 only results in a micromodule and not an Access Point. Is that some older number that has since disappeared? BoosterLincs appear to be X10 signal repeaters and may hurt your Insteon signals.

Maybe I am not reading the correctly but I see the OP wanting. On button = SceneX lights on A button = SceneA lights on Off button = SceneX (includes A lights too) off, **Button A LED off**= the request Could the A led not be included in SceneX as the kitchen lights are included in Scene X and the LED would also indicate as if A have been pushed on. Or....maybe the penny just dropped. Would button A not change it's toggled position thinking it is still on? I don't use the toggle mode on mine so I am not familiar with the fine details and I know you have lots of KPL polish (but in English:)). Mine just flash uncontrollably after I am done .

Only having limited experience with KPLs I am learning this one. I only use my KPL as a combination keypad for a notification system, restarting my well pump and washing machine after a leak.. Can the A LED not be included in the SceneX to turn it off along with other SceneX devices and vice versa?

That is exactly what my last program example does. IRule sets a variable, ISY uses it and sets it back to 0 after changing the fan speed.

No RPi needed. Just the Network Module for ISY is needed and use of lots of network resources or with the addition of non-cached variable substitution in Network Resources with ISY v5.x only one, or maybe a few, Network Resources. If you can tolerate a Wait 1 second between controlling each Hue bulb then this can be done with v4.3.18 and up with only a few network resources used.

I am not familiar with iRule. Can the programs not just control the variable? That way all the trigger and supervising programs work based on the variable value. That is the beauty of the event based ISY engine. Multiple programs can just stuff a value into the variable and the fan just shifts gears, seemingly by itself. Perhaps just duplicate the master control program with the iRule as a trigger? If iRule sets a variable then set it back to 0 after the $sFanspeed variable is changed. This could also be incorporated into the existing master control program with an "OR" condition. If ( Control KPL is switched on OR $s.iRule.variable > 0 ) AND $sFanSpeed <= 3 Then $sFanSpeed +=1 $sFanLinc init to $sFanSpeed $s.iRule.variable = 0 Else $sFanSpeed = 0 $sFanLinc init to $sFanSpeed $iRule.variable = 0 EDIT: Added s prefixes for state variable designation.

I was using cascading programs for everything but now I find the state variable triggering works very well. It's a little cryptic with unrelated programs running but that is classic for event based programming. The nice part is viewing the program tree in Admin Console shows the currently selected program automatically as green/true and the rest as red/false in a self managed case style switching arrangement. Now we need to add control from iRule (assuming some apple sauce here) to synchronise the variable from the other influence..

You're welcome. Scenes can work also, but only with one component device in each so there is no point.