I’ve opened a case, escalated to higher service level at Enphase support, after speaking with three persons it started working again. But now it’s gone, it lasted 3 days. They asked me for the GX IP? It’s incredible that you can’t fix the IP of the Envoy or IQ gateway, and they ask you for a fixed IP on the GX part of the system. I’ve asked for a solution for other 3 systems and they aren’t fixed. I’m a professional Victron and Enphase installer and I’m starting to get a little upset with this mess that they have created with a thing that was already working. I have a bunch of Enphase & Victron installations and I’m really worried if they stop working.
As professional installer this situation is very bad.
Think your customers don’t understand why something that worked well certainly is a problem.
Please escalate it at enphase this isn’t a workable situation!
Today they said over email that my system should be working again.
this isn’t the case, so I replied today.
But the bigger problem is, that you have to wait several days for their response..
Even while this problem should already be known internally.
The fact that enabling a feature such as Modbus-TCP requires contacting Enphase Support suggests that it is not a standard, plug-and-play option. It should ideally be a fully tested feature, directly configurable by the installer.
Hi everybody,
I just found this topic. I experienced the same problem. Communication between Cerbo GX and my Enphase gateway was lost June 13th. Restarting both systems several times didn’t solve the issue. I suspected the Modbus TCP setting of the Enphase gateway and contacted customer service, with no result. The English speaking support engineer said he is not certified to check and pointed towards api@enphaseenergy.com.
Yesterday I was calling again and the (Dutch) support engineer recognized the problem. According to him it’s related to a firmware update (mine is on D8.3.5289) and said he might be able to fix it in 20 minutes - otherwise will send a mail. After 30 minutes connection was restored - I am happy.
Little later a mail arrived which might be helpful to some of you: (Dutch translated with Google) - sorry for the long post.
Subject: Modbus
Hello,
We have given the go-ahead to open Modbus, and it is now open. However, there is no guarantee that it will stay open.
It is important to note:
The actual reason is that the Gateway has been upgraded, causing the outdated Modbus server to be removed in the new software.
It seems that the third-party services used by these homeowners still rely on the old Modbus implementation and do not yet support the new Modbus functionality.
We will provide these external parties with instructions on connecting to the new Modbus implementation.
Unfortunately, this requires a change on the external party’s side; it will take some time before they support the new solution.
Of course, we will also continue working on a solution ourselves and keep you updated on our findings.
Enphase Energy | Customer Support Netherlands & Belgium
The worst part is that the loose of connectivity or communication is due to IP change. In the last updates Enphase had removed the ability to fix the IP of the IQ gateway by the installer. There is no way to achieve this. Talking with support they lead me to a non existing IP in the gateway. That IP were the place where you could fix the IP when this was available. This caption shows the different IP 's during 5 days, without resetting the router. I’ve lost communication this morning again…
This might help:
Network routers (and Wi-Fi access points) may have a feature called DHCP Reservation. This allows the MAC Address of the device to be assigned to a fixed IP address.
You’ll need access to the adminstrator setup screens of the router. It usually has a list of IP and MAC addresses. Find the Enphase in the list, and add it to the DHCP Reservation table. This will set it permanently to the preferred IP address. Later, when the Enphase connects to the network, it will make a DHCP request, and the router will assign the same IP address every time.
I am assuming that the router has this feature, and that the Enphase can use DHCP.
In my case, the IP is static and connected via Ethernet; it hasn’t changed (it’s been the same since the installation). As of today, I’m still waiting for Enphase to give me some kind of answer…
Got this answer from Enphase:
Blockquote
Modbus is a local communication protocol that allows our Envoy to communicate with other devices via readily available APIs.
Customer support does not provide in-depth support for API requests. For any related questions, please redirect your questions to the respective team: api@enphaseenergy.com
As discussed earlier, reiterating the same:
Why Third-Party Modbus Access on Port 502 Fails???
The most common reason people face issues connecting third-party monitoring devices to the Gateway via Modbus is that Modbus is blocked on the Gateway by the gateway. Because it is third party tool. This prevents external devices from communicating with your Enphase system.
Thank you for your understanding
Blockquote
Conclusion, they don’t want that third party devices talk with Enphase!
Don’t know what a API has to do with Modbus,…
First did run a API implementation, but after for security reason the token expires and a internet connection was needed to renew it, I changed to modbus.
I asked the API team for the Modbus team contacts.
I don’t believe a word anymore what Enphase tells people. Every time something else. A closed port makes zero sense. And a gateway that filters / blocks based on the requesting hardware is completely rubbish. What is it exactly that Enphase sells that works with modbus to lower the production?
They just want to sell their own battery and ems system.
Enphase may have decided to implement MAC address filtering to “secure” access to the Modbus TCP service. If so, it is a very poor security measure that is completely worthless!
The SunSpec Alliance is working on a project to secure the Modbus service. It is a serious initiative, but it won’t be ready anytime soon.
After two weeks, API support replied, claiming to have fixed the issue. After verifying—including restarting the gateway—the service remains unavailable and is behaving exactly as before.
To everyone: don’t give up, and keep contacting them at least once or twice a week.
Regarding the IP addressing issue: on my gateway (running version D8.3.5528 / f9db90), it is still possible to configure a static IP address for the Ethernet port. I tried connecting it to Wi-Fi but was unsuccessful, so I cannot say whether it is possible to set a static IP address for the Wi-Fi connection.
What do they mean with following:
The problem is at the venus OS side?
Hi ron_h,
I don’t know what exactly they mean with that reference to third-party services. I am not very knowledgeable about this anyway. From what I understood from the service engineer is that the firmware upgrade of the enphase gateway blocked access to port 502 (due to removal of the outdated Modbus server). Hence the problem is caused by the Enphase system and Enphase needs to grant access (again). In my case, with the second call, it was fixed quite fast. It looks like you need to be lucky to have the right person at the other end of the phone. In fact back in November requesting access after the installation of my Victron setup Enphase was very cooperative with enabling Modbus TCP/IP and information about frequency settings for the grid profile.
I don’t think the problem lies with Venus OS.
They talk about an old Modbus implementation versus new Modbus features—that’s just a smokescreen. The use of Modbus TCP is defined by the SunSpec Alliance to ensure all manufacturers use the protocol in a standardized way; all that’s required is compliance with the specifications issued by the Alliance. Right now, it seems to me that an open protocol doesn’t sit well with Enphase, even though they took the steps to comply with it.
A non-compliance issue had already cropped up previously. The system’s power output drops to zero at night because the microinverters go into standby mode. This is non-compliant because the specifications define the value as constant, yet it varies (too frequently).
I implemented a Modbus TCP data-reading procedure in Node-RED, following SunSpec Alliance guidelines. Venus OS does the exact same thing (based on network traffic observations). Everything worked fine until the day they unilaterally decided to alter the service’s operation without notifying users or installers.
If they fail to comply with the specifications, their certification should be revoked.
Thank you!
may I ask you on which version your gateway is now on?
Mine is also on the D8.3.5289.
Exactly what I think, blame the other party.
Modbus is a standard protocol!
I asked about old Modbus implementation and the new Modbus functionality so we can implement it.
At that moment I got the standard reaction but none answer,…
Seems they are lost and don’t know the source of this issue.
Last time Modbus failed, mine gateway did perform a watchdog reset, in simple words there is a bug in the firmware that caused a never ending internal loop.
But it is running strong now already a few weeks, hopefully is stays like that.
The last version that worked for me was D8.3.5176.250527 Even with older versions of VenusOS.
Note that the release notes are notoriously bad. Nothing to see there. Just a generic security fixes.
Hi George, my gateway is on D8.3.5289, but don’t know when it was installed (guess around 13th June when connection was lost). I tried to check this in HomeAssistant but history isn’t kept that far back.
This has nothing to do with the current firmware version, I don’t think, I had a working modbus connection with this same firmware version.
A few days after, the first people showed up here, I still had the same firmware version, and modbus TCP stopped working.