[Phlabry]

Closes #239. Updates #195 with the port, which that issue can keep tracking for the import procedure.

#239 was written when nobody knew the port and asked for a placeholder that clearly was not a value to copy. We now have the real one, so this does the better version of that: carry the confirmed value with its provenance, instead of a number three files happened to agree on.

Where 5050 came from

Read off the lab machine's iMotions install, Global Settings > API > Event Receiving, with Enable event reception and Use TCP both ticked. The same panel lists our event source as Id: PilotDataSync, version 1, Positional Flight Data, which matches what the relay's generated iMotions.xml defines and what it puts on the wire.

It is a setting rather than a product default, so the README says to check it on whichever machine you are using instead of trusting the placeholder.

Changes

• relay/src/view.rs: placeholder is 127.0.0.1:5050, with a comment recording where the value came from.
• relay/src/state.rs: the validation message matches.
• src/server/src/main.rs: the mock keeps 9999, now labelled as its own local testing port so running it is never mistaken for talking to iMotions. That was Relay's 127.0.0.1:9999 placeholder reads like a real iMotions port #239's suggestion and it still holds.
• README.md: a short section on reading the port off the API tab, what the event source should look like, and which three ports on that same tab are not ours. The "nothing confirms it is iMotions' real port" warning is replaced.

Still open

How iMotions.xml is imported is still undocumented. It was already registered on the lab machine and nobody on the team performed the import, so #195 stays open for that half.

Untestable here: the relay has still never been pointed at a real iMotions instance. This changes a default and documentation only, and the relay has no default address, so nothing connects anywhere on its own.

[jmacd867]

Thanks for tracking down the port. Documenting where to read it (Global Settings > API > Event Receiving) in the README is exactly what #195 needed.

A few things before this closes #239:

1. The placeholder is still a value people will copy. The placeholder (DEFAULT_TCP_PLACEHOLDER) and the validation error both read 127.0.0.1:5050. #239 asked for something "clearly not a value to copy", and that's what happened with 9999. 127.0.0.1 also means the relay's own machine, but in the lab iMotions runs on a separate computer. Could the placeholder, the error message and the README examples (README.md:105-108) all use something like <iMotions IP>:5050?

2. The mock server still prints a bare 9999. The comment is updated, but #239 asked for the output to say it too. The startup line (Server listening on ...) and the usage line ((default 9999)) could say it's a local testing port, not iMotions'.

3. Smaller, take or leave:

• The error message could build its text from the placeholder constant, so the next port change is one edit instead of two.
• The name DEFAULT_TCP_PLACEHOLDER contradicts its own comment ("a setting rather than a fixed default"). Maybe IMOTIONS_ADDR_HINT?
• "9999 used to sit here..." in view.rs is history and fits better in the commit message.
• docs/client_meeting_notes.md (lines 61 and 68) still lists the port as open. That's fine as a meeting record, but a one-line pointer to the #195 comment would stop people from rereading it as unresolved.

cargo test in relay passes (8/8) and the mock server builds. I can't check 5050 end to end without the lab machine.

[Phlabry]

All four addressed in 1c0dcc0 (force-free, pushed to the branch).

1. The placeholder and the validation message now read <iMotions IP>:5050 and come from one constant, IMOTIONS_ADDR_HINT in state.rs. You were right that 127.0.0.1 was worse than a non-value: iMotions is on a separate machine in the lab, so it is wrong as well as copyable. The README says that explicitly now.
2. The mock prints Mock server listening on ... followed by a line saying the port is local to the mock, and the usage line says the same.
3. Taken: the error builds from the constant, the name is IMOTIONS_ADDR_HINT, the history sentence is gone, and client_meeting_notes.md has a one-line pointer to the Confirm how iMotions.xml is imported and which port iMotions listens on #195 comment rather than a rewrite of the record.

One thing for whoever merges second. #242 adds "No address entered. Type one, for example 127.0.0.1:9999", a fifth place with the old port. It is not on this branch, so after #242 lands that string wants the same treatment. I will pick it up in the rebase if this merges after it.

[jmacd867]

Approving. All four points are addressed, the placeholder and the error message now share one constant, and CI passes. cargo test in relay also passes locally.

Not blocking, fine as a follow-up:

• docs/client_meeting_notes.md: line 61 still points to "the open question" in the README, which is gone now, and the Open items table still lists "Confirm which port iMotions listens on".
• A small test that validate_tcp_addr("localhost:5050") fails with a message containing IMOTIONS_ADDR_HINT would pin the link between the two. It matters for #247, see my comment there.
• The error-message line in state.rs is 105 characters, over rustfmt's 100.
• Could you confirm the three outgoing port names in the README (Remote Control, the two Destination Server ports) match the lab screen? They aren't in the #195 comment.