DNewkirk

@Jimbo.Automates I am using the HomeKitHub PG3 Professional edition plugin to access my Honeywell T9 Thermostats. Some of my thermostats have connected air sensors. The Plugin creates subnodes for the air sensors, however the data displayed in the IoX nodes is not correct, typically 0s. However, if I query the subnode in EISY-UI and watch the screen, the correct values appear in the subnode for a split second and then revert to 0. When I check the log file, this appears to be confirmed by double entries for the subnode. A set of IoX responses with the correct values appear, and then 1/2 second later, a second set of responses appear with a 0 values. See log excerpt: This same pattern of behavior appears across all of the thermostat subnodes. This seems to indicate that the plugin can correctly read the subnode values, but for some reason is immediately overwriting them. The first values which appear match what the thermostat is displaying so they appear valid and accurate. The other issue I have noticed is that the values of the main nodes don't appear to be updating regularly. I can click on the node and query it to update, but its values are not current when I open AC, EISY-UI or UD Mobile. My shortpoll and longpoll are 60/600 as is the default, but I don't see updates in the PG3 logs unless I run a query. Are the regular updates written to the PG3 log file, or are they not supposed to be logged? Any help you can provide to resolve these issues would be helpful. Thanks, Dave

For anyone trying to link to Honeywell thermostats, see also https://forum.universal-devices.com/topic/46803-attention-honeywell-users/#findComment-407514

@hawk4974 I had the Honeywell plugin but couldn't get a developer account from Honeywell to use the plugin. I assume that they have stopped issuing them since they were bought by (or bought) first alert and are consolidating their apps and products. I gave up on the plugin. I installed the HomekitHub V2.0.17 and have eight Honeywell T9 thermostats working with it. You need to use the professional version of HomekitHub and enable the generic frameworks in the configuration screen, both under custom parameters "generic_nodes_enable" (change to true) and under the last line of each Homekit pairing slot under "Create generic IoX control nodes (Professional)" (also set to true). Discovery only worked for 3 of my thermostats with older firmware. The newer ones I purchased wouldn't show up in discovery, whether they were in Homekit Discovery mode or not. To get them to connect to HomeKitHub, I looked up the thermostats in my router to get their IP address and network name. I then manually added them in HomeKit pairing slots filling in slot number (use next available), HomeKit pairing code (choose Connect to Homekit on your thermostat and write down the eight digit number), the Name substring (network name: TSTAT-XXXXXX where XXXXXX is the last 6 digits of the mac address), LAN host:port (ip address + :80, i.e. 192.168.1.100:80), stable node key can be left blank, and final entry should be "true". Save the configuration, wait several minutes, and then restart the plugin. Sometimes, I had to restart several times. Eventually you should get a notification when the plugin restarts either that it paired with a 12 digit address (which looks like a mac address, but isn't) or a notification that the device rejected the Homekit code. I am not sure, but I think that it won't make the initial connection until the thermostat times out and leaves Discovery mode, but then the Homekit code is no longer valid. If you get the second notice, then go back into the thermostat and get a new Homekit code (they change every time you go into Connect to Homekit) and update the Homekit pairing code in the configuration and save the changes. Restart if necessary. Once you get the notification that it paired, copy the 12 digit address from the notification and update the Accessory id in the HomeKit pairing slot for the device on the configuration page so it can find it again next time. When pairing is successful, it will create multiple nodes. The one you have (TSTAT-DFF263) under HomeKit Hub only indicates the pairing status (and it isn't always accurate- sometimes mine said it was paired when it wasn't). It will also create an additional TSTAT-DFF263 under at the IoX level with subnodes under it. The subnodes will be called "TSTAT-DFF263" and "TSAT-DFF263-motion" (or some of them on mine were "T9 thermostat-motion"). It will also create subnodes for any room sensors you have connected to the thermostat. In my case, all of the relevant information and controls was in the TSTAT node under IoX. Although there are parameters under each of the subnodes, the populated data was not correct. I tried changing the generic nodes to false and it eliminated the subnodes, but the data under the main node was then no longer correct and the controls didn't work. You can verify that the thermostat paired by going back to the thermostat and choosing Connect to Homekit. It should tell you that pairing was successful. If it gives you a new code, the pairing has not succeeded. If for some reason you have to delete this pairing and start over, you can reset Homekit pairing on the thermostat from the Advanced Setup>Reset menu. Once everything is paired and working, you can move the nodes from IoX to the appropriate room or folder you want it to appear in. I also renamed this node in IoX and on the configuration page to something more descriptive and it doesn't seem to have broken the pairing connection, but I only got it working yesterday so time will tell. Dave

@Jimbo.Automates I was eventually able to connect to all 8 thermostats by manually adding the network name and IP address in the Add Homekit Device line in the configuration page. Discovery never worked for me for any of the 5 newer firmware models, whether or not they were in discovery mode. I added each thermostat one at a time and then restarted the server (sometimes several times). Eventually I would get an error that the device rejected the Homekit code (it had timed out by then) and I could then update the code, save and restart. Once the device connected, I would then copy the address from the confirmation message and update the configuration record with the address. After everything was connected, I renamed the thermostat node in IoX and on the name line in the configuration page, and moved the thermostats in IoX into the various room folders. All thermostats appear to be responding. The subnodes (dry contact, motion, and any room sensors) appear below the thermostat nodes, but they are not populated with valid data. I tried changing the configuration to not load the generic thermostat and this removed the subnodes, but the main node then stopped responding, so I changed the generic profiles back to true. Is there a way either get the subnodes to read the actual data, or to remove the subnodes without affecting the functionality of the main node? Similarly, is there a way to remove or hide the data below the node that is irrelevant? Seven of the thermostats only control hydronic heat, so the cool setpoint, humidity setpoint and fan controls don't apply to these zones. Can a configuration file be edited to hide these values some way? One other question: now that the configuration is populated with the hexadecimal address and the IP address, will the connection fail if the IP address changes? My thermostats get their address through DHCP, so do I have to make these static through address reservation so that it doesn't break the connection in the future, or will the bridge find the devices by the hexadecimal homekit address? Thanks, Dave

@Jimbo.Automates I have 8 Honeywell T9 thermostats which are theoretically Homekit compatible, so I tried your Homekit plugin 2.0.1 to gain access to these. I installed the professional trial version and enabled the generic IoX plugins. Three of the thermostats are a couple of years old and have firmware 01.05.03. These were discovered by the plugin even without being in discovery mode. I added the homekit code to the configuration page for each one and saved it. All three paired with a TSTAT-XXXXX node and two or three subnodes. Relevant values in the main nodes appear to update and be correct, although the subnodes are mostly irrelevant (T9 thermostats don't have built in occupancy and they are not battery powered) or are not populated with correct data. The other five thermostats are newer with firmware 03.04. None of these were discovered, even if they were put in discovery mode. I tried to install one manually, but I don't know what the value should be for the Accessory ID since none was discovered and the pairing was therefore not successful. Are you familiar why with these newer T9 thermostats aren't visible to the plugin? According to Honeywell, the T9 thermostats are only compatible with homekit above firmware version 03.xx, so they must have made some kind of change/update at that point. Is there a way to determine the Accessory ID of a device to attempt to force a pairing (although if the discovery didn't find it, a force may not work anyway)? Thanks, Dave

Techman illustrated what I was describing. I don't have EISY-UI beta installed, so I can't see what is exposed by Node>Configuration>NodeInfo in the beta. If this screen shows what is currently set in the backlight/LED Brightness settings, then that would allay my concern. Another minor wrinkle to these settings: By default, a new keypad comes in with the buttons off when the associated circuit is off and on bright when it is on. This would correspond to a backlight setting of 15/0. As discussed, the backlight setting in AC is 0/0. But interestingly, the LED Brightness settings are also 0/0 by default, even though the keypad is operating as 15/0. Setting the backlight setting to something else, say 15/3 does change the backlight, and is then reflected in the LED Brightness setting. Restarting AC makes the backlight setting dropdown revert to 0/0 but the LED Brightness setting remains at 15/3, so AC is not accurately populating the backlight setting but it is capturing it in the LED Brightness dialog box. Resetting the keypad backlight to 0/0 as it was in the default doesn't reset it to default behavior. As you would expect, with 0/0 the button is off all the time. To get back to the default behavior, the Backlight/LED Brightness has to be set to 15/0. After this, the LED Brightness dialog box will reflect the 15/0 settings. Short of doing a factory reset, there is no way to get back to the default behavior with the LED settings showing 0/0. The keypad must have a default logic of 15/0 of there are no user overrides of the setting. In AC, the backlight dropdown actually "sticks" for the rest of the AC session. If you set it on one keypad, the dropdown will stay where you selected it even when you go to a different keypad. This might be convenient if you wanted to set a number of keypads to the same setting, but it certainly isn't showing you what the selected keypad setting is. Restarting AC will revert the dropdown to 0/0. EISY-UI doesn't have this sticky issue since the backlight dropdown button doesn't show a value until the button is selected.

Thanks, Techman. After a little more searching on the forums and in AC, I did notice that the settings are retained in the "LED Brightness" settings at the bottom of the screen in AC. There is more information in https://forum.universal-devices.com/topic/33228-backlight-led-settings/ that proved helpful. I'm still not sure if the Backlight settings and the LED Brightness settings are setting the same thing, but using the LED Brightness settings seems to be more consistent and you can see what is actually set. The "LED Brightness" option doesn't appear to be present in the current version of EISY-UI, so this functionality might disappear with AC.

Most of my keypads (2334-2s) are configured with the backlight off when the key is off, and the backlight bright when the key is on. However, the ones in the barn are configured to be dim when the key is off, and bright when the key is on so that I can see the buttons even when the lights are off. These were configured years ago under my ISY. The minor issue I am having is that I do not know what backlight settings these keypads have. When I click on the keypad in either AC or EISY-UI, the backlight setting is 0/0, not whatever is currently set in the keypad. Querying the keypad doesn't update this. I assume that the bright/off keypads are 7/0 and the barn keypads are something like 7/1 or 7/2, but I don't know this for sure. Is this by design or should the AC and/or EISY-UI display the current backlight setting? If by design, is there a way to determine the current backlight setting for a keypad? I can of course change the setting by trial and error to replicate the current setting, I was just wondering if there is a more direct route.

The old AJAX and Home Automation Dashboard local interfaces which were built into IoX on the ISY 994 are still present on the EISY (at least in version 5.7.1). They have been deprecated and may be removed with any future updates, and some options are not functional (for example, the admin console doesn't seem to open from the UD AJAX interface). Basic control of devices, scenes, programs and variables seems to work, at least for Insteon devices. On the EISY, http and https ports have been moved from default 80 and 443 to 8080 and 8443 respectively. In addition, the mapping of a default web page has been eliminated, so the exact URL to the desired page has to be specified. They can be accessed at the ip address of the EISY, or alternatively at eisy.local if the EISY is properly registering its name. EISY Local URLS include: UD AJAX interface: http://xxx.xxx.xxx.xxx:8080/WEB/udajax.htm or https://xxx.xxx.xxx.xxx:8443/WEB/udajax.htm Home Automation Dashboard interface: http://xxx.xxx.xxx.xxx:8080/WEB/HAD.htm or https://xxx.xxx.xxx.xxx:8443/WEB/HAD.htm You can also download the appropriate admin console for your version from the EISY at: https://xxx.xxx.xxx.xxx:8443/WEB/admin.jnlp or access your local Polyglot server at: https://xxx.xxx.xxx.xxx:3000

After trying a number of different wiring combinations, it turned out to be that I had a Netgear router configured as an access point in the barn that must have been blocking some protocols. It wouldn't let the EISY connect to NTP, and I couldn't SSH into it. The funny thing is that I wired it to the network exactly as the 994 had been wired, and the 994 never had an issue with it. The EISY didn't like it, though. Go figure. In the end I just had to switch one patch cable to resolve the issue, but it took me three days to figure that out, with Michel's help.

Michel resolved this issue through a support ticket. TLDR: It was a network issue My 994i was always located out in my (heated) barn, since that is where the majority of my Insteon devices are. I originally started using Insteon to control the various lights and doors in the barn so that I wouldn't have to run a bunch of switch legs back to the house. The barn has a CAT5 run (about 100 feet) from my house network with a 8 port switch on it, and various other network connected gear. The 994 worked fine on it, as do my other items out there (Roku, laptop, etc.) The EISY must be more particular about its network connection, or there is some kind of issue with that network run or switch. Including the barn switch, the EISY was two hops from my main router, which is another two hops from the internet. The EISY couldn't communicate through that many hops, or at least through that particular connection. When I brought the EISY into the house and plugged it directly into the router, everything works fine. FYI for anyone else who is suffering from this, the symptoms were that the EISY would not synchronize its time, my Polyglot Dashboard wouldn't launch, and I couldn't SSH into the system. I could talk to it fine through Admin Console and UDMobile could connect and sync. IoX launcher found it without a problem, and the EISY got a reserved IP address through DHCP and reliably registered eisy.local with the router. Since the EISY responded on the network in many ways, and it was literally a plug and play installation of where I had the 994 installed, I didn't think that it could be a network issue. Relocating the EISY proved that this was the problem.

I can change the timezone (including putting in a custom Lat/Long), but it is already correct. EISY isn't updating its time, and I have no way of manually setting the time or forcing a time update. It thinks it is February, 2021, so that doesn't seem like a timezone issue. In the 994 admin console system configuration page, the clock area had options to synchronize with the computer time, to manually adjust the clock, or to enable an NTP server, including specifying the server and sync interval and forcing an immediate synchronization. None of those settings appear in my EISY admin console. If this is by design, then the EISY must automatically just go to a time server, but mine is obviously not doing that. Making NTP the only option would make the EISY useless on any installation that isn't connected to the internet, so I wouldn't think that that would be a design choice by UD. Internet isolated systems might be rare, but not unheard of. Anyway, thanks for your help @Geddy. Hopefully, I can get this straightened out through the ticket.

After the EISY cooects to the portal, you have to authorize the connection from the EISY. Go into the admin console, and on the Configuration>Portal tab, authorize the connection. Once you authorize the EISY to connect to the portal, the migration can continue The migration process on UD Mobile/portal only moves the portal license over to the new system and migrates your Google or Alexa spokens. It will not migrate your devices in ISY. Restoring your ISY backup to EISY will populate your network with all of your Insteon devices

I recently installed one of these (albeit on an ISY 994i 5.3.4) and only changed a few of the parameters. Looking at the options on mine now, this is what they show: Program Lock: not checked LED, Key Beep, Send Cleanup Messages and Send Cleanup Errors: all checked LED Brightness: 0 Off Button Timeout: I changed this to 300 minutes, but I think the default was around 1545 if I remember correctly. I believe that this is how long the detector waits to turn motion back on if you manually turn if off with the button on top of the unit. Motion Nodes: One Condition: Always Report: On & Off Sensitivity: I changed this to 255, but I think it started at around 35. It doesn't actually seem to make a difference what it is as far as I can tell. Timeout: 120 Seconds Light Polling Interval: 15420 Hysteresis: 5 Day Threshold: 80 (31%) Night Threshold: 64 (25%) Hot Not Hot: 74.4 F (69.0 F battery) Hot: 86.1 F (80.5 F battery) Cold Not Cold: 67.1 F (61.8 F battery) Cold: 69.3 F (64.0 F battery) Battery Nodes: None Low Threshold: 133 Misc. Nodes Motion Enabled: One Tamper: One I don't think it makes a difference, but my motion detector is not on battery as I power it with a 5V USB power supply. I only have experience with the one, but my motion detector seems to be a bit flaky. The sensitivity varies significantly from one day to another. Also, I have a program that when I turn on the garage lights from the switch, it sets the Motion Enabled node to off, and when I turn the lights off again, it sets the Motion Enabled node back to on. This is just to keep the motion light from going on and off while I am working in the garage. However, I have noticed that it takes quite awhile, maybe 5-10 minutes, before the motion detector will again function to turn on and off its light after I have toggled the enabled mode. Hope this helps.

This link worked to bring up the UD Ajax dashboard. The link to load admin console doesn't work. It brings up the Java splash screen that tells you to keep the window open, but never launches the console. That's what I thought, but that is not what my admin console shows, whether I launch it from the EISY or from the cloud. See the attached screen grab. My time section just allows me to change the timezone, but the other time items are missing from this section of the tab. Thanks! I've lurked here for awhile when I needed some information, but never posted before. I don't consider myself enough of an expert in this to give any credence to any answer I might provide.