larryllix

Yes! There will be coloured oval cornered rectangles beside each device containing a "1011" code to indicate trying to write binary to the device(s).

Are you using European frequencies with North American Insteon?

Factory reset each one, and then restore it. You better get some methods in place to prevent this from going through your house in the future. It sounds like the lightning got into your wiring. This may get costly and annoying, and not just for Insteon. If you do not understand electrical discharge phenomenon, look for a sharp electrician.

Nice. Justa suggestion: Put Wait 2 Seconds between each Set line. You are writing data to each device's eProm and it can take a lot of Insteon comm talk time. This may tie up your other HA communications and flood ISY's caching, causing some operations to be dropped, devices to be marked as 'comm failure', or mess up program timing in other programs. Most Insteon operations are fairly quick and don't tie up much comm line time but updating eProms in devices can take much longer. This seems like background process anyway without any urgency.

You likely have battery Insteon devices waiting to be put into linking mode so that ISY can finish writing updates to them. That can bog ISY down attempting to write updates every time that device has any action. A factory reset of ISY with a follow up Restore may clear things out also.

import urllib.request import base64 # Server (this CPU) IP address server_IP = '192.168.0.175' server_port = 8000 # ISY parameters to be defined by user ISY_username = 'zzzzzzz' ISY_password = 'xxxxxxxx' ISY_IP = '192.168.0.161' # Heartbeat to ISY variable ISY_HBpage = 2 # 1=Integer, 2=State ISY_HBaddr = 83 # ISY heartbeat variable ISY_HBperiod = 90 # In seconds. toggles ISY flag variable ISY_HBlast_sent = 0.0 # Write ISY handshake variable via REST i/f def write_ISY(data): ISY_rest = "/rest/vars/set/%s/%s/%s" % (ISY_HBpage, ISY_HBaddr, data) get_url = urllib.request.Request('http://' + ISY_IP + ISY_rest) #format the URL ISY_authorise = base64.b64encode((ISY_username+":"+ISY_password).encode('utf-8')) #encode it get_url.add_header("Authorization", 'Basic %s' % ISY_authorise.decode('utf-8')) try: r = urllib.request.urlopen(get_url) returned = r.read() r.close() except: report("NRBridge: ISY heartbeat send failed!***") return

Most problems I have seen here are solved by disconnecting the Alexa skill from your UDI account, and then reconnecting them. It seems to take a fresh data grab and all is fixed again

Mine didn't.

I had a random problem with lights turning themselves on for about a year. Finally I recognised the pattern as one of my scenes. After digging through programs each occurrence for months I found errors in the error log after some Humidifier On (a OnOff plug-in module) commands. I unplugged the module and plugged it back in and it hasn't done it for about two years now. It seems my OnOffLinc module was sending out a scene On command (well noise, interpreted as a scene on) instead of an ACK occasionally. The module was not in any scene at all.

For the CAI Webcontrol board you don't need a RPi at all. See my screenshot (above) as the WC8 board has it's own I/o interface designed to support ISY's Rest interface without any further hardware.

The Network Module can send almost any style of Ethernet packet out. The Rest interface inside ISY can receive formatted Ethernet packets to control programs, variables, scenes etc.. The CAI WC8 board would fit your bill perfectly. it would take only a few lines of code and rest interface commands installed into it's table to write to ISY from the logic inputs on the WC8 board.

What ISY firmware and UI are you using? They must match.

@k0d3g3ar Welcome to the UDI forums! Great entrance you made! Thanks from all of us!

I have none now but... Can you use "switched" instead? Can you use "Off"? Can you use < 1% ? Why so many decimal places? I suspect ISY is showing you a rounded off value and never really matched 0.0000% BTW: Your AND specifies you must have both off. This will not work with "Switched" triggering. Two devices are never triggered at the same time with ISY logic.

Always welcome. We live to solve problems here. Sent using Tapatalk

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