Guy Lavoie

Maybe you could keep the micro module and light sensor as a weatherproof motion sensor combination, and replace the lights with smart bulbs (Does Hue have weatherproof floodlights?) that are hardwired to line voltage, controlled by a program.

Understood. I wasn't familiar with the micro module.

Well I can see this being useful when implementing some new functionality and you want to monitor it for a while to make sure it's working as planned. Logging security events might also be a useful application.

I do something similar to Paul, which is basically detach the motion detection from the action, by having a program in between the two. I use Insteon motion sensors in my basement to turn on a Hue bulb for a short time, for those situations where I'm just going there to get something momentarily. This avoids the need to turn on the big ceiling fluorescent lights for just a minute. Having a program allows it to retrigger by new motion, and avoid the motion sensor turning off the lights because it's timer is up (I do the opposite of Paul: I set it to the shortest on time, and ignore the off signal altogether). It's the program that sets the on time. I can also make it time of day sensitive as you are doing, and also ignore the motion sensing and the Hue bulb if the fluorescent lights are on. Post your program. It should be easy to figure out.

To add to Paul's questions: does the light detect device have it's own status indication, that you could compare with that of the iolinc?

So the problem seems to be one of hysteresis, where the varying light level isn't tripping the sensor output reliably unless the swing in light level is large or fast enough. There isn't much that you can do to program around that if you don't have an actual analog light level reading. The momentary C setting above is for the output relay of the iolinc, so it isn't relevant to what you're using it for.

Was the old breaker an ordinary breaker, or a special one (like GFI or AFCI)? A breaker producing noise would be quite unusual, unless it was very old and the contacts were worn, producing arcing or something like that.

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.

Well, let's just see if these guys chime in, or if they have a workaround process, or a systematic procedure. Thanks.

There are generic rack mount shelves you can get. A simple 1U shelf would be good, plus you'd have room left for other devices.

Well the eisy can certainly communicate with a serial PLM for Insteon using a USB adapter. But now the question is: if you can add a second USB adapter, how could you talk to it? There are no programming options to access a USB or serial device. You would need to have a module like the networking module, but to talk to a serial port over USB. I did experiment with accessing a serial device server from a python program over IP. It works. But a plugin would need to be developed to do this. I'm experimenting with creating a plugin that communicates with that serial device server, but for another purpose.