Guy Lavoie

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.

Many of the handy features in IoX are those for maintaining and upgrading an installation. I'm talking about things like restore device, PLM replacement process, replace switch with... etc. I've just had the pleasure of using the replace feature to upgrade several switches to dual band models. One constraint is that it only allows replacing a switch with one of the same type (dimmer with dimmer, on/off with on/off). It would be handy if this feature also allowed replacing one with the other type. It could list the differing type switches at the bottom of the list, and selecting one could pop up a message warning that this is a different type, and that adjustments might be needed in programs and scenes. Sometimes you only want to replace a switch that is used as a 3 way slave, so it doesn't matter what type it is. Or simply don't need the dimming feature anymore in a location and want to reuse it elsewhere. Economics and availibility. Food for UDI thought.

The utility of the virtual switch is that it can serve as a flag for following the status of a scene. If all the lights in your scene are lights that can also be controlled individually, then you can't know for sure if any given light was turned on by itself or as part of a scene. If you want to keep track of if a scene was activated, the idea is to add a virtual switch as an additional responder to the scene. The virtual switch doesn't have a physical control, so the only way it can get turned on or off is with a scene command. So let's say that the eisy turns on the scene, and you'd like to update the backlight for that scene on your keypadlinc: First you create a new scene with one of the switches that can control the scene as a controller, and add the keypadlinc button as a responder. You might already have this if you have switches other than the keypadlinc that can turn the scene on or off. You might need to create a new, separate scene if it has the keypadlinc button as a controller, because you can't have the same button both as a controller and a responder in the same scene. I name these as "reverse" scenes. Now you create a new program that looks for the status of that virtual switch turning on or off, and have the program turn that new scene on or off, for the purpose of updating the button.

I also have keypadlincs and I like the button to reflect the status of the last scene command, wherever it originates from. This is especially true of keypadlinc buttons that are set up in toggle mode. So what I did was install a plugin called "Virtual" with which you can create virtual switches. It's a free plugin. Then I added a virtual switch to the scene as a responder, so that it get's turned on or off with the scene, no matter who/what turns the scene on or off. After that I added a program which monitors the status of that virtual switch, and sends the appropriate on or off command to the keypadlinc button. That keeps it in sync perfectly. If you have a light that is only ever turned on as part of a scene, then you can monitor the status of that individual light instead, and skip the virtual switch.

1- Please don't close the thread. I think there are still a few things worth discussing, and reliability testing over time. Wow, how long did it take you to write that post? You say that it would have been easier to just start from scratch, but I would argue that everything learned along the way was more valuable, and not just for you... About that quote I just made above: what type of keypads are these? If there is a way to turn off the light on the button by sending a off command to it, then I do have a workaround that is able to track scenes nicely. I have keypadlincs that I do that with.