Guy Lavoie

Just for fun, I created a scene with a Jasco z-wave on/off module as a controller, and an Insteon wall switch as a responder. It works; turning the Jasco module on and off controls the scene perfectly. So the eisy can certainly use z-wave devices as scene controllers.

If you look at one of your z-wave switches in the admin console device list and turn the switch on and off manually, does it's status update in the admin console? If so, then you could look for the status change using a program, and have the program correspondingly turn the scene on or off.

You mention migrating. From a ISY994i to a eisy? Are you reusing the same PLM or is this a new one?

Yes, you can program the eisy to send a "query" to the IOLinc. This asks the module to send it's current status. I do this with a garage door opener application. The IOLinc is not a dual band module, it's powerline only. This makes it more likely to lose a signal transmission if it activates a motor driven device that produces electrical noise. To poll it's status regularly, you could schedule a bunch of hourly requests, such as like this for every 15 minutes: If Time is 8:00 Or Time is 9:00 Or time is 10:00 .... Then Set (IOLinc name) Query Wait 15 minutes Set (IOLinc name) Query Wait 15 minutes Set (IOLinc name) Query Wait 15 minutes Set (IOLinc name) Query But before doing all that, try activating the gate with your program, then wait for the time it takes the gate to open or close, plus 10 extra seconds, and then adding a query statement after that. This would have it queried after the time that the motor has finished opening or closing the gate, when the electrical noise has stopped. See if that makes a difference.

Here is my idea about how it might all work (just speculation based on what I've read so far). Matter is an IP addressable protocol, so it would likely have a very well defined set of instructions and definitions for generic support. Much like "Class compatible" USB devices that need no drivers. As for physical layer, it supports both straight IP (hardwired and wifi) and Thread, which is a mesh network, like Z-wave and others. Battery powered devices will likely use Thread. Both both physical layer types support IPv6 addressing. Think of it as a type of dual band capability similar to Insteon, though I don't know of devices can act as repeaters across both physical layers the way Insteon does. Thread uses 2.4 GHz frequency, like Zigbee. I saw somewhere that the Zmatter dongle will use the Zigbee antenna for Matter too, which would make sense. So it would appear that the Zmatter dongle could be the equivalent of a wifi access point, but for Thread. Since both physical layers support IPv6, maybe the dongle will create it's own subnet and act as router? Who knows. Straight IP wifi or hardwired Matter devices probably won't need the dongle at all if you don't have any Thread devices. I can't wait to find out how wrong I am!

I had been wondering where "SkyLink" on the box came from. It was the only Insteon product with that.

Well no one has seen it yet, but I would be extremely surprised if Matter support came in the form of a plugin. It just wouldn't make sense, especially with the Zmatter dongle being part of the equation. I expect it to be integrated like z-wave is.

I'd say more than likely. In ISY, everything becomes a node, and get equal treatment in program statements. Even devices that are created by plugins. The notion of scene is also democratized among all types of switches, not just Insteon. You can have an insteon triggered scene also turn on z-wave devices, etc.

How long does the 9V battery last in the winter?

Can you tell if the flicker is being caused by the motion sensor sending out it's rf signal (which would be unusual) or if it's from the powerline and rf signal being sent from your controller to the on/off module? One way to tell would be to temporarily disable the program turning on the receptacle, and see if the flicker still occurs when the motion detector is tripped. If it seems to be caused by the command being sent to the receptacle, do Insteon commands sent to other devices also cause the flicker?

Agreed. Just brainstorming here. Yes, Hue is expensive. I only mention Hue because I'm familiar with it. It does work with a polyglot plugin. But getting Hue just for this is a bit expensive, since you need the hub too. The second micro module looks like the best solution, and you're familiar with it already.

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.