Re: Problems sending the right commands - What does actually get sent out?

have you tried just:
new_state 777 1\x0A\x0D

if its controllable via telnet using ascii input, then shouldnt need
hex conversion. After all, it all comes in as identical bytes whether
its hex or ascii in the end.

Jarrod

On Dec 11, 1:28 am, deciBel <e...@mangset.no> wrote:
> Its a controller similar to Crestron / AMX.http://www.io123.no/adapt/html/AHC3000%20Ver%201_6%20User%20Manual.htm
>
> I've no idea of the what the ^A and ^B is. I tried pasting the code as
> you wrote it, but its the same.  (LED indicates that something is
> happening...and nothing happened in telnet either...)
>
> Could it be that I need to "convert" all the " new_state 777 1(\x0A
> \x0D) code to HEX   (?)
>
> On Dec 10, 2:48 pm, Jarrod Bell <jar...@guilink.com> wrote:
>
>
>
> > Hi Even,
>
> > What model of hardware is your actual controller?
>
> > "Start allways with ^A, end with ^B, space between parameters, max 32
> > parameters." - what is ^A and ^B? If it's uppercase A and B then your
> > commands would be:
> > Anew_state 777 1B\x0A\x0D
>
> > Sometimes with devices that are designed for telnet, you need to end
> > messages with both a line feed and carriage return (\x0A and \x0D).
>
> > We will be eventually adding a debug option to winViewer (which will
> > also be able to be used to test iViewer projects), but for now its
> > quite simple: whatever you put in your command values is what is sent
> > out, with \xFF formatting replaced with the equivalent hex byte (with
> > the exception of sliders which can use the slider value within the
> > command also).
>
> > Without knowing the device protocol, it's a bit hard to help any
> > further. Can you link us to a PDF with the full protocol details?
>
> > Jarrod
>
> > On Dec 11, 12:36 am, deciBel <e...@mangset.no> wrote:
>
> > > Hello.
>
> > > I'm having a bit of trouble sending the correct commands from CF
> > > iViewer to my controller unit.
>
> > > To give you the best background information, I've provided my setup
> > > for the test that I'm working on:
>
> > > System properties:
>
> > > My Controller device:
> > > IP: 192.168.1.160
> > > Port: 10023 (standard port for send/receive commands)
> > > TCP
> > > Maintain constant connection: Yes
> > > Heartbeat managed by system: Yes
> > > Rx:
> > > Tx:
> > > EOM:
> > > Connection Join: 0
> > > Startup Comand: "None"
>
> > > Within this testproject I've made 4 buttons with  4 differenent
> > > commands:
>
> > > "Testcode1" has a command value: new_state\x0A777\x0A1\x0D
>
> > > "Testcode2" has a command value: new_state 777 1\x0D
>
> > > "Testcode3" has a command value: 777
>
> > > "Testcode4" has a command value: 777\x0D
>
> > > If I simulate a command directly from the included software or telnet,
> > > for example a button with 2 states. "on" and "off" .  This is what It
> > > looks like in telnet:
>
> > > new_state 777 1 ("enter")           (= switch lamp on – only "enter if typed in
> > > telnet)
> > > (then it gives the feedback: "end 777"
>
> > > new_state 777 0 ("enter")           (=switch lamp off  - only "enter if typed
> > > in telnet)
> > > (then it gives the feedback "end 777"
>
> > > I can see on my controller that it receives "something" when pushing
> > > the buttons from iViewer/iPhone. (the LED on my controller indicates
> > > that something is happening.) but I can't see anything happening in
> > > telnet, or in the software that came with the controller unit.
>
> > > I did another test, linking my light switch button to also send an IR
> > > signal to my TV at the same changing the channel up and down as the
> > > lights went on and off :p . This IR worked fine when I sent it from
> > > the software, but nothing happened (at all) from iViewer…
>
> > > Abot to get really frustrated now. Feel like I've tried everything.
> > > I'm no programming guru, so don't blame me if this is "common sense"
> > > I would appretiate any guide, or help in the right direction…
>
> > > 1:
> > > Do I write my "command values" correctly? If not, what could be wrong?
>
> > > 2:
> > > Is there any way I can see the commands that are sent? (i.e. a debug
> > > window?)
>
> > > I've added some information from the Controller unit that I think
> > > might be of relevance. (Taken from the manufactures manual)
>
> > > Telnet
> > > The controller has a telnet server for interpreting commands – connect
> > > to controller IP address. The commands are the same as when connecting
> > > to the controller through port 10023 as a master program using the
> > > server protocol (explained below), except ^A and ^B are omitted at the
> > > start and end.
>
> > > Server Protocol:
> > > Send/receive socket port=10023
>
> > > Command stream:
> > > Start allways with ^A, end with ^B, space between parameters, max 32
> > > parameters.
> > > Command names are not case sensitive.
>
> > > The following escape sequences are recognized:
> > > \\ is replaced with single \
> > > \r is replaced with Carriage Return
> > > \n is replaced with New Line
> > > \" is replaced with single "
> > > \t is replaced with TAB
> > > \NNN is replaced with character with octal number NNN
> > > \xNN is replaced with character with hex number NN
> > > \ss is replaced with checksum at this position in string. The checksum
> > > is one byte, is initially zero and is from start of string.
> > > \sz is replaced with checksum=(256 - (sum&0xff)) at this position in
> > > string. The checksum is one byte, is initially zero and is from start
> > > of string. This is used when sum of all characters including check sum
> > > shall be zero.
> > > \sx is replaced with checksum as XOR sum at this position in string.
> > > The checksum is one byte, is initially zero and is from start of
> > > string.
> > > \sy is replaced with checksum as inverted XOR sum at this position in
> > > string. The checksum is one byte, is initially zero and is from start
> > > of string.
> > > \sc is replaced with checksum as CRC16 sum at this position in string.
> > > The checksum is two bytes, is initially zero and is from start of
> > > string.
> > > If character NULL is placed in the string (i.e. \000), this will
> > > normally terminate the string except when string is sent to RS232
> > > object in binary mode. The character will be replaced with NULL in the
> > > RS232 driver.

--

You received this message because you are subscribed to the Google Groups "CommandFusion" group.
To post to this group, send email to commandfusion@googlegroups.com.
To unsubscribe from this group, send email to commandfusion+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commandfusion?hl=en.