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
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!
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?
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?
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.
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.
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.
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
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.
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.
@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.
Download the Hubitat app
