DTU connection improves when saving network settings

[Ascendor]

Hey @tbnobody,

have you seen this? I think this is worth analyzing:

I noticed some strange behavior. I have connected the chip via Ethernet and it is not possible to connect to my inverters. As soon as I save the network / WLAN settings in the UI (no matter what is entered) a connection is possible for a few minutes. Then the connection breaks off again, until I save the WLAN settings again.

Originally posted by @morzan1001 in #339 (reply in thread)

I can reproduce this 100%: My signal deteriorates over time. As soon as I press "save" on the network settings, it works rockstable again for a few minutes. Is this a hint at a bug in network hardware/software?
Or does any kind of "reset" happen here, that could help if done on a regular (configurable?) basis automatically?

See my power graphs as a reference:

The empty times are missing data. I pressed save at 14:14, 14:42 and 14:54. Afterwards, perfect line for 2 minutes...

[tbnobody]

I have seen it and it doesn't make sense. The only thing what happens when the new wifi credentials are applied is a reconnect to the AP. This has nothing todo with the whole receiving logic. Only thing might be power spikes or something like this. I am running a lot of ESP instances with this software and it doesn't occour on any of them. So I would conclude that it's not a software issue.

[Ascendor]

Thanks for the quick response. Weird thing. Note, it also works when not even changing the credentials. Don't know if it reconnects to the AP as well then.
Funnily enough, I don't get ANY connection while using ethernet before saving network setting for once - so there seems to be something with regard to wifi on this board (I also use an Olimex board)...

I'll do some more experiments, when the sun is back ;)

[morzan1001]

Hey guys, i fixed this issue.

Heres what i did:

I saw that there was a problem with setting the wifi mode during the upload/initial bootup.

[WiFiGeneric.cpp:1130] mode(): Could not set mode! 12308

I looked for the right place in the code and saw that the WiFiMode is set to WIFI_MODE_NULL. I tried to enter WIFI_OFF here, but that didn't change anything and I noticed later that WIFI_MODE_NULL points to WIFI_OFF via a define.

Obviously, it is not possible to disable the Wifi module here or to change the mode. For this I stumbled over the following other issue, but I have already checked, the fix is already included in the WIFIGeneral.cpp used here.

I then noticed that a connection with my HM-300 module is always possible when the WIFI module is activated or in the mode WIFI_MODE_STA, this is set when you save the settings. In the UI, the WLAN module is then also displayed as Enabled.

After a few minutes this setting is overwritten again, because the environment variable OPENDTU_ETHERNET is set or the _networkMode is set to Ethernet.

The restart happens here, I think, because the admin mode is disabled after the 180sec timeout is reached here.

15:35:26.567 > Admin mode disabled
15:35:26.574 > WiFi disconnected
15:35:26.627 > E (184355) esp_netif_lwip: esp_netif_new: Failed to configure netif with config=0x3ffb2700 (config or if_key is NULL or duplicate key)
15:35:26.638 > E (184357) esp.emac: esp_eth_mac_new_esp32(595): alloc emac interrupt failed
15:35:26.644 > [184368][E][ETH.cpp:270] begin(): esp_eth_mac_new_esp32 failed

The WLAN module is now deactivated again and it is no longer possible to connect to the HM-300.

But if you write WIFI_MODE_STA in both lines, 129 and 157, so that the WLAN module is switched on although you use ethernet, everything works without problems.

But I would call this a workaround at most, because I actually want to turn off the WLAN module when I use Ethernet. Also, I really have no idea or found a connection between receiving data from the HM-300 and the WLAN module, I could imagine that the entire program flow is disturbed by the error when setting the WLAN mode, but this is only a vague assumption.

An important side info maybe, it is not important if the chip is connected to any network. the main thing is that it is active. Also an access point does not have to be created.

[tbnobody]

I will double check this at the weekend with my own hardware. Imho it was working without problems at @klahus1
The Hoymiles lib does not contain any checks regarding connection state when receiving packages. The only check which is included is regarding the time. But in this case the no request packet is sent. But in your case, request packages are sent but you don't receive anything.

[Ascendor]

Hey guys, i fixed this issue.

Awesome, @morzan1001! Do you have a version/fork to test?

[morzan1001]

Hey guys, i fixed this issue.

Awesome, @morzan1001! Do you have a version/fork to test?

No yet, i am hoping that @tbnobody will invastigate that further and maybe come up with a sollution 🥇 . For now you can just change WIFI_MODE_NULL to WIFI_MODE_STA here and here.

[tbnobody]

Was für ein Olimex Modul verwendet ihr genau? Und betreibt ihr es mit oder ohne POE?

[Ascendor]

Ich nutze das Olimex ESP32-POE-ISO-EA-IND ohne POE.

[Ascendor]

Vielleicht noch mal als Ergänzung/Klarstellung:
Bei mir ist der Effekt auch da, wenn ich NICHT Ethernet, sondern WiFi verwende:

1. Perfekte DTU-Verbindung (ich kann jede Sekunde einen Messwert bekommen)
2. Nach exakt 180 Sekunden: DTU-Verbindung wird erheblich schlechter, nur alle paar Minuten kommen Daten rein
3. Abspeichern der Netzwerk-Settings, weiterhin Wifi-Nutzung!
4. go to 1.

[morzan1001]

[English version below]

@Ascendor wenn du dein Olimex Board sowieso mit WIFI benutzt, dann könntest du die Ethernet-Schnittstelle auch einfach deaktivieren. In der platformio.ini kannst du hier die Umgebungsvariable rausnehmen, dann sollte der WLAN Chip automatisch in den richtigen Mode gesetzt werden.

@tbnobody Ich nutze das Olimex ESP32-POE-ISO Board. Ich verwende Ethernet für eine Netzwerkverbindung aber kein POE, Strom kommt aktuell noch via USB.

[English version]

@Ascendor if you use your Olimex board with WIFI anyway, then you could just disable the Ethernet interface. In the platformio.ini you can take out the environment variable here, then the WLAN chip should be set to the right mode automatically.

@tbnobody I use the Olimex ESP32-POE-ISO board. I use Ethernet for a network connection but no POE, power currently comes via USB.

[Ascendor]

Ich nutze WiFi aktuell nur, weil es stabiler läuft. Ich möchte schon auf Ethernet setzen, wenn es geht.

[Sprinterfreak]

What would be interesting is if Wifi itself is the actual cause.
NRF24 and Wifi 2,4 use the same frequencies and inadvertently interfere.
Usually Wifi reduces data rates on interference to sustain successful connections and with this disturbs the band even longer. If Wifi syncs relatively high data rates in the beginning, it then starts slowly decreasing it after it learned lots of noise in the first 2 minutes. With that it also blocks the band longer for transmission and with that causes more loss on the NRF transmissions which of course results in more re-transmits which causes Wifi to reduce it's rate further down.

I also bet that the usual NRF24 clones also emit noise from high power stray wifi signals, overloading the non-shielded hf amplifiers on the modules. This causes disturbed echoes from wifi signals re-brodcasted by the NRF modules which make the wifi signals even more unrecognizable. I guess the slower the wifi data rate, the more likely it becomes for the stray power to hit the tuned freq/rates of the NRF causing it to transmit more rogue noise.

If this is the case, shielding should help. Also placing the concurrent hf amplifiers as far as possible apart from each other is always a good idea.

[tbnobody]

I've just created a small test installation:

• ESP32-POE-ISO Board
• Power via USB
• Ethernet connected
• Cheap NRF24 module (https://www.amazon.de/gp/product/B07VQ838KT/)
• RF Power is at Minimum (-18dbm)
• Module is located in the cellar, inverter somewhere in the garden

--> No Problems in ethernet mode

After the grace period the internal wifi will be disabled as well, and I am also seeing these warning:

Admin mode disabled
E (534789) esp_netif_lwip: esp_netif_new: Failed to configure netif with config=0x3ffb2700 (config or if_key is NULL or duplicate key)
E (534791) esp.emac: esp_eth_mac_new_esp32(595): alloc emac interrupt failed
[529860][E][ETH.cpp:270] begin(): esp_eth_mac_new_esp32 failed

But there is no effect on the function.

I would guess it's an hardware issue on your side. Either the power supply is not sufficient or creates ripples or something different. It may work under some cercumstances but seems to fail when e.g. more or less power is drawn (by changing the wifi mode e.g.).

I know that is no satisfying answer, but it's working here so I would guess no issue in the source and ESP framework.

Another question:

• What's your current RF power level?
• Does your ethernet network and your wifi network belong to the same subnet?
• What is your current poll interval? I would not set it below the default of 5 seconds as it will maybe block some other actions (and you wrote you receive data every second so you must have set this to a lower value)

[Ascendor]

Thank you so much for taking the time and effort to test it.
I agree it's most probably a very specific hardware issue.

• What's your current RF power level?

Minimum / -18, but I can reproduce it at any level

• Does your ethernet network and your wifi network belong to the same subnet?

yes

• What is your current poll interval? I would not set it below the default of 5 seconds as it will maybe block some other actions (and you wrote you receive data every second so you must have set this to a lower value)

I've only set it to 1s in order to make the issue more visible. When clicking save you can see the live view to update every second right away. With 5 seconds interval, you have to wait 10-20 seconds to be sure, because a single request can always fail I guess.

But, as above: It can also bei reproduced with every other interval setting.

Note, since you only refer to testing with Ethernet plugged in: I see similar behaviour with using WiFi as well.