Sending raw TCP packets

Can’t. Submit a ticket. It’s a bug in the hubaction. We need more people to claim this as an issue. Needs to get priority.


Submitted one yesterday about this issue. Got a response stating to ask other forum members about it. Too bad, because TCP—even without a response—would be incredibly helpful…

1 Like

It’s a joke. Everything about HubAction sucks. That’s all I can add to the conversation that hasn’t been said already.

I’ve already forgotten the terminology, but what I ended up hacking together was sending bytecode that would intentionally be converted (by ST) to the UTF-8 (hex) signed equivalent, and then stringing together those bytes to form the command I needed.

So for instance, using your example, I would find a byte sequence that maybe ended in 0xCC, then another that started with 0x23 and 0x33. It was super hacky and, as you can guess, still only supported certain combinations of bytes, but I mean I did get it “working”

last edit: after a quick look here: , I couldn’t find a UTF8 combination that would work.

1 Like

Thanks, Jared. Unfortunately, you’re 100% correct, there seem to be more combinations that don’t work, than do.
For documentation’s sake, using extended ASCII characters doesn’t work, either. So, in a method similar to yours, sending an extended ASCII code of 0xCC, or 204 (╠) doesn’t work, either.

Don’t convert to ASCII. ASCII is 7bit so you’ll have some loss of data

Convert to either UTF-8 or ISO-8859-1.

byte[] bData = getMyByteData();
String sData = new String(body, "UTF-8");
sendHubCommand(new physicalgraph.device.HubAction(sData, physicalgraph.device.Protocol.LAN, getDataValue("mac"), [callback: calledBackHandler]));

Now if somebody can tell me how to get BACK a raw packet, that’d be very much appreciated.

1 Like

How are you getting from bData to body?
I think you use the deviceID to hold the hex host and port that you connect to, is this correct?

I played with things for quite some time and I still can’t get the raw data that has a 1 in the significant bit to transfer directly with either of these encodings.

I gave up getting this to work, so for now I am using a cygwin man-in-the-middle solution. Should you like to use it as well for a personal project, you can find it on my github.

source only - no binaries available at this time.

I then use the following for how to send example data from a DTH:

byte[] bytes = [0x71, 0x24, 0x0F, 0xA3]
String body = bytes.encodeHex()
sendHubCommand(new physicalgraph.device.HubAction(body.toString(), physicalgraph.device.Protocol.LAN, getDataValue("mac")))

Then once you have done a configure and make you start the application such as this:

./tcptunnel --local-port=5577 --remote-port=5577 --remote-host=<Local IP Address of target device> --log --stay-alive

BTW - I am encoding and decoding, so it should work for returned data as well, but I have so far only tested the ability to send data out from SmartThings.

I’m sorry I didn’t get back to you.

The code I shared with you was older code. I was trying to build a TLS transport layer with SmartThings. I was able to output data just fine, just I can’t receive byte which made my work pointless.

I’m using ISO-8859-1 which shouldn’t have the collision issues when converting to and from String and Byte[] types. It’s my suspicion that SmartThings, internally, takes the String object and calls String.getBytes() with no encoding specified. It would then use the object’s specified encoding which should keep the data 1:1.

def hosthex = getDataValue("ip");
def porthex = getDataValue("port")
def target = "$hosthex:$porthex";
device.deviceNetworkId = target;

byte[] body = buildTLSClientHello();

log.debug "${body.length} ${bytesToHex(body)}";
String strBody = new String(body, "ISO-8859-1");

return sendHubCommand(new physicalgraph.device.HubAction(strBody, physicalgraph.device.Protocol.LAN, getDataValue("mac")));

Here are a couple of functions I built that may serve useful for you, or others trying to send byte data:

// Build random block of 32bit integers
byte[] buildRandomData(size) {
  ByteArrayOutputStream out = new ByteArrayOutputStream();    
  writeInt(out, (int)Math.floor(new Date().getTime() / 1000), 32);
  for(def i = 0; i < size - 4; i++)
    out.write((int)(Math.random() * 0xFF));
  return out.toByteArray();

// Write int of varying bit-size (8bit, 16bit, 24bit, 32bit, etc)
public static void writeInt(ByteArrayOutputStream out, int value, int bits) {
  for(def i = bits - 8; i >= 0; i-=8) {
    out.write((byte) (0xFF & (value >> i)));

// Return hex-string interpretation of byte array
public static String bytesToHex(byte[] bytes) {
  final char[] hexArray = "0123456789ABCDEF".toCharArray();
  char[] hexChars = new char[bytes.length * 2];
  for ( int j = 0; j < bytes.length; j++ ) {
    int v = bytes[j] & 0xFF;
    hexChars[j * 2] = hexArray[v >>> 4];
    hexChars[j * 2 + 1] = hexArray[v & 0x0F];
  return new String(hexChars);

Thanks for trying; however, that does not work on my hub at least. :confused:

I changed one line from above to be"

byte[] body = [0x71, 0x24, 0x0F, 0xA4]

and when it sends, the value that I receive is:

71 24 0F C2 A4

It injected an extra [C2] byte to handle the A4 which is > 7F. I’ve tried this with other value as well previously and it would return very different values the higher up you go such that the last byte didn’t match the value requested.

Yea, this has been the problem all along, it won’t do 8 bit asci…


BUMP, any chance there has been any prioritization in the product plan to include this support?


Not really a direct help for the discussed issue but mozilla has an interesting product that might interest people frustrated by SmartThings limitations:

It’s probably not for everyone but for me it hits just the right spot between HomeAssistant and SmartThings (take care of remote access including basic mobile compatible UI, but run locally and remain fully open and easily extendable, already contains rules engine, …). Running node is also a bonus to me (writing extensions with good IDE support will be nice).

Does ST still have this limitation, as far as you’re aware?

[Edit: Nevermind, I still had my test file in the IDE and have confirmed that it’s still hobbled. So arbitrary.]

Hey, I know this is an old thread, but I think I just got the same issue.
Does ST still have the 8 bit ASCII limitation? any progress on that or a way to overcome this?

This is really strange, it seems that Smartthings is hemorrhaging customers to Hubitat because of this (and probably some other issues)

Is Samsung trying to kill this platform? It just seems such simple things are still now allowed. Any ideas why?

Over 90%, and maybe more, of people using the smartthings app don’t have a hub at all. They have a Samsung smart television or smart appliance.

The percentage of people going to Hubitat is a slice of the power users who use the hub, but that’s not where Samsung is making its money. It’s good to have choices, of course.

Ok thats interesting. SO really SmartThings is like Tuya or SmartLife. You can add Samsung devices to it natively without the hub (as you can tell, I don’t have any Samsung smart appliances lol) And that the hub is just an indulgence for the power users, when really when Samsung brought SmartThings they just wanted the platform for other stuff?

You can add some Samsung devices to a smartthings account without needing a hub. Specifically the smart TVs, smart appliances, and the smartthings branded Wi-Fi devices. And you can add any of the cloud to cloud integrations in the new V3 app without needing a hub. Really you only need a hub for Z wave or Zigbee devices.

As far as why Samsung bought smartthings when they did, they’ve never said officially for sure. At the time, I mentioned that I personally thought they bought it for the name and the buzz that it had at that time. But we don’t really know for sure. All we do know is that power users are a very small percentage of the total customerbase. :sunglasses:

1 Like

Do we still have this problem in 2021? :frowning:

Any chance you can provide the full code for a DTH to simulate a multi-button switch?
So each button would be linked to a specific hex string.
Sorry, I’m really new at this, with very limited coding experience.
I am able to control the device sending hex strings using Netcat on the Mac terminal.
Thank you!