Advanced Command & Feedback Reference – MyURemote

Advanced Command & Feedback Reference

This page explains how commands, responses and UI feedback actually work inside MyURemote.

MyURemote is not command-driven. It is a response-driven execution system.

Commands trigger communication. Responses determine UI state.

1. The real execution model

Every command execution follows this chain:

command → transport → device → response → parsing → UI update

Most integration issues happen because one of these steps is misunderstood.

A command that sends correctly but does not update the UI is usually a parsing problem, not a transport problem.

2. Action vs Query

Action command

PLAY → setPlayerCmd:resume

changes device state
may return nothing
UI is not updated automatically

Query command

STATUS QUERY → getPlayerStatus

requests current device state
returns raw data
feeds parsing logic

Queries do not update UI by themselves. They only provide data for parsing.

3. One query, multiple UI values

A single device response is often reused for multiple UI fields.

getPlayerStatus → {
  "status":"play",
  "vol":"100",
  "Title":"Song",
  "Artist":"Artist"
}

This one response can feed:

Power state
Volume
Title
Artist

This is a core MyURemote principle: one query → multiple parsing targets

4. Feedback parsing model

MyURemote does not interpret responses automatically. Each UI field has its own parsing configuration.

Prefix → where value starts
Position → optional offset
Digits → fixed length
StopSign → end marker
Hex → special decoding

Example

{"vol":"100"}

Prefix: "vol":"
StopSign: "
Result: 100

Prefix + StopSign is more reliable than fixed-length parsing for JSON-like responses.

5. Fire-and-forget vs read

No callback → no read → returns OK
Callback present → read response

This behaviour is deterministic and controlled by the request contract.

If you expect feedback but get only OK, your command is not executed as a query.

6. What “OK” really means

OK only means:

connection succeeded
data was written

It does NOT mean:

device executed the command
state changed

Real state must always be verified via query + parsing.

7. Response formats

Text / JSON

{"status":"play"}

Hex string

416C74696A64

Binary

\x02\x01\xFF

These are not interchangeable.

Hex parsing must match actual response type, not assumptions.

8. Multiple valid responses

stop;pause

Means:

“stop” OR “pause” = same logical state

Useful for power or playback state interpretation.

9. Escaped values

Quotes and special characters are often stored as:

\x22status\x22:\x22

This ensures safe transport through JSON, JS and parsing layers.

10. Input-driven queries

MyURemote does not always run all queries.

Active input determines which queries are relevant.

FM → RDS queries
Spotify → Spotify queries
Generic IP → Title / Artist queries

11. Troubleshooting

No response → device did not reply
Wrong value → parsing mismatch
Empty result → prefix or stopsign incorrect
Command works but UI wrong → parsing issue

Always inspect the raw device response first.

12. Final model

transport + query + parsing = UI state

Understanding this formula is essential for building reliable integrations.