Guy Lavoie

https://bondhome.io/product/bond-bridge/?srsltid=AfmBOorgH_cOydFlDoW4OqUwL9_0NPRQfd2bycSXlSLF6FhhDMW0Jnqs Not sure if it can learn new devices, or if it can be controlled via a local API

That's neat, and I think we all learned a bit more in the process 😀

Interesting, thanks. So a keypadlinc toggle button sends dim commands if you hold it down. I'll experiment with that.

Well, could you explain how the keypad (a Keypadlinc?) button is configured. We might learn something here.

For Alexa, see here. Scroll down to Using Alexa Routines https://wiki.universal-devices.com/index.php?title=ISY_Portal_Amazon_Echo_Integration_V3#ISY_Can_Talk_To_You.21_.28Alexa_Routines.29

Well how are you doing it? Triggering scenes? That would work. But he wants real time control, manually.

It's the fact that you need to use a program at all that's the limiting factor. Dimming is usually a realtime thing that you do manually and intuitively, and doesn't lend itself well to translation. Take someone who speaks English fluently and someone else who speaks French fluently, and now add a translator between the two. The fluency is lost.

Well that's it, this is an early attempt at implementing it, and is even labeled as being beta. It's an opportunity for us to get up to speed early on as to how it will work. I bought that Cync bulb for the very purpose of familiarizing myself with Matter, because it looks like over time, this should become as common as "works with Alexa" and such on packaging. I've already managed to get that bulb working with a Google mini speaker, and the learning experience has been very productive. Because Matter is being presented as an interoperability standard (and not another communication protocol like Zwave or Zigbee), this is of particular interest to people like us, who like the UDI controller because it is already a unifying component for us. Insteon, Zwave, etc all brought to a common level (nodes) that we can program with. For the longest time, we've been patching together these independent ecosystems with solutions like the eisy. For the first time, the automation industry itself has finally recognized the interoperability problem and has actually done something to address it with Matter.

Since translating your intentions from an Insteon dimmer to a Hue bulb requires using programs, there is no easy solution. You could try creating a bunch of programs, each one for a range of desired dimming, but you're still stuck without real time control, because of the way Insteon sends the final dim level as previously mentioned.

Fading up and down in real time isn't very likely to work with programs because when you dim an Insteon switch manually, it only sends the new, final dim level when you let go of the paddle. This means you'll be limited to detecting a dim level (more like a range) with one or more programs, and/or detecting fast on/off commands, and then sending equivalent Hue commands. Things like that. You'd need to post your program(s), to see what it's trying to do.

Well that's better. It wasn't clear from your description. So you're using programs to detect the Insteon switch status, and then send Hue commands via the plugin?

That's contradictory... If you set the Insteon dimmers to anything less than 100%, then the bulbs aren't getting 100% power anymore. Try powering your PC through a dimmer and lower the level to control the screen brightness... You'll just blow the power supply, or dimmer, or both. The Hue bulb is a computer. It needs 100% sine wave AC power to operate properly and do it's thing, which is to receive commands to dim, change colors, etc.

Do you mean that you are trying to use Hue bulbs powered through an Insteon dimmer switch? That won't work, and can possibly damage the Hue bulbs. Hue bulbs contain electronics that need constant, full line voltage. Any functions like dimming need to be done by the bulb itself, through Hue commands. You could use regular LED bulbs, but then again some are dimmable, others aren't. Read the packaging carefully.

It was mentioned several weeks ago that all portal renewals were now one year only.

It's a wifi bulb, and supports either their own app, or Matter. I actually went to the hardware store just to find an inexpensive Matter compatible bulb that I could experiment and learn with. I did manage to link it to a Google home mini speaker, and it works. I tried Matter linking inUD mobile with: 1- The bulb itself 2- A Philips Hue hub 3- The Google home mini, as a shared device In each case I get the same 500 error code. In the situations where the device or app only gives me a numeric pairing code, I used a website to convert it as text to a QR code, and tried scanning it off my computer screen. The UD app would show the correct pairing number when scanning it, but still give the 500 error. In the case of the Hue hub, the pairing code is only valid for 15 minutes. then you need to get a new one (the usual Philips security paranoia!) As for multiple sharing, it might depend on the capabilities of the individual device. The bulb might not have enough smarts to share to several hubs, but hubs (or some hubs) might be capable. All part of the learning process.

Quite likely. In the documentation of the GE Cync bulb I tried, it said that the bulb can be set up either with their app or with Matter, but not both. Probably the same thing applies to being linked to two Matter hubs.

I haven't tried that, but since the serial port is normally used for an Insteon PLM, then that port would not be enabled as a login port. Back in the old Unix system V days, the port would be enabled in /etc/inittab. This would be different in FreeBSD, looks like it's /etc/ttys. The serial port appears to be /dev/ttyu0 Look at this link to see how how to set this up. Scroll down to section 29.3.1 https://docs.freebsd.org/en/books/handbook/serialcomms/ Once you get that figured out, find the equivalent for the OS you want to install.

Same here. It looks like there is something missing when it comes to actually adding a device. At least we're getting a feel for how it will be done.

I know, the terms are confusing, and overlap somewhat. I'm only about 8 months into being a UD user so the learning curve is still fresh in my mind. ISY used to be the name of the device itself (ie: ISY994i, and some previous models. Then they went from a custom box to a more general platform running FreeBSD Unix, (first the Polisy, then the eisy). The only product sold now is the eisy. The term ISY is still mentioned now and then, but we generally say IoX instead. IoX is the application that runs on the Unix machine, giving us the automation controller capabilities. A bit like you'd say running MS Word running on Windows. PG3 is the development and runtime environment that allows external programs (plugins) to add functionality to IoX.

In the program list screen, right click on "My Programs" and click on "Find/Replace". You'll get a screen like this: In the second line (where I have Lab dimmer), choose the light that is turning on when it shouldn't, and then click on "Find". You will see the programs, if any, where that light is referenced.

Do you have programs that look for status changes in your light switches?

Right here: https://polyglot.universal-devices.com/

Hah, another case for keeping things local!

Thanks. It's igb0 that has the ip configuration, and includes IPv6 information. My Polisy is connected by the wired network port.

I also retried scanning the original bulb's QR code, being that the bulb is now configured on my network. No go. One thing that remains to be determined is if my Polisy is configured and recognizing IPv6. Anything I could look at from a unix command line?