paulbates

The iolinc is single band, meaning that it only communicates via powerline. The gate motor(s) will create powerline noise, with the added complication of likely being far away from the rest of the Insteon network in terms of wire feet, which is how long the iolinc's signal has to travel Some direct remediation things to try an Insteon plugin filter on the gate motor if that's possible. It will block the motor's noise If your gate is relatively close to the house and insteon RF signals might make to other Insteon dualband devices in your house, plug a lamplinc or other dualband module into the back of the iolinc. Plug one in the area by the gate temporarily as a test. Another programming idea in addition to Guy's is to create a program that you set to "Run Then" on startup. This will cause the program to automatically run and it will keep running until eisy is shutdown or rebooted: IF - No conditions Then Repeat Every 15 minutes Set 'Gate device name' Query When in programs, go to the summary tab and right click on the program on the Run at Startup column and click "run Then". For the very first time after you write that program, you'll also need to go back to the Details tab, right click on it and click "Run then" to get it going There are a couple of complications with using query. I don't believe that the query will resend the scene to sync the keypad buttons, so a program will be needed to detect and resend the scene "on" or "off": If 'gate device' status is on Then wait 3 seconds set 'gate switch scene' on Else wait 3 seconds set 'gate switch scene" off 3 second waits are recommended because this program will also run when the gate operates and the iolinc catches it, there's a chance of the program and the iolinc traffic banging into each other. The program will only run when there is a change. The query could return an error, so program to trap that might be needed, depending on how the above works that might be another step

If that didn't fix it, sometimes java needs more memory to run the admin console / iox: - Close the admin console / iox - Open the Java Control Panel, select Java tab, press View button, then add or modify the Runtime Parameter -Xmx to the following: -Xmx512m - Press Ok to close the window, then Press Apply to save the changes

Yes, all insteon dual-band devices, including plugin-in modules repeat insteon traffic. It's repeated on the powerline too, and the LED light may be reacting to that. Insteon sells a 2 capacitor pack to try and avoid this problem

Ok, I see what you're saying. I use one of these in a box with hardware store lamp post photo cell for a dusk sensor.. but I've capped off the load and use iox programs to control the lights and avoid unwanted behavior like car lights reaching the sensor. The only way I can think of to do it is to add hardware like another micro module or switch to control the lights. The yellow lead in the micromodule is expecting a hard on/or off voltage, kind of the equivalent of dry contacts, and it looks like there are fluctuations in what the sensor is sending the micromodule. I know for my dusk sensor app, I have to use an iox program to send it an "off" in the afternoon this time of year in my northern latitude as there were days it wouldn't work simply because the photocell never reset it back to off for similar reasons.

Don't want to be a broken record, but you need to take control of the lights' off away from the sensor and let a program do it

It's going to help to see the program. What you're describing could happen its totally controlled with a scene What I do in these situations is: Use a scene where the sensor is the controller to turn the light on fast Set the "off" time of the detector to the longest time possible if possible Use a program to detect it "switched on" and use a wait of my choosing and have the program switch it back off If you can;t set the off time on the sensor to be long, do the whole thing program only with no scene

The rebuild comment was meant for the scene. Take a picture of or write down the current scene in the ISY. Create a new scene, under the link menu, on eisy and drag the related devices in

A couple of other things related to the iolinc: If the io linc is old, it could be failing. Unhook the light sensor and try completing the circuit several times to see if you get consistent operation directly The io linc is single band, powerline signals only. Something could have been added to you electrical system that is intermittently blocking the signal to the plm. Try temporarily plugging a dual band plug in device like a lamplimc behind the iolinc and see if things improve

You could, but I would simply look at the original and rebuild it from scratch on eisy... It will take less time

What does the plm links look like? I would pick a few wired in and plug in modules and individually right-click on them and pick "restore device" and retest devices. Did that help?

PLM Links and iox links. Can you post those 2?. They should compare identically, or close to it. I can see only 2 links in the picture and one of the 000s. That's not good. Also, what does PLM Info/status say when you look at it? Where this could be going is that the last back-up you had, backed up a corrupted link table from a failing PLM. Do you have other, older backups?

Under Tools/Diagnostics there are options to see PLM links and ISY links. Can you capture and post both of those?

Start iox and turn on the event viewer level 3... And try to be in view of it. Repeat you tests while watching the event viewer.. how many entries show up per switch action... First time vs against presses

All great questions that don't have answers yet. The link you provided is all that can be known at this time. When they're certain its good to roll out, we'll get a post with all the answers.

Need some clarity, your ultimate goal is to upgrade the 994 to eisy and sunset the 994? If yes: Don't upgrade or make changes to the 994i Set up the eisy There are 2 PLM variants: USB version can go ~10' Serial can go ~50'... + UDI offers a serial > usb adapter I would get a new USB PLM for the eisy Set up eisy with the new PLM How many programs do you have and how big are they? If not a lot of programs and not that big, re-enter them into the eisy as you migrate devices, one room or one function at a time Come up with a plan to move one room or function of Insteon devices at a time to eisy Delete a room or group/function of IInsteon devices from the 994 Add them to the eisy and verify Add related scenes and programs Give it time to verify everything works Go to the next room or function Not clear on the wiring need of the ezio, but you should be able to get a 50' CAT 5 or greater cable to work

You can try Start Linking under Link Management and put it into linking mode (Press and hold Dim and Bright at the same time for 10 seconds)

The journey that got you to this point is not clear. What steps did you take to get to that point?

First, do you have Lutron's serial command spec, is publicly available, not proprietary? If yes, it will require some digging, but it's plausible. There are products that can accept REST calls and communicate serially. eISY Network Resources can generate REST calls: iox program statement > Network Resource > Your network > Network/Serial controller > Homeworks. Here are some Network/Serial controllers to look at: Lantronix XPort or UDS: These are industrial serial-to-Ethernet device servers that allow serial devices to connect to a network and be controlled via IP. Lantronix also offers some models with built-in web interfaces. USR-TCP232: A series of low-cost serial-to-Ethernet converters, with REST API support. Moxa NPort: A widely-used serial-to-Ethernet gateway with various models that support different protocols, including HTTP/REST API for controlling serial devices over the network. Raspberry Pi. Petty sure it has a serial UART on it. There'll be tons of examples to search for but you're likely looking a python coding to receive the eisy's Network Resource call and turn it into RS232 commands Also, figuring out the RS-232 pin out will be required for any solution. It's going to be a bit of technical exercise

Has any one tried with this with insteon i3 paddles? I only have those as switches which have not flickered, but 2 micro dimmer modules in scenes with the i3s that occasionally do. It's not all the time but I can recreate it sometimes getting the modules to flicker when generating insteon traffic. It usually takes actions that are not normal, eg turning the same switch on/off several times back to back. It's all the same brand/model of recessed led lights. They're all older, ~5 years old. If the comment level gets high enough, I'll try swapping the problem locations with newer recessed leds. I believe the i3s are triacs too which probably makes this a long shot, but alternatives to the are being discussed here.

The hub question should be posted here To @Guy Lavoie's point, Amazon echo is supported through the UDI portal, not the 994 specifically. Even though the 994 is at end of life, Amazon echo through the portal should work

I use http://<ISY local ip address>:3000 ( not https: ) as the pg3x server is located there. It will give security warnings but I move through them as it's a local only connection. Try that in a browser window. I don't know why iox sent you where it did.

Not sure exactly what you're looking to do. You can right click on the scene name and see the options. You can also "click and drag" devices in to scenes as well as scene members.

Can you post the scene in question?

The portal can support multiple devices. Add the eisy and maintain both as long as you need to.

I've had Samsung and LG tvs.. I think you have to enable something on the tv to allow it to use local network discovery, something in the tv's menu