Goose66

The OnQ boxes on Amazon were exactly what I was looking at. I was just wondering if anyone had put the Polisy, PLM, and maybe a UPS or transformer all in a box like that and what the performance was. It would certainly be nice just to mount it on the wall open like @Geddy's picture, but I don't think that would fly with the wife - especially if it is in the hallway. I particularly like the built-in bubble level. Can't have the whole thing tilting and all the electrons pooling on one side! 😁

My new townhome has sufficient living space, but significantly less utility closets and unused/dead spaces than my house did. I need to install my Polisy Pro (destined to include ZMatter board) in a central location in the home - perhaps a laundry room or hallway. It needs to be installed with an Insteon PLM and a small Li+ UPS (like the TalentCell unit). WAF probably requires that it be installed inside a box, either one flush mounted in the wall or perhaps surface mounted (if in the laundry room). Has anybody had experience with mounting a Polisy with Wi-fi and/or Zwave radios inside an enclosure and/or wall mounting such in a visible location, and what solutions have you found?

Note that the TalentCell comes with a 2A power supply. It’s fine for ISY (and probably Polisy) and keeping the battery charged. However, if you’re going to run more things off it, you will need to up the amperage of your 12v PS accordingly.

So the initially reported version in the Dashboard on startup comes from the local database entry in PG3 database. But a few moments after startup, the Dashboard shows the version indicated by the running node server code itself. I had one that was doing what you described, and it was because the code package specified with the new version either wasn't being found or failing on unzip/install, and what ended up being started was the older version, despite the fact that PG3 thought the new version was installed (in my case it wasn't finding the specified zip file on the Node Server Store servers). Choose one of them and work with the node server developer to go through the log package and see if you can troubleshoot what is (may be) failing on the installation of the update. WRK

Update PG3 using the Admin Console in IoP - specifically "Configuration"->"System"->"Upgrade Packages."

@Panda88, if you are running the Python interface for your node servers, you can drop the server.json file and just pass a version string on the poly.start() call. That way, there are only two places (Node Server Store purchase option(s) and version string passed to poly.start()) that have to be kept in sync.

This is a question for @bpwwer.

I recommend the TalentCell Mini UPS: https://www.amazon.com/dp/B07WLD32RP?ref=ppx_pop_mob_ap_share

I have released the PG3 version of the iAquaLink Node Server (v3.0.9). The iAquaLink node server interfaces with the iAquaLink™ cloud service to allow the ISY to control Jandy® AquaLink® pool controllers and accessories. See https://www.iaqualink.com for more information on iAquaLink™. Installation instructions, release notes, and version history can be found here: https://github.com/Goose66/NSDocs/blob/main/iaqualink-pg3.md There is a 1-month trial period and an annual subscription price of $10.95. Similar to MyQ, the subscription price is for keeping up with the occasional breaking API changes that Zodiac makes.

It was a team effort!

@Chris McKean Please try upgrading your version of PG3, then reinstalling the node server. Send the new log file if it still fails.

@Chris McKean Also, please send a new log package with the attempt to reinstall the Bond node server.

Yes, the error is caused by the fact that the 3.X firmware on the Bond Bridge introduced something in the API that breaks the 3.0.9 version of the node server. So the problem here is that you can't upgrade to the 3.0.10 version, but I don't understand what the problem could be. Others were able to successfully upgrade to version 3.0.10 without problems. What version of PG3 are you running?

Also, there's no reason the 16 devices should have disappeared from your Admin Console simply because you are upgrading the node server. So if you had 16 device nodes under the bridge before and now they are gone, there is something else additionally going on here.

The problem is indeed that you have the 3.X version of the Bond firmware but the older version of the node server. There are a couple of other posts in the forum in regard to this error, and v3.0.10 fixes it. Have you tried going to the node server store and manually upgrading the node server? I see no indication in either log that Polyglot is trying to install the new version of the node server.

I will need to see a log, but my suspicion is that you upgraded your Bond Bridge Firmware to 3.X but since your node server is staying at 3.0.9, it is failing. The 3.0.10 version of the node server was primarily to fix a change introduced in the 3.X Bond firmware. What I don't understand is why all your devices are gone. Did you delete them before you upgraded the Bond node server? I will need to see a log package to understand why the Bond node server is not updating to 3.0.10. Please DM me your logs.

I have released the PG3 version of the VenstarCT Node server (v3.0.9). The VenstarCT node server provides an interface for the ISY to Venstar ColorTouch series of thermostats through a local API. See https://venstar.com/thermostats/colortouch/ for more information on thermostats. Installation instructions, release notes, and version history can be found here: https://github.com/Goose66/NSDocs/blob/main/venstar-pg3.md. There is a 1-month trial period and then the node server is a one-time purchase at $10.95.

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.

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.

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.