iTach IR - Extending to other Global Cache products

[CNelson03]

In a previous post, the discussion morphed to using the iTach IR Node server for other Global Cache products, so I decided to create this new post.

In its current state, the iTach IR Node Server is designed to work primarily with the Global Cache iTach IP2IR device.  I'm migrating from an iRule/ISY/GC environment that also has other Global Cache boxes, namely older GC-100-12 all-in-one boxes and a couple iTach IP2SL232's -- both not officially supported by the iTach IR Node Server, so I decide to investigate/test further.

Per the GC-100, it doesn't work now, but I think the existing Node Server may work for IR, provided the Module Address can be changed to 4 or 5.  Not sure how easy this is to do, but it appears modules 4 and 5 are needed for the GC-100-12: (diagram from the GC-100 API Specification Version 1.0d)

For iTach IP2SL RS-232 support, it requires a different code set (ASCII?).  iRule handled this with it's Gateway/Devices infrastructure (which is all no longer available as the servers were shutdown).  Fortunately, I had created a couple Network Resources to do some scheduled activities like a nightly sweep to power down devices.  I tried re-creating these as a iTach IR Node Server with a similar command structure except the "setstate" command:   function, code1, hexcode1, code2, hexcode2  "Power ON","setstate,1:1,@PWR:2\r\n",,  "Power OFF","setstate,1:1,@PWR:1\r\n",,   OR  "Power ON","setstate,1:1,@PWR:2",,  "Power OFF","setstate,1:1,@PWR:1",,   Neither of these works (at least in my system).  Perhaps this is due to other differences such as being "C-Escaped", ports, etc?

While the Network Resources approach does work for some of my devices, others I created do not seem to work (not sure why yet).  The Node Server approach is recommended anyway (and slicker than creating lots of Network Resources), so I'm wondering if others have found ways to get these to work via a Node Server?  For the Network Resources approach, have others found things (config, etc) that are needed to get them to work with various devices?

[Javi]

I'll try to change the iTach NS to allow for Module Address change when I get some free time.  So this should work for all of the GC IR Modules. 

I think the serial modules, or any of the other modules, would need their own Node Server.  I own a GC serial device but I'm not sure if I'll have time in the near future to develop anything.   If I remember correctly, the GC Serial modules can also publish incoming data which could also be handled by a NS.  The iTach NS is open source so if anyone wants to use or modify the existing code they are free to do so without restrictions.  My knowledge of Python is limited, so even the current NS could use improvements. 

[CNelson03]

Thanks, Javi.  My knowledge of Python is even more limited, but I do have some programming experience and Python book so maybe...

I'm going to start with seeing if I can get some Network Resources serial-232 and Hue calls working on the eisy.  But would welcome the ability to alter the IR module address should you find the time. 

For the iTach IR, I tried to just edit the Global Cache code that comes from the control tower (edit so the sendir points to 4:1 instead of 1:1) but that didn't work -- strangely even the commands didn't show up in the node hierarchy so not sure if there was some other error.  Either way, I assume the better solution would be to add a "Module" selector like there is for "Connector".

[Javi]

13 minutes ago, CNelson03 said:

For the iTach IR, I tried to just edit the Global Cache code that comes from the control tower (edit so the sendir points to 4:1 instead of 1:1) but that didn't work

The node server resets the Module Address and Connector, so manually editing these values will have no effect. 

15 minutes ago, CNelson03 said:

strangely even the commands didn't show up in the node hierarchy so not sure if there was some other error.  Either way, I assume the better solution would be to add a "Module" selector like there is for "Connector".

Could be the Node Server's parser.  If I recall I only tested parsing with the default Global Cache Database values, i.e. 1:1.

I'll update here when I have something to test for module address changes.

[glsmith777]

Nice job on the iTach NS!  I have been using the ITach NS for LED candles, Samsung TVs, etc.  It is working without issue.  Took me a couple of minutes to determine that I could run 3 instances of the iTach NS - one for each of the GC ITach IRs I have (in three different locations).

I also have an ITach IP2SL device to control our Bose Lifestyle system.  Using it requires over 60 Network Resources.  Which makes defining programs a challenge as the list of resources becomes unmanagable. I just wanted to let you know, I would be very much interested if you either added IP2SL support to the existing iTach NS or created a separate IP2SL NS.

Or maybe someone should develop a generic Network Resource NS with input something like:

proto    tcp
url    192.168.0.3
port    4999
mode    binary
Bose    "Upper Office Power On","11;0;1;4;76;1;0;2;11;1;75",, "Main Power On","11;0;1;4;140;1;0;1;0;0;130",, "All Power Off","11;0;1;4;247;1;0;1;1;0;248",,

My 2 cents anyway.

Thanks for the iTach NS!

 

[CNelson03]

While I'm interested in potentially trying to build a IP2SL solution (much cleaner than a ton of Network Resources), I can't seem to get my Network Resources to the IP2SL to work consistently under the new eisy box.  Not sure what is the problem, but commands don't work consistently and I often get a message back in the Admin Console "TCP client read response failed (Net Module Rule xx) (where xx is an often a different number) and a REST error when trying though the UD Mobile app.  

I have one IP2SL connected device that does seem to work better than the others, and the IP2SLs all still work through my old iRule system, but that has it's own gateway/device structure that communicates directly to the IP2SL, not through the eisy.  iRule is no more so can't stay there long-term, I just have one old iPad that seems to still run it, probably because it's 'frozen' back at an old iOS version.  

Don't know if anyone has ideas on what might be wrong, but until I can get them working under eisy, I'm kind of stuck.  Any tips you found to get your IP2SL to work through eisy and Network Resources?

[Javi]

On 4/10/2023 at 8:33 AM, CNelson03 said:

While I'm interested in potentially trying to build a IP2SL solution (much cleaner than a ton of Network Resources), I can't seem to get my Network Resources to the IP2SL to work consistently under the new eisy box.  Not sure what is the problem, but commands don't work consistently and I often get a message back in the Admin Console "TCP client read response failed (Net Module Rule xx) (where xx is an often a different number) and a REST error when trying though the UD Mobile app.  

I have one IP2SL connected device that does seem to work better than the others, and the IP2SLs all still work through my old iRule system, but that has it's own gateway/device structure that communicates directly to the IP2SL, not through the eisy.  iRule is no more so can't stay there long-term, I just have one old iPad that seems to still run it, probably because it's 'frozen' back at an old iOS version.  

Don't know if anyone has ideas on what might be wrong, but until I can get them working under eisy, I'm kind of stuck.  Any tips you found to get your IP2SL to work through eisy and Network Resources?

If you post the network resource someone may be able to see the issue.  Usually a rest error for network resources is because the resource failed or responded or responded with something that could not be parsed by ISY.  

[CNelson03]

@Javi Where is the best place (forum group) to post under?  Today I'm not getting the TCP client errors but things still not working when trying to interface through the iTach IP2SL.  Probably something easy (to the trained eye) but just wanted to start the thread in the correct group.  I could post here but technically not an IR unit.  Recommendations?

[CNelson03]

While somethings are working fine, I'm having a couple problems with the eisy to IP2SL232 setup.  Here's one of the problems:

I have a Dayton Audion DAX66 Distributed Audio System (multi-zone whole house audio controller).  The serial command to mute zone 16 is "<16mu01" (zone 16 mute on).  It works through the Global Cache iTest utility:

 I've setup Network Resources in eisy with the same command to mute the volume but receive an error:

(Note the \r\n is a Carriage Return/Line feed and should be converted to an invisible character in the "Actual" box above)

After running the Network Resource, and looking at the iTest tool, I see that the command from Network Resources went through, but this time returned an error (and the additional 'setstate' command text was visible.

I have other IP2SL commands that are working through a Global Cache GC-100-12 and I believe these were working for the Dayton in the ISY994 box (my primary method was from iRule and that's no longer available).  Can't help but think I'm missing something obvious, any ideas?

[Javi]

Just eyeballing this but it looks like the Global Catch hardware may not need the #setstate.....  in the command.  Also my commands have "<cr>" for the carriage return.  Finally I am using Raw Text not C - Escaped.

 

 

 

[CNelson03]

Quote

2 hours ago, Javi said:

Just eyeballing this but it looks like the Global Catch hardware may not need the #setstate.....  in the command.  Also my commands have "<cr>" for the carriage return.  Finally I am using Raw Text not C - Escaped.

Thanks, removing the 'setstate,1:1," did indeed work.  Interesting as the 'setstate' works with the Marantz AVR that I have connected to another iTach IP2SL. It is required when setting the contact relays on/off (on a GC-100-12 or (I assume) an iTach IP2CC).  I believe it was working with the isy994 as well, but as noted previously, I primarily used the iRule device/gateway method to pass the codes so it might have been it didn't work on the isy994.  Either way, working now for the Dayton amp, so thanks.

I did also try the other ideas you suggested:

• Swap <cr> for \r\n:  That didn't work, at least with this device in my system.  The Resource Response pop-up just returned the whole command string (including the <cr>)
• Use Raw Text instead of C-Escaped:  I tried this with both the <cr> instead of \r\n and with the suggested method (no "setstate,1:1") and neither worked.

I also did some additional testing with other devices in my system:

• The Marantz AVR works with either "setstate,1:1,@PWR:2\r\n" or just "@PWR:2\r\n" in the Network Resource body.  Raw Text didn't work for me.
• I have an Oppo DVD player that uses similar commands to the Marantz (e.g. #PON to power on) and that also will work with, and without, the "setstate,1:1" statement included (C-Escaped method).
• Last, I have a Panasonic projector, it uses a different command structure with not just literal characters but mixed hex and literal characters.   The basic command structure is STX|command|:<optional parameter>|ETX   (where STX is hex \x02 and ETX is hex \x03).   

This command string in iTest works to turn on the projector: "setstate,1:1,\x02PON\x03\x0d" (where x0d is Carriage Return and you select 'Mixed' command type in iTest).  However, the same string called from a Network Resource, with or without the 'setstate', returns a pop-up window error containing the message:

 "TCP client read response failed [Net Module Rule: 62]"   (same message for Raw Text, C-Escaped or URL).  And unlike with the Dayton amp, no additional error message or ASCII Response shows up in iTest.

I didn't try creating a binary string in the Network Resource as I'm not sure my coding skills are quite that good but I did try with/without and ending carriage return.  Ideas on this one?

[CNelson03]

UPDATE:  Using an online ASCII Conversion Table, I was able to convert the Panasonic projector command in the previous post, \x02PON\x03\x0d into the binary 'decimal' format that it was looking for:  2;80;79;78;3;20

Entering the binary string into the Network Resource (with Mode=binary) recognized it as a PON (power on) and the command did work to turn on the projector:

A similar POF (power OFF) command (2;80;79;70;3;20) did work as well.

So it appears that sending IR2SL RS232 commands using Network Resources (or a Node Server if that is developed) for different devices requires flexibility in command structure, inclusion/exclusion of "setstate,x:y,", the selected mode, and port (for GS-100-12 it could be 4998, 4999, or 5000). 

A Node Server could make this easier, but probably will be a challenge to write without some programming skill and at least more documentation on how it all works.  Handling the return codes (for things like getting the current volume level) could be an additional challenge (but really cool

Next up: tackling IP controlled devices...

[glsmith777]

I have been using the Binary mode to control my Bose lifestyle and it also works consistently.   So, binary mode would certainly be a requirement

 

[CNelson03]

I did some additional work on migrating from my iRule-based system to UD Mobile this weekend.  In digging through some Global Cache documentation, it sounds like no matter what form you enter the commands (literal, hex, decimal, mixed), it must be converted to its "byte forms" before being passed to the serial port.  So both iTest (the Global Cache test utility) and Network Resources must be converting the command string to machine readable form.  I assuming the reason some things work in iTest, but not Network Resources, is the string to byte conversion the tools are doing.

Here's a few observations:

• A format that works for one device (e.g. literal), may not for another -- it pays to test different approaches (especially 'binary' (decimal) for any string that has non-readable characters like STX \x02 in the projector, or BEL \x07 in your example);
• There is no command structure for serial data and the 'setstate' command is not needed for GC serial RS-232 ports unless maybe if you are doing something GC-specific like setting baud rates, etc.  Some devices may just ignore these commands and work fine (e.g., Marantz), while others throw an error (e.g., Dayton Audio).
• The 'command' ports (IR and CC-relays) do require a leading GC command (e.g., sendir or setstate) in Network Resources (hence Javi building a command string in the iTach-IR Node Server).
• 'C-Escaped' in Network Resources means ending with a carriage return.  A \r or \x0D is enough, you don't need to a line feed (\n) (although I think some things in iRule may have required this, at least per an old note I found).  With the 'binary' mode, an ending CR (20) wasn't needed (but didn't seem to hurt at least in my case, but this may depend on the device.)
• With all of the above, a bit of trial and error may be needed to see what works for a specific target device.

Per a possible IP2SL node server, this still would be nice for devices that have lots of commands (e.g., AVR or multi-zone audio).  However, as I migrate from iRule to UD-Mobile, I decided not to try to recreate every button/macro from the physical remote (like I did in iRule), and just build a simple iPhone remote that would do the things that I did 90% of the time (volume, select source, etc.)   A design choice?  Yes.  But so far it seems to be working, and in this case, just creating Network Resources for the things I need seems easy enough.  Network Resources are also fine for the CC-relays as there's only two commands for each relay (ON and OFF).

That said, for the whole house audio system with a dozen zones, each with a couple dozen commands, an iTach-SL Node Server would be much cleaner approach than hundreds of Network Resources.

I'm also currently having trouble with my iTach-IR Node Server, but I'll put that in a separate post.