Full local solution for insteon integration?

My HE hub is on the way, came from ST, Really like the idea of run automation locally. Anyway, I have quite a few insteon devices ( those device has high WSF (wife satisfaction factor:) ) and like to integrate with HE locally. I integrated insteon hub with ST locally before, but find the (local) API of insteon hub is slow, unreliable. I am thinking about the following approach, is this right approach to HE?

  • CMD: HE->(insteon bridge)->PLM(USB/serial, not hub2245)
  • Status: PLM->(insteon bridge)->HE(port 39501)
  • The insteon bridge is a daemon (light http server receiving command from HE, http client post status to HE, and a device driver for PLM) running on either RPi or my wireless router (running openwrt) (any other recommendation?)

Any suggestion or feedback is highly appreciated!

There's been talk back and forth about integrating either Insteon Hub or ISY with Hubitat. I've looked into this a little.

However I have to ask, if your primary tech is Insteon why not use ISY?

1 Like

So I use insteon and the 2245 hub but there is a local solution that sends commands from HE to the 2245, been very reliable for me.

There are some limitations wrt devices that have direct support, for me I just had switches so it works great.

We will be introducing a new community driver very soon. I'm holding off a bit, as we are working on Insteon Keypad integration. The driver uses web sockets to create a local link between HE and the Insteon Hub. It does require an additional Node.js application running on a Raspberry Pi or spare computer, but it is a very low impact application, so you don't need a lot of horse power for it.

This new Parent/Child driver type is much faster than the direct integration and provides instant updates to physical changes at the device, which isn't supported by the direct driver. In addition, this new driver supports automatic device discovery and child device creation in HE. Input devices such as Insteon Contact Sensors, Insteon Motion Sensors, and Insteon Leak Sensors are also now supported.


I have other Zigbee/Z-wave/Wifi devices, HE is a much better solution than ISY :grin:

Really? ISY supports Z-wave as well... and there's a Polyglot Nodeserver than integrates Hubitat with ISY bringing all the Hubitat device goodness to the ISY....

The problem is that from HE ( or my ST) -> Insteon may be okay, but feedbacks from dimmers/switches/sensors could not get back to HE (ST) reliably.

Ah, yes had that too - I setup a rule to poll them occasionally to get around it, I agree not great.

1 Like

Guys. There will be another solution available soon. As @SmartHomePrimer said it will require a node server but will allow for auto updates.

That's great news! Just out of curiosity, the web sockets that you referred is a different API or ports than published one? I was struggled to get devices changes reliably with local link. Thanks!

@cwwilson08 has/is creating the drivers. That's something he could answer I think. I'm not a dev and don't understand your question.

I am not sure where he is having trouble getting events from.

However this integration opens a websocket to a node server. Port can be configured as desired. I have found it to most reliable. If the node server registers an event. Hubitat always responds.

Edit @chuck.schwer can hubitat support raw TCP sockets?

Admittedly, I don't own ISY, didn't have first hand experience. But I spent sometimes studying different solutions and based upon my personal needs/experience, I chose HE over ISY because 1) IDE and GUI is much better, 2) lack of Zigbee support natively from ISY.

Well that's an interesting approach. Most determine what their primary tech/protocol is and build around that. Either way I run a lot of systems so I'm not promoting one or the other they each have their benefits and weaknesses.

Could you please point me to public API you are using? My info may be out of date. When I integrated Insteon devices into ST more than one year ago, the only method I knew talking HUB locally is "GET" from /buffstatus.xml. This method is unreliably for me.

Yes that method is most unreliable.

We are using the node server as a middleman. It holds a constanct connection to the plm. Then sends all events to hubitat over websocket.

How node server talks to PLM? does it use "GET" from /buffstatus.xml? For me, that's the weakest link.

no it uses a raw tcp socket. keeps connection all the time.

the problem with the get buffstatus is it actually takes two http get calls to the plm. first one loads the buffer with data from the last command (which may not be the command you want the data from). then the second one retrieves the buffer data so you can parse it. If it is for the device you want all is good. If not you get errors.

the node server is more of an event listener. it just keeps the line open and waits for things to happen..

Is raw tcp socket API published somewhere? Or it requires NDA.