Hat schon jemand Erfahrungen, oder es erfolgreich geschafft eine AV-Vorstufe Trinnov Altidue 16 einzubinden? Über die deviceinfo.xlr? Ein Mustereintrag würde mir reichen, um den Rest selber nach zu arbeiten. Laut Automation-Protocoll von Trinnov ist grundsätzlich eine Steuerung über TCP/IP Port 44100 möglich.
Also ich selber wüste zumindest nicht, wie sich das Aufgrund der Dokumentation von Trinnov nur mit NEO alleine bzw. der deviceinfo realisieren lässt, da Du mit dem Weg über die deviceinfo auch keinerlei Möglichkeit besitzt, eine Rückmeldung des Vorverstärkers auszuwerten.
Ja, über die Anbindung von IP-Symcon an NEO lässt sich so was z.B. lösen, bzw. IP-Symcon kann so ein Gerät (Vorverstärker) ohne weiteres mit Auswertung der Rückmeldung des Vorverstärkers ansteuern. So könnte man also auch das Gerät bei Bedarf aus NEO ansteuern bzw. dort visualisieren.
Dazu wird ein Clientsocket auf Port 44100 benötigt
https://www.symcon.de/en/service/documentation/module-reference/io/clientsocket/
Zusätzlich braucht man dann noch eine Registervariable um die Daten des Clientsocket auszuwerten.
https://www.symcon.de/de/service/dokumentation/modulreferenz/registervariable/
Befehle über den Clientsocket zum Vorverstärker werden dann CSCK_SENDTEXT geschickt
https://www.symcon.de/en/service/documentation/module-reference/io/clientsocket/csck-sendtext/
Alternativ könnte Du bei IP-Symcon auch über RS232 ansteuern wie von Trinnov beschrieben, wäre aber nicht meine persönlich bevorzugte Wahl, da Du dazu ja ein Kabel brauchst was Du an RS232 anschließen kannst. Mir Persönlich wäre da der Ansteuerungsweg über ein Clientsocket per LAN lieber.
Die Kommunikation ist ähnlich aufgebaut wie bei meinem Denon AVC, diesen steuere ich auch vollständig über IP-Symcon und zeige den Status in NEO an.
Ein fertiges Modul für den Trinnov Alitude 16 gibt es denke ich zumindest noch nicht, daher müsste man da selber Handarbeit anlegen um so was einmalig zu konfigurieren.
Besitzt Du denn eine Version von IP-Symcon oder eine Demo Version von IP-Symcon um die Ansteuerung des Vorverstärkers über ein Clientsocket auszuprobieren?
Testen kann ich das selber nicht, da ich den Vorverstärker nicht besitze, falls Du aber fragen zum Testen hast bzw. Du auf dem Weg eine Ansteuerung ausprobieren willst, kannst Du Dich ja melden.
So in etwas habe ich es "befürchtet".
Das über deviceinfo keine Rückmeldungen zu bekommen sind war mir bewusst. Ich hatte gehofft, dass zumindest das Ansteuern darüber einfach zu realisieren ist.
Aktuell habe ich nur eine Test-Trinnov zu Hause. "Befürchte" jedoch ich werde mir eine zulegen. Von daher wollte ich schon mal bezüglich mediola-Anbindung nachfragen.
Eine Testversion von Symcon habe ich installiert, jedoch ist der Testzeitraum abgelaufen.
Ende des Jahres möchte ich mir eine Symbox zulegen, um zwischen den Feiertagen mich damit beschäftigen zu können.
Dein Denon/Marantz-Modul funktioniert ja auch mit meiner aktuellen Marantz-Vorstufe, inkl. Rückmeldungen.
Wenn die Kommunikation von Denon und Trinnov ähnlich aufgebaut ist, kann dann auf deinem Modul aufgebaut werden?
Wie gesagt mit der deviceinfo geht das wohl nicht, da Dir auf diese Weise die Rückmeldung vom Gerät fehlt.
Das Denon / Marantz Modul wird aktuell von bumaas weiter gepflegt, da mir persönlich die Zeit dazu fehlt, es werden auch aktuelle Denon / Marantz Geräte vollständig unterstützt. Mir persönlich war es natürlich am wichtigsten das sich mein eigener Denon AVC vollständig mit allen Befehlen benutzten lässt, der hat so viele Endstufen, dass ich zur Zeit keinen zusätzlichen Vorverstärker benötige.
Grundsätzlich würde ich persönlich bei einem neuen Gerät die Ansteuerung erst mal mit einer Registervariable, Clientsocket und einem Skript lösen. Wenn man dann will, kann man da natürlich auch ein PHP Modul dazu schreiben, der Quellcode für das Denon Modul liegt ja offen auf Github, das kann man von der Grundstruktur als Vorlage nehmen wenn dazu Bedarf ist.
Im IP-Symcon Forum findest Du wohl auch genügend Benutzer, die da hinreichend Erfahrung mit dieser Art der Ansteuerung von solchen Geräten über einen Client Socket haben. bumaas, Nall-chan usw., um nur nur ein paar Nutzer exemplarisch zu nennen, die auch PHP Module für AV Verstärker geschrieben haben, haben neben mir hinreichend Erfahrung mit der Kommunikation mit AV Verstärkern bzw. Vorverstärkern.
Viel Erfolg zumindest bei Deinem Vorhaben. Bei Fragen kannst Du Dich ja melden.
P.S.: Falls Du Dir eine Symbox Pro in Zukunft anschaffen solltest, vergiss nicht gleich eine passende Schnittstelle mit zu bestellen, da Du diese nicht nachrüsten kannst. In Deinem Fall würde sich da wohl KNX als Schnittstellenerweiterung für die Symbox Pro anbieten, dann bist Du direkt mit KNX Bus verbunden und kannst auch KNX Secure benutzen, insofern benötigt.
KNX Secure wird zur Zeit von mediola leider selber auch nicht unterstützt.
Trinnov Altitude Processor Automation Protocol
Version 1.15
Remy Bruno
April 19, 2019
## 7 & + 1
Contents
1 Introduction 1
2 General description of the protocol 1
3 TCP/IP protocol 1
3.1 Network conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.2 TCP/IP protocol parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.3 Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.4 Power on using network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4 RS232 protocol 2
5 Commands 3
6 Messages 6
7 Power control 7
8 Example 7
9 Conclusion 8
1 Introduction
The Trinnov Altitude processor may be remotely controlled using tcp/ip or rs232 serial link.
Both communication modes work very similarly using a bidirectional link, where the client sends
commands and the Altitude answers these commands and sends messages providing its current
state.
In both modes, the recommended use is to connect to the Altitude, possibly request its current
state (see x 5), then alternately send commands and read back data it replies. As the Altitude
sends a message for each state change (volume, loaded prole and preset, etc.), the client can know
the state of the Altitude at each time.
2 General description of the protocol
Communication is achieved using ascii characters. Each communication (command or mes-
sage) consists of a text line ending with a return character.
Each line begins with a keyword consisting of alphanumerical characters and indicating the
command or the message type, possibly followed with arguments separated by spaces.. The Al-
titude recognizes the three following return characters: \n (or 0x0A), \r (or 0x0D), and both
characters \r\n (or 0x0D 0x0A). This allows compatibility with Unix-like, Mac and Windows sys-
tems. Commands and their arguments are case sensitive, so you have to respect uppercase and
lowercase (command and COMMAND are two dierent commands).
Since version 4.1.3 of the Altitude, a command may be ended using character ";". It is therfore
possible to provide several commands on only one line without the need to use escape characters,
and use command lines such as:
echo "id My Automation System; dvolume 1" | telnet 192.168.0.1 44100
Each command is followed by an answer message from the Altitude, which is either OK if the
command succeeded, or ERROR followed by a description of the error that occurred. The processor
may also send other messages, indicating for example a state change, depending on the eects of
the command. You should note that the answer does not necessarily occur before the other possible
messages from the Altitude.
3 TCP/IP protocol
This communication mode uses the available tcp/ip network connections of the Altitude.
April 19, 2019 Trinnov Altitude Processor Automation Protocol 1
## 7 & + 1
3.1 Network conguration
The user manual explains how to congure the network in a detailed way, so details will not
be considered here.
RJ45 network conguration of the Altitude is done using dhcp during the boot. The dhcp
client of the Altitude sends an identier (dhcp-client-identifier option of dhclient), which
is TRINNOV-SRP- where is the identier of the processor. This allows for example to
automatically give it a specic ip address using an appropriate dhcp server conguration.
It is also possible to specify manual network settings in the Network (or System Status depend-
ing on the version) sub-menu of the Setup page of the Altitude.
3.2 TCP/IP protocol parameters
The communication uses tcp on port 44100.
Please be aware that, for security reasons, connection is only possible from the same subnet as
the machine's.
This protocol is very similar to smtp, ftp, or even http. A rst approach of this protocol
may consist in connecting to the processor using a program like telnet in order to type command
lines using the keyboard.
3.3 Connection
When a tcp connection is established on port 44100, the Altitude sends a welcome message,
also providing the Altitude version and its unique identier. This identier (ID or SRPID) is a
number which allows to get the serial number of the machine (provided by the 20 least signicant
bits of this identier), and the machine type (provided by the most signicant bits). The format
of this line is as follows:
Welcome on Trinnov Optimizer (Version 4.0.0, ID 10485761)
This identier 10485761 is written 0xA00001 in hexadecimal, so the machine type is 10 (corre-
sponding to the type Altitude) and the serial number is 1.
The Altitude then waits an identication from the client. This is achieved by sending an id
command with an argument identifying the client. This identication is not an authentication,
and only allows a possible specic behavior with certain clients. For example:
id my_automation_system
Communication is then achieved according to the commands and messages mode presented
in the preceding section 2 and detailed in the following section 5. You should note command
processing only starts after the client has identied itself using the id command.
3.4 Power on using network
The Altitude supports the Wake on LAN standard so as to be switched on through ethernet
network. We invite you to read the available online documentation on this subject, such as the
Wikipedia page http://en.wikipedia.org/wiki/Wake-on-LAN. The MAC address of the Alti-
tude, which is required for using this functionality, is displayed on the network information page
of the graphical user interface.
Please note that, for Wake on LAN to work, you need to have the automation server and the
Altitude on the same sub-network. Typically, this means that the IPv4 adresses of both devices
must start with the same three numbers (such as 192.168.0).
4 RS232 protocol
The Altitude can also be controlled using an rs232 link with a 9-pin null modem cable. The
rs232 serial port parameters are as follows:
19200 bauds
April 19, 2019 Trinnov Altitude Processor Automation Protocol 2
## 7 & + 1
1 stop bit
8 data bits
no parity
As soon as a client is connected to the serial port, the Altitude is in the commands and messages
mode presented in the preceding section 2 and detailed in the following section 5. You should not
identify yourself, contrary to the tcp/ip protocol.
Please note that not all machines have an rs232 connector. Check the available connectors on
your machine.
5 Commands
Here is a list of recognized commands. This list is not comprehensive but includes all commands
useful for a normal use of the Altitude. Arguments for each command are represented between
<...>.
volume This command allows to change the main volume to the value dB. This is the
master level as it appears in the GUI of the Altitude.
dvolume This command allows to add dB to the main volume. This value may be positive or
negative.
volume ramp This command allows to apply a volume ramp starting from current volume and reaching
volume (in dB) after milliseconds. This command is available since
version 3.7.3 of the Altitude.
mute This command allows to change mute state:
{ if is 0, mute is disabled (sound is enabled),
{ if is 1, mute is enabled (sound is disabled),
{ if is 2, mute state is inverted.
dim This command allows to change dim state:
{ if is 0, dim is disabled,
{ if is 1, dim is enabled,
{ if is 2, dim state is inverted.
bypass This command allows to change bypass state:
{ if is 0, bypass is disabled,
{ if is 1, bypass is enabled,
{ if is 2, bypass state is inverted.
send volume
This command requests that the Altitude send messages providing current state information
related to the volume, in particular messages VOLUME, MUTE, DIM and BYPASS (see these
messages in paragraph 6). This command is available since version 3.5 of the Altitude.
remapping mode This command allows to change remapping mode:
{ if is none, remapping is disabled,
April 19, 2019 Trinnov Altitude Processor Automation Protocol 3
## 7 & + 1
{ if is 2D, 2D remapping is enabled,
{ if is 3D, 3D remapping is enabled,
{ if is autoroute, autorouting mode is enabled,
{ if is manual, manual remapping is enabled.
use acoustics correction This command allows to change acoustic correction state :
{ if is 0, acoustic correction is disabled,
{ if is 1, acoustic correction is enabled,
{ if is 2, acoustic correction state is inverted.
use level alignment This command allows to change level alignment state :
{ if is 0, level alignment is disabled,
{ if is 1, level alignment is enabled,
{ if is 2, level alignment state is inverted.
use time alignment This command allows to change time alignment state :
{ if is 0, time alignment is disabled,
{ if is 1, time alignment is enabled,
{ if is 2, time alignment state is inverted.
quick optimized This command allows to change optimization state :
{ if is 0, optimization is disabled,
{ if is 1, optimization is enabled,
{ if is 2, optimization state is inverted.
change page This command changes the menu page currently displayed on the GUI. The value of indicates the number of pages to change, and may be positive or negative (1 for going to the
next page, 1 for going to the previous page).
loadp This command allows to load the preset number . User presets start with number 1
and preset 0 corresponds to the built-in preset. This syntax is available since version 3.3.4
of the Altitude.
For older versions, you have to use the syntax described below, where you provide a
le name instead of a preset number. For compatibility with versions before 3.3.4, newer
versions also support this syntax. The argument is the name of a le depending
on the preset number to load and is formed as follows:
Config n.xml
where n must be replaced with the preset number. For example, in order to load preset
number 1, you should send the following command line:
loadp Config_1.xml
As command lines are case sensitive, you should use an upper case letter in the le name
Config 1.xml. Note: this second syntax does not allow to load the built-in preset.
get current preset
This command sends back the current preset number. This command is available since
version 3.3.4 of the Altitude.
April 19, 2019 Trinnov Altitude Processor Automation Protocol 4
## 7 & + 1
get label This command sends back the name of preset number . This command is available since
version 3.3.4 of the Altitude.
get all label
This command sends back the list of all presets available on the machine, along with their
numbers and names. This command is available since version 3.3.4 of the Altitude.
get current state
This command sends back a set of messages providing the current state of the machine.
profile This command allows to change the current source (also knwon as prole) and thus select
the active audio input. The argument is the source number, where the rst source is number
0. This command is available since version 3.4.
tac preset This is an old alias for command profile.
upmixer This command allows to get and set the upmixer mode of the Altitude, depending on the
argument provided :
{ without argument, the command returns the current upmixer mode,
{ + or 1 allows to switch to the next upmixer mode,
{ or 0 allows to switch to the previous upmixer mode,
{ auro3d, dts, dolby, auto, native, legacy and upmix on native allow to switch to the
corresponding upmixer mode (refer to the manual for more information about upmixer
modes).
fav light This command allows to get and set front panel display mode of the Altitude, depending on
the argument provided :
{ without argument, the command returns the current status,
{ 1 turns o front panel display,
{ 0 turns on front panel display,
{ 2 toggles front panel display status (as does the Light button of the remote control).
get current profile
This command sends back the current source number (also known as prole). This command
is available from version 3.5.0rc8 of the Altitude.
get profile name This command sends back the name of the source (or prole) number . This is the name
as it appears in the source selection page of the GUI. This command is available from version
3.5.0rc8 of the Altitude.
bye
This command requests the server to close the connection. The server then replies BYE (in-
stead of OK) and closes the connection. Commands exit and quit are synonyms. This
command has no eect on the operation of the Altitude itself (no shutdown nor sound van-
ishing), but only on the client-server connection. This command must not be used with the
rs232 protocol.
power off SECURED FHZMCH48FE
This command allows to switch o the Altitude.
April 19, 2019 Trinnov Altitude Processor Automation Protocol 5
## 7 & + 1
6 Messages
Here is a list, non-comprehensive too, of the main messages sent by the Altitude to connected
clients:
VOLUME This message provides the current main volume (in dB).
DIM This message indicates whether dim is active (if is 1) or not.
MUTE This message indicates whether mute is active (if is 1) or not.
BYPASS This message indicates whether bypass is active (if is 1) or not.
META PRESET LOADED This message provides the active prole (or source).
SRATE This message provides the current sampling rate of the Altitude.
AUDIOSYNC STATUS This message indicates whether the Altitude is correctly synchronized with the audio source
(if is 1) or not.
AUDIOSYNC This message provides the current audio synchronization mode of the Altitude, which can be
Master or Slave.
SPEAKER INFO <> <>
This message is sent for each calibrated loudspeaker when a preset is loaded. The argument
indicates which loudspeaker the following information relate to (loudspeaker
numbers begin here with 0). Arguments , <> and <> give the corresponding loud-
speaker's position in spherical coordinates. (r in meters, in degrees from the ceiling (north
pole), in degrees from the front and positive towards the left).
START RUNNING
This message is sent when the Altitude is ready to make sound. This is the case for example
short after a loadp command is sent (typically a few tenth of seconds after).
LABELS CLEAR
This message indicates that the whole list of available presets will be sent by the Altitude
just after this message. This tells the client that it should clear its internal preset list that
it maintains, in case the client maintains such a list, and that a new list of available presets
will follow right after this message. This message is typically sent after the get all label
command and just before the presets list.
LABEL : This message indicates that the preset number exists and that its name is . This
message is typically sent as an answer to commands get label and get all label.
DECODER NONAUDIO PLAYABLE DECODER UPMIXER This message indicates if the Altitude has detected PCM or data content (argument is
respectively 0 or 1), if it succeeded in decoding the content or not (argument is
respectively 1 or 0) and which decoder is used (argument ). Since version 4.0.12,
the active upmixer (argument ) is also provided.
It should be noted that connected clients must be ready to receive a message from the Altitude
at any time. For example, when a user changes the current volume, whatever the way he does it,
the Altitude sends a message indicating the new volume to all its connected clients. Also, when
a calibration is started using the GUI, the Altitude sends loudspeaker coordinates to connected
clients, as after the loadp command. This allows the Altitude to interact with its connected clients.
April 19, 2019 Trinnov Altitude Processor Automation Protocol 6
## 7 & + 1
This is therefore more a "dialog" between the client and the server than a "request/answer" pro-
tocol. In other words, the stream is constantly bidirectional rather than unidirectional alternately
in each way.
Also, it is highly recommended not to poll the Altitude, namely regularly reading the state of
the Altitude, a fortiori if this is done using frequent connections and disconnections to the machine.
As the Altitude sends all state changes to the clients, it is useless and deleterious to constantly
request the state of the machine. The recommended approach consists in connecting only once to
the Altitude, read all state variables which are relevant for the client, and then remain connected,
waiting for possible changes sent by the Altitude (such as the volume, for example). However,
occasional connections and disconnections of a client to the machine are ne.
7 Power control
Power on automation may be achieved using one of the following methods:
using the Wake on LAN standard as described in section 3.4,
supplying between 5 and 12 V on the trigger input of the Altitude.
Power on is not possible through the regular rs232 or tcp/ip protocols described above, since
these functions are powered o together with the processor.
Power o automation may be achieved using one of the following methods:
using the power off SECURED FHZMCH48FE command of the rs232 or tcp/ip protocols, as
described in section 5,
switching the trigger input of the Altitude from 5{12 V to 0 V.
The trigger output connector has a 12 V voltage as soon as the Altitude is powered on.
8 Example
Here is a communication example using tcp/ip between the Altitude and a client. The client
used here is simply the telnet program, that can be found for example on all Unix systems
(including Linux). The rst line is the shell command line used to start the client, lines starting
with ">" are the lines input by the user (without ">"), the other lines are the answers of the
Altitude or of the telnet client.
This example is transposable almost as is for the case of rs232 protocol, by replacing telnet
with a program providing serial port communication and by removing the rst three lines (namely
the Welcome message from the Altitude, the id command, and the OK answer) as well as the last
two lines of this communication (the bye command and the BYE answer).
$ telnet srp 44100
Trying 192.168.77.10...
Connected to srp.
Escape character is '^]'.
Welcome on Trinnov Optimizer (Version 3.8.7, ID 123456)
>id Trinnov Audio automation system
OK
>loadp config_1.xml
ERROR: non-existing or inaccessible config file
>loadp Config_1.xml
OK
SPEAKER_INFO 0 1.36485 102.091 -43.3817
SPEAKER_INFO 1 1.21479 100.781 28.5073
START_RUNNING
>volume -12
OK
VOLUME -12.000000
>dvolume 1
April 19, 2019 Trinnov Altitude Processor Automation Protocol 7
## 7 & + 1
OK
VOLUME -11.000000
>mute 2
OK
MUTE 1
>mute 2
OK
MUTE 0
>volume_ramp -20 50
OK
VOLUME -11.000000
VOLUME -11.960000
VOLUME -12.920000
VOLUME -13.880000
VOLUME -14.840000
VOLUME -15.800000
VOLUME -16.760000
VOLUME -17.720000
VOLUME -18.680000
VOLUME -20.000000
>bye
BYE
Connection closed by foreign host.
9 Conclusion
This communication protocol is subject to changes, but, in case this happens, the evolutions will
always remain compatible with the previous behaviour. This compatibility approach explains why
some command names seem inconsistent regarding their nomenclature (for example tac preset
and get current profile).
If you have questions or face implementation issues, please contact Trinnov support (support@trinnov.com).
April 19, 2019 Trinnov Altitude Processor Automation Protocol 8
Ein Versuch wäre es zumindest Wert ob sich über die deviceinfo zumindest was schicken lässt, ich bezweifele persönlich aber, dass so eine richtige Ansteuerung möglich sein wird.
Dadurch passiert erst mal gar nichts, wenn müsstest Du den Platzhalter
COMMAND_TO_TRINNOV_ALTITUDE
durch einen passenden Befehl aus der Dokumentation des Herstellers ersetzen, und dann schauen ob irgendwas passiert.
Das Ganze sollte nur ein Grundgerüst sein mit dem Du was ausprobieren kannst. Ob das überhaupt funktioniert keine Ahnung. Falls das nicht geht muss man halt doch über ein Clientsocket arbeiten, und ein externes System das dies ermöglicht
Passiert ist leider nichts.
Auch der Versuch mit "volume" anstatt "COMMAND_TO_TRINNOV_ALTITUDE" blieb erfolglos.
Soweit ich es richtig verstanden habe erwarte die Trínnov aber noch einen Zahlenwert.
Jedoch wußte ich nicht, wie ich diesen eingeben soll.
Ich habe es erfolglos mit "volume", "volume40", "volume 40", "volume <40>" versucht.
Von
Hallo Fonzo
auf folgender Seite ist die Dokumentation zur Altitude 16 zu finden:
https://www.trinnov.com/en/support/#Automation-Drivers
Grüße
Von
Wie sieht es mit IP-Symcon aus, könnte ich darüber auch die Rückmeldungen bekommen?
Von
Also ich selber wüste zumindest nicht, wie sich das Aufgrund der Dokumentation von Trinnov nur mit NEO alleine bzw. der deviceinfo realisieren lässt, da Du mit dem Weg über die deviceinfo auch keinerlei Möglichkeit besitzt, eine Rückmeldung des Vorverstärkers auszuwerten.
Ja, über die Anbindung von IP-Symcon an NEO lässt sich so was z.B. lösen, bzw. IP-Symcon kann so ein Gerät (Vorverstärker) ohne weiteres mit Auswertung der Rückmeldung des Vorverstärkers ansteuern. So könnte man also auch das Gerät bei Bedarf aus NEO ansteuern bzw. dort visualisieren.
Dazu wird ein Clientsocket auf Port 44100 benötigt
https://www.symcon.de/en/service/documentation/module-reference/io/clientsocket/
Zusätzlich braucht man dann noch eine Registervariable um die Daten des Clientsocket auszuwerten.
https://www.symcon.de/de/service/dokumentation/modulreferenz/registervariable/
Befehle über den Clientsocket zum Vorverstärker werden dann CSCK_SENDTEXT geschickt
https://www.symcon.de/en/service/documentation/module-reference/io/clientsocket/csck-sendtext/
Alternativ könnte Du bei IP-Symcon auch über RS232 ansteuern wie von Trinnov beschrieben, wäre aber nicht meine persönlich bevorzugte Wahl, da Du dazu ja ein Kabel brauchst was Du an RS232 anschließen kannst. Mir Persönlich wäre da der Ansteuerungsweg über ein Clientsocket per LAN lieber.
Die Kommunikation ist ähnlich aufgebaut wie bei meinem Denon AVC, diesen steuere ich auch vollständig über IP-Symcon und zeige den Status in NEO an.
Ein fertiges Modul für den Trinnov Alitude 16 gibt es denke ich zumindest noch nicht, daher müsste man da selber Handarbeit anlegen um so was einmalig zu konfigurieren.
Besitzt Du denn eine Version von IP-Symcon oder eine Demo Version von IP-Symcon um die Ansteuerung des Vorverstärkers über ein Clientsocket auszuprobieren?
Testen kann ich das selber nicht, da ich den Vorverstärker nicht besitze, falls Du aber fragen zum Testen hast bzw. Du auf dem Weg eine Ansteuerung ausprobieren willst, kannst Du Dich ja melden.
Von
So in etwas habe ich es "befürchtet".
Das über deviceinfo keine Rückmeldungen zu bekommen sind war mir bewusst. Ich hatte gehofft, dass zumindest das Ansteuern darüber einfach zu realisieren ist.
Aktuell habe ich nur eine Test-Trinnov zu Hause. "Befürchte" jedoch ich werde mir eine zulegen. Von daher wollte ich schon mal bezüglich mediola-Anbindung nachfragen.
Eine Testversion von Symcon habe ich installiert, jedoch ist der Testzeitraum abgelaufen.
Ende des Jahres möchte ich mir eine Symbox zulegen, um zwischen den Feiertagen mich damit beschäftigen zu können.
Dein Denon/Marantz-Modul funktioniert ja auch mit meiner aktuellen Marantz-Vorstufe, inkl. Rückmeldungen.
Wenn die Kommunikation von Denon und Trinnov ähnlich aufgebaut ist, kann dann auf deinem Modul aufgebaut werden?
Grüße
Von
Wie gesagt mit der deviceinfo geht das wohl nicht, da Dir auf diese Weise die Rückmeldung vom Gerät fehlt.
Das Denon / Marantz Modul wird aktuell von bumaas weiter gepflegt, da mir persönlich die Zeit dazu fehlt, es werden auch aktuelle Denon / Marantz Geräte vollständig unterstützt. Mir persönlich war es natürlich am wichtigsten das sich mein eigener Denon AVC vollständig mit allen Befehlen benutzten lässt, der hat so viele Endstufen, dass ich zur Zeit keinen zusätzlichen Vorverstärker benötige.
Grundsätzlich würde ich persönlich bei einem neuen Gerät die Ansteuerung erst mal mit einer Registervariable, Clientsocket und einem Skript lösen. Wenn man dann will, kann man da natürlich auch ein PHP Modul dazu schreiben, der Quellcode für das Denon Modul liegt ja offen auf Github, das kann man von der Grundstruktur als Vorlage nehmen wenn dazu Bedarf ist.
Im IP-Symcon Forum findest Du wohl auch genügend Benutzer, die da hinreichend Erfahrung mit dieser Art der Ansteuerung von solchen Geräten über einen Client Socket haben. bumaas, Nall-chan usw., um nur nur ein paar Nutzer exemplarisch zu nennen, die auch PHP Module für AV Verstärker geschrieben haben, haben neben mir hinreichend Erfahrung mit der Kommunikation mit AV Verstärkern bzw. Vorverstärkern.
Viel Erfolg zumindest bei Deinem Vorhaben. Bei Fragen kannst Du Dich ja melden.
Von
P.S.: Falls Du Dir eine Symbox Pro in Zukunft anschaffen solltest, vergiss nicht gleich eine passende Schnittstelle mit zu bestellen, da Du diese nicht nachrüsten kannst. In Deinem Fall würde sich da wohl KNX als Schnittstellenerweiterung für die Symbox Pro anbieten, dann bist Du direkt mit KNX Bus verbunden und kannst auch KNX Secure benutzen, insofern benötigt.
KNX Secure wird zur Zeit von mediola leider selber auch nicht unterstützt.
Von
Bestn Dank für die Informationen
Neuen Kommentar hinzufügen