Full local solution for insteon integration?

šŸš§ Developers
54

Yes it can, I actually worked on an insteon integration last year, it was a real pain since the messages do not have an end delimiter and they are of differing lengths. We ended up not using it since our understanding is that not all insteon hubs support that raw socket, it was closed on the newer ones and the older ones could no longer be purchased.

docs are here: https://docs.hubitat.com/index.php?title=Raw_Socket_Interface

I have gotten some reports of slow down issues with this interface, I have not been able to reproduce them so feedback is welcome.

55

Chuck, compared to using a standard TCP message, is there additional overhead in the system involved with Raw sockets?

Also, can I use raw TCP sockets to send a global message and capture message from all responding devices? This would solve a issue I have in the TP-Link integration in discovering devices.

Dave Gutheinz

56

Are there any examples of the Raw Sockets code?

I've been unable to get sendMessage to be happy with the input I am providing.

57

This works for me during my testing. I get a proper return. Remember, the return is raw, not a parseLanMessage

//	=====	TCP TEST CODE	===================================================
private sendTcpCmd(command) {
	def message = tcpEncrypt(command)			//	See note in method tcpEncrypt
	interfaces.rawSocket.connect(deviceIP, 9999, 
								 byteInterface: true,
								 readDelay: 150)
	interfaces.rawSocket.sendMessage(message)
	runIn(5, closeSocket)
}
def parse(response) {
	log.warn "TCP Response is ${response}"
	def encrResponse = parseLanMessage(response)
	def cmdResponse = parseJson(inputXOR(encrResponse))
	log.warn "TCP Return message is ${cmdResponse}"
}
def closeSocket() {
	interfaces.rawSocket.close()
}
def socketStatus(response) {
	log.warn "TCP Socket is closed"
}
//	===========================================================================
58

Thanks. I'm pretty close to the same thing, but have not been able to get my message in the right format.

Are you able to share more of the "tcpEncrypt" method?

59

Code is below; however it is particular to the TP-Link devices. What it does is convert the ASCII (JSON) command to HEX and then complete an XOR conversion. Makes it hard to read, but not secure.

//	Utility Methods
private tcpEncrypt(command) {
	def str = ""
	def encrCmd = "000000" + Integer.toHexString(command.length())
 	def key = 0xAB
	for (int i = 0; i < command.length(); i++) {
		str = (command.charAt(i) as byte) ^ key
		key = str
		encrCmd += Integer.toHexString(str)
	}
	return encrCmd
}
private udpEncrypt(command) {
	def str = ""
	def encrCmd = ""
 	def key = 0xAB
	for (int i = 0; i < command.length(); i++) {
		str = (command.charAt(i) as byte) ^ key
		key = str
		encrCmd += Integer.toHexString(str)
	}
   	return encrCmd
}
private inputXOR(encrResponse) {
	String[] strBytes = encrResponse.split("(?<=\\G.{2})")
	def cmdResponse = ""
	def key = 0xAB
	def nextKey
	byte[] XORtemp
	for(int i = 0; i < strBytes.length; i++) {
		nextKey = (byte)Integer.parseInt(strBytes[i], 16)	// could be negative
		XORtemp = nextKey ^ key
		key = nextKey
		cmdResponse += new String(XORtemp)
	}
	return cmdResponse
}
60

It sounds like you are asking if you can send a broadcast message and then listen for the response. That is not possible with this interface. The raw socket interface is just like telnet in that it opens a connection to a specific device and starts up a listener for any responses, it maintains that connection so it is not a single message and response mechanism, you should use HubAction for that still.

61

you should try something like this, it avoids the overhead of starting up the raw socket interface:

import hubitat.device.HubAction
import hubitat.device.Protocol

...

sendHubCommand(new HubAction(message, Protocol.RAW_LAN, [destinationAddress: "${deviceIP}:9999", encoding: HubAction.Encoding.HEX_STRING]))

any response should be sent back to parse.

edit: I realize there is a part missing from Raw Lan, added destination address

1 Like
62

I assume this is better than the hubAction for UDP. True?

I have it working with the the Protocol.RAW_LAN. Added options for timeout and callback method. NICE!

63

I was able to get the rawSocket version to work:

interfaces.rawSocket.connect(ip, port.toInteger(), byteInterface: true, readDelay: 500)
interfaces.rawSocket.sendMessage(formatMessage("status"))

But what should be the HubAction does not send the response to (the same) parse function.

sendHubCommand(new HubAction(formatMessage("status"), Protocol.RAW_LAN, [destinationAddress: "${ip}:${port}", encoding: HubAction.Encoding.HEX_STRING]))

(formatMessage is my string to hex conversion function)

I have confirmed with a packet capture that the request is being received in the expected format and the reply is being sent back, but parse is only called in the rawSockets setup.

The response is a raw blob of text, lines with a KEY: Value format.

I am looking for the command, it's reply and then can close out the socket, there is a "end of response" key, so I can close the socket from my end and avoid most of the issues associated with a stale socket -- but it seems the HubAction would be the best solution for my use case.

Am I missing something simple, or is this expected behavior and I should stick with the (working) rawSocket version?

64

does the device expect a byte array or a string? if it is expecting bytes, that is the correct way to call it, if it is expecting a string, then you should just send the string to the device without encoding. What device is it? does it expect a persistent connection or is it single message/reply?

65

The device sends and receives a short integer before text.

That seems to force me in to binary / bytes.

And it is a signal request -> response poll. (I close the connection from my end as I process the end of the response.)

The device does receive and respond to the message in either case, it just doesn't seem to trigger the parse function in the HubAction form.

66

@SmartHomePrimer,

I have a substantial investment in Insteon devices, so I am very interested in controlling them via my new HE that I am using to control ZWave and Zigbee devices.

After reading hundreds of discussions on HE / Insteon integration, it seems the simple solution you mentioned in this post would be ideal for me.

Did this project ever come to a satisfactory conclusion? Is there a link you can provide to the resources I will need to install it?

Thank you.

67

I use this everyday. Most stable devices in my home, no contest.

It was moved to Beta after an issue one user had, but Iā€™ve never been able to duplicate that more than once. It should almost be changed back to [Release] in my opinion. However, Chris did all the development and he isnā€™t on the forums much these days, so if it has a problem, I cannot fix it myself. I can say in my home, thereā€™s no problem.

68

Thanks, @SmartHomePrimer,

The implementation of the Insteon server on an intermediary computer looks too tough for me. Is there any hope for a direct Insteon Hub to Hubitat solution in the future? Excluding the installed base of Insteon devices from the Hubitat community seems like a bad business decision.

Don

69

In short, No. That's an Insteon users opinion.

Don't get me wrong, I'm with you 100% on how great Insteon is, but everyone else in the world that doesn't own Insteon isn't going to drop any coin on a proprietary solution when there's so much Zigbee and Z-Wave to choose from. Yes, Insteon is superior with their dimming control in hardware, and putting all Insteon devices in an Insteon scene gives very nice results that other systems cannot achieve. They don't however, participate in Hubitat Elevation groups with the Hue Integration in HE, as an example. If you're only using Insteon, you can access Insteon groups via an Insteon keypad. Might be a way by software without owning a keypad. Can't recall and I don't own a keypad either. Only bought one temporarily for initial testing with Chris (who, despite not being an Insteon owner other than a few devices he bought just for testing) graciously donated a significant amount of his time, money and effort to build these drivers, together with the help of Scott Kuester whom was the author of the node.js apps (Scott also wrote the original Homebridge plugin where this evolved from).

Having said that, because they are such an island, you either go with our community implementation that uses a separate computer to forward and receive updates via IP, or you replace the Insteon hub with an ISY. There's another user that's written an implementation for ISY, but I'm not sure he shares the code publicly, if at all.

We must have the separate node.js server. If you're not familiar with node.js, it's something you may wish to familiarize yourself with. I have other node.js apps I run too (i.e. Homebridge to allow Hubitat to show up in HomeKit, v1 Google Assistant Relay to allow silent control of Google Home compatible devices, and CastwebAPI to allow me to send TTS message in the official Google Assistant voice to a mini), in addition to the two simple node.js apps needed for my link to the Insteon hub. I run all mine on an old MacBook Pro laptop by just opening terminal windows and starting each process. Works great for me, and gives me the bonus of an always on computer to use with TeamViewer so I can remote back in to the hub for admin purposes. Plus, it's fast and automatically backed up with Time Machine.

If you're a MacOS or iOS user, and you own an Apple TV 4 or later, you could use HomeKit automations to sync Insteon via a Homebridge plugin for Insteon. I used to do this. It's not as capable as our driver, but it works. Was far too slow and unreliable when I had it configured long ago, but that was also a different Hubitat Homebridge app that wasn't as efficient as the one @dan.t has built. It might work fine now, but I've zero good reason to try it. This setup with our app is a far superior way to get Insteon directly into HE, instead of having to sync a bunch of virtual switches. The Homebridge part is really easy today with the Hoobs installer on a Pi or other computer.

70

2245 Hub+Homebridge didn't work reliably for me. Mainly due to web API of 2245Hub is unreliable. Homebridge requires nodejs, which is too big for my router. So I ended up writing a c++ programing: it opens websocket server port that can communicate with HE, and the other side, it talks to a PLM.

71

@SmartHomePrimer ... in your post you made reference to another HE user who wrote a implementation for the ISY. Could you please PM me the name of that user as I currently manage my INSTEON devices via an ISY and would like to link it to my HE.

72

@hlyi ... are you running your C++ program on a separate device/server or on the HE?

73

See here