Insteon_PLM on Hass.io, Anyone have it working?

Have a look at this post

I see some changes with the latest version. My Insteon motion sensors now not only appear as motion sensors but also (1) a gear-like thing – that’s apparently a sun and I presume to be the state of the light sensor on the motion detector and shows a status of “On” – and (2) a battery icon with a status of “Normal” – perhaps this would change state if the battery were low.

The new items show up on the Home Assistant Overview page with same Insteon address of the motion sensor, but with “_2” and “_3” appended.

Any official word on how to use these new items?

I also noted that X10 support appeared a version or two ago. Thanks! (Unfortunately for me all my X10 devices are on the other leg of my house wiring, me having assumed that I’d never have to worry about X10 working on the PLM).

@roborob, yes those are the other sensors available in the motion sensor. The battery is (hopefully) obvious and the sun like thing is the light sensor. It senses light and dark. I cannot configure it yet but you can (using other software) set the light sensitivity. Working on an interface were these settings can be made right in HA.

For custom naming purposes (in section “customize:”), what are the sensor types of the battery and light sensors of the Insteon motion sensors?

binary_sensor.1a2b3c_2 = light sensor
binary_sensor.1a2b3c_3 = battery sensor

where 1a2b3c is the Insteon device address of your motion sensor.

1 Like

FYI on a breaking change to both insteon_plm and insteonlocal. Please see this thread and give your input:

I have recently moved over from openhab, because the integration you have done with insteon. It is amazing, thank you for the work!! I have all 29 of my various devices working flawless. I was able to monitor the door sensor battery in hidden door sensor in openhab. Can you explain how to get it going in homeassistant? I have a motion sensor and it is reporting the battery on group 3 just like this post suggests. I have tried different groups to get the battery for the door sensors “address: 1a2b3c_2” etc. and it is not reporting back anything. Are these battery devices different?

Thanks again on the work! You made it worth the hassle to move over.

Battery sensor for the door sensor is not enabled yet. It is in the to do list but not sure when.

Wow, thanks for the quick reply, it’s all good. That and the “fast-off” option are the only features I miss from Openhab. But the door sensor and keypads being responsive enough to trigger devices and automations is worth the switch! I appreciate the work put into this component, it shows. This component is why I switched.
On a side note, the “fast-off” would be a good future feature as well. I used “fast-off” to control under cabinet lights. The kitchen switch kicked the lights on. And an automation also kicked on mqtt under cabinet lights. Turning off the switch would leave them on (ambience lighting). Double taping the switch “fast-off” would turn the under cabinet lights off too, with an automation. Useful for having two switches in one.

This topic is admittedly pretty old, but I’m new to HA. I’m a long-time Insteon user looking to ditch my hub and most of its associated devices in favor of HA running on RPi. In fact I would’ve fully walked away from Insteon by now except that I’ve not found anything in the [ z-wave | zigbee ] world to match the design, feel, and responsiveness of the Insteon mini-remotes.

So my device needs are quite slim at this point: I want Insteon on/off mini remotes to trigger HA automations.

Q: is it the case that once I get an Insteon 2448A7 USB dongle into my RPi, the remaining work is:

  1. add relevant lines to my configuration.yaml file
  2. join my mini remotes to the USB dongle and vice versa
  3. set up new automations with event handlers listening for insteon.button_on and insteon.button_off

If so, is Insteon missing from my manifest of configurable HA integrations simply because I don’t have the USB dongle installed yet?

I’ve successfully integrated an Insteon LampLinc-style dimmer, via HA’s native support for my 2245 Hub, such that I can control the dimmer via HA and work it into automations.

However I can’t seem to trap events from my mini remotes. I can hear them chirp when I put them in linking mode and then call the HA insteon.add_all_link service, as if they’re responding to the link request. But that’s the limit of my progress.

Is that only possible via (a) using a PLM instead of a hub, and/or (b) running HA on something other than hass.io on a Raspberry Pi (so that I can install certain Python libraries)?

Mini remotes do not appear as Entities in HA, they only trigger automations. For example,

- id: '1552262250942'
  alias: Mini Remote Lock Front Door
  trigger:
  - event_data:
      address: 1a2b3c
      button: b
    event_type: insteon.button_on
    platform: event
  condition: []
  action:
  - data:
      entity_id: lock.front_door_lock
    service: lock.lock

The example above will listen for mini-remote 1a2b3c button b.

I’ve not seen anything come across the HA event stream of the type insteon.button_on, even after attempts at pairing. So I can’t set up automations as you recommend.

I suspect I need more progress on the pairing side before mini remote events will pass through HA via the 2245 hub.

Put insteon in debug mode by using the following somewhere in your configuration.yaml file:

logger:
  default: info
  logs:
    insteonplm: debug
    homeassistant.components.insteon: debug

Then update the logs so I can see what devices the Hub knows about.

Also, with the insteon component in debug mode, if you press the buttons on the remote, the log with catch them. This will confirm the Hub can see the remote’s buttons.

OK, log sent to you via direct message.

The mini-remote is a battery operated device and so it does not reply to device id requests. In order for HA to see the device you need to setup device override configuration as follows:

insteon:
  host: !secret hub_ip
  username: !secret hub_username
  password: !secret hub_password
  ip_port: 25105
  
  device_override:
    - address: 44899f  # 8 button mini remote
      cat: 0x00
      subcat: 0x1b
    - address: 449b4e  # 1 botton mini remote
      cat: 0x00
      subcat: 0x1c

Hopefully you saw this in the documentation for the Insteon component.

As you mentioned, this is a case of not “RTFM”-ing. I didn’t get down to that section of the documentation because I assumed I was still stuck on the pairing process.

Having now added overrides to my configuration.yaml I can trap and act on events generated by the mini remote. Thanks a bunch for the help, and for writing the module in the first place.

Glad you figured it out.

I have just released a significant update to the insteon component as a beta. It is available through a custom component to allow people to test without disrupting current implementations. The details are in this thread: