larryllix

You mentioned it was a remote, so I figured it was portable. If it wired in to a battery backed GDO, why do you need a separate power supply? If you need a separate power supply what is wrong with a solar panel instead of a wallwart? I am confused exactly what this is, you want to backup.

basically each section takes thisset a variable to the hue set a variable to level set the saturation set a variable to ramp speed (if written into the NR. I just keep mine at about 2 seconds) set a variable to the bulb number (unless you have a NR for each bulb - I do) call the NR. Check back on the screen shot I posted and look at the variable substitutions in the URL and the body section.

If it will just sit there with very little load, a couple of NiMH cells with a few watt solar panel to charge your car battery. The type that actually drains a 12v battery due to the flashing LED taking more energy that the cell puts out on your dashboard. Some experimentation would be needed but the 3-5W rating would likely be just enough to top the battery off each day with garage lighting. Pick one up at a garage sale for a buck or two. Solar PV panels act like constant current devices (light dependent) and can be shorted without problems. Afterthought; Pickup a solar garden light with a 3v NiMH battery in it and connect into that. It's all there already. This depends on your standby load on the battery.

I have the Insteon Outdoor On/Off module, another two On/Off Modules, and an X10 Appliance module outside on my deck, white taped around the modules to keep the snow out of the plug/receptacles and they all work fine. They were covered in snow last winter for the Christmas lead-up season and using the same units again this year. Keep the water out of them and don't get them sub-zero and bring them into warm humid air, they should be OK. If you have frozen wiring that is wet, Ice is s hort circuit for RF. I am not sure if that would affect Insteon signals though, They are low frequency compared to business band stuff. Bring them into the warm and try them. They can go back then or be replaced, either way they need to come in.

Here is a long one with a few examples involved for you. This puts my whole rom on to flowery colours everywhere. WAF is high as it is relaxing. Note the usage of colour constant variables = $cZ.XXXXXXX so that the values don't have to be looked up all the time. The "Z" in the name is to force sorting to the end when in pull-down menus for the variables. I use four banks of colours for the 6 major colours so when I select that purple they all match. Even Hue bulbs don't match Hue Bloom bul colours. These are all placed over the integer 150 count range so I never have to scroll past them once defined. The NRb.xxxx references are the same technique sending commands to my own NRbridge python3 code on a RPi that controls my LEDenet strips. Note: no Wait times as I use a NR parameter bank for each NR. This may disappear once the caching problem is resolved. Colours.movie - [ID 0060][Parent 00C5] If $sGathRm.colours is $cMODE.MOVIE Then Set 'Gathering Room / ML2' to 20% $CornerLamp.hue = $cZ.MAUVE.HUE $CornerLamp.saturation = 254 $CornerLamp.brightness = 100 Resource 'CornerLamp.set' $TVLeftPot.hue = $cZ.ORANGE.HUE $TVLeftPot.brightness = 80 $TVLeftPot.saturation = 254 Resource 'TVLeftPot.set' $TVBackLamp.hue = $cZ.BLUE.BLOOM $TVBackLamp.saturation = 254 $TVBackLamp.brightness = 100 Resource 'TVBackLamp.set' $TVRightPot.hue = $cZ.MAUVE.HUE $TVRightPot.brightness = 150 $TVRightPot.saturation = 254 Resource 'TVRightPot.set' $FloorLamp.hue = $cZ.ORANGE.HUE $FloorLamp.brightness = 100 $FloorLamp.saturation = 254 Resource 'FloorLamp.set' Set 'Gathering Room / ML2 / SideLamp' to 60%, color '$cZ.GREEN.ML Index' Set 'Gathering Room / ML2 / BufCornerLamp' to 100%, color '$cZ.RED.ML Index' Set 'Gathering Room / ML2 / BuffetandDesk' to 100%, color '$cZ.AQUA.ML Index' Wait 2 seconds $NRb.RGBlevel = 100 $NRb.Wlevel = 0 $NRb.bulb = 4 $NRb.colour = $cZ.VIOLET.ML Resource 'LEDenet.Set' Resource 'LEDenet.On' Wait 2 seconds $NRb.bulb = 3 $NRb.colour = $cZ.BLUE.LED Resource 'LEDenet.Set' Resource 'LEDenet.On' Wait 2 seconds $NRb.bulb = 2 $NRb.colour = $cZ.RED.LED Resource 'LEDenet.Set' Resource 'LEDenet.On' Wait 2 seconds $NRb.bulb = 1 $NRb.colour = $cZ.MAUVE.LED Resource 'LEDenet.Set' Resource 'LEDenet.On' Set 'Gathering Room / ML2 / UnderBar' to 60%, color '$cZ.GREEN.STRIP Index' Else - No Actions - (To add one, press 'Action')

This was discussed in another thread recently. It appears UDI has added a pseudo method of adding a Swutchlinc to a scene as a controller, and also pushing scene preset levels, into the same switchLinc, as if it were a responder, by programming the local levels. To the user, this appears that the SwitchLinc can control itself via a scene, affecting itself, by operation of it's own paddle. The paddle only operates the dimmer portion of the switchLinc to it's own local levels, directly. By pushing scene programmed levels into the local levels of the switchLinc, it appears to be "part of a scene" that it also controls. In V4.x this can be taken advantage of by adding the switchLinc to a scene as a controller along with any other devices, as controllers. They all appear to operate each other as well as themselves. In V5.x this can be put into a program line (without secen usage) by setting the "local On" level and the local ramping level. When operated at the paddle locally, the local parameters set resume. This was installed in X10 devices in the 1980s and in Insteon devices since inception.

Energy meters can have communication PCBs added to them or not and it may not be ZigBee at all. The meter type does not usually specify if they have the capability. I worked for a distribution utility that doesn't offer the customer to connect to their system, period. They offer online reporting on a website though.

A SwitchLinc can change it's own local level settings from the paddle but only it's own paddle can trigger it to the local preset level. Insteon devices cannot change scene levels by operating their paddles On. They can change their own local levels so that next time that switch is tuned on at that particular switch, it goes to that same level, but the scene levels need to be changed from a scene management device like ISY. IIRC the SwitchLinc switches can send dim and brighten commands, just not control loads to levels other than on/off.

Symmetry through asymmetry. It is all the same in that, everything is different.

Your scene states this. Maybe just an entry error? Maybe you have some internal connection between button1 and button2 with your usage of an 8 button KPL. I do not have or use an 8 button KPL but the only responder portion of my KPL buttons are the LEDs. Stu is probably the guy to fix you up on KPL stuff. He uses a lot of them. Scene: Living Room Main 8 button dimmer button 1 (LOAD)(Controller) ::Set for on=75% ramp rate=4.5 paddle switch 1 (Controller) ::Set for on=75% ramp rate=4.5 paddle switch 2 (Controller) ::Set for on=75% ramp rate=4.5 8 button dimmer button 2 (Responder) ::Set for on=0% ramp rate=0

Take the LEDS out of the scenes and use a program, with a Wait 2 seconds in it before operating another scene with the LEDS only in it. I don't believe you can adjust KPL led levels in a scene, only turn them on and off. I am not a scene guy or a KPL guy but I know that KPL s are weird and demand weird controls. Maybe it is your button labels that confuse me but I am on mobile right now and can't view it easily.

Your program will do what it is designed to do regardless of what any other program does. From runs Then To runs Else There are several ways to handle this Manual Override. You can use change your program to call another disabled program with conditions in it. You could write a Manual Override program that temporarily disables your auto-program and then re-enables it when you are done. Probably many other methods but those are the two method I would use. Warning. I always put a failsafe long timer (like 6 hours) in my manual override programs because people get used to lights turning themselves off, and will walk-away from the On light, expecting it to look after itself.

There is something wrong with those scene involving the KPL. KPLs do some weird things with cross button from history here. As an experiment, I would divorce the button LEDs from the scenes and try a program to set just the LEDs with a few second delay for the LEDs. This should separate the button push command signal from the LED signal in time, to avoid Insteon signal clashes. This is providing the factory resets don't make it all go away. The ALL ON I created last month, was involving a KPL using command signals to immediately send back a signal to set a KPL LED on/off. All the KPL functions are considered one device, and that can cause problems, for some reason in the Insteon protocol, when you include two different parts in one operation, apparently. I am grasping at straws here, but there must be a way to sleuth this down to the root cause or bug.

There are plastic boxes that seal out rain better but... Boxes can be mounted on the surface or inside the brick level to the surface. With a flood light fixture mounted on the box you will hardly see the extra 2" of box, if not level mounted in the wall. After that you may notice that many other house already have them.

OK then the pipe and surface mount box I was going to suggest, down the wall is a no go. Wouldn't look good in the bedroom. LOL The module inside the octagon box for the wall fixture would keep it cooler and ladder accessible, for maintenance, if needed.

Are you running above the garage in the attic space? is your run to the attic existing or are you adding it?

This appears that your scenes are interoperating. Scenes are supposed to be individual and not interact. Did you factory reset the KPL especially, and every device, before linking to ISY? Have you factory reset the KPL, especially, but all of them, and restore each from ISY? Have you checked your links in each device and used the automatic compare feature in ISY to identify messed up links?

Thanks. Another day. After finding the iR LEDs wired back to back and the way the thing acted erratically and different so many times, and now it doesn't link at all, I am a little disheartened with it, and so close to the garbage too. I may give up on this route and go buy different AV equipment. Time for some Anynet+ stuff anyway. LOL

I know we get can away with that in certain Industrial installations but not residential.Breakers are not made to switch loads on and off buut they do.

I don't think that is really acceptable, but if there is nothing else on the breaker you don't want shut down...sure. Switches/dimmer and MS sensors always have an air gap feature for safety when changing bulbs. If possible, I would install a switchbox somewhere semi-convenient, and keep all electronics not too inconvenient. You also may want to switch it on/off as you walk past at times. Your PLM could be dying and taking a week to get a new one.

Your OP stated it wasn't working fine. I was attempting to give you a method to help of locate your problem.

You need switch somewhere to change the bulb, not alive, and for when any inline products fail. You can control the light there by paddle or from any Insteon device / ISY in your network.

Stuffing a Wait 5 seconds into your program can help diagnose sources of trouble.

hmmmmm. No, AV gear is inverter backup up and this circuit isn't. It's an extra circuit that runs around the room dodging AV and Network closet gear circuits. LOL A few Hue and MiLight bulbs running on it. I plugged an On/OffLinc into the duplex receptacle at the base of the 10' long extension cord. When I did get it to link (a few times) and ran a test program to test the iR 100 times, the iR flashing pattern and blue linking LED never seemed to miss. So I assume the Insteon signal gets there OK. That may be my next try to take it into another room circuit.

A note about NR hitting on your Hue bridge. You can do variable substitutions in the NR but the substitution is not done until transmit time. If you use a few variables as passed parameters, for your Hue setting NR, and you immediately change the parameters to another value/bulb etc.., There is a good chance you will not transmit the data parameters for the first NR transmit, when it grabs the variables, for substitution, from the variables at the time of Tx not at the time of the NR call. UDI has promised to make this time and option in a later version. Until then, you will need a Wait 1 second between each call, or make a set of variables for each bulb.