larryllix

Click on the Devices page/Tab. Slide down to the bottom and you will find "Delete All" After that is done ask Alexa "Discover" or click the discover button on the app. It will find everything in the ISY Portal that you set up. Multiple instances of devices and edits you made since the beginning will be cleaned out.

This may be a slip of the tongue but sending codes to the KPL is not controlling the FanLinc. You are tapping the wrong person's shoulder. Not a good process to attempt without ISY, agreed, but it sounds like it should have worked. This seems to present that ISY made an assumption and didn't go by actual status of the device. Usually a "Query" will correct the status error.

Have you used the Alexa app on a mobile device to "delete all" devices and then used "Discover" again? I got messed about for months, by using their webpage app and then an Android v4.x mobile app. They just make things not work magically without warning. My Win 10 Edge Browser webpage app makes my routines all disappear into generic triggers. Just some thoughts.

What is your exact vocal syntax you are using to control this device?

I have to wonder if they changed the port number on the newer hubs. The port number was changed once before early in their development. Try finding a packet sniffer and monitor some packets from the app. The sniffer must run on the same cpu as the app as switches don't pass packets to uninvolved devices. Sent using Tapatalk

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.