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?)
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.
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.
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..