Things to do with your network-connected Denon/Marantz receiver

This post will focus on the things you can do with your network-connected Denon/Marantz receiver. I bought my Denon AVR-3808 in 2007, so it’s actually my very first IoT device. Unfortunately my receiver doesn’t support the newer HTTP/XML-based protocol or streaming services, but the old telnet-based AVR protocol still gives a lot of opportunities.

So without further ado, a walk-through of options I know of…

App control
Denon doesn’t support the AVR protocol in their app, so third party apps are the only options for me. If you have a newer receiver you won’t have that problem. I’ve been using AVR-Remote for Denon/Marantz for years. It’s a bit old, but still works.

Control with Yatse
Another use within Android is volume control and more within Yatse. Yatse is a full-featured Kodi remote control app and much more. If you have a Kodi media center and an Android device, you should definately give Yatse a chance. And if you use Yatse and own a Denon/Marantz receiver, you should try the Denon/Marantz plugin. Please note that this is a shameless recommendation, since I’m the developer of this plugin.

Control with Tasker
Into automation and using Tasker? Yet another use within Android. Use Denon/Marantz plugin to automate interaction with your receiver. Yes, this is the same plugin as mentioned in previous chapter. Example usages:

  • Mute receiver when phone rings.
  • Use as clockradio: Turn on receiver on radio at 6:00 in the morning.
  • Turn off the receiver when leaving home.
  • Well, whatever you can think of.

openHAB
Staying with automation, integrate your receiver into your home automation when using openHAB. I’m not using this binding myself, since it constantly occupies the only connection available for the AVR, so it would block all other usages. If you have a newer receiver, you won’t have that problem. Instead, I can integrate through the Logitech Harmony binding.

Linux shell script
I wrote this small script years ago and scheduled it to to be run by cron daemon on my server at midnight. Purpose was to save energy in case I’d forgotten to turn off my receiver. It demonstrates how to send a simple command from a shell script, but other than that it’s obsoleted today by openHAB rules or similar.

#!/bin/bash
# Written by Jacob Laursen , 2009-2011.
#
# This script turns off a Denon receiver if none of the listed
# hosts to be checked are up and running.
#
# Options:
# --force : Skip host checking, just turn it off.

HOST_CHECK=`echo {"ps3","smarttv"}`
HOST_DENON="denon"

standby ()
{
        {
                sleep 2
                echo -n -e "PWSTANDBY\r"
                sleep 2
        } | telnet >/dev/null 2>&1 $HOST_DENON
}

if [ "$1" == "--force" ]; then
        standby
        if [ $? == 0 ]; then
                echo "Power turned off"
        else
                echo "Already turned off"
        fi
        exit
fi

host_up=0

for host in ${HOST_CHECK}
do
        ping >/dev/null -c 1 $host

        if [ $? == 0 ]; then
                host_up=1
                break
        fi
done

if [ $host_up == 0 ]; then
        standby
fi

Logitech Media Server/Squeezebox plugin
For controlling volume from my Squeezebox Receiver I’m using DenonSerial v0.1.42 extension by Peter Watkins. I’m not sure where to find it today, as it’s quite old – but still working nicely. An alternative might be DenonAvpControl, but I haven’t tried that.

The purpose of this extension is to set fixed volume to 100% on the Squeezebox Receiver and instead control volume on the Denon receiver. Using this extension should work no matter how you control your Squeezebox Receiver. However, the app (or whatever) must support sending volume commands even for players with fixed volume configured. The Android app Squeeze Ctrl supports this. The ancient, but still excellent, Squeeze Commander does not.

Miele XGW3000 firmware 2.3.4

New firmware, this time noticed a bit late, since XGW3000_version.txt is still showing 2.3.0. I guess I should switch to http://GATEWAY/Rest/Update/ and check “AvailableVersion”, or once again reverse engineer how the gateway checks the version. Anyway, here goes…

Release 2.3.4 – 12.09.2018

  • Improved Miele@mobile behavior in conjunction with ZigBee appliances
  • Stability improvements and bugfixing

Good news is the this fixes the Miele@mobile app so it doesn’t crash anymore on startup. I guess this reveals that they changed the API between the app and the gateway in app version 2.9.4 and didn’t provide backwards compatibility for the existing gateway API. So the app was constantly crashing until the gateway firmware received an update. Not elegant.

First observation: It seems like phases for my oven (H 5581 BP) isn’t supported anymore. Running self-clean/pyrolysis:

Homebus

<information>
<key name="Appliance Type" value="Oven"/>
<key name="State" value="Running" type="state" raw="5"/>
<key name="Remaining Time" value="1:21" type="duration" raw="81"/>
</information>

Rest

{"SignalFailure":false,
"TargetTemperature":[0,0],
"Temperature":[0,0],
"SignalInfo":false,
"ProgramID":2348810240,
"InternalState":0,
"RemainingTime":[1,24],
"RemoteEnable":[0,0,0],
"Status":5,
"ProgramPhase":3072,
"ProgramType":1,
"ExtendedState":"000C100500110000000100000000110400000000000000000018010000000000000000000242000000000000400000000000000000000000000000",
"ElapsedTime":[0,42],
"SignalDoor":false,
"Light":0,
"ProcessAction":0,
"StartTime":[0,0]}

These are my notes for ProgramPhase 3072 and pyrolysis:

			case 3072:
				// Purpose unknown, seems to be set when the oven is just turned on.
				// Catch it here to avoid excessive logging.
				return setPhase(PHASE_UNKNOWN);
[...]
			case 3076:
				return setPhase(PHASE_PYROLYSIS);

Also, temperature is now reported as 0°C. Removing functionality for my oven is just sad, since it’s the appliance with least functionality already (for example, ProgramID’s are not supported). Here’s how it looks in Miele’s own app now:

Miele@mobile screenshot

Update/precision: This bug was probably caused by the fact that I upgraded the firmware on the gateway while the oven program was running. Since the phase didn’t change after the gateway rebooted, the gateway probably had some uninitialized values. I guess it should be possible to query the devices after a boot to get updated values, but I don’t know which limitations may exist. So the bug is there, but it’s rare.