hubAction and character encoding issues

Arggg…
Dinking with an iTach IP to serial device so I can send some commands to an audio device.
This equipment command set is in hex, fair enough.
I’m finding that somewhere after the string is submitted to hubAction any value over 127 is being split into two bytes along the way.
ST device debug:
5‎:‎20‎:‎17‎ ‎PM: debug hex:11 22 ff Int:17 34 255 acs:[]["][ÿ]
I put brackets around the ascII text for debugging so I could verify the character counts in the final string.
So I know the string is correct, however on the serial port I get this: 11 22 C3 BF

If I use any hex value with an integer value of less than 128, things are fine…
WTH???, anyone run into this? or have a solution?

Just a wild guess, since I don’t know the context: Signed vs. Unsigned byte somewhere along the line?

Yea, something like that, all I know is that it was fine until ST got a hold of it…

Anyone know how to escape these so they aren’t truncated along the way?

1 Like

You can certainly try writing Support@, but this is definitely an example of something they would like to help with, but the problem would stall for two reasons:

  1. iTach IP is not on the Supported “Works With SmartThings” Device List.
  2. If there’s a bug, there’s no documentation to cross-reference if the behavior is to spec or not.
  3. Escalations back to engineering are worth encouraging … but I know some folks have ended up… discouraged.

Well – hopefully someone here has either encountered and worked-around, or can suggest more traces.

Good-luck.

It’s got nothing to do with the iTach, and everything to do with some character encoding mismatch…

1 Like

Not to put her on the spot (during her first week?), but @April mentioned to not hesitate to @Mention her for things like this (I think). She wants to help maximize the value of Community, including helping to relay developer-level tech problems like this to ST engineers.

The idea is to get around the inconsistent results that directly @Mentioning certain engineers that we’re familiar with. Sometimes that sort of direct @Mentions works very well, but sometimes not.

So: She’s @Mentioned now.

(I’ll step out of the way now, unless I come up with something more specific.)

I think I need to make a BeetleJuice reference here, and you’ll have to mention me 3 times before I magically appear.

@Mike_maxwell , I’m actually unfamiliar with this issue, but I’d be happy to call some attention to it. As it’s the weekend, I suspect some delay in response, however I’ll update you when I hear something.

2 Likes

You should also remind him to bring the Handbook.

1 Like

I would very much appreciate the help on this. Calling hubAction is very undocumented, and pushing raw ascII through it even more so. The basic issue here being sending extended AscII (integer values between 128 and 255) results in two bytes on the other end, vs one as it should be. I’ve blown about 8 hours on this so far trying different ways of doing this…

Answered my own question, utf-8 can’t create a single byte value > 128, they’re all two bytes. So unless someone knows how jack binary data into hubAction I think I’m screwed on this project.

1 Like

Hi, did you make any headway on this? I have been smashing my head against the wall on this all weekend as well. Anything over 127 gets screwed up.

@jared
I did not, in fact I gave up…

Hey Mike,

I found a way to do this – I was able to send a character outside of the normal ascii range (0xC2 hex 194 dec).

Let me know if you’re interested in the how to.

@jared ah yea! For sure man!

Why don’t you share your findings with everyone? This is what this forum is for. :slight_smile:

1 Like

@jared, dude, why did you delete this?
I didn’t even have a chance to mess with it yet…

I couldn’t reduplicate the results with other values

So, with understanding that this method requires verification:

I don’t know why it works; I sniffed the traffic this morning and smartthings doesn’t send the right bytes. Not sure if my device just ignored the noise or what, but like I said I couldn’t reproduce working results with other >127 characters.