Docs/fix readme inaccuracies

[ronaldvdmeer]

Fix README inaccuracies

Fixes multiple documentation issues found during a README review.

MockPooldoseClient examples (commit 996b272)

All 5 MockPooldoseClient constructor examples were missing the required model_id and fw_code parameters, which would cause crashes when copy-pasted.

Program Flow diagram (commit 7a53c7a)

The diagram showed mapping JSON loading as the last step of connect(). In the actual code, it happens as the second step (right after fetching debug config), before WiFi/AP/network info.

API Architecture diagram (commit 749e74e)

• Endpoint names didn't match the actual method names (e.g. getInstantValues > get_values_raw, getDebugConfig → get_debug_config)
• Missing endpoints: get_device_language, set_value

Constructor API Reference (commit 9cdb79a)

• Missing parameters: websession, debug_payload, retry_delay
• Missing keyword-only marker (*) in signature

Methods API Reference (commit 479ae59)

Missing methods: set_switch(), set_number(), set_select()

CLI docs, German comment, alias table (commit 780fe53)

• Translated German comment "Beispiel mit Fantasiewerten" to English
• Documented --version flag in both CLI usage sections
• Added note about --host/--mock mutaul exclusivity
• Added note that --analyze/--analyze-all require --host
• Fixed VA DOS EXACT alias reference in Supported Devices table: changed "Alias for PDHC1H1HAR1V0 mapping" to "Alias for PDPR1H1HAR1V0 mapping"

Note on the VA DOS EXACT alias fix: This may look odd at first glance, a VÁGNER POOL device (PDHC prefix) aliasing to a SEKO model-ID (PDPR prefix). However, this is correct per the actual code in constants.py:

MODEL_ALIASES: dict[str, str] = {
    "PDHC1H1HAR1V1": "PDPR1H1HAR1V0",
}

The mapping file that gets loaded is model_PDPR1H1HAR1V0_FW539224.json. The previous text ("Alias for PDHC1H1HAR1V0") referenced a model ID that has no mapping file and no alias entry.

Separately: VA DOS BASIC (PDHC1H1HAR1V0) has no alias and no mapping file either, it may need its own alias entry pointing to PDPR1H1HAR1V0, but that's a code change outside the scope of this PR.

[lmaertin]

Thanks for this update, I was thinking about to shrink the whole readme. Since you are the first contributor, you can judge on this. Is the document overloaded or helpful in that form?

[ronaldvdmeer]

The README has grown quite long (~900 lines), which makes it hard to navigate. What do you think about splitting the detailed sections into a docs/ folder in the repo?

Proposed approach:

• Keep README compact: intro, installation, quickstart, and a short API summary with links to the detail pages
• Move detailed content into docs/ as separate markdown files (e.g. docs/cli.md, docs/ssl.md, docs/mock-client.md, docs/api-reference.md, etc.)

Why docs/ folder over GitHub Wiki:

• Changes go through PRs, same review workflow we're using now
• Docs stay in sync with code changes
• No extra tooling needed, just markdown, readable directly on GitHub
• Easy to upgrade to MkDocs/GitHub Pages later if needed

I'll prepare a draft-PR

[lmaertin]

I like, thanks for honest feedback.

This changelog summary we also do not need in the readme. Just a reference to the changelog is sufficient.

However, I think the wiki is made for such details for ease navigation. I need to think about...

You did so much already for this project. If you like, please continue, otherwise I take the part on the remaining tasks. Decide on your own please.

[ronaldvdmeer]

See #38

[ronaldvdmeer]

Thanks! Happy to continue.

On wiki vs docs/ — my main reasons for preferring docs/:

• PR workflow: Wiki edits bypass review entirely. docs/ changes go through the same PR process as code
• Code + docs in sync: Both can be updated in the same PR. With a wiki it's a separate manual step that's easy to forget
• CI: You can lint docs/ files. Wiki has no CI
• Versioning: docs/ is tied to the code commit. Wiki is always "latest" with no version alignment
• Migration: docs/ is the standard starting point for MkDocs/GitHub Pages if you ever want a proper docs site

That said, wiki is great for community content (FAQ, troubleshooting) that doesn't need to track code versions.

[lmaertin]

May we start like this. I saw some actions to auto-update the wiki from a bunch of md files. However, we do need this right now. Let's follow you approach...

[ronaldvdmeer]

May we start like this. I saw some actions to auto-update the wiki from a bunch of md files. However, we do need this right now. Let's follow you approach...

PR is ready

[lmaertin]

Ok but this one here is outdated?

[ronaldvdmeer]

yes, this one can be closed. Moved all the changes to the other PR