Adding CE-COM2 to MU1300

mfloyd · April 5

Having an issue with my first Muse project. I spoke with tech support for over an hour yesterday and they knew nothing about how to help me. All I am needing to do at this point is add a CE-COM2 to my project to control a Samsung TV in another room. This works fine if I put the local MU-1300 in the room and control the TV so I know code/drivers are correct. My biggest question is just how to add the unit and define the RS-232 like you do on the MU-1300. Using io:list in putty to grab the name of the serial device (idevice-serial-0) does not return any info about the CE-COM2 and I can not putty into CE-COM2. I have tried adding with various names with no success.

davedavez · April 10

I got the impression HControl devices were plug & play. Enable HControl, define the device and then use the device name you assigned in your code.

Tech support doesn't seem to have been trained much on Muse. I've only been able to get one out of four Duet modules working properly and so far support has only referred to the "code snippets" which don't address anything I've got issues with.

Are you using any Duet modules, or rolling your own code?

Marc Scheibein · April 11

I don't have a CE-COM2 box on hand, so can't check the descriptor file for VScode, and can't have a look by Automator... have you loaded firmware v1.2.3 to the CE box?

Regarding modules: I already tried

the Precis PR-0402 module
the Tascam DV-D01 module
Both overall worked fine. If you use older modules you have archived, it may be required to download them again, as all modules were reworked to include the descriptor files required for Muse.

Regarding the code snippets: for switcher devices modules (like the PR-0402) the snippet for setting a route and parsing a route currently are wrong.

I currently playing around with the N26x2 series encoder and decoder in VScode (Python). It's is a little challenge to understand the descriptor structure to set and read parameters, but basically at least I'm able to change the streams on the decoders (and it is more challenging if you also have to learn also Python itself... ). The N26x2 require firmware 1.4.2 or higher to support Hcontrol.

Marc Scheibein · April 11

Regarding accessing the COM ports of the CE-COM2....
The CE boxes are bound as Hcontrol device.

See attached a screenshot how to bind a Hcontrol device into Muse (here it is the N2622 decoder).

in Automator, the basic descriptor structure would be the same as shown in my screenshot.
As the CE-COM2 has 2 comm ports, you may have an additional parameter "port" to select the COM port.

To receive data, add an Event node, and use the parameter
For my decoder: decoder > serial > response
For the CE-COM2, again you may have an parameter to select the Com port

The following regarding VScode implementation is theory only!!
In VScode, the parameter for sending data might be the same path as in Automator.
For my Decoder kind of:

<myDevice>.decoder.serial.sendSer = "Hello World"

As the COM2 has 2 ports, the top device parameter may be an array, so kind of

<myDevice>.port[0].serial.sendSer = "Hello World"  // first serial port
<myDevice>.port[1].serial.sendSer = "Hello World" // second serial port

Marc Scheibein · May 3

Now have a CE-COM2 on hand.... I wasn't too bad with my assumptions

Sending data is

<myDevice>.serial[0].send = "Hello World" #serial port 1
<myDevice>.serial[1].send = "Hello World" #serial port 2

To receive data, you have to create listeners

<myDevice>.serial[0].receive.listen(parseSerial1)
<myDevice>.serial[1].receive.listen(parseSerial2)

Then create functions to parse the data

def parseSerial1(eventData)
  print("serial data 1 ==" +str(eventData.arguments['data'].decode()))

def parseSerial2(eventData)
  print("serial data 2 ==" +str(eventData.arguments['data'].decode()))

Marc Scheibein · May 3

What's the difference between "listen" and "watch"...???

Staying on the CE-COM2, having a look into its Descriptor file:

+- serial: Array [2]
   |   +- 0: Component (14)
   |   |  +- baudRate: Parameter <enum> ro [0 - 6] [ 1200, 4800, 9600, 19200, 38400, 57600, 115200 ]
   |   |  +- dataBits: Parameter <integer> ro [7 - 8] 
   |   |  +- mode: Parameter <enum> ro [0 - 2] [ 232, 422, 485 ]
   |   |  +- parity: Parameter <enum> ro [0 - 2] [ NONE, EVEN, ODD ]
   |   |  +- receive: Event (1)
   |   |  |  +-- data <byte_array> 
   |   |  +- send: Command (1)
   |   |  |  +-- data <byte_array> 
   |   |  +- setCommParams: Command (5)
   |   |  |  +-- baudRate <enum> 
   |   |  |  |   +- [ 1200, 4800, 9600, 19200, 38400, 57600, 115200 ]
   |   |  |  +-- mode <enum> 
   |   |  |  |   +- [ 232, 422, 485 ]
   |   |  |  +-- stopBits <integer> 
   |   |  |  +-- parity <enum> 
   |   |  |  |   +- [ NONE, EVEN, ODD ]
   |   |  |  +-- dataBits <integer> 
   |   |  +- setflowControl: Command (1)
   |   |  |  +-- mode <enum> 
   |   |  |      +- [ NONE, HARDWARE ]
   |   |  +- status: Event (1)
   |   |  |  +-- value <string> 
   |   |  +- stopBits: Parameter <integer> ro [1 - 2]

An parameter that is shown in the descriptor as "Event" has to be "listen", where any other parameters are just to "watch".

Compared to NetLinx, on the "Event" parameters Muse will "listen" actively for any change (like a DATA_EVENT), where a "watch" only reacts on the moment (like a BUTTON_EVENT).

An Event type parameter could be referenced by "arguments", to pick individual values, where the other parameters only can be read by the parameter path directly.

This "arguments" thing is very helpful e.g. by responses from a Precis Duet Module. The module on a switch returns the changed route with the arguments
{'outputs': '1', 'input': 2, 'sl': 'VIDEO'}
And so can referred by argument names

myOutputs = myData.arguments['outputs']
    myInput = myData.arguments['input']
    myLevel = myData.arguments['sl']

Adding CE-COM2 to MU1300

Comments