larryllix

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.

There is no syntax conversion. same syntax. Maybe the upgrade conversion corrects a few minor items that you don't see or notice.

Sorry. corrected the step numbers.

Thanks Stu The event log shows ISY getting involved at step 4 as soon as the button is held down to link. Mon 12/05/2016 09:41:58 PM : Stop Insteon Device Linking Mode, Final processing to follow It just doesn't seem to do any ACK to the iRLinc to shut the flashing off as per Step 5. EDIT: Listed step 6 and 7 in error.

It all seems to go OK, until step 5, which never happens. I allowed about 15 minutes, one trial, and it just seemed to time out, and the LED stopped blinking. No linking data was received after on the same trial. On step 7 I click OK and nothing happens. It did work a few times, when I first got the unit with the bad iR cable, but now I can't make it work at all. Step 1 sometimes doesn't go into linking mode and wont blink. It takes many tries at double taps to make it work sometimes. Not ISY related but...I have discovered the recording of the iR code has no intelligence. Other smart remotes, I have experienced, want many repeats of the code sample to ensure they have it correct via repeat verification and then extract one good pattern of the code for sending. This unit records and iR sends as many repetitions as you hold the button down for while recording. This can take a lot of time if the pattern is not kept short while recording. Here is a level 3 Event log from factory reset (first line) to giving up at step 7 and tapping again to stop the flashing link LED. ISY-Events-Log.v5.0.7__Mon 2016.12.05 09.43.24 PM.txt The iRLinc IP address is 33.54.2A. I don't see that appearing in the event logs but lots of another address. 27.1B.85 which is a KPL in another room.

Welcome to the forum! I am not really sure what is happenning but I will try to relate some information to inprove your ideas, maybe. Scenes do not rely on ISY at all. ISY is a very good scene link manager to make it easy to set up scenes and have them download into your devices. scenes can be done the old fashion way without iSY by doing tap sequences and putting devices into linking modes. If you have a scene (link between two devices) whether done with ISy's help or not, It is already sending the codes between devices. If try to compete with this process you may get the effects you disclosed. I like using all programs in ISY to do things except for MS with lights where I use a scene to turn it on really fast and a program to turn it off when it gets around to it and no rush. I also use scenes for every device in the house whre I would use it for a blinking house effect / alarm. You situation sounds like you have a scene turning your light on and a program that tries to do it at the same tie. This may also cause some Insteon data storms to slow things down when so many commands are shoved into the tiny Intseon data tube.

Now I can delete a dozen test programs and a couple of test scenes. Then we wonder how we get bad links in devices. LOL

See my previous admission! I am so glad this was workable in v4.x for you. Yes I was using the scene, as you persisted and got caught doing the opposite of my own preachings from a year ago. Sorry to have eaten your time on this. I goofed up twice here, badly. I use this technique for dula device scenes but never one. With v5, I don't need it though.

Bingo! You hit the nail on the head. I was selcting my scene contrary to what I was tooting to everybody else a year ago Son of a b... I got caught on my own stuff. grrr... At this point, totally embarrassed, I have to thank you, carealtor for being so stubburn and persisting with my education. I was always informed you could do this. Thanks!!! A also have to thank zerop for posting the idea in the first place. I didn't know you could do this with one device in a scene. It totally does make sense, user wise but again I was misinformed a device couldn't do this. Thanks so much! Stu. Thank you also for being so persistent in my education. After all that I realise I don't need the technique with v5 as the On level and ramping are settable without scenes. probably doing the exact same codes behind the scenes, I would be sure. I have to reread that UDI documentation again. I believe they are stating it incorrectly, supporting my original ideas.

Here is a UDI wiki document explaining what you are describing.https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Working_With_Scenes_-_in-depth_tutorial#INSTEON_Devices_and_Local_Settings It also explains that the controller/responder device does not respond with the settings from the scene but only from it's own local settings when it's local button/paddle is activated to cause the scene to be activated. The SwitchLinc is described as a controller and responder also (as you stated) but it doesn't respond to scene activation. The docs also mentions devices that are only controllers and not responders.

Yuphttp://forum.universal-devices.com/topic/17495-how-to-use-a-ms-with-lights/?hl=%2Bxathros+%2Btechnique If this actually works there will be a lot of really happy people but it doesn't work in v5.0.7. Anybody else test or use this technique?

Nope. V5 hasn't changed the Insteon protocol. My SwitchLinc paddles are not responders, only controllers. Buttons on my plug-in devices are not responders and either are my KPL buttons. Is this some shortcoming in the Insteon protocol you refer to? ISY doesn't add devices to scenes with that style. At least not indicated. Does this show up in the devices links when you add then as a controller to a scene?

1. You cannot have a SwitchLinc in a scene both as a controller and a responder. ISY won't allow you to place it in the scene once it has been entered as either type. It would never be required as the paddle always operates it's own dimmer circuitry and cannot be affected by outside influences, except for the local preset settings. 2. A scene created with only a controller doesn't control anything. Local switching is not a scene preset and the two are not related. Local controls have their own presets that are not affected by a separate scene's settings. 3 . As an experiment I have created a scene with only a controller. I have created a test program that changes the controller settings inside the scene. I ran the program Then, and also Else, changing the controller settings the scene, I have posted many threads explaining this technique to people, in the past. The local settings of the SwitchLinc were not affected in any way, and the SwitchLinc only responded with 100% brilliance each time, where the local setting was last left. The ramp speed was not affected either. However, when I run the local preset program I normally use the local settings were changed and the paddle taps respond accordingly. This technique works well for a scene with a separate controller like an MS and a SwitchLinc responder, but not for a scene with no responder on my v5.0.7. ISY. http://forum.universal-devices.com/topic/17495-how-to-use-a-ms-with-lights/?hl=%2Bxathros+%2Btechnique Here is my test program used to operate the scene with no responder. Ensuite Lights Level.adjust.scene method - [ID 014A][Parent 00FA][Not Enabled] If From Sunrise To 10:00:00PM (same day) Then In Scene 'Master Bedroom / Ensuite Lights.scene' Set 'Master Bedroom / Ensuite Lights' 100% (On Level) In Scene 'Master Bedroom / Ensuite Lights.scene' Set 'Master Bedroom / Ensuite Lights' 0.5 Sec (Ramp Rate) Else In Scene 'Master Bedroom / Ensuite Lights.scene' Set 'Master Bedroom / Ensuite Lights' 20% (On Level) In Scene 'Master Bedroom / Ensuite Lights.scene' Set 'Master Bedroom / Ensuite Lights' 4.5 Sec (Ramp Rate)

Your program adjusts the levels in a scene only. The paddle only operates the dimmer using the local levels set elsewhere. They are different presets. Are you using another program that activates the scene with the levels you changed? This is not the technique Gary mentioned and I posted the program for. There are no scenes used.

The light requires a switch. Install a SwitchLinc, instead of mechanical switch, to control it, wherever you mount the switchbox. HCS

My apologies! I went to v5.0.x as soon as it came out over a year ago, and I would have (and did) swear those options were there in V4 and earlier. Sorry I wasted your time with a solution that wasn't going to work for you.

He is operating the dimmer from the built in paddle in the SwitchLinc and the two devices cannot be divorced. Scenes are not going to do it very well, without bright flashes with the light going on full brightness first and then a program delay to activate a scene to dim the light. In the middle of the night that is unforgivable. on the eyes. Thinking back there is a better way that I have used for this. Set the local level to say..20% (for night usage) and create a program that overrides, and beats, the 20% with a fast On during the day time The level can be set in the admin console with the device's webpage page. If ...SwitchLinc is switched On ...And ...from 7:00 AM ...to 11:00 PM (same day) Then ...set SwitchLinc 'Fast On' Else ...--

With a good backup file, you could try v5.0.7 for the least problems. few admin console errors on bootup and a few devices not showing status. All Insteon programs work properly AFAIC. If you have too many trouble you could reinstall 4.5.4? and use the Restore to resume where you started from. May take an hour or so. I have no Zwave and it would be a bigger concern to do this, from reading others reports. I have never had a system hang, or an undesired (that wasn't my fault) operation from even the worst of the v5.0.x alpha versions, yet. Totally stable, just not complete or without useless errors popping up.

No? Thanks. But they should all have the local level as a basic setting. @OP. What version are you running?

At first glance your idea should work. Post your programs here so people can look for quirks that are easy to overlook. You may need to quote his post to get his attention.

Here you go! It's hiding. Maybe you have to scroll more on the pulldown.

and I answered you that you do in every version since v3 that I have been using ISY. Post #8. Maybe you missed it.This was the very first thing that Insteon devices did. have a local, settable light level and ramp speed. You can even set it at the switch paddle if you read the manuals. Look harder. It's there. I need to get on another computer to give you a screen shot