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

I have my own C code running on a Rpi that I am using to monitor and and control a MPPT solar charger, this has worked formany months. I use the hex protocol to obtain various historic values etc. and the Text protocol to collect the current values.

I was using a ‘cheap’ inverter to provide power to a bore hole pump, this was switch on/off via a 100A relay when the battery was charged and the sun was out.

I have a Phoenix Inverter 24/800VA inverter and thought the same code would work.

The problem I get is that when I send queries like :451 to get the model number the response appears in the middle of a text block

The following is from my logging, non-printable characters are converted to #ooo where ooo is the octal value of the character

csum mismatch frame[PID#0110xA2E2#015 FW#0110124#015 SER##011HQ2147HEQAQ#015 MODE#0112#015 CS#0119#015 AC_OUT_V#01123001#015 :1E2A2D0 #015 PID#0110xA2E2#015 FW#0110124#015 SER##011HQ2147HEQAQ#015 MODE#0112#015 CS#0119#015 AC_OUT_V#01123001#015 AC_OUT_I#0110#015 AC_OUT_S#0110#015 V#01124174#015 AR#0110#015 WARN#0110#015 OR#0110x00000000#015 Checksum#011]

The bold text high lights the hex protocol response 1E2A2D0 #015 embedded in the text block.

Is this the expected? and how should I manage the check sum calculation?

I’ve found using a mix of protocols to be less effective than using purely hex protocol with VE-direct.
Text protocol will restart if there is a gap of more than 1s in the hex requests (it would be nice to be able to turn off text or make this a programmable delay…)
So as well as dumping the serial receive buffer, I always send the first request twice so as to stop the text mode, preventing most conflicts - the processor I’m using is slow and quite heavily loaded with other tasks…
I uses string methods to identify the start and end of transmission of a transmission (: xxxx /cr) , then do a sanity check on the decoded information, and put up with the occasional invalid data.

Maybe youve seen this already, its listed under technical information on the inverters product site

Thanks for the feedback.
I have implemented some code that detects the ‘:’ at the start of a line while the state machine is collecting a text protocol block, and collects the hex data till the next new line. This data is then decoded as normal, and then the state machine returns to collecting the text block. Removing the :\n from the text block then allows the checksum to match.

It is a bit convoluted but seems to work in my initial testing.