DNewkirk

Yes, the node info is the same in mine: But if you right click the node and choose Configuration, there is no "Options" option in the configuration screen: Dave

@Javi None of my Insteon Plug in Dimmer Modules (2457D2) expose any configurable options in EISY-UI (or in AC). The module supports the 4 options typical of most Insteon devices (i.e. Program Lock, Transmit LED, No LED and Beep) as well as Resume Dim and Load Sense On/Off. There is no "Options" button on the Configuration menu in EISY-UI, nor is there an Options button on the node screen in AC. Most of my modules show up as "(B2457D2) LampLinc BiPhy v.43" although a couple are v.41. The behavior is the same for both versions. Is this by design, or is there some corruption in my installation? Thanks, Dave

Eastern Time Zone on production repo 1.4.6. System time changed with no issues. The sunrise and sunset times on the graphic on the configuration page are an hour early, but my programs that run at sunset have the correct next run time, so go figure.

On the Insteon protocal page, you can turn off "Automatic Writes to Devices" or "Automatic Writes to Battery Devices" similar to the buttons on the top of AC. I didn't find a Write to All Devices command, so I assume that once you turn this back on all of the stale devices will write but I haven't actually used this option either in AC or EISY-UI.

I am on EISY-UI 1.4.6. If this has been corrected in 1.4.8, please disregard. I use a lot of Insteon Micro Modules to control my lighting. I install these behind either standard wall toggle switches or, in many cases, Victorian push button switches. Either I have misunderstood the programming of the options on these units, or the options menu in EISY-UI has reversed the logic of some of the micro modules options both from how they actually operate and and how they were presented in AC. By default, the modules are shipped configured for a latching switch (Momentary option is off). If a momentary switch is used, the Momentary option must be enabled. The modules come with two sense wires. By default, the module only listens to the sense #1 wire (yellow). This way the module works with a standard single pole switch. If a double pole switch is used and connected to both sense wires, then the Dual Line option must be enabled. A third option determines how the switch responds to the power on the single sense wire. By default, it will switch the load when the sense wire either senses power applied to the sense wire or when power is removed from it. This way, throwing the switch will always switch the light either on or off, even if it was previously switched by a different controller. This is the default and it is called 3 Way mode. It is active when the Line High always mode is turned off (i.e. not selected). If it desired that the light always follow the attached switch, the option must be enabled (i.e. 3Way mode turned off). If this is done, it may be necessary to flip the switch twice to control the light (i.e. if the light is on but the switch is off, turning off the light with the switch will require you to turn the switch on so that it matches the light and then turn if off to turn off the light). In AC, these options were clearly labeled, and the additional explanatory text in red made it even more obvious that you had to deselect the option to choose the option in red (the default mode). In EISY-UI, the logic has been reversed. The options have been labeled with the AC red actions, which are NOT what you will get if you select the option. The options in EISY-UI should be labeled "Momentary" rather than "Latch", "Dual Line" rather than Signal (?) Line, and "Line High On, Line Low Off" rather than 3-Way. Even better, the wording from AC should be used directly, providing the information of what turning the option on does, as well as what leaving it off does. In addition, the option labeled "Ramp Dim" in EISY-UI should say "Resume Dim". Enabling it makes the light come back on at the light level it was at when it was turned off. It has nothing to do with ramping. If I have misinterpreted these items, please correct me. Thanks, Dave

The ability to present as main node and "subnode" is defined by the node. If a node has a defined parent (or child), right clicking on the node will include "Group Nodes" among the options. Choosing this option will move the subnode to be below the main node, where the tree can then be collapsed to show only the main node. This is not to be confused with the ability to "Add to Group". There has been some discussion to change the nomenclature of combining nodes and subnodes for clarity. I am not sure what controls if the nodes/subnodes are grouped by default. Some node servers generate main nodes with subnodes that are introduced into IoX with heirarchy, while some seem to come in flat (i.e. with the subnode next to the node rather than below it). One beta node server I have used (LG ThinQ by @TJF1960 ) came in heirarchal in EISY-UI and flat in AC in my installation for some reason. Dave

@Javi Continuing our side discussion started in https://forum.universal-devices.com/topic/47304-no-scenes-in-eisy-ui/, my understanding of the programmatic intent is as follows (please correct any misinterpretations I have made): Groups: Are a collection of various nodes that have been associated together to act in concert. They appear in the node tree in IoX as a separate entity and contain other nodes, some defined as controllers of the group and others defined as responders to the group. Groups can have multiple controllers and multiple responders. They are analogous to what were referred to as Scenes in Administrative Console. Scenes: Are a defined subset of a group, associated with a specific group controller, which specifies the on level or other parameters of the responders in the group when the group is activated from that controller. Scenes are designated by the group controller which activates them, have no separate name, and do not appear in the IoX node tree as separate entities. Every controller assigned to a group has an associated scene, which by default contains all responders and controller/responders in the group at an on level of On or 100%. When the first node (controller or responder) is added to a group, IoX creates a virtual controller of the group (with a name to match the group) which also has an associated scene. The virtual controller's scene is invoked whenever the group is controlled programmatically by IoX, and the scene associated with a specific controller is invoked whenever the group is triggered by that physical controller (switch, keypad button, mini module, etc.) Since IoX (and Insteon) need to know what you want to happen when you press a physical button, every physical controller can only be assigned (as a controller) to one group, and therefore has only one scene associated with it. Although every controller's default scene that is assigned when the controller is added to a group contains all responders at full brightness, each scene can subsequently be modified in EISY-UI (and in AC). Each responder in a scene can have its brightness, ramp rate and retries changed. Responders in the group can effectively be eliminated from a scene entirely by setting their on level to off, even while they remain in the group. It should also be noted that these scenes are implemented in native Insteon commands (at least for Insteon nodes) and will therefore continue to operate in the absence of IoX and the EISY controller. Implementation of scenes can also be mimicked programmatically in IoX by creating programs that set individual on level for each desired responder node. A couple of suggestions for future updates to EISY-UI to reinforce these distinctions:Right clicking a node in the EISY-UI node list brings up the option to "Add to Group". Subsequent dialog boxes, including the Scene Selector and Add to Scene should be changed to Group Selector and Add to Group. Throughout EISY-UI (and UD Mobile for that matter) most references to Scenes should be changed to Groups. Since Scenes are not separate entities, they don't actually appear anywhere in the node tree. In generic Insteon linking (i.e. without a hub or controller), the linking process actually creates a group and automatically modifies the associated controller scene since the responder is linked to the controller at whatever on level the responder is currently set to. In IoX, the addition of a controller to a group sets its scene at full on for all responders. Similarly, adding a responder sets it at full on for all controllers. This is understandable, since the association is being made remote from the physical entities and if a controller were added to a group when all of the responders were turned off it would appear that the linking failed since none of the responders would come on with the controller. However, to reinforce the availability and customizability of scenes, it would be desirable to add an additional radio button to the Add to Group dialog box so that when a node is added, a separate option allows the user to "Customize Associated Scenes". Leaving this unselected would preserve the existing behavior: all responders would be added at full brightness to new controllers and new responders would be added at full brightness to existing controller's scenes. However, if Customize Scenes was selected, it would bring up a dialog box listing existing responders (for added controllers) or existing controllers (for added responders) and what their associated levels should be for the added node. It is my impression from forum comments and threads that many users, particularly new users, aren't aware of the possibility of customizing scenes within an IoX group. As you have indicated, this has been further muddied by the nomenclature that has been used in the past. This enhancement (with associated documentation on the wiki) might go a long way to clearing up the confusion on this issue and providing users additional flexibility in the way that they utilize their systems. Dave

That might work, although combining them doesn't necessarily collapse the combination as it could still stay expanded in the tree. To me, collapsing is what you do to the tree after they are "grouped". Maybe associate, combine, cluster, or unite? Of these options, I think I am leaning towards associate or cluster, but maybe others can chime in on what terminology would be clear to them. Dave

@Javi I appreciate this explanation. I was confused by the switch from scenes (which has been referenced by every resource up to now, including the forums, wiki and even Insteon documentation) to groups. I understand now what you are trying to clarify. You might also give some thought to how to refer to devices or nodes that have "subnodes". Right now, this is also referred to as grouping nodes in Eisy-UI, not to be confused with groups previously scenes. Some other term might be better for this consolidation of subnodes under the prime node, although I can't come up with any recommendations off hand. Dave

@Jimbo.Automates Thank you, Jimbo. 2.0.20 installed and appears to have addressed the noted issues. Dave

@Javi Thanks for the explanation. I know that eventually the point will be moot, but I was just curious if my current (6.1.2_7) installation of AC was corrupted, or if this is by design (or more accurately, purposeful omission) in AC. You have answered my question. Dave

I recently installed my first I3 device (an I3 dial) in my Insteon network. I am using an EISY on the latest production version of IoX/Eisy-UI (6.1.2_7/1.2.2) so I installed it through Administrative Console. After installation, I could see both the I3 dial and I3 dial flags nodes, but when I click on the I3 dial node, AC would not show any data, and I could not control the light. Clicking on the I3 flag node would correctly populate the various flag values. I also could not select the I3 node when trying to control this light via a program. In Eisy-UI 1.2.2 I can see the I3 dial node and flag node values and control the light. I know that AC is going away, and the Eisy-UI is the up and coming way of managing Insteon devices, but is this normal with the 6.1.2_7 AC console or is my installation missing some type of configuration file? I was under the impression that I3 devices could be fully managed under the current iteration of the AC. Any insight would be appreciated. Thanks, Dave

Log files sent via PM. Log files no longer contained previous installation, so I stopped and deleted the node server and reinstalled at 10:08:14 this morning in the logs. The ThinQ node server is installed in slot 5. I also temporarily stopped the Ambient weather node server in slot 3 to reduce the entries in the log files, since that NS updates about 20 values every minute. Reinstallation went smoothly and nodes appeared in IoX. After installation, I modified a number of settings on the unit (through the ThinQ app) to see what the affect on the node values would be. On/off updates relatively quickly, and consistently updates if the node is queried, as do current temperature and target temperature (in Celsius). Interestingly, most of the timer values seem to update when set, and will update as the time counts down, but will not reset after the unit or timer is switched off. GV15/GV18 appear to correspond to what the unit calls Sleep Timer. GV14/GV17 correspond to the unit's "One Time Schedule" start and GV16/GV19 correspond to the unit's "One Time Schedule" start. Setting a recurring schedule on the unit does not appear to affect any of the node values. As my unit is a heat pump, it has mode in addition to on/off, and changing the mode from heat to cool does not appear to be reflected anywhere in the node. Let me know if you need anything else. Dave

@TJF1960 I installed the Beta LG ThinQ plugin to give it a try and provide some feedback. The only LG appliance I have attached to my ThinQ account is an LSN120HSV4 mini split inside wall unit with a PCRCUDT3 Wifi module. The ThinQ app identifies it as a Wall-Mounted A/C. Plugin installed correctly and connected to my ThinQ account after I created and input my thinq_pat. The Plugin created a "LG ThinQ" node with a subnode for my A/C unit. Unit data seems to populate correctly, although the plugin at this point offers no control, just reporting for my unit. Data reported as follows: If I turn the unit on, the Run State correctly updates. Updates take a couple of minutes, or immediately if you Query. If I set the sleep timer, the "Timer Relative Minute to Stop" in the right hand column updates (although when I turn it off, this doesn't reset, probably because the unit doesn't report a reset on this event). Note that both the current temperature and target temperature report in Celsius, with no option to change. Since GV7 is the target temperature, I thought that I could change the target temperature by using the G07C07 command at the bottom, but this doesn't seem to affect the target temp. I am currently on the production IoX 6.1.2_7 and PG3x 3.4.26. I installed the plugin through the PG3 console, not through EISY-ui, although it appears in EISY-ui. Hope this helps your development. Let me know if you have any questions on my install.

Email sent

If I am not mistaken, I think it is actually http://your-isy-ip-address:8080/WEB/admin.jnlp on the ISY. If that doesn't work, try removing the port (i.e.":8080") from the ip address.

The "notification" I referred to is a notice that pops up on the HomeKitHub PG3 page in Eisy-UI in a light colored box (I am colorblind, so I can't tell you the color). It automatically clears after two long polling periods. I'm glad the instructions helped.

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