Full local solution for insteon integration?

There is no secret to it. From what I understand it is a standard low level protocol. There is lots of stuff scattered around about how to use tcp socket with insteon plm. Just have to google around a bit. All the heavy lifting is done by the node server, which people much smarter than I put together to control insteon devices.

All the driver does in this situation is also holds the line open to the node server via a websocket and listens for stuff to happen.

Direct control of devices with this driver is identical to the insteon direct dimmer driver. It issues the the get commands directly to the plm.

Several moving parts. But when it all comes together is very solid.

Do you know if the author of this node server on this forum? I saw the following in sample configuration file. It seems to me that it uses GET method via HTTP

	"platforms": [
				{
				  "platform": "InsteonLocal",
				  "name": "Insteon Local Platform",
				  "user": "<username from Insteon app>",
				  "pass": "<password from Insteon app>",
				  "host": "<local IP of your Insteon hub>",
				  "port": "<port from Insteon app [usually 25105]>",
				  "model": "2245",
				  "refresh":"300",
				  "server_port": "3000",
				  "keepAlive": "3600",

He is not. He can be found on the smarthings forums. You can always fire up the node server and see for yourself. Or not. the choice is yours.

I will google around about the raw tcp socket. BTW, does HE support raw TCP socket? If not, any plan to open it up?

I just asked this question a little bit ago. At this time I do not think so. I was hoping to open a socket directly to the plm and eliminate the node server. lol would be some major work though.

Ok @cwwilson08 you are confusing the crap out of me... you keep saying PLM but the PLM is serial or usb it does not support TCP sockets. So are you actually referring to the Insteon Hub?

you are correct. sorry

the many differences between these devices confuse me i must say...

Opening socket directly was often asked features on ST as well. Maybe I am over simplify the technical aspect the problem, I though it may open up can of worms for cloud based solution like ST, for local controller, such HE, it may be doable, sending data is relatively easy, for receiving, we could have callback function, similar to hubaction for http?

Users want to reduce number of devices that they need to deal with, getting rid of yet another middleman will be great. For me, I already had a powerful router, adding node server to it is not a problem, but for a lot of users, it requires setting up a RPi or similar, not so user-friendly.

I am getting a v2 HE. One of feature I wish for v3 HE is a USB port (like v1), so developers could add more functionality to HE. For example, some users complain about no wifi support, Hubitat could sell USB/wifi dongle, it is a win-win situation.

You can't add low level functionality when you can't access the low level. There's no way for a end user to add device support for USB devices with HE.

Maybe I misspoke it. I didn't mean the end-users add device support, I mean it enable developers to add more devices. Hubitat approves/certify them. It also enable Hubitat adding more supported devices later on.

I'm fairly sure the Hubitat team purposefully removed the external USB ports for the reason you are wanting. I don't think they have plans for "expansion" options as this hub is a "consumer" device with specific purpose/use.

I googled around. Here are what I found so far, raw tcp socket was available on older hub 2422, which is no longer supported by Insteon. Local http link to Hub 2245 only supports their lousy RESTful API, no raw tcp socket. @cwwilson08, do I miss something?

lol - ok i give - i tried to explain it from my understanding. perhaps i am wrong.

here is what i can say. i have a insteon hub 2245 (from bottom of hub).

The insteon server performs some magic that allows it to hear all the events broadcasted from hub. I can confirm this works great. What voodoo is involved in this i am apparently misunderstanding. From what I had read and looking at the code, i was sure it was tcp socket.

I have access to the Insteon developer docs as well as a Hub API key. I've been thinking of working on this but I haven't had time. Depending on how far along you are let me know what info you want/need.

Could you please clarify "Insteon server" and "hub" here? We have three nodes here: HE Hub, Node server (middleman), and Insteon Hub. The "Insteon server" refers to Node server or Insteon Hub? And the "hub" refers to "HE Hub" or "Insteon hub"?

The v2 has micro USB port for power, based upon your comments, now I think it could be a USB OTG port, we might just need a correct cable to enable USB devices :grin:

Yeah... or you could just crack it open and solder new pin connectors.... not the point really though.

ok

insteon server = the node server middleman (which is named insteon express server or some such)

hub = insteon hub 2245

Thanks a lot @jeubanks. Is the Hub API Key for their cloud solution? Are those Insteon developer docs the same as publicly published ones?