Written and (C) 2015-16 Oliver Wagner [email protected]

Provided under the terms of the MIT license.

Update by Brice VALENZA (2021). Only the command via the use of "/set" has been tested

Bridge between the Onkyo AVR EISCP remote control protocol and MQTT. Allows to remotely control networked Onkyo AVRs and get status information.

It's intended as a building block in heterogenous smart home environments where an MQTT message broker is used as the centralized message bus. See https://github.com/mqtt-smarthome for a rationale and architectural overview.

• Python 2.7+
• onkyo-eiscp - https://github.com/miracle2k/onkyo-eiscp (implements the Onkyo EISCP protocol and command translation)
• Eclipse Paho for Python - http://www.eclipse.org/paho/clients/python/ (used for MQTT communication)

The message format generated is a JSON encoded object with the following members:

• val - the actual value
• onkyo_raw - the raw EISCP command before parsing by onkyo-eiscp

The onkyo-eiscp module by miracle2k provides sophisticated parsing which translated the raw EISCP commands into readable strings. Please see the module page at https://github.com/miracle2k/onkyo-eiscp for more information about that.

onkyo2mqtt will translate incoming EISCP status events into their textual representation, and publish those via MQTT.

For example, the raw "power is off" status is published into the topic "<prefix>/status/system-power" as follows:

{"onkyo_raw": "PWR00", "val": "standby"}

Sending commands is possible in three ways:

1. By publishing a value into a textual topic ("<prefix>/set/<topic>") with a new value
2. By publishing into the special topic "<prefix>/command" with a textual command as described in https://github.com/miracle2k/onkyo-eiscp#commands
3. By publishing a raw EISCP command into the special "<prefix>/command" topic

A special topic "<prefix>/connected" is maintained. It's a enum stating whether the module is currently running and connected to the broker and to an AVR.

onkyo2mqtt will terminate when it cannot establish a connection to the AVR, or the connection dies for any reason. It will, however, reconnect to the MQTT broker without restart.

--mqtt-host MQTT_HOST
                    MQTT server address. Defaults to "localhost"
--mqtt-port MQTT_PORT
                    MQTT server port. Defaults to 1883
--mqtt-topic MQTT_TOPIC
                    Topic prefix to be used for subscribing/publishing.
                    Defaults to "onkyo/"
--onkyo-address ONKYO_ADDRESS
                    IP or hostname of the AVR. Defaults to autodiscover
--onkyo-id ID
					Device identifier of AVR to connecct to. Uses autodiscover
--log LOG           set log level to the specified value. Defaults to
                    WARNING. Try DEBUG for maximum detail                        

• Copy the script wherever you want (for exemple /opt/onkyo2mqtt.py).
• Create the file /etc/systemd/system/onkyo2mqtt.service with content : [Unit] Description=Onkyo2mqtt Sevice After=multi-user.target [Service] Type=simple Restart=always ExecStart=/usr/bin/python3 /opt/onkyo2mqtt.py --mqtt-host 192.168.1.42 --log DEBUG [Install] WantedBy=multi-user.target

Change 192.168.1.42 with your MQTT broker IP (in this example, we will be in auto discover Onkyo mode)

• sudo systemctl daemon-reload
• sudo systemctl enable onkyo2mqtt
• sudo systemctl start onkyo2mqtt

• 0.8 - 2021/03/30 - Brice VALENZA

  • Fix Mqtt v5 change
  • add service on README

• 0.7 - 2016/06/05 - owagner

  • support --onkyo-id

• 0.6 - 2015/06/07 - owagner

  • deal with onkyo-eiscp returning an int as an argument

• 0.5 - 2015/04/04 - owagner

  • removed reconnect() call in onDisconnected -- Paho will reconnect on it's own anyway, and an exception during reconnect would actually kill the service thread

• 0.4 - 2015/01/25

  • adapted to new mqtt-smarthome topic hierarchy scheme with set/ and status/ function prefixes, and connected being an enum

• 0.3 - 2014/12/28

  • set /connected topic
  • add new option "--log" to set the log level
  • implement MQTT-side reconnect handling

• 0.2 - 2014/12/28

  • maintain a minimum of 50ms wait time between commands