Guy Lavoie

What exactly do you mean by "local access"? IoX finder is not showing your controller? If so, try clicking on "Add" and writing the URL manually. For example, if your controller appears in your router's device list as 192.168.0.123, then the URL would likely be https:192.168.0.123:8443/desc

How about a simple test for the PLM: try manually linking a spare switch or module to the PLM, just using the link buttons on each device. Just to see if they can talk to each other, without the isy being involved.

He's logged in on the console (physical keyboard and hdmi monitor) so no network access is needed to log in and see this.

We love happy endings 😀 Good to know. So no automatic updates, but there were some unintended update errors caused by this.

Look at the file: /var/isy/FILES/WEB/sysconfig.txt Scroll down to the *****IoX******* heading and you'll see the version on the following line.

Since you can access it on the console, what happens if you try to reinitiate the acquisition of a ip address? Something like this: sudo dhclient -r re0 What error message do you get, if any?

What version of IoX were you running up until now? 5.9.1 or older? If older, any hints that an update might have happened? Tried just unplugging and reconnecting the network cable, or a different cable? Everything else in your local network is working as before?

Well, if the distance is too great for the technology desired (Insteon or zwave for example) but you have wifi or wired ethernet, you could set up a separate controller (like a ISY994i) and have your master controller, like a eisy, send commands to it using REST commands. That might be a useable solution if the number of devices to be controlled is small. Tracking status would be more difficult however.

If you can detect the double tap as an event in a program, then you could have two programs, something like this: If switch double-tap on event Then set motion detector parameter 1 to <enable> If switch double-tap off event Then set motion detector parameter 1 to <disable> I don't know these devices, so I can't tell you what is settable or not by program statements.

Which Insteon device has no link button?

The mystery here is that Insteon is working but not X10, and (seemingly) only X10 transmission with the eisy. It's as if the PLM was unable to transmit X10. Yet another PLM was tried with the same results. The hardware connections like the PLM cable seem ok since Insteon works. The next thing I'd try is moving the PLM to an outlet on a different circuit, and maybe on the alternate phase. It sounds like there is a X10 signal issue, at least in some area of the house. Alternately, try a X10 transmitting device (like a transceiver) in the same outlet as the PLM. Is that device now having trouble transmitting? Has anything been added that might be a "signal sucker"? We add and move so many electronic items nowadays that this might be hard to really be aware of.

Have you tested to see if your eisy can receive X10 signals? Do you have programs triggered, or variables set by received X10?

If I'm not mistaken, after a while it will also disappear on it's own.

It's in nostalgia mode. Have you tried highlighting the line and clicking on "delete"?

Yes, the X10 module was mostly a convenience, allowing you to add X10 devices to your device list. It would still be handy to a user who is looking to replace a defective unit and recover from a backup, without needing to edit all the programs.

If it doesn't already have the X10 module, you can't add it anymore. If you want to stick to a ISY994i, you'll need to find a used one that already has any modules you want.

Oh the (X10) memories! One thing I had acquired at the time was the Elk ESM1 signal meter. It turned out to be handy for this kind of thing. I sold off a bunch of X10 stuff but I hung on to that meter, because the bar graph shows signal strength of anything around the 120 kHz frequency, which is close enough to Insteon powerline signals. It helps me see any residual noise, as well as Insteon transmissions.

Yes, some individual skills have it. The Venstar thermostat skill also says the temperature. As UDI users, we'd like a generic variable -> spoken number capability.

Having that functionality would certainly be a boon. I wonder if it's something that UDI could add into their portal integration.

The ZWave backup and ZWave restore is the way I also understand it, since you're already using the Zwave/Zmatter board. The "Migrate to ZMatter/ZWave" menu option only appears (in the Configuration -> System menu, not Zwave) if you're currently using a Zooz 700 series stick and you want to go to the ZMatter dongle.

There might be more than one way to delete plugins, but the one I know is by going into IoX ->plugins ->configure. then pick the slot group and then plugin you want to delete. The configuration screen will come up, and click on "dlete" at the bottom.

Then start slow, and learn. Variables allow lots of flexibility in programs. For example, define a state variable, with a name like s_test. Then create a program such as: If s_test = 1 Then (turn on light) Then manually edit the variable value (in the same screen where you defined it) and set it to 1, and watch your light turn on. Variables are a great way to have one program trigger another, etc

Have you ever used variables in your IoX programs? There are two types of variables: integer and state. The difference is that programs can be triggered by the value of a state variable. Furthermore, in the portal you can define an action to be triggered by the value of a (state) variable. then you can use the Alexa app to define a routine triggered by that value.

It might help if you'd specify the make and model of your thermostat, and a screen shot of the device as displayed in the admin console.

I've had good results with the Venstar T7900 thermostat. The heating element that larrylix is referring to in mechanical thermostats was the "anticipator" winding. This was when the thermostat used a bimetallic coil to sense the temperature and a mercury bulb to switch the furnace on and off. The weight of the bulb made it difficult to obtain a narrow deadband, so the anticipator winding heated inside the thermostat a bit when the furnace was running, making the bimetallic strip come closer to tripping when the setpoint was reached, and narrowing the deadband. Electronic thermostats don't have this problem, and can be made to have very narrow deadbands, which can also lead to inefficient short cycling of the heating/cooling equipment. To even things out some will have adaptive software, and/or settings to specify minimum run times to avoid tripping off after only a short run time due to a random air current or other transient condition. Some "smart" thermostats will also learn how far past the setpoint the temperature will get after stopping the equipment and then adaptively stop it earlier to avoid overshoots and keep the air temperature closer to the desired setpoint.