shbatm

Fix pushed.

I have 2 ZEN30s and they are a pain to pair. You also need to repair after a firmware update. I think I gave up on one of them pairing securely...

If you're keen on an alternative, check out insteon-mqtt, still not as easy as the AC, but probably closer than the built in HA Insteon from the little testing I've done.

Yep. That's all they are. They make repeating similar automations easy by just giving you some dropdown options. So to clarify my set up (now that I'm not on a phone): 1) Insteon devices: since most of my lights are on dimmers, I only control the devices with the loads from Home Assistant or Alexa, that way I can set the brightness. Several of these have a 3-way follower or can be controlled by a KPL Button/Remote. The IoX Programs just sync these "secondary" device states to the load. The programs all have a built-in delay of 2s to avoid Insteon traffic loops, so I don't really notice any delays. By traffic loop, I mean the 2s delay essentially allows the program to abort if one of the secondary devices is the thing actually doing the controlling (versus HA, Alexa, or the load), since it will be synchronized by the Insteon scene. 2) The AppDaemon and Blueprint apps I linked above are used to control non-Insteon loads like Zigbee lamps or Z-Wave switches from a KPL or RemoteLinc. In the case of the AppDaemon script--it will do the same thing as #1 and sync back the status if the lamp is controlled by another means. This could be done with a crafted HA native automation, but AD was easier for me. 3) I have a mix of Insteon "alternative function" programs -- like using a Fast-Off on a switch to turn something else on/off. Those are still mixed between IoX and HA (really depending on how old they are). In general though, yes--if you have adequate hardware on the HA side and don't use HTTPS to connect to the ISY/IoX from HA, I find HA actually faster to process the automations than my ISY. When I switched to the Polisy, the delay was less noticeable, but HA is still quicker (subjectively). Finally, when possible it is always faster to use native groups rather than controlling a bunch of single lights from HA. Native groups = Insteon Scenes, Zigbee Groups, Z-Wave Mutlicast. These use a single command on the related protocol to control mulitple lights, vs. one command per device. Because of this, I have some HA groups like "All Lights Off" that include an Insteon All off scene switch, a zigbee all light group, etc. For tying these to a KPL button to control in HA, I have a second group which excludes the Insteon All off switch (it will control it's devices natively) and an HA Automation that listens for the isy994_control "DOF" or "DFOF" events from the button and turns off the non-Insteon devices from HA. Example below. # Notes about All Off Groups: # Groups without _hass include ISY Scenes. # These allow control repsonse from an ISY All Off without duplicating # the Insteon traffic group: all_off_exit: # Use this group to control all lights from HA/Alexa name: All Off Exit entities: - switch.all_off_exit # ISY All Off Scene - group.all_off_exit_hass all_off_exit_hass: # Link this group to ISY "All Off" Button name: All Off Exit Hass entities: - light.zb_all_off_exit # Zigbee all lights - light.living_room_lamps - more wifi/Z-Wave

My IoX Keypadlinc sync programs are only for Insteon keeping buttons/slave devices in sync with dimming loads (inspired by this), everything else is either in HA Native (blueprint) or AppDaemon (see shared app here).

I'm pretty sure I remember this was the exact use case for the 'restart' option in HA.

I don't have a good answer for that. Your best bet is to try it out. From my experience, HA Insteon requires putting much more thought into the actual links for scenes than AC. YMMV though, I am very biased towards using ISY for Insteon. Go vote for this on the HA community forums... It has been a long requested "Why the hell?" feature.

I've only read about the HA Insteon Panel for setting scenes and links, is that what your experience is with? Yep, I played with it a little bit as a backup option, and if you're coming from manual linking or the Hub, its definitely a step up. But if you're used to ISY, you may start to miss the AC pretty quick.

From my experience, Polisy is still going to be a better experience than using the PLM in HA. It's still much easier to configure the scenes and links in the Admin Console.

I've put some of my thoughts about support for Node Servers here: https://github.com/shbatm/pyisyox/discussions/9 In short, if you're using Home Assistant, my personal recommendation is to use the native integration in HA over trying to port in the Node Server through the IoX integration. You are probably going to be hard-pressed to find a Node Server that doesn't have a HA integration. And for the record, my DSC alarm works very well with the HA integration and opensprinkler even has a custom card for the dashboards: https://github.com/rianadon/opensprinkler-card

Nail on the head for me. It is very much what you are used to, and how well you understand the logic. Keep in mind, Home Assistant has the built-in automation engine which some people have a sour taste from when it was all YAML written. It has improved with the UI quite a bit, but there are also several other engines that may suit your skill level: NodeRED (visual/JS), AppDaemon (python), Pyscript (python), NetDaemon (C#), and a Rust option too. My personal setup uses IoX programs only for Insteon state synchronization (keeping secondary buttons synced when the load is adjusted by something else), everything else is a combo of HA Native, NodeRed, and Pyscript/AppDaemon.

You should use the control events for triggers from buttons: https://www.home-assistant.io/integrations/isy994/#handling-insteon-or-other-isy-control-events Note: the documentation shows everything in the event_data, but you only need to use the entity_id (sensor.mb_mirror_d_heater) and the control you want to listen for (e.g. DON)

https://www.home-assistant.io/dashboards/area/ The single button in an area card is not specific to ISY. You'll need another type of card. You can use auto_entites as suggested above to generate a card with everything from an Area. There are a few other options, but that's why I linked the HA communities. Generally for Insteon: if it's dimmable it's a light (or fan), if it's on/off or a Scene it's a switch. Keypadlinc secondary buttons and RemoteLincs are sensors, because they don't allow DON/DOF controls being sent, only received. This is a vast oversimplification, so if you really want to dig into it, the sorting is here: https://github.com/home-assistant/core/blob/130c8ea5f54f73ed84e34da20683ebbd2b9d4ce0/homeassistant/components/isy994/const.py#L193 You can change a switch's device type using the 'Switch as X' option in the entity-specific settings menu in HA. Insteon will not be changing. Some devices for Z-Wave may change after the improved sorting is added in the upcoming release. If you have one that you know is wrong, open an issue on GitHub so I can make sure it gets corrected.

Just a general recommendation, once you get out of the ISY specific integration details and into things like dashboards, you're going to get a better breadth and depth of support on the Home Assistant sites: https://www.home-assistant.io/help/#communication-channels

Another handy one is dumping the trigger to the log to see the exact structure: action: service: system_log.write data: message: "{{ trigger | to_json }}" level: debug

condition: - condition: template value_template: > {{ trigger.from_state.state != 'unavailable' }} - condition: template value_template: > {{ trigger.from_state.state != 'unknown' }}

They can be in any folder. It searches all folders for the "HA.platform" name.

Should still be working. Can you share screen shots of your programs? Also, please enable debug logging (click the 3 dots under Universal Devices ISY/ioY in Devices and Services, log is in your config directory) and check for any errors or items about loading programs.

If you're using the current core version in Home Assistant then everything will be a state attribute in the single sensor. One of the changes being made in the testing version is to break these all out into individual entities. If you're wanting to test: look for the Alpha Testing topic here and make sure you enable "Load Node Servers" in the configure options dialog.

There is a HA Query button entity for each device you can use. And what you saw is just kind of a side effect of the way heartbeat nodes are translated to battery entities in Home Assistant, they'll go to Low if a heartbeat or trigger isn't received in 25 hours. If you're restarting HA frequently, these timers will get reset often, and it's better to have a low battery status 'stick' on a restart and then possibly not be seen again for several days.

I would try this:

Any ideas what might be happening? Try pasting into the Developer Tools > Template tab to see if you can get a better idea of what the error is.

https://forum.universal-devices.com/topic/40165-help-why-insteon-appliance-link-has-6-entities/?do=findComment&comment=359311

The isy994.cleanup_entities service used to be needed to run manually. After 2023.2.0, it now runs automatically when the integration is reloaded or HA restarted.

From the docs: https://www.home-assistant.io/integrations/isy994/#isyiox-variables Short answer: some things like variables and 'extra' property entities are disabled by default since they aren't as commonly used. There's nothing wrong with them, this just helps reduce clutter on the HA side. Once you enable the ones you need, they will stay enabled.