shbatm

Use an event trigger to pick up specific commands (independently of the device state) triggers: - event_type: isy994_control event_data: entity_id: light.main_bathroom_recessed_left control: DFON trigger: event Example Blueprint: https://gist.github.com/shbatm/5b48d2272fb136557ac9b77d2de1beb3 Docs: https://www.home-assistant.io/integrations/isy994/#handling-insteon-or-other-isy-control-events

You can use the isy994.send_node_command actions in Home Assistant to send dim/brighten to specific nodes. This can either be used in automation/scripts or custom buttons with tap_action assigned to call the action. X10 dimmers that don't support setting an exact brightness level do not have a native translation to a Home Assistant 'light'. Side note : this also works for Insteon scenes to dim/brighten.

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

Just an FYI -- this is a limitation of Home Assistant, not just the Insteon or ISY integrations. There's been several discussions over the last years about how to enable "native" groups/scenes (Insteon, ISY, Zigbee, Thread, Z-Wave all have some variation), but the choice has been to maintain Home Assistant scenes as self-contained to Home Assistant and just act as "state-recall" scenes. You can look for some of the discussions on https://github.com/home-assistant/architecture.

Looks like there's a few differences in the node server files compared to what I had available to test with that I'll need to fix. Can you please take a backup of your polyglot from the web interface, delete the 'backup.db' from the zip file, and send me the rest in a message? All your private credentials and info should be in the dB file, the rest is the node server definitions and profiles so I can narrow down the format changes.

I would suggest trying the beta version of the Home Assistant integration, which must be installed with HACS. One of the primary feature differences is that Node Servers get a lot more love in the re-write. 1. Add the custom repo (first link in post above) to HACS 2. Search for and install the IOX integration in HACS. 3. Restart Home Assistant (this should override the default integration with the beta). 4. In HA Devices & Services menu, find the ISY/IOX integration, click configure, and make sure 'Use node servers' is checked in the options.

You may be missing doing a replace on one of the files. Make sure you do all of the ones listed in that post and double check the MAC address replacement too, and then reboot HA right away. It should be surviving an upgrade if it survives a reboot. Worst case, do option 1 and remove/re-add the integration.

Echoing what @carealtor said above, my suggestion is to use folders for ignoring bulk items and then just disabling or hiding anything else inside Home Assistant at the device or entity settings. I personally use an ignore string of '[i]' and just have several folders named just that as subfolders in each room/folder to ignore. It's also easy enough to append to a single device/folder if needed.

The HACS version (4.0.11) is the latest 'testing' version: https://github.com/shbatm/hacs-isy994 which has to be added as a Custom Repo in HACS (top right corner menu). HACS is using the new module in python, different than the core version. It is near functionally equivalent at the moment, with some new features around Node Servers. I have not made the progress I expected over the past couple months (life has gotten in the way), so this is still the latest version. The only recent change is that the custom services that were replaced by new button, select, and number entities, have been removed from the Core version (as promised/threatened in 2023.5.0).

Glad you found the issue. I'll tweak the PyISY logs for future to show the values for better debugging.

If I had to guess based on how often it's firing, your '_differential' variables may be floating right at 1.5 because there's no room for float and it may be short cycling the two programs. Can you enable debug logging and see if the ISY is actually sending two updates? That will narrow it down to a HA issue or ISY issue. Under Devices & Services in HA, click the menu next to IoX and select enable debug logging. You can then watch the logs either by opening the /config/home-assistant.log file or in Home Assistant navigate to Logs in settings, (hit 'c' and then type Logs), then View Full Log at the bottom.