HTTPS connection error #150 "Unexpected response text" since this morning — MQTT works fine

Modifications
, ,
1

Hi,

Since approximately 5:00 AM CEST today (April 3, 2026), my GX device has been showing #150 Unexpected response text on the HTTP/HTTPS channel. MQTT Real-time and MQTT RPC channels are both Connected.

What I’ve tried so far:

  • Enabled HTTPS — same error

  • Rebooted the GX device — no change

  • Connected via mobile hotspot (different ISP/network) — same error

  • Navigating to http://ccgxlogging.victronenergy.com/log/log.php from a browser on the same network returns “vrm: fail”

System info:

  • 3x MultiPlus-II 48/5000/70 GX (three-phase system), firmware v3.72

  • Date/Time UTC correct: 2026-04-03 11:15

  • Time zone: Central European Standard Time

  • Connection: Ethernet (also tested Wi-Fi hotspot)

Since the VRM logging endpoint itself returns “vrm: fail” rather than a captive portal or redirect, this seems to be a server-side issue. I noticed a similar report from March 29 that resolved itself after a few hours.

Is anyone else experiencing this today? Any guidance appreciated.

Thanks!

2

Update: The issue resolved itself after approximately 12 hours. No changes were made on my side — VRM HTTP channel started working again on its own.

This confirms it was a server-side issue, similar to the report from March 29. MQTT remained connected throughout.

Thanks for any attention to this. Closing the topic.

3

Hi,

I can confirm this is not an isolated case.

I’m currently managing 100+ installations, and lately I’ve been seeing this error (#150 “Unexpected response text”) quite frequently across multiple systems.

Observations from my side:

  • The issue usually resolves itself, but:

    • most of the time within hours

    • in some cases it takes multiple days

  • During this time:

    • MQTT (real-time & remote console) works fine

    • but VRM logging is broken

  • As a result:

    • logs start piling up on the Cerbo GX

    • graphs and historical data lag behind

What I’ve tested:

  • Toggling HTTPS / SSL → no effect

  • Reboots → no reliable improvement

  • Different networks → same behavior

This has been happening on multiple installations recently, which strongly suggests a server-side issue on the VRM endpoint, not something local to individual setups.

It would be great to have:

  • some status/acknowledgement from Victron that this happens and what is the root cause and if fix is planned at some point

Right now the system just sits in error state until it recovers on its own.

Thanks.