config add: random UUIDs + NextObj/NextMem not bumped (deviates from Loxone scheme)

[tobsch]

Observation (not a crash — a deviation worth confirming)

Added blocks don't follow Loxone Config's UUID/counter scheme.

Repro

grep -oE 'NextObj="[0-9]+"[^>]*NextMem="[0-9]+"' config.Loxone   # e.g. NextObj="109928" NextMem="49"
lox-cli config add --type And --title "probe" copy.Loxone
# new block UUID: e07fec7b-4206-eefc-ffffed57184a04d2  (serial suffix preserved, first 3 groups RANDOM)
grep -oE 'NextObj="[0-9]+"[^>]*NextMem="[0-9]+"' copy.Loxone   # UNCHANGED: NextObj="109928" NextMem="49"

Loxone's own UUIDs increment (15ea0aa4-0243- -> -0244- -> -0245-, same serial suffix) and the editor bumps NextObj/NextMem.

Why it may matter

Random prefixes won't collide, so uniqueness is fine. But the file is no longer numbered the way Loxone Config would, and NextObj/NextMem no longer reflect the real object count. Unclear whether the editor/Miniserver relies on that on round-trip.

Suggestion

Mint UUIDs from NextObj/NextMem in Loxone's incremental scheme and bump the counters, so a lox-cli-written file is indistinguishable from an editor-written one and round-trips cleanly. If random is intentional, a short doc note (+ a validate check that counters are >= max index) would help.

---

Found during an agent-driven analysis session (Claude Code) building multi-room logic on a real config.

[tobsch]

Refined assessment after digging in (and after #7):

The generated UUIDs preserve the Miniserver serial in the last segment and are random-but-unique in the first three, so there is no collision risk — including against future editor-assigned UUIDs, because those are derived from NextObj while these are not, so the two spaces don't overlap. Not bumping NextObj/NextMem is therefore harmless for correctness (only leaves the counters cosmetically stale).

A "real" fix — minting UUIDs in Loxone's incremental NextObj-derived scheme and bumping the counters — would require reverse-engineering that derivation (the increment is split across segments in a non-obvious way) and, critically, validating a round-trip against a real Miniserver upload. I don't want to ship an unverified guess here, so I'm intentionally not sending a PR for this one.

Recommendation: either keep the current behavior and document it (it's safe), or have someone with a Miniserver validate a scheme-matching implementation. Happy to help with the latter if a maintainer can test uploads.