Does anybody know of a HDMI Matrix that is supported by LinuxMCE
I am looking to add support for one and want a reference template
Quote from: Techstyle on November 10, 2012, 09:05:51 PM
Does anybody know of a HDMI Matrix that is supported by LinuxMCE
I am looking to add support for one and want a reference template
We have several implemented as DCE Whisperer devices (Wyrestorm/Grandbeing and a few others too) that you base things on. They are rs232 or IP controlled. But you'd have to build a DCE Whisperer device to make use of then obviously.
All the best
Andrew
Hi Andrew,
I'm also wanting to write a device for an HDMI Matrix. I've had a look at the Wiki and it looks to be a fairly simple job. So I don't go off on a tangent, it'd be great to see one of the devices you mentioned. I've had a quick look in the source and can't see them.
How do you surfaces the devices controls in the UI? Or is it solely triggered from scenarios? An example of this would also be very handy.
I look forward to your response.
Steve
Quote from: stedaniels on June 07, 2013, 09:43:58 PM
Hi Andrew,
I'm also wanting to write a device for an HDMI Matrix. I've had a look at the Wiki and it looks to be a fairly simple job. So I don't go off on a tangent, it'd be great to see one of the devices you mentioned. I've had a quick look in the source and can't see them.
How do you surfaces the devices controls in the UI? Or is it solely triggered from scenarios? An example of this would also be very handy.
I look forward to your response.
Steve
Here is the source for the DCEwhisperer device for the HDAnywhere 4x8 v2 Matrix;
Quote
#!/bin/bash
shopt -s extglob
. /usr/pluto/bin/Config_Ops.sh
. /usr/pluto/bin/Utils.sh
DEVICEDATA_COM_Port_on_PC=37
DEVICEDATA_Port=171
DEVICETEMPLATE_HDAnywhere_Zone=2034
## Mandatory functions
Configure()
{
local Q R
local SerialPort
local IPAddress
SerialPort=$(GetDeviceData "$DevNo" "$DEVICEDATA_COM_Port_on_PC")
SerialPort=$(TranslateSerialPort "$SerialPort")
## Device connection generics
DeviceConnection_Type=serial # choices: none, serial, inet, custom
## Connection parameters
# type=serial:
DeviceConnection_BaudRate=600 ## yes, really: 600 baud
DeviceConnection_Parity=N81 # choices: N81, E81, O81
DeviceConnection_SerialPort="$SerialPort"
# type=inet:
DeviceConnection_Protocol=TCP4 # choices: TCP4, TCP6, UDP4, UDP6
DeviceConnection_Endpoint="$IPAddress:23" # Address:Port
# type=custom:
DeviceConnection_Command=
## What to do when the device is lost
DeviceConnection_OnDisconnect=reconnect # choices: disable, reconnect
## Device protocol generics
DeviceProtocol_Type=stream # choices: line, stream
# type=line:
DeviceProtocol_Separator=$'\r' # must match encoding
DeviceProtocol_Encoding=hex # choices: none, enc, hex
DeviceProtocol_AutoAppendSeparator=no # choices: yes, no
DeviceProtocol_Delay=.2 # delay between commands (seconds)
local Q R
Q="SELECT PK_Device FROM Device WHERE FK_Device_ControlledVia=$DevNo AND FK_DeviceTemplate=$DEVICETEMPLATE_
R=$(RunSQL "$Q")
local ZoneDevice Zone
for ZoneDevice in $R; do
Zone=$(GetDeviceData "$ZoneDevice" "$DEVICEDATA_Port")
if [[ -z "$Zone" ]]; then
continue
fi
export -n "Child_$ZoneDevice=$Zone"
done
}
ProcessDeviceStream()
{
local Data="$1"
Data=$(builtin echo "$Data" | tr -d '\r')
echo "Device said: $Data"
}
## Unknown command handlers
ReceivedCommandForChild()
{
local From="$1" To="$2" Type="$3" Cmd="$4"
local Zone
local VarZone
VarZone="Child_$To"
if [[ "$Type" != 1 ]]; then
ReplyToDCE "UNHANDLED" ""
return
fi
if [[ -n "${!VarZone}" ]]; then
Zone="${!VarZone}"
case "$Cmd" in
966) RouteMediaPath "$Zone" "$Parm_219" ;;
91) InputSelect "$Zone" "$Parm_71" ;;
esac
else
ReplyToDCE "UNHANDLED" ""
return
fi
ReplyToDCE "OK" ""
}
ReceivedUnknownCommand()
{
local From="$1" To="$2" Type="$3" Cmd="$4"
ReplyToDCE "UNHANDLED" ""
}
## Hooks
OnDeviceConnect()
{
:
}
OnInit()
{
## User configuration code
##########################
:
}
OnExit()
{
:
}
## Command functions
# Parameters come as environment variables of this form: Parm_<Number>
Cmd_1000()
{
Log "One thousand!! $Parm_999"
SendToDevice "$Parm_999"
}
## User functions
RouteMediaPath()
{
local Zone="$1" MediaPath="$2"
local Path Type Input
if [[ -z "$Zone" ]]; then
return
fi
Log "Route media path zone $Zone: MediaPath=$MediaPath"
MediaPath="${MediaPath//:/ }"
for Path in $MediaPath; do
Type="${Path%_*}"
Input="${Path#*_}"
if [[ "$Type" != IN ]]; then
continue
fi
InputSelect "$Zone" "$Input"
done
}
## The algorithm for computing the checksum is unknown
## These values have been extracted from the almost useless documentation received
## Otherwise, the commands are structured enough to be able to programatically build them
declare -a HardcodedChecksums=(
AE FB 3F 51
4C 19 DD B3
12 47 83 ED
91 C4 00 63
)
InputSelect()
{
local Zone="$1" Input="$2"
Log "Input Select for zone $Zone: $Input"
if [[ -z "$Zone" || ! "$Zone" =~ ^[1234]$ || ! "$Input" =~ ^[1234]$ ]]; then
return
fi
local HexZone HexInput
local Checksum
local HardcodedChecksumsIndex
HexZone=$(builtin printf "%02X" "$Zone")
HexInput=$(builtin printf "%02X" "$Input")
HardcodedChecksumsIndex=$(( (Input - 1) * 4 + (Zone - 1) ))
Checksum=${HardcodedChecksums[$HardcodedChecksumsIndex]}
local Cmd="BABABFC603${HexZone}${HexInput}${Checksum}"
## Send twice, for reliability
SendToDevice "$Cmd"
SendToDevice "$Cmd"
## The 03 after BABABFC6 appears to be a "select input" command
## There are two other commands in the documentation: 04 - "select previous input", 05 - "select next input
##
## The structure thus appears to be:
## BABABFC6 - 4 bytes that don't change
## CC - one byte representing the command (03 - "select input", 04 - "select previous input", 05 - "select
## OO - the output the command operates on
## PP - the input to be selected (for command 03), or 00 (for commands 04 and 05)
## KK - a checksum - algoritm unknown (see note on hardcoded values above)
}
## Start eveything up
. /usr/pluto/bin/DCE-connect.sh "$@"
Such devices are part of scenarios, and in the case of LinuxMCE, would be configured as the result of hooking pipes together.
I'm not sure if Dianemo still actively uses the pipe model, or if they've eschewed this for manual configuration.
-Thom
Quote from: tschak909 on June 10, 2013, 03:38:44 AM
Such devices are part of scenarios, and in the case of LinuxMCE, would be configured as the result of hooking pipes together.
I'm not sure if Dianemo still actively uses the pipe model, or if they've eschewed this for manual configuration.
-Thom
Dianemo supports the pipe model. But we also have media_config which is a text file that allows you to create pipe type connections between devices and can be edited by any text editor.
All the best
Andrew
Hi Andrew,
Thanks for the example code to work from, thankfully I'll have a simpler time I think as the protocol for my matrix is quite basic!
PORT $output$input
E.g.
PORT 11
Thom, I don't quite understand how it's going to be configured from the scenario yet, so will likely muddle my way through that over the weekend, I'll try and get onto IRC too if I don't get anywhere fast.
Thanks again,
Steve
Basically, when an AV device is created in the system, you have Pipes associated with it,
Those pipes can be configured either manually (in the AV screen), or they can be configured via the Connection Wizard, specifying what inputs are used, what outputs are used, etc.
This way, once a piece of media has asked to be played via a scenario, it can then be routed to the correct destination.
-Thom
I did some more digging with regards to the HDMI matrix support.
We have a database table, DeviceTemplate_Output, which can be used to create outputs for a given device template.
It consists of three relevant columns:
* FK_DeviceTemplate, this specifies the device template that this output belongs to.
* FK_Command, this specifies what command should be sent to the matrix to select this output, look at the Command table for command numbers.
* FK_ConnectorType, This specifies what connector to show in the connection wizard, (HDMI, Composite, S-Video, whatever), this is purely aesthetic, and has no functional impact, and can be completely optional.
Once this is filled in, you'll see entries show up in the Output pull-downs for your device, and in the Connection Wizard.
Interestingly enough, we don't have anything in this table yet, but all the logic in the system does reference this table and use it, sooo...
-Thom
Quote from: totallymaxed on June 11, 2013, 01:37:21 PM
Dianemo supports the pipe model. But we also have media_config which is a text file that allows you to create pipe type connections between devices and can be edited by any text editor.
Technically that is incorrect. We don't support the original pipe model at all. I made my own WTF to replace it because I couldn't and didn't have the time to read the existing WTF to understand it and fix it :)
Quote from: totallymaxed on June 08, 2013, 06:43:54 PM
Here is the source for the DCEwhisperer device for the HDAnywhere 4x8 v2 Matrix;
[...]
This script is useless to LMCE. Their problem lies in the fact that there may be no matrix logic in the pipe commands, or that nobody implemented a matrix that can be used as reference, or that the website is incomplete and doesn't provide access to all these things and you have to dive into SQL directly.