Goose66

Yes, cleared the cache and all that, but Firmware still shows "Polisy v.5.4.2" under About.

Is "Automatically Upgrade Test-Polisy to 5.4.4" under Help dropdown supposed to work? It reboots my Polisy (currently on 5.4.2) but doesn't upgrade it.

Sorry for being out of pocket for so long. Moving is not as easy as I remember it from 24 years ago. Anyway, the Bond Bridge is unboxed, updated to the new firmware, and in the Master BR, and while the fan has to go back (couldn't get it to balance), I will add it to the Bond Bridge for testing and get the Node server working - hopefully by this coming weekend.

Sorry guys, my Bond Bridge, Polisy, and other equipment are all still packed up. I move into a townhome on August 20 and will have access to some of it, but permanently lose access to my iAquaLink pool controller, MyQ garage door openers, DSC Alarm panel and more. I'll see what I can do in September to address some of these issues.

Sorry guys, my Venstar thermostat, Bond Bridge, Polisy, and other equipment is still all packed. I move into a townhome on August 20 and will have access to some of it, but permanently lose access to my iAquaLink pool controller, MyQ garage door openers, DSC Alarm panel and more. I'll see what I can do in September to address some of these issues.

A better comparison for purposes of troubleshooting the Node server would be to compare the operation of the Node server to the Bond app on your phone. The Node server should be (and can only be) as reliable as the Bond mobile app in controlling your fan and retaining the fan state. If you are having similar reliability problems when using the Bond mobile app, then the problem lies somewhere in your Bond bridge - perhaps position, interference, or robustness of the recorded remote signal(s). If, on the other hand, the Bond mobile app is working 100% of the time but the Node server continues to fail, then we can take a look at the logs. Also, if you have state tracking turned on for your devices in the Bond mobile app, you can look at the app to see what it thinks the ISY->node server is changing the state to even if that state change doesn't physically show up at the fan. E.g., you mentioned that your fan remote only has a "toggle direction" button. With state tracking, the app and the node server will present the direction state as "forward" or "reverse" and allow selection of the desired direction state despite the fan only having a "toggle direction" capability. If you are also using the fan's remote to toggle the direction, this tracked direction state in the app will be corrupted and the app/node server will behave unexpectedly. Again, using the app to watch for the intended direction state change is a better indicator of ISY->node server functionality than the fan itself, in these situations.

That would explain the problem. I can maybe open up the code in github and try and resolve the discrepancy, but I will have to just commit it as new version and download to it to my production ISY 994i and Polisy (the only things not packed) for "testing." Otherwise, it's going to have to be sometime after August. The main question for this forum is what is the priority for functionality? How many folks are using the Amazon Alexa/Google Home interface in the portal to control their Venstar CT thermostat requiring it to utilize the standard thermostat UOMs vs. how many people want to program the thermostat and want access to proprietary statuses like "Error" and "Lockout."

This may be a question for @Chris Jahn. If I select a value for a driver in a program defined with one UOM for an If statement, but the Node server reports the value for that driver with a different UOM (even if represented by the same integer value), will the If statement fire?

Configuration parameter for hostname or IP address is named “hostname”. See https://github.com/Goose66/NSDocs/blob/main/evldsc-pg3.md

I guess it depends on how many folks would buy it. Same for AquaLinkRS Node server. I feel like these have been pushed aside for the corresponding web-based control mechanisms, e.g., iAquaLink.

Unfortunately my RPis are all packed up and I can't get to working/debuggable code. But it does look like there are inconsistencies in the profile and the code for Heat/Cool State, the profile making it a custom index (UOM 25) with the 5 values shown above in the editor, but the code reporting the state value from the thermostat mapped to the ISY UOM 66 for Heat/Cool State (which is why the display state value 0 is "Idle" and not "Off.") Unfortunately, since I am technically supposed to leave the Venstar thermostat behind when we leave the house, I may not have it available to test and/or convert to PG3 once we are moved.

No need to dig into RS-485 traffic. That is what the Autelis does - interfaces a TCP/IP REST-based interface to the RS-485 control system of the AquaLink interface. Also, no need for Wireshark or Fiddler to intercept/decipher the REST traffic - the REST interface for the Autelis device is published (again this is its raison d'etre). The PG2 Node server is public and in Github. The information that is missing is the Home Assistant integration side, and this is probably not the best forum to be finding that kind of information.

Thanks for the info. All my development stuff (PG3/IoP) is all packed up for the move. My production stuff is PG2, so don't know that will help. Hopefully late July I can get back to this.

@bmercier Can you confirm exactly what "hint" values the Alexa and Google Home values are expecting? Are they long integers, e.g., "hint = 0x01020100" or arrays (lists) of 4 16-bit values, e.g., "hint = [0x01, 0x02, 0x01, 0x00]." It appears that the folks over on the Slack channel are not convinced these are even used anywhere.

Just an additional note, my Bond nodes, including a ceiling fan, light, fireplace, and shade all show up in both the Amazon Alexa Connectivity and the Hint Editor. Of course, my nodes are coming from the PG2 Node server and not PG3 Node server.

Here are the Bond node hints: CEILING_FAN: hint = 0x01020100 # Residential/Controller/Class A Motor Controller LIGHT: hint = 0x01020900 # Residential/Controller/Dimmer NODID_LIGHT: hint = 0x01021000 # Residential/Controller/Non-Dimming Light GENERIC: hint = 0x01040200 # Residential/Relay/On/Off Power Switch FIREPLACE: # (same as generic) SHADE: hint = 0x01040500 # Residential/Relay/Open/Close If @bmercier or whomever is in charge of the Alexa interface wants to comment, let me know and I can change the hints to support this functionality. Like I mentioned, it's my understanding that if they are being used here, this is the only place, so I can make the values comply with whatever is necessary. Unfortunately I am moving, and this is going to throw a huge wrench into much of my testing and conversion of node servers. Maybe Bond will be one that survives the move.

I am not exactly sure what they "ISY Portal Device Hint Editor" is or where it can be accessed. I came away from my last conversation on the Slack channel regarding hints a couple of months ago with the understanding that hints were dead, were never used by anything, and could be ignored.

Depends on what triggered the close. If the Node server is in "inactive" polling mode (longpoll interval) it's possible that the door went from "Open" to "Closing" to "Opening" and back to "Open" so quickly that the Node server never sees the status change. If the closing was initiated from the ISY, you should at least see the transition from "Open" to "Closing," and then a transition back to "Open" in the MyQ Node server logs.

That button should say “Force Update”. It causes the bond Node server to immediately poll the Bridge for up to date status. It’s really an artifact leftover from before the Bond Bridge Node server had BPUP (real-time) status updates. The problem with the text is a profile problem. I will take a look.

Unfortunately I am selling my house. I think I will be taking the Venstar Colortouch with me (putting back the old Insteon thermostat so they all match), but if I am renting for a while (looking likely), I may not be able to have it available for testing of the conversion. May need to get somebody to help. Similar story for Autelis, MyQ, EnvisaLinkl-DSC, and iAquaLink, I'm afraid.

The Autelis presents a REST interface over the LAN for status and control. That’s what the Autelis Node server uses, and several people use the network module. Should be fairly easy to build a HA interface if you know REST and the HA integration definition language.

If a command was sent from the ISY, then it will be in the MyQ Node server log. Search for “DON” and/or “open”.

Yikes! The only "normal" wiring I see there are the (seemingly) 14-2 and 12-2 romex (white and black pairs) coming in from the side and those are capped off. This really requires some electrical sleuthing. You could disconnect the orange wires from the switches, flip on the breaker and see which of the six orange wires at the two switches remains at 120V vs ground (I am assuming the metal boxes are grounded). That would be the line from the panel. The two other orange wires on the switch containing the line would be the travelers to the other 3-way switch. I would suggest getting a long strand of wire and, with the breaker OFF, using a continuity check between the orange wires in the two switch boxes to verify the travelers. Then, the one wire left over between the two switches (not the travelers and not the line) is likely the power to the fixture (the load). Then you just need a valid neutral in the box at the bottom of the stairs. You could do a continuity check to ground (again with the breakers OFF) to see if one of those white wires is still a valid neutral, but that may not be 100% accurate. Plus, as somebody else said, using a neutral from a different circuit may work, but its not to code, so you are going to need to pull these before you put your house up for sale. Of course, all this assumes you have a mutlimeter. BTW, you see the one orange wire in the picture(s) above that has the piece of black tape around it near its end. That's usually done by an electrician to signify that the wire is being used as hot (either line or load) despite the fact it is not a black wire.

Orange and red? What country are you in? Also, do the switches have 4 lugs or 3 lugs for connections (not counting ground). Also, are there no white (neutral) wires in the boxes not connected to the switches at all?

Of course, those diagrams work great when you have a traditional 3-way wiring setup, but if something doesn't seem quite right (e.g., there's no red wires, the wire with power (line) comes into the same j-box as the the wire from the light (load), etc.) then post the details back and get help before proceeding if unsure.