Protocols

English | Deutsch

Protocols — why your device can more or less than someone else's

Do I need this page?

Read on if you wonder why a neighbour's Yamaha shows datapoints yours does not, why some values update instantly and others take a moment, or what info.transports.* is telling you.

You never have to choose a protocol. The adapter sorts that out. This page only explains what is behind it.

Yamaha built three control paths over fifteen years

Every one of them still exists in devices out there, and they can do different amounts:

	XML	YNCA	MusicCast
Devices	before ~2010	network AV receivers ~2010–2020	everything from ~2015
Power, volume, mute, input	✅	✅	✅
Sound programs	✅	✅	✅
Zones 2/3/4	✅	✅	✅
Tuner (FM/AM)	limited	✅	✅
DAB	—	✅	✅
What is playing (artist, album, cover)	✅	limited	✅
Browsing the media menu	✅	✅	✅
CD drive	—	—	✅
Multiroom groups	—	—	✅
Reports changes by itself	—	✅	✅

"Reports changes by itself" is the one you notice in daily use: with MusicCast and YNCA the adapter is told when something changes at the device. A pure XML device has to be asked at intervals, so a change you make at the receiver itself shows up with a delay.

Your device speaks one to three of them — and the adapter uses all of them

The adapter does not pick one and ignore the rest. It connects over everything that answers and builds one object tree from all of them. Every datapoint is served by whichever protocol reports it best, and a value you write is sent over the one that can actually set it.

That is why a MusicCast AV receiver gives you the most: YNCA brings the control base, MusicCast adds media, tuner detail and multiroom on top.

When one of them stops answering

The adapter learns once which protocol serves which datapoint, and keeps it — a receiver does not change what it can. When one protocol drops, or all of them because the receiver lost power, no datapoint changes: nothing is rewritten, no list is emptied, and nothing moves to another protocol.

A value you write while the protocol that serves it is offline, or that the receiver refuses over it, goes out over another protocol that understands it the same way — same type, same unit, same values. Where none does, it is not sent. A key press or a step is never sent a second time.

When the adapter reads the receiver again

After an adapter update, and after a firmware update of the receiver. For a firmware update the log says new firmware found (old → new) — reading the receiver again, this can take a few minutes, and later the usual ready line. The adapter reads with the receiver switched on — until then, every datapoint stays as it is. Only this read may remove a datapoint the receiver no longer has.

Which ones are active at your device?

Look at <device>.info.transports.* — one flag per protocol, true if it answered:

What you see	What you have
ynca only	a network AV receiver, roughly 2010–2020, without MusicCast
ynca + yxc	a MusicCast AV receiver — the common case from ~2015
ynca + yxc + xml	a receiver that speaks all three; you get everything
yxc only	a speaker, soundbar or CD receiver
xml only	a receiver from before ~2010
everything false	the device did not answer — see Troubleshooting

What is missing when a device speaks only one

• Only XML: no DAB, no multiroom. Values are polled, so changes made at the device show up delayed. The interval is the XML query interval in the instance settings.
• Only MusicCast (speaker, soundbar, CD receiver): no surround processing, no HDMI, usually one zone. That is the device, not the adapter.
• Only YNCA: no cover art, no multiroom groups, and the media menu is more basic.

A datapoint that is missing is almost always a device that does not have the ability — the adapter creates only what the device confirms. Devices goes through the classes.