Conext Gateway v1.16 BN4 Bug: AP Mode Random Enable / WiFi Performance Issue

[JustJoe]

This same bug should also apply to InsightHome and InsightFacility. I have documented this to Schneider and discussed it with them on the phone, but their call volumes are high and also migrating to a new phone system so getting a fix may take a while.

Setup: Mine is a Schneider CG (Conext Gateway) providing management GUI & Modbus network access to two grid tied XW-Pro's charging a big bank of batteries and AC coupled to a couple of SMA PV inverters.

IP network access from local management PC via LAN, implemented by configuring the CG in WiFi client mode. It maintains a continuous link to a 2.4GHz 802.11g generic router AP. Physical Ethernet jack on CG is always left disconnected.

CG / Setup / Network / Wi-Fi Access Point settings

Access Point | X | _ | (Indicator to the left = disabled)
SSID ConextGateway_xxxxxx
Server IP Address 192.168.100.1

.. / .. / Wi-Fi and Ethernet Settings

Ethernet connection
LAN DHCP | X | _ | (Indicator to the left = disabled)
IP Address 192.168.36.73
Subnet mask 255.255.255.0
Gateway
DNS Server 192.168.35.70

WiFi SSID Sunshine (Connected!)
WIFI DHCP | X | _ | (Indicator to the left = disabled)
IP Address 192.168.35.73
Subnet mask 255.255.255.0
Gateway 192.168.35.70
DNS Server 192.168.35.70

XW-Pro Power Shaving is enabled from 16:00 (start of grid premium rate) to 07:00 the following day.
Charging is blocked from 15:30 to 09:30.
A charge cycle is initiated every day by applying "Bulk" mode at 10:00 using a timer controlled Modbus write from a custom SBC application. Usually, both master/slave XX-Pros follow expected Bulk / Absorpstion cyles and fully charge the batteries every day.

Normally, LAN performance PC to CG is good, ping times 260 ms.

PROBLEM: At very random times, approximately 5 to 14 day intervals, the CG improperly ENABLES its Access Point mode! Our first indication is that network performance to the CG becomes very bad, ping times 800-1200ms, or totaly dropped. (Pings and network access to the colocated SMA WiFi clients remains fine.) My opinion is the CG internal WiFi processor was never designed to efficiently time share between both wireless client & AP modes being active.

AP active can be confirmed by doing a local WiFi scan from a PC and seeing the ConextGateway_xxxxxx SSID.

With some patience & effort to deal with the performance, it is often possible to log into the CG over the WiFi. Surprisingly, under Wi-Fi Access Point settings, the Access Point "switch" still indicates "disabled". The only "fix" we have is simply clicking the GUI menu "Apply" button (no need to make any config changes). Once done, the performance instantly recovers, and the SSID disappears from WiFi scan.

Note: Initiating a software reboot from the GUI menu (or even from the Modbus reboot register setting) does *NOT* fix the AP active behavior.

Also: This "acts" as if someone had pressed the "WiFi" button on the side of the CG. But our CG is inside a dry, secure outbuilding without others having access.

The big impact for us is that the custom SBC app is also using Modbus to continually adjust EPCMaximumCharge Power, so the batteries only charge from solar and send the excess to the grid. The WiFi performance hit totally disrupts that when the Bug is active. (Unfortunately no Modbus key register for AP mode disable.) The only thing the app can do is a WiFi scan for the CG AP and start flashing a warning to manually disable it.

I have seen others reporting the bug. Some even just use wired Ethernet seeing the AP getting enabled. Others just notice random WiFi performance issues. I figured it would be good to pursue that from one place on these forums.

 

[JustJoe]

For now, we have updated just the Conext Gateway to v1.17 Build 079 and will wait to see if it still randomly recurs.

 

[JustJoe]

Hi @Eber & @sancsam You might find this thread useful.

 

[400bird]

I just did a wifi scan and saw my Insight AP was active. But then I went and looked and the setting was set to "on"

I'm pretty sure has it set to "off"
But, I clicked it off again.
Doesn't effect much here as I've got a hardwired network connection to it. I figured that I need to send the EPC max charge command frequently enough that I wanted the reliability of copper.

 

[JustJoe]

I just did a wifi scan and saw my Insight AP was active. But then I went and looked and the setting was set to "on"

I'm pretty sure has it set to "off"
But, I clicked it off again.
Doesn't effect much here as I've got a hardwired network connection to it. I figured that I need to send the EPC max charge command frequently enough that I wanted the reliability of copper.

Thanks for the feedback. On mine, the GUI only ever shows it disabled.

Could you remind me, do you have the model labelled Conext Gateway or the repackaged InsightFacility ?

Signal strength wise, both our generic router AP and CG client show -56dBm . When the AP is off, the Modbus communication is great. That's good, because I was not around when they dug the trenches between the XW-Pro shed and the grid connection, put in PVC for the AC, and buried it, (with no Cat5 conduit) so wireless was the way to go. With such an expensive set of "tier1" products, in this day and age, I figure the WiFi should work.

 

[400bird]

I have an Insight Home.

I can't say for sure that the AP was disabled before, but I turned it off now. Also, I'm on older firmware (1.16), but as you said this bug has been going on for a while.
Too bad about the lack of cat5 at the power shed.

 

[JustJoe]

I have an Insight Home.

I can't say for sure that the AP was disabled before, but I turned it off now. Also, I'm on older firmware (1.16), but as you said this bug has been going on for a while.
Too bad about the lack of cat5 at the power shed.

Ah, interesting.. If you should think of it in a week or two, please check it again. Schneider is mostly saying the 3 models have identical innards. But I know from experience that WiFi chipset hardware makers have very fast chipset version cycles. Differing WiFi hardware versions could definitely impact the results of this bug.

 

[sancsam]

You might find this thread useful.

Thank you @JustJoe . Im following this. I also have the previous Conext Gateway but now running on 1.18. After this upgrade the gateway reset all network settings and had to configure the Wi-Fi and disable the AP.



Im also executing logic outside the system and updating parameters through Modbus. Previously i was running 1.17 without any Wi-Fi issues other than from time to time the gateway would be unresponsive after a Grid Outage (Not sure the cause of this) and require a power cycle.

I have also experienced the AP is on even after being set to off but i have not had any Wi-Fi performance issues because of it. I have also experienced better performance after upgrading to Wi-Fi 6.

 

[JustJoe]

Thank you @JustJoe . Im following this. I also have the previous Conext Gateway but now running on 1.18. After this upgrade the gateway reset all network settings and had to configure the Wi-Fi and disable the AP.

View attachment 159254

Thank you for following up here! For me, as far as I can tell, the update from v1.16 to v1.17 went smoothly without any config changes. IMHO it is very poor programming style for their update to have lost the connection settings! A WiFi connection in this day and age is expected to be a reliable thing. So like if someone is trying to manage their CGateway remotely ... f/w update surprise, now you have to unexpectedly go (possibly run) to get connectivity back?

And OK, so it's a new Version, big news for developers and marketing. But for end users, big whoop! Sure there might be some incompatibilities ... But in the end if the stupid thing loses something as simple as the connection, that's just a big red flag against the rest of the firmware reliability.

Im also executing logic outside the system and updating parameters through Modbus. Previously i was running 1.17 without any Wi-Fi issues other than from time to time the gateway would be unresponsive after a Grid Outage (Not sure the cause of this) and require a power cycle.

Depending on the Modbus controlling device, sometimes the retries are hidden from the end user. The program I have posts to a syslog server when things get excessive. But I would also notice the sluggishness of the GUI once the AP was active.

I have also experienced the AP is on even after being set to off but i have not had any Wi-Fi performance issues because of it. I have also experienced better performance after upgrading to Wi-Fi 6.

Ahhh, do you remember if the CGateway did its random AP enable bug when you were running v1.17 (as opposed to v1.16) ??

And, if you have a chance to notice if v1.18 experiences this bug, please post a comment here.

 

[sancsam]

Ahhh, do you remember if the CGateway did its random AP enable bug when you were running v1.17 (as opposed to v1.16) ??

And, if you have a chance to notice if v1.18 experiences this bug, please post a comment here.

I remember having the same issue you are having about random AP enabled and poor performance (or even Wi-Fi client stop working) when the AP as well as connected to the house Wi-Fi.

I dont remember what firmware version fixed it but i do remember 1.17 being stable and having no issues with Wi-Fi connectivity.

I now see that 1.18 was removed from the download page.

 

[JustJoe]

I remember having the same issue you are having about random AP enabled and poor performance (or even Wi-Fi client stop working) when the AP as well as connected to the house Wi-Fi.

I dont remember what firmware version fixed it but i do remember 1.17 being stable and having no issues with Wi-Fi connectivity.

I now see that 1.18 was removed from the download page.

OK, then in that case I will stay at v1.17 and post here if I experience this bug again. Thanks for the info!

 

[Eber]

So the bug does not show up in 1.17, or maybe i am reading this thread wrong.
I am still on 1.16 and was holding out until bugs were fixed.

 

[JustJoe]

So the bug does not show up in 1.17, or maybe i am reading this thread wrong.
I am still on 1.16 and was holding out until bugs were fixed.

I actually wrote a custom lua program to scan for various solar network communication problems every 25 minutes. One of the checks I added was WiFi scan for the specific ssid. From my experience on v1.16, bug would recur between 4 to 14 days since the last time it was cleared. So far only been running v1.17 for 4 days, so still at least 10 days before I declare this house clean of poltergeist.

 

[JustJoe]

It might be useful to add that I only updated the Gateway f/w. v1.17 installed without any quirks. But the XW-Pro's are still at 1.11.01bn49. I did this to minimize changes for isolating the bug. Schneider v1.17 release notes recommend upgrade to v2.04. l have seen no adverse incompatibility (modbus still works fine). But this is a very stable config. So I wouldn't recommend running with this f/w mismatch if say, you are installing/configuring a whole new system.

 

[sancsam]

Just an update.

So far, all good with 1.18. AP is still disabled.

 

[400bird]

I'm on 1.16 and the AP also has not turned itself on. It's been just shy of 3 weeks.

Note to self: I really do need to do those updates. The security vulnerability patch isn't something I should ignore. Oh look, a squirrel!

 

[400bird]

I'm on 1.16 and the AP also has not turned itself on. It's been just shy of 3 weeks.

Note to self: I really do need to do those updates. The security vulnerability patch isn't something I should ignore. Oh look, a squirrel!

Another month on 1.16 and the wifi AP still hasn't turned itself on.

Also, still haven't updated the XW or insight.