Goose66

I would try and either 1) buy switches that will be field-upgradable to Matter over Thread or 2) buy cheap/used Insteon or Zwave until Matter switches become available.

I have never used the Rachio node server before so maybe I shouldn't be commenting, but the error is "[Errno 61] Connection refused" which often means there is already a connection to the socket at that port. Is it possible that Polyglot v2 version is still running?

Looked at the log, and I can't figure it out. The 20/A0 message doesn't seem to follow any pattern timewise, sometimes occurring seconds apart and sometimes 20 minutes apart. I thought it might be correlated with your frequently cycling AC trouble status, but it doesn't appear to have anything to do with that. The data appears to be a 3-byte hex string, which doesn't match data with any of the documented commands. The data appears to be relatively consistent (just one bit changes) so it's not time related. Searching the Eyez-On forum and Googling doesn't reveal anything. Do you have a DUO or SideKick that may be sending something specific to status of the communication link? Let's wait and see if anybody else gets these or similar. BTW: The unhandled command 81 is normal when you have SmartZoneTracking enabled. This is the EnvisaLink's zone state update and it's simply ignored when the node server is tracking the zone states.

The actual command from the EnvisaLink is either "A0" or "20" due to a quirk in the way the API module deals with ACKs vs. incoming commands. But I don't know this command, and it's not documented anywhere. I would like to see a log file taken with log level set to Debug. You can DM me the file, please.

You should be able to drop the KeyPad Linc button in the scene as a controller and the Ceiling Fan in the scene as a responder, then set the Ceiling Fan link type in the scene to "Command" with command "Set Speed" with the parameter "Speed" set to whatever speed number you want. Turning the scene on should set the fan to the selected speed. Turning the scene off should turn the fan off. If you leave the link type of the Ceiling Fan in the scene at "Default," then when you turn the scene on it should indeed turn on the fan back to the previously set speed (as remembered by the Bond bridge). EDIT: I was going to point out that you could also use the Link Type of "Default" and set an On Level percentage, but this does not appear to be an option. Seems like it use to be. You could use a "Command" type of "On" and set a percentage there. The node server was designed to allow the fan to respond to DIM and BRT commands as well, so that an Insteon SwitchLinc Dimmer could be used to control the fan speed, but that appears not to work either due to a design problem in the node server. Right now DIM and BRT commands make the fan change its speed in one speed number increments, instead of the percentage changing the correct amount and then the fan calculating a new speed number from the new percentage, as would be more intuitive. I don't currently have any Insteon SwitchLincs in my new townhome, and I wasn't going to install any due to Insteon being defunct. However, I do have 10 or 12 switches in boxes and no other alternative right now, so I may install some just to get some basic functions working, then I can play with this design.

@hart2hart Sorry for the late reply: 1) One of my favorite shows as a teenage/young adult male (you da bomb, Mrs. H!) 2) Speed is a state value of the fan device. You can control it from the Admin Console, you can retrieve it and set it in programs, you can drop the fan device in a scene and have Insteon and ZWave devices control it. It doesn't fit standard ISY node design patterns to have separate nodes (i.e., separate devices) for the individual speeds. BTW, speed is accessible two ways: The default state value (ST - "Fan Speed") of the fan, that can be read and set as a percentage value of the max_speed number of the fan, and a separate command "Set Speed" that can be used to set the fan to a specific speed number, e.g., in your case 1, 2, and 3. This was done to both give discreet control to fan speed as well as allow the fan to be dropped into a scene with a dimmer switch and and allow the dimmer to control the fan speed. 3) Dimmable lights are only added for fan lights where the brightness value can be set to a specific value (i.e., supports "SetBrightness" API command). This is because that is the only way the node server can control the brightness. If your fan simply responds to the holding of a button to alternately brighten or dim the light (specifically made for interactive control by a human), then there is no way for the node server to recreate this behavior programmatically, primarily because it doesn't have access to a light sensor to know 1) what the brightness level currently is and 2) whether the action from the button is currently brightening the light or dimming the light. That said, if your fan light can't be set to a specific value but has separate commands (buttons) for increasing brightness and decreasing brightness, there is an argument to be made that there is an interim light type between "LIGHT" and "NODIM_LIGHT" that could be supported by the node server. I would be interested in hearing from folks in this regard. The unfortunate truth is that I currently (after the move) only have two ceiling fans of exactly the same type to work with, and they only have light and brightness toggle buttons, not separate light on or off or bright or dim commands (buttons). If you could provide the FCC ID of your remote, I might be able to set it up as a device in my Bond Bridge and then play with it (without the actual fan to see the real-world response) and see what I can do in this regard.

Yes. It's next.

I have released the PG3 version of the EnvisaLink-HW Node server (v3.0.3). The EnvisaLink-HW node server provides an interface for the ISY to a Honeywell/Ademco Vista series alarm panel through EnvisaLink™ EVL-3/4 and DUO™ adapters from EyezOn. See http://www.eyezon.com/ for more information on these products. Installation instructions, release notes, and version history can be found here: https://github.com/Goose66/NSDocs/blob/main/evlvista-pg3.md. There is a 1-month trial period and then the node server is a one-time purchase at $10.95.

Like photos of my new eisy?

Should I even bother to hang my Polisy w/ USB PLM on the wall in my new townhome?

Is this meeting open or invitation only?

I don't mind using an Insteon Hub and Insteon Website/app to configure my Insteon devices if it means I can leverage my Insteon investment (which was severely reduced in my move). I will even pay a monthly fee for Insteon access assuming it's reasonable, but that will simply hasten my transition to ZWave or RadioRA3. But it only makes sense if the hub has an API that allows integration with smarthome integration platforms (e.g., Polisy, Smart Things, Home Assistant, etc.)

Glad someone will be there. We need to push for an API because I feel like the motivation to maintain native support in Polisy may be waning (and who can blame them).

What about a (preferably local) public API for the hub(s) to allow integrations with Insteon products.

A new version v3.0.10 is available that fixes this problem and a few others raised by changes in the Bond v3 API and newer versions of PG3.

A new v3.0.10 version is available in the Node Server Store that fixes this problem and a couple of others raised by changes to the Bond API and PG3.

A new version v3.0.10 is available with bug fixes - primarily to account for the Bond API changes with the v3+ firmware versions.

Development environment back as of Friday. Will be done this weekend.

Still completely dead in the water as to Polisy, PG3, and IoP. At this stage, my Polisy is a brick. We've reached a point in the architecture evolution where node server development is 20% coding and 80% trying to keep a development environment running. Hopefully will get some time from Michel on my service ticket this afternoon.

I believe the hubs offer a local API (I think a TCP socket) to read and write serial data from the PLM inside the hub. Requires polling and speaks low level Insteon PLC commands. It could be something that UDI implements into their native Insteon support to add available Insteon interfaces, but makes little sense for a node server because a lot if not most of the higher level Insteon functionality implemented in the ISY would have to be duplicated.

If "Ken" would open up a local API (with UDP broadcast of state changes) on the hub simply for sending commands and receiving state changes, someone could write a node server for it. I would be glad to design the API (something along the lines of the Bond Bridge API). That way, configuration of Insteon devices (old and new) could be done through Insteon apps and websites, transition to Nokia devices would be a lot easier, and UDI could drop their native support for Insteon devices in favor of something more open, stable, and with more of a future, like Zwave.

Also the date in the IoP Admin Console on my Polisy says Sun 08/31/1952. So that ain't good.

A quick update: ran some test functions on the API code and found the problem. Seems the latest version of the bridge firmware added an additional hash value in the device list (identified as "_ _" instead of the existing "_" that is used internally. However, I was only screening out "_" from the list of devices for further query. Quick fix. However, I can't get the latest version of Polyglot v3 (or IoP, for that matter) to install on my Polisy, so I am unable to test the Node server with the API changes. I have to go out of town today and attend to a family matter and won't be back until Monday. I will circle back to it then.

Right. But it's not upgrading IoP. I ran an upgrade of all the packages on my Polisy (including the UDI packages) separately when I booted up the Polisy initially. But the "Automatically Upgrade Test-Polisy to 5.4.4" in the IoP Admin Console is not upgrading IoP to 5.4.4 (remains at 5.4.2). In addition, Polyglot v3 on the Polisy is not getting upgraded either (remains at 3.0.55). The net-net is that I can't get anything up to latest versions to test changes to a Node server before I roll it out.

I had AT&T Fiber at my last home and had painstakingly gone through all my devices and set the timeserver to be my Ubiquiti EdgeRouter since outbound NTP seemed blocked. Then my EdgeRouter died and I spun up the AT&T gateway in router mode at the same address, but it would not serve time to local devices. Then I moved (completed a week ago) and now have Spectrum with an Orbi mesh Wi-fi system/router and have painstakingly gone back through and set all my devices to sync with their default timeservers over the Internet. Just one man's story. I wish timeserver was part of DHCP protocol. EDIT: After a quick Google I guess I should say I wish NTP timeserver was supported from DHCP by consumer-level devices like my Orbi and/or I knew how to set it up for Windows, RPis, and FreeBSD machines.