shbatm

Try a full restart of Home Assistant. The integration should not reload the entities, but Home Assistant has some retention of these (e.g. in case of an integration failing to load or only partially loading, it still retains the old state/name details).

You can use the `select.select_option` service in an automation to set the ramp rate of the Insteon device. From the device page, you can also click create new automation and then choose Change Device Ramp Rate Option to get a template for the action. As far as I know there is no transition support for insteon where you could set it on the fly for a specific turn on event like you can with most Zigbee/Z-Wave/Wi-Fi lights.

Your "S-Christmas Lights" scene has a link to your "Leak Sensors" folder, I'm not sure how or if that's intentional, but my guess is that's whats causing it to choke: <group flag="132" nodeDefId="InsteonDimmer"> <address>15887</address> <name>S-Christmas Lights</name> <family>6</family> <hint>0.0.0.0</hint> <parent type="3">47955</parent> <deviceGroup>29</deviceGroup> <pnode>15887</pnode> <members> <link type="0">ZY076_1</link> <link type="0">ZY077_1</link> <link type="0">37 C7 69 1</link> <link type="0">35 53 E5 1</link> <link type="16">3D 7A 77 8</link> <link type="0">51393</link> </members> </group> <folder flag="0"> <address>51393</address> <name>Leak Sensors</name> <family>13</family> <hint>0.0.0.0</hint> <parent type="3">53032</parent> </folder>

This looks like something I've seen before that had to do with naming of a node/folder on the ISY side that pyisy didn't like. Can you please visit http://192.168.1.72:8080/rest/nodes and http://192.168.1.72:8080/rest/status in a browser and send me the files saved as XML and I'll take a look? (assuming that's your Polisy ip from logs above)

What are you running HA on? I don't think you're going to 'overwork' it, but you may be over complicating things by trying to manage 2 instances if that's the only reason for separating. For example from mine: But otherwise, there should be no issues with two different HA instances connecting to 1 eisy.

How did you set up the Keypad? Did you use 'group buttons' or set any of them to 'always on' instead of toggle? What I would do: make sure there aren't any 'grouped buttons' on the keypad Add the other two buttons to each scene and set the on-level to 'off' (so when Scene 1 turns on, Scene 2 and 3's buttons get an Off Bonus 1) if you have another 4th button for 'Kitchen All Off', do the same thing as above to turn off the keypad lights, but you can also set the first 3 buttons to 'Always On' instead of toggle, then they'll always activate their scene when pressed the first time. Bonus 2) Make another scene with just the buttons as Responders. Add an ISY Program to check if all lights they control are 'Not On', then: wait 2 sec, turn off the keypad button scene.

Just want to summarize my understanding of it: Insteon Links ≈ Zigbee Bindings ≈ Z-Wave Associations — Device to Device, or Device to Coordinator pairings for communication Insteon Scenes ≈ Zigbee Groups ≈ Z-Wave Multicast — Single network commands addressing multiple devices simultaneously Insteon links can be used to control scenes directly from the device (without a modem/coordinator), some Zigbee devices support direct bindings to groups as well. However, to muddy the water further, each protocol also has 'Scenes' in the sense of 'recallable states and attributes of one or more devices.' For Insteon, this is integral to the second bullet above. Zigbee has partial support for this (Hue & Ikea for example). Home Assistant only considers scenes in the last sense above, a set of given states and attributes to recall for a given set of devices. These are protocol agnostic, and as I referenced earlier in this thread, the HA developers have been asked on several occasions to consider native support for these external scenes and/or 'one-shot' group protocol commands (by me at least twice), but it is not supportable given the number of overall integrations. Even for device groups in Home Assistant, it doesn't know how to differentiate between the different protocols. The easiest way I've found is to just create the groups you use frequently in the 'native interface' (for me that's ISY AC, Zigbee2mqtt, and Z-Wave JS) and call those from Home Assistant when you need to or combining those further as Groups in HA when controlling multiple protocols. Yes, it's an annoying workaround, but there's always hope for Matter (/s https://xkcd.com/927)

There's no way to change the default, but you have a couple options for each light: 1. Use a template switch and change the turn on service to use the send_node_command service with the fast_on command. 2. Dashboard only: change the tap_action of a card/entity to use the service above. This won't work to toggle the light though, so you'll either need a separate on/off button or set tap and hold actions (with hold being off).

That would be extremely helpful. I jumped back in on Slack, just ping me if there's anything you'd like me to test. I'll hold off on progressing further with pyisyox on the profile downloads piece--I was at the point of trying to tackle Z-Wave node defs, so a good place to stop. Just FYI -- my intent is that once this module is stable, the original pyisy will be deprecated--I know there are still a few node servers out there that use that module. The new one has been re-written from the ground up to be much faster and fully asynchronous.

Looks like something didn't fully update yet--this is the old error message. Make sure you've fully restarted Home Assistant after updating from HACS. You can double-check the version in your the "/config/custom_components/isy994/manifest.json" file to make sure it says `pyisyox==1.0.0a10` and `4.0.16`. Nevermind. I had the files flipped. The "The unit of sensor.xxx cannot be converted to the unit of previously compiled statistics" can be cleared by going to Developer Tools > Statistics and looking for the "Fix" buttons.

@stevehoyt I found the original issue with loading your node servers in Home Assistant, it was related to Windows/DOS vs Unix line endings in the profile files for WeatherLink. Better guards for this were added and the HACS version has been updated.

Sorry for the confusion. There's no hard requirement for the ISY control names to match device classes in Home Assistant. The integration uses known ISY control names to try to guess what HA device class the device might fall into, but for things like the GV* controls, or ones where we know the units won't match (LUMIN/VOCLVL), it just doesn't assign a device class. The user can manually force a device class in Home Assistant if they want. The only hard matching 'requirement' is within HA--that if you set a device class, the units must be one of the expected for that class. The actual mapping of ISY's UOMs to HA's Units is independent of all of this. Device classes aren't required, they just enable some additional things like long-term statistics, pre-set icons, unit conversions, etc. The change I made on my side and referenced above just adjusts the "guess" that "CPW" can represent any of the power classes and the unit needs to be checked to see which one to prevent a unit error. The suggestion for the change on the ISY side to include more control names is only a suggestion for future consistency across node servers (e.g. so you don't have some using CPW and some using GV0)--as far as the Home Assistant side is concerned, it's not required. EDIT: Just wanted to add--the current HA integration doesn't use the NLS or any profile info from the Node Servers, only what it can interpret from the "fixed" ISY core family schemas and documented API--it's about 90% educated guessing as to how to properly display things from the context given in the REST response. The new python module (pyisyox) that I'm working on actually requests the NS profile info from the device to get the details of how to display properly, but this is still in "alpha" testing.

Hi @Michel Kohanim - The comment was that the ISY Control names don't appear to differentiate between Real (W), Apparent (VA), or Reactive (VAR) power categories. All of the UOM are supported, but the controls are not specific to the category--the last list I saw only included "CPW" for current power and "TPW" for total energy used, and "PPW" for polarized power used. This came up in the Home Assistant integration, since Home Assistant now enforces Device Classes having specific units that match, and an error was being thrown for "CPW" (translated to Power device class, units of W/kW) having units of "VA". I have added a workaround on the HA integration side to segregate Real, Apparent, and Reactive power device classes, but suggested Steve reach back out here to see if its something to consider including in a future update, considering all of the other controls added over the past few years for the Node Servers.

The only repo you need to add in HACS is: https://github.com/shbatm/hacs-isy994 V4.0.12 was just released, update in HACS and restart Home Assistant and let me know if you have issues loading. This version has a lot more tolerance for unexpected data coming from Node Servers. If it doesn't know what to do with the data, it should skip that node server (or part of it) without completely bombing out.

@stevehoyt - I've tried to tackle most of the errors from your log files but I couldn't pin-point one of the errors loading the Natural Language file from one of the node sesrvers yet. I've pushed a new release of `pyisyox`, but have not yet updated the Home Assistant integration. Would you be able to run some tests from a command-line for me? The following commands should install the package (assuming you have Python >= 3.10 and pip installed) and then connect to the IoX device, dump all of the config files to a "./.output/" directory and output the events to the log. Ctrl+C to disconnect. pip install pyisyox==1.0.0a7 python3 -m pyisyox http://polisy.local:8080 admin "password" -o -v