It happened again, mine Enphase system doesn’t show up in VRM. A re-scan of the PV inverters did help last time, but doesn’t seem to help this time. Is there a way to check if Enphase did turned off modbus support? Anyone noticed the same issue?

Thanks for the info. This is an “old” Enphase firmware, it comes from April 15th, the most problematic firmware is 8.3.5528.260506 coming in May the 6th. Older firmwares from 2025 an back are working with the modbus. The most annoying issue is that Enphase cannot roll back or downgrade the firmware to prior versions. Still waiting for a solution as long as we have 200 systems with Enphase and 10 with Victron and Enphase. Most of them are still working because they didn’t update. I don’t know their politics to update the installations, and also can’t block them to update :smiling_face_with_tear: . Hoping this is solved ASAP or we’ll have to move to energy meters.

My understanding is that the metered envoy runs a newer firmware version. This is my test system with the standard envoy. The software is up-to-date. Even triggering the firmware update in the toolkit won’t change that.

note: it now even works on non-metered devices, even with old Victron firmware. @BAnders Do you mean I can read my PV power and such on the enphase non-metered envoy?

So now it works with standard Envoy but still doesn’t work with metered…

[image] Juan Guerrero: with standard Envoy And if it works with the standard Envoy, does Modbus TCP (port 502) also need to be enabled by Enphase? Six months ago, Enphase stated that the Modbus option cannot be enabled on a standard Envoy.

[IMG_0942] Modbus/TCP works here out of the box.

Probably not. I do have a MID certified meter for this. Which is a whole lot faster of course. But it enables me to lower the power to what I want. Edit: there are values for the lowest, normal and highest voltage. The lowest is 230 minus 5% (219V). The highest is 230 plus 15% (264V). The latter is too high. Should be 253V.

My case involves firmware version SW VERSION D8.3.5528.260506, which I believe has been one of the most problematic releases. The Modbus TCP service stopped working on May 27, 2026. After contacting soporte_es@enphaseenergy.com, support@enphaseenergy.com, and api@enphaseenergy.com, following Enphase’s instructions, the Modbus TCP service was re-enabled on June 29, 2026, after I provided the IP address of my Victron Cerbo GX. I therefore assume that this procedure is related to security requirements. However, since the service was re-enabled, the IQ Gateway has been reporting my system as a three-phase installation, even though my installation is single-phase. When I contacted Enphase again, I was informed that the issue was caused by Victron’s interpretation of the data sent by Enphase. However, before the Modbus TCP service stopped working, the system had been operating correctly for approximately one year, and the Gateway was reporting the installation correctly as single-phase. As of today, I have disabled Modbus TCP data acquisition on the Cerbo GX. As a temporary workaround, I retrieve the production data directly from Enphase using the HTTPS API (with an authentication token). I then use Node-RED to transfer this information to virtual sensors in Home Assistant, allowing the Victron system to use the data. It is unfortunate that, throughout this process, the information provided by Enphase has been, in my opinion, limited and at times contradictory. In addition, the response times have been excessively long, at least in my case. Update: Enphase has confirmed that firmware version SW VERSION D8.3.5528 reports all three phases even on single-phase installations. They also stated that they will request this issue to be corrected in a future firmware release.

Good news: the issue regarding the AC type has been acknowledged. My system started reporting errors again on July 23rd. After contacting Enphase, they reactivated the service, claiming the client’s IP address had changed (even though it is static). Now, I have read-only access. Attempts to modify data (write operations) return Modbus exception 2: “illegal data address.” Other users are encountering this error, including fobrs on GitHub, who had alerted me to the issue two weeks ago. The problem has been reported. I hope Enphase will provide an explanation and fix the issue quickly.

Hi, According to the latest update regarding Modbus TCP in the Enphase tech brief (june 2026) ( AC-coupling with Victron battery inverters using Modbus TCP/IP | Enphase ), they indicate that reading is indeed possible (address 700). I haven’t tested it myself yet…, but I believe that if they truly intend to comply with SunSpec standard requirements (https://sunspec.org/contributing-members/enphase-energy/), they will have to fix several of the current issues. Update: (After several attempts to write to registers 40310 and 40311 from Node-RED) Following up on this thread — after some testing, I wanted to share a conclusion that might be useful to others trying to control Enphase curtailment independently via Node-RED (or any other custom Modbus TCP client), separately from the Cerbo GX’s native integration. Enphase confirmed that Modbus TCP/IP access to the Envoy requires a static IP, and — importantly — only allows one simultaneous Modbus TCP connection to the gateway. This means that if you enable the “Export limiting Control” option on the Cerbo GX (as described in Enphase’s TEB-00199 tech brief), the Cerbo will establish its own persistent Modbus TCP connection to the Envoy to take over control of the PV production limit. Since only one connection is allowed at a time, any other Modbus TCP client — such as a custom Node-RED flow reading/writing registers 40310/40311 directly — will no longer be able to connect once the Cerbo has claimed that connection. In other words, these two approaches are mutually exclusive: Enabling native control via the Cerbo GX (“Export limiting Control”), letting Victron/ESS manage the WMaxLimPct/WMaxLimPctEna registers directly. Keeping full manual control via a custom Modbus TCP client (Node-RED or similar), in which case the Cerbo’s native option should be left disabled to avoid connection conflicts. If anyone has tested this differently, or knows whether the Envoy handles connection contention any other way (e.g. dropping the older connection instead of refusing the new one), I’d be curious to hear about it — but for now, we’re treating these as exclusive control paths in our setup.

Enphase modbus system not showed in VRM

DIY

Q.x (Quentin) 25 September 2026 07:05 168

On August 6, with system version 8.3.5528, I encountered a similar problem. The Modbus service was returning error 6, “Slave Device Busy.” After a restart, the service became operational again.

MultiPlus-II 48/5000 + Enphase IQ7 : Frequency Shifting, ESS et zéro injection réseau

Topic		Replies	Views
AC-coupling Enphase Modbus TCP DIY diy , multiplus-ii , enphase	25	2734	31 March 2026
Solaredge communication dropping every few minutes Q&A and troubleshooting vrm , multiplus-ii , cerbo_gx , solar_edge	293	9753	19 October 2026
There is still a problem with the MPPT Can SmartSolar firmware 3.18 DIY expert , ess , multiplus-ii , gx_device	93	1701	7 May 2026
EVCS constantly falling off wifi EVCS professional	176	3831	29 October 2026
VM-3P75CT shows no power readings after firmware update Q&A and troubleshooting professional , dess	22	830	23 September 2025

Enphase modbus system not showed in VRM

Related topics