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