Guy Lavoie

A program like that will normally only trigger once, when the time interval becomes true for the first time. Ideally, you'd want to mathematically integrate the analog value of the sensor (take several samples over time and take an average). The thing is, you're not reading an analog value, only on/off. The iolinc should normally report a status change when it occurs. So instead you'd need to integrate the on (or off) duration time over a time interval instead, like a duty cycle measurement. But let me ask you, what is this light sensor? A Light Dependent Resistor (LDR)? If so, there might be a way to calibrate it's sensitivity with an external potentiometer or something.

Well retries are also traffic...that shouldn't be happening. Don't let the robustness of the protocol lull you into a sense of overconfidence. If it's all happening on one electrical circuit, then that's already a big hint and starting point. How many Insteon devices and other things do you have on that circuit? I would try disconnecting the easiest devices first and test it again. It's not fun, but there are only so many ways of finding the problem.

Sounds more like a noise issue than actual Insteon traffic. The blinking and delayed response might be caused by retries.

What kind of device (model number) is it, and how old is it? Some types are more known for issues than others.

1- Because we're such a reasonable bunch! 2- Yes, the d-word: documentation. Any extra effort in good documentation will pay off 10 to 1 against a flurry of support issues and tickets. UDI generally has good documentation, but it's just not up to date. This is a golden opportunity to catch up.

They have up until Jan 31st at 11:59 PM before the users get restless! Well, better be a bit later and thoroughly checked out. Either way, I'll wait a bit before upgrading, in case something unforeseen comes up early on. I'm in no rush for Matter functionality.

I have a wood stove. I added a furnace air return on one wall above it, with an older Venstar thermostat (T6800) that activates a blower in the air return to draw more air into it when the temperature exceeds a threshold. It's an external thermistor mounted just behind the return grille. This particular thermostat isn't compatible with the eisy Venstar plugin, but a newer one could be used (I also have two T7900's working with the plugin). An alternative thermostat would be an Insteon 2441TH, often available used for very cheap. The temperature sensing thermistor in those is very easily accessed and removed for mounting externally. I actually have two of these that I'll be using for a solar pool heating project, to have the eisy turn the diverter valve based on the water temperature vs the air temperature in the rooftop panel boxes. I've been doing this for years with my Ocelot automation controller but this will now be an improved version on the eisy. For the wood stove, you'd be monitoring the air temperature close to it, the thermostat's temperature range isn't high enough to directly monitor surface temperatures, but you could establish a correlation of the air temperatures vs surface temperatures first, and go with that.

Another trick could be to have the monitored circuit power a small electromagnet of some kind, and have that next to a Insteon open / close sensor, such that the contacts on the sensor reed switch would open when the magnetic field stops due to power failure. It has the advantage of being battery powered if a separate reliable power source isn't nearby.

Well, similarly for scenes, you can look at the old device's "membership" list on the right side of the screen, telling you what it is a responder and/or a controller for. For keypadlincs, each button has it's own list, for added fun... But it's still a manual process.

If you add the new switch as a temporary device, and you don't see it in the list when you select your old one and do "replace with", then you're out of luck. Eisy won't make it easy. You'll have to go over the scenes and programs involved and manually adjust everything. Interestingly, I had started a discussion about device replacement just 2 days ago:

I just did a bit of googling, and it appears that GE Cync is using Matter. This means that they should work with the eisy soon, as soon as the Matter update is released, which should be within weeks.

No. the Virtual plugin creates a virtual device (switch, etc) in the eisy, mainly for the purpose of acting as a flag in scenes, so that you can do things like trigger program actions on the status of the virtual switch being on or off, having been turned on or off by a scene command. IoX doesn't have an instruction to trigger on a scene command (eg: if Scene kitchen is turned on). Since individual switches can usually be turned on or off by themselves as well as through scene commands, the trick is to add a virtual switch to it, which cannot be turned on other than by the scene command. Monitoring the status of that switch can thus be your indication of a change due to a scene command. The plugin also has other virtual device types than switches (dimmer, generic, temperature) which might also be useful for other types of situations. I have not used those. If you know the protocol and communication type (wifi, zigbee, etc) then you could potentially control them directly with the eisy, or by using the network module.

Yup, I've done it that way. Link it to a spare lamplinc or other module not being used it your home, then link to the lamplinc, selecting "Add devices found in links and keep existing links". Then look at the lamplinc's link table. Works with battery powered devices like mini controllers, open / close sensors, motion detectors.

Ok, thanks for confirming that I'm not missing out on a trick or workaround. I guess the manual procedure would be to: 1- Start by going over every scene that involves the device to replace, and noting if it's a controller or responder, and remove the device from the scene(s). 2- Then going over the programs using the search feature for any programs using the device. What happens if you delete a device that is still referenced in a program? Possible corruption? If so, then delete the lines and note where they were in each program. Otherwise correct the programs once the replacement device is added. 3- Delete the old device and add the new one 4 - Add the device to the scenes and programs that were found in steps 1 and 2 Would that make sense? Anything else, or done differently?

That could actually probably be done. You could create generic raw serial strings (even with binary characters) with the network module, and they would be sent to the IP address and port of a device server by your programs. In the tests I mentioned in my previous post, I use a Lantronix EPS1 print server. I bought a bunch of these for $5 apiece about 20 years ago. Using the Lantronix configuration utility, I configured the serial port on it to send and receive raw bytes on port 3001 of it's IP address. Raw binary data, even with null characters, works reliably, and both ways.