The text protocol from my Phoenix Inverter (24/800VA) has hex protocol responses embedded in the tex

Interesting one this — I've been down a similar rabbit hole with my shepherd's hut setup.

Running a Victron Phoenix 24/500 here alongside a SmartSolar MPPT, with a Raspberry Pi Zero W doing the monitoring. The MPPT side has been rock solid using the VE.Direct hex protocol for months — pulling historic yield data, bulk/absorption cycle counts, all the good stuff. No drama whatsoever.

But when I wired up the Phoenix via VE.Direct and started parsing the text protocol stream, I noticed something similar to what you're describing — occasional hex-framed bytes appearing inline within what should be a clean ASCII text output. Took me a while to realise the Phoenix firmware seems to interleave async hex notifications (unsolicited responses, I think — flagged by the 0x0 frame type) into the text stream without any clean delimiter separation from the human-readable fields.

My current bodge is filtering on the : prefix character to separate hex frames from text records before passing anything to my parser. Seems to work, but it feels fragile.

A few questions for anyone who's tackled this:

• Is this behaviour documented anywhere in the VE.Direct Protocol PDF? I'm on version 3.33 and can't find a clear explanation.
• Does the Phoenix behave differently from the MPPT in terms of how frequently these async frames appear?
• Has anyone found a more robust parsing approach in Python or C that handles both frame types gracefully in a single read loop?

The Victron Community forum has some threads but they tend to go quiet or disappear behind ESS-specific discussions. Hoping someone here with hands-on VE.Direct experience might have dug deeper into this.

Hey @HighlandExplorer, great timing on this thread! I've been dealing with exactly this on my cabin setup.

The hex strings embedded in the VE.Direct text protocol caught me out initially too. What you're seeing are essentially framing bytes that slip through when the checksum byte happens to fall within printable ASCII range — it's not a separate protocol, just the raw serial stream being a bit untidy.

On my Pi Zero W I found the simplest fix was filtering lines strictly by the \r\n delimiters and only parsing fields that begin with a recognised label like V, I, PPV etc. Anything that doesn't match your expected label list just gets discarded.

Have you looked at the vedirect Python library on GitHub? Saved me a fair bit of head-scratching — handles the checksum validation cleanly and just gives you a nice dict back.

What labels are you specifically trying to capture?

Right so this rang a bell — had the exact same head-scratcher on my van build when I first wired up VE.Direct monitoring on my Phoenix 500.

The embedded hex chunks are essentially binary flags that Victron smuggles inside what looks like plain text output. The text protocol and hex protocol are running simultaneously on the same serial stream, which is... a choice.

The bit that got me: your parser needs to strip anything between \x00 and the next valid ASCII line before you try to make sense of the alarm/status fields. I was getting completely mangled voltage readings for about three weeks before I realised the hex was corrupting my splits.

@JimButler did you find the same thing on your cabin rig? Curious whether the 24V models behave differently to the 12V units here, because mine definitely threw more hex noise than I expected.

@HighlandExplorer this is a known quirk worth documenting properly — the Phoenix text protocol occasionally embeds raw hex frames mid-stream when the device is transitioning states, particularly around inverter mode changes.

On my static caravan setup I parse the VE.Direct stream with a simple state machine in Python — when I detect 0x sequences I flush the buffer and wait for the next clean \r\n delimited block before resuming.

Rough approach:

if line.startswith(':'):
    # Hex frame, discard or handle separately
    continue

The colon prefix is your reliable discriminator between text and hex protocol frames. Victron's own VE.Direct Protocol FAQ confirms the two can coexist on the same UART.

Once I implemented that filter my monitoring script went from constant parse errors to rock solid. Worth checking your baud rate is locked at 19200 too — seen that cause similar weirdness.

Has anyone confirmed whether this behaviour is consistent across firmware versions? I'm asking because I'm planning a similar monitoring setup in my van — Victron Phoenix 500W on 12V with a Pi reading VE.Direct — and I'd rather build the parsing logic correctly from the start rather than retrofit it later.

Specifically wondering:

• Does the hex embedding only appear on certain PID values, or is it scattered throughout the frame?
• Is there a reliable delimiter to split the clean text fields from the embedded hex segments?

@DriftWizard or @SprinterConvert — did either of you find the Victron VE.Direct Protocol PDF covered this, or was it purely discovered through trial and error? I've had a look at the document and couldn't spot any mention of mixed-format frames, which suggests it might be undocumented behaviour rather than intentional design.

@VanKev — firmware version absolutely matters here. I've seen this on my shepherd's hut Phoenix 24/800 (same unit as the OP essentially) and the hex bleed-through is far more pronounced on older firmware builds. Victron's changelog for the Phoenix range doesn't always flag comms-layer changes explicitly, so worth cross-referencing your actual firmware string against the VE.Direct protocol PDF revision history — they don't always align neatly.

Practically speaking, my parser on the Pi filters any line where the field value fails a basic ASCII printable check before it even hits the database. Crude but effective — haven't had a corrupt reading in months.

Check your firmware via VictronConnect → device info. If you're below the version that shipped with the current VE.Direct Phoenix PDF (rev 11 at time of writing), update first and see if the frequency drops before building complex filtering logic around it.