IP2SL and Rotel Feedback

So I've got this Rotel RT-1080 tuner with serial control. The protocol document can be found here:

http://www.bwgroupsupport.com/download/rs232

I have it plugged in to an iTach IP2SL and have the iTach configured properly. I can send it commands and it takes the commands properly. The problem is feedback. This devices does not use any kind of newline delimiter for the commands NOR on the feedback it sends.

Now I happen to know Crestron devices can be programmed to talk to this thing via serial and get feedback, but not because I've done the programming, just because I'm replacing working Crestron with Indigo. But as near as I can tell, it would take some fairly involved programming to fish out the useful part of the feedback.

Currently, I get a lot of errors from the python code if I have this module enabled at all, and I presume it's because the module is listening for the feedback and, more importantly, the termination for the feedback, which never comes. Here's the important part of the log:

Code: Select all

Cynical Network Error           plugin runConcurrentThread function returned or failed (will attempt again in 10 seconds)
  Error                           XML Parse Error: not well-formed
  Error                           On character 354 of line number 1.
  Cynical Network Error           in runConcurrentThread: Traceback (most recent call last):
  File ".../Server Plugin/cyin/debugging.py", line 46, in diagnostic_log
    yield
  File ".../Server Plugin/cyin/debugging.py", line 56, in diagnose_call
    return method(*args, **kwargs)
  File ".../Server Plugin/cyin/asynplugin.py", line 51, in runConcurrentThread
    self.run()
  File ".../Server Plugin/asyn/inject.py", line 49, in run
    asyn.Controller.run(self)
  File ".../Server Plugin/asyn/controller.py", line 88, in run
    item._can_read()
  File ".../Server Plugin/asyn/selectable.py", line 227, in _can_read
    result = scan(self._rbuf, self.callout)
  File ".../Server Plugin/asyn/scan.py", line 68, in scan
    callout(ctx, *m.groups())
  File ".../Server Plugin/asyn/core.py", line 136, in callout
    results = [cb(ctx, *args) for cb in list(self._callbacks)]   # latch callback list
  File "plugin.py", line 140, in _event
    self.lastinput_var = matches[0]
  File ".../Server Plugin/cyin/attr.py", line 272, in __set__
    indigo.variable.updateValue(self._variable(obj), str(value))
StandardError: ServerCommunicationError -- timeout waiting for response

  Cynical Network Error           plugin runConcurrentThread function returned or failed (will attempt again in 10 seconds)


That repeats every 10 seconds for as long as the device is comm enabled. So am I hosed on getting meaningful feedback from this device unless I want to start parcing it directly in python? That's a bit over my not-really-python-enabled head, unfortunately. All I really want is the station number after hitting a preset button or the tune-up/tune-down buttons.


--Donnie

If that post really was from November, it fell through the cracks. Did this resolve itself with a newer version of the plugin?

It really was from November, and no, it hasn't resolved itself. But then again, I haven't tried it again. Should it resolve itself?

Based on everything I've *read*, it seems like you need a newline in the feedback. Is this not actually the case, or has it been updated to not be the case?


--Donnie

I too had a similar error as Donnie:

Code: Select all

  Cynical Network                 **Crestron (.226) recognized ***Data Received from Crestron 'SN05 T?\rSN01 R?\rSN01 T?\rSN02 T?\rSN05 T?\rSN01 R?'
  Error                           XML Parse Error: not well-formed (invalid token)
  Error                           On character 370 of line number 1.
  Cynical Network Error           in runConcurrentThread: Traceback (most recent call last):
  File ".../Server Plugin/cyin/debugging.py", line 46, in diagnostic_log
    yield
  File ".../Server Plugin/cyin/debugging.py", line 56, in diagnose_call
    return method(*args, **kwargs)
  File ".../Server Plugin/cyin/asynplugin.py", line 52, in runConcurrentThread
    self.run()
  File ".../Server Plugin/asyn/inject.py", line 49, in run
    asyn.Controller.run(self)
  File ".../Server Plugin/asyn/controller.py", line 91, in run
    item._can_read()
  File ".../Server Plugin/asyn/selectable.py", line 212, in _can_read
    self._scan(input)
  File ".../Server Plugin/asyn/scan.py", line 53, in _scan
    result = self.scan.scan(self._rbuf, self.callout)
  File ".../Server Plugin/asyn/scan.py", line 108, in scan
    callout(ctx, *m.groups())
  File ".../Server Plugin/asyn/core.py", line 140, in callout
    results = [cb(ctx, *args) for cb in list(self._callbacks)]   # latch callback list
  File "plugin.py", line 140, in _event
    self.lastinput_var = matches[0]
  File ".../Server Plugin/cyin/attr.py", line 358, in __set__
    indigo.variable.updateValue(self._variable(obj), str(value))
StandardError: ServerCommunicationError -- timeout waiting for response

  Cynical Network Error           plugin runConcurrentThread function returned or failed (will attempt again in 10 seconds)

When I asked (you) Perry about it you wrote:

The traceback shows the plugin asking Indigo to set a variable, and (looks like) getting a timeout from the Indigo server. I don’t know where the “XML Parse Error” message is coming from. These kinds of error logs are a bit confusing because the Indigo log mixes messages from the plugin process and the server together, and server errors get there first (since they don’t have to be sent over from another process), so they’re often out of order.

The obvious question is what value is (trying to be) set into that Indigo variable?

And, of course, double-check that you have the latest Indigo and the latest version of the plugin.

I have the latest version, and I don't think the data being set is anything funky, but I wonder if there are disallowed characters (maybe something that was not escaped correctly)? I still get this error on a regular basis and it is still "fixed" by simply turning off the plugin and turning it back on. I'm thinking of trying to bandaid it by scanning the logs and trying to script together something to turn it off and back on, since I don't know python all that well either....