Guy Lavoie

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!

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.

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?

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.

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.

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.

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.

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.