larryllix

Not unless the devices have lost links internally. A device restore can relink those. Sent using Tapatalk

I just remembered what my problem was. Canadian spelling in the routines after disconnecting and reconnecting ISY with the Alexa app. There may be some other clues in this thread.

Try changing the style of device in ISY Portal, saving it, and then change back and save again. I had a lot of trouble with this same thing with routines. I think I have found if you load the Alexa Webpage App and edit anything your routines or devices with change to blanks. Sent using Tapatalk

I found this old thread that may help more.

The controllers do not send any response and udp protocol doesn't include a response anyway, so N/A is the expected response. IIRC the bulbs have to be addressed by turning them on first. Then levels can be assigned next. If your bulbs were dimmed to 0 before turning them off they will return to 0 when turned on again. After turning them on you need to wait 100+ mSec before sending the next command. Since ISY cannot support 100 mSec, Wait 1 second must be used between each NR sent. Each NR command contains three bytes. A command byte, 0, sync byte The command bytes are composed of a command code + 2 * bulb number(1-4) Note: The 0x numbers below are hexadecimal and must be converted to decimal for the ISY NRs. # MiLight UDP command codes cmd_on = 0x45 cmd_off = 0x46 cmd_alloff = 0x41 cmd_allon = 0x42 cmd_dim = 0x4E cmd_hue = 0x40 cmd_allwhite = 0xC2 cmd_white = 0xC5 cmd_effect = 0x4D sync_byte = 0x55 So to turn on bulb 1 you would use a NR substituting 0x45 or 69 + 2*1 = 71 0x00 = 0 0x55 = 85 The screenshot above, should have been for bulb 2 On (0x45 or 69 + 2*2) If you don't have a group 2 then the code sent would not affect anything

Welcome to the forums!!! If you have the Network Resources module this turns one group of bulbs on. I am not sure which one as each controller controls up to four groups of bulbs. I haven't used NRs for a long time (the NRs are all removed) and now have all my MiLight bulbs and strips in a box unused. All MiLight commands are three byte codes and you would install a NR for each group of bulbs x an On/Off/ and Set NR.

Great! Glad it worked for you. BTW: add the '@' before the nickname and it pings the other person's notifications

"Switched" and "Status" have two completely different behaviours. Using a switchLinc for example: Status has two opposite states. ie: On and Off are opposite. Switched has four states ie: Switched On is not negative logic of 'Switched Off'. They are two different signals. We won't touch dimming values here. Common problems are created in programs by using the status of a 'device' in an If section condition of the same program that is controlling the status. If status deviceA is On Then set deviceA Off Else --- will oscillate because you are controlling the status of the electronics that you are triggering with. (I didn't say 'on' there ) However, using 'Switched On', instead, will monitor the status of the switch paddle and you cannot control that, so no feedback can occur.

Watch your parenthese. IF: ( buttonA Swicthed On OR buttonB Switched On OR buttonC Swicthed On ) AND buttonA is NOT Switched Off AND buttonB is NOT Switched Off AND buttonC is NOT Switched Off

OK...OK.. it wasn't "Search" but I am not much of a detail type guy! BTW: The words "Find/Replace" both have caps! (sarcasm) Yeah...ISY is pretty awesome but like the rest of the whole app world now...it's all hidden to the person that doesn't finger every spot on their screens just to see what happens. If we write a manual it will all be obsolete by the time we are done. YUK! Enjoy!!

There is a secret search function but if I tell you , dont spread it around! Right click on any program title in the program tree under the Detail tab. Select the search option where you will find search by device, variable, etc.. as well as raw text. While the search box is open you can even edit your programs etc.. without closing the search function box.

Are the backups from v4 loadable into a V5 system?

A new ISY will come with v5 preinstalled.

If you are using a scene you should probably delete the Set Fluorescent light on line to avoid any signal competition possibilities.

You still have four emails going out in rapid succession from one program trigger. If you really must have them, try a Wait 1 second between each one as well as Wait 1 second before most of the others also. This may give your Ethernet some time to "breathe" and give you some diagnostic information. Waits give the ISY OS time to process I/O and other background tasks.

I am not sure what watchdogs ISY contains but it seems to me overloading the Ethernet cache was one of them that could cause a reboot. Looking at your programs I see about half of them are sending emails to sometimes more than one recipient. If you get a lot of action your Ethernet may bog down doing that also. I started doing some of this, especially for debugging, but it gets very annoying every time somebody turns on a lightswitch. Along with that idea, if your email notifications setup got messed up, with the a newer ISY firmware revision installation, it could accelerate the problem and possibly explain your events.

Here is how I would do it. Rename your existing switchlinc by adding an 'XX' to the end of the name Get a new device and link it to ISY, naming it the same name (no 'XX'). In the program tab right click on any program title and select 'Replace' Select the deviceNameXX in the From box Select the deviceName in the To box Click 'Replace All' Done. Ohhhhh Except you may have to modify your scenes manually. Check them. ISY admin console also has a replace device feature but I have never been able to make that work, and I can never remember how it works.

Looking at your programs I can see what appears to be programming before V5 and even before variables where introduced. With so many programs running other empty program I would try something else here. Create a good, up to date, backup. Delete groups of programs and retest until they are all gone and ISY is clean. or factory reset your ISY. Reset your time zone and other basic parameters for ISY. See if the problem clears up. Write a few simple programs to test. Restore your programs. I would carefully look for oscillating programs in your admin console. Are you getting the "busy" box a lot? Are program icons oscillating? Variable usage and V5 feature usage could simplify and reduce the number of programs greatly and may find any cyclic loops that could be clobbering your ISY.

You seem to be quite aware of the factory reset difficulty and have done that quite well....agreed. I would check the ISY log to see if it recorded a beep sent right after receiving signals from it. Then swap the device and see if it corrects itself. You could try completely deleting the device from ISY. Power cycling ISY to make sure it really forgets it, and then relinking the SwitchLinc. I didn't think there is even an option for software to cause a beep on paddle operation. This could be a defective device.

Do you have any remote CPU devices that input into your ISY Rest inputs or using any Node servers? I notice that NodeLink can reboot ISY remotely, so it is possible for another external device to reboot ISY intentionally, or even by comm error.

I would try the factory reset again. It can be tricky with SwitchLincs because if the buttom stops at the neutral position and it is On for even a half second the factory reset will fail.

With V5.x, all linear devices can take a variable value to set their levels AFAIK. I have built some 2-3 hour ramps using that technique. (sunset simulation) I also "borrow" some RGBW bulbs for flashing red when garage doors are open, and at midnight as a bedtime warning, and then replace their previously saved values from variables. ISY only uses percentages so the resolution is 1%, while most devices I have programmed take 0-255 (8 bit) values. The driver has to convert. Not much of a change in perception until you get down to the low percentages. Then 2% down to 1% halves the light output.

The LEDenet controllers you linked to are PWM voltage switching outputs. They will dim down to 0.4% level no problem. @Scottmichaelj should have experience with the real MagicHome UFO controllers regarding scenes inside ISY.

Under the devices tab in the admin console you should find an "Options" button on the device's page. There ire some options there.

I cannot answer that as I don't use PolyGlot for LED strips/bulbs. You will have to load the PolyGlot node server and try it. I can send my NRs to control my LEDs simultaneously with my Insteon equipment. Sometimes the LEDs come on first and sometimes the Insteon switches come on first. It is not predictable with different technologies and comm pathways. The ISY program delay cannot be measured or seen and I know it isn't a factor unless multiple devices are being controlled from the NR with different addresses. With PWM dimming techniques that the controllers use you can dim lighting right down to 1% without any flicker. With an Insteon dimmer that is not likely going to happen. SwitchLincs with LED bulbs usually flicker and/or fail about 8-15% levels. The PSU unit you linked to may be way oversize for RGBW strips. Some recommend a 60W supply for all four channels but after measuring and testing, even a 12W PSU will run all four RGBWW channels simultaneously without problems. I use a 3A 12v PSU for two 5m RGBW strips (radially fed) , four channels lit simultaneously without problem. This has worked fine for MiLight controllers and now LEDenet controllers the same. Sequentially feeding two 5m strips doesn't work either ,as the voltage drop gets too large and the second strip starts to show dimming with increasing length.