CNelson03

I tried the solution above (uninstall existing 'beta' version and reinstall from production store in the same slot). Overall, it worked (now on 2023.1.9 [Production]), although I had a bit of weird behavior (one parameter (device) not populating with their IR 'buttons' but 'borrowing' from other parameters). But I've seen this before and usually re-pasting, re-starting the IoX and UD Admin screen a few times gets everything in sync. Thanks.

Your corrected database worked, I was now able to upgrade the iTach-IR server. However, it still shows as "Beta" but the version is 2023.1.9 (without zeros) Per the sending of Global Cache commands with some erroring out, it's a wired (not wireless) IP2IR, and I tried connecting to it via a web browser and it was very sluggish. A power off/on reboot seems to have fixed that, at least for now, and I am able to send IR commands through the UD Node Server to the target devices.

When I press the described "Update" button under "Purchase" and "Available purchase/install options", nothing happens (no dropdown or action other than the button going inverse to show I clicked it. I tried this button when accessing it via menus: "Plugins Store" and "Purchases" as well as under the "Dashboard > iTach-IR(1) screen > Update button" -- always the same result, just an empty click. It says I'm on PG3x Version 3.2.20 and IoX version 5.8.0. Ideas?

I'm starting to work with the iTach-IR Node Server again (after not using it for the last year) and am getting some inconsistent operation -- sometimes a Global Cache code is passed successfully and works, sometimes an "Unknown Error (see Logs)" appears (and don't see much explanation in the node server log). I noticed I am on version 2023.01.09 [Beta] and it says there is a new 2023.1.9 version. Not sure if the update will solve the problem, but clicking the "Update" button (on two different pages) does not seem to update the Node Server. How do I force the update?

Thanks @Javi, I was able to connect with just a local connection and still use the iTach-IR Node Server I set up. I see the Portal license is reasonably priced so I might go ahead and get that as well.

I'm receiving a "System Closed" error when I open up UDM and it suggests trying a reboot (did that) but still receive the message. The eisy box appears to be working normal and I can login and control lights from the Admin Console. I can still open the Favorites section and the devices/buttons appear but clicking one returns an "Access license is expired." I recently migrated from a ISY994 that I had for many years, and it mentioned "Portal licenses" and a 30-day trial. Is this something to pay for now? I've bought modules in the past (e.g. Network Resources). I looked in my profile under the portal but can't find anything like "Buy now" or details. Or is there possibly another problem with the system?

Good to know on the Favorites, especially if I happen to notice a previous Favorite button missing. For the Sherwood receiver that I'm creating favorites, I have noticed that some (like Power On/Off) are working, while others (like Volume control/mute) are not. I figured this may have been because the "Sherwood" codes I downloaded from the GC Control Tower, were not for the same unit that I had (usually the vendor codes are common across a line, but I suppose not always). Maybe there was a bad code in there? I'll have to do more research as I do have the codes for my Sherwood recorded from a previous iLearn session that I did for my iRule controls. Thanks!

UPDATE: I went into Polygon and found "sherwd" in a previous test node server "iTach-IR(4)". I deleted the "sherwd" line/node and nothing changed (message-wise) but when I deleted the whole "iTach-IR(4)" node and then synced, I received the message that I received yesterday about the values to be removed. So I assume the "iTach-IR(4)" node deletion triggered the 99 missing values this time (not sure what did yesterday) and the "sherwd-NAME" in iTach-IR(4) was part of the problem. After backup, I selected the "Remove Unused Values" and synced. There was still a sync error: "1. could not match ND paramName error" but there was another old/test Node Server in Polygon, "iTach-IR(3)", and after deleting that and syncing a couple times, all the errors had cleared. So it appears those messages are 'normal' if there are unused things, or something has been deleted and changed. Good housekeeping rewarded (hopefully).

I'm working on building out a UDM-based interface on the iPhone and yesterday when I sync'ed UD Mobile (Settings>Systems>My Home), it downloaded many of the new Network Resources commands from eisy. At the end it said there were eight bad codes and did I want to remove these, so I said 'yes' (after the option to backup). At the end of the sync there was a screen similar to this: I selected 'Finish' and everything seemed to work fine except for the Sherwood receiver IR commands that are in the iTach-IR Node Server. One of the messages above mentions 'sherwd-NAME' so I'm guessing the errors are related to the iTach-IR NS. When I looked at the Admin Console, the entry for the Sherwood receiver was missing under the iTach-IR node. It was a bit late, so I left it and when I tried syncing again today, I received a similar message (the image shown above) but in looking at the iTach-IR Node in Admin Console, the node for the Sherwood was back again and the Sherwood commands are now working on the UD Mobile app. I noted the error message has a slightly different name than Admin Console ("rwood-receiver" vs "sherwd-NAME") but the Node Server node was created a couple times when I was trying to get it to work initially. So I'm not sure if that's part of the problem, but wondering why I'm getting the errors and the inconsistent operation. It was working fine before and I didn't change anything related to the Node Server (all the new adds were Network Resources.). @Javi Any ideas?

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.

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...

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?

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?

I noticed in the "Notifications" tab of UD Mobile, that my eisy will go offline and then back online a couple minutes later. I assume this is a reboot of some sort and it's been happening once or twice per day on average. Is this for firmware updates or some other normal behavior? It's not always the same time, some overnight, others during the day. I've been having some intermittent connectivity issues so I just wanted to check to see if something is up with the eisy.

@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?