Goose66

@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.

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.

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.

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.

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.

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

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.