BrewPiLess
BrewPiLess copied to clipboard
vitotai
4.0r1 still loosing wifi
The wifi issues from 4.0 that it looses the wifi settings seems to be fixed but it's loosing connection to the wifi intermittently. After rebooting it pops up on the network again.
You can see the straight purple line that shows SG when it looses connection 12th May and last night until now
I do copy that. Today after 5 to 6 days my little D1 lost again the wifi connection - Version 4.0r1.
Not sure if this is relevant for some reason but the wifi loss seems to happen at regular intervals
May 12th: 03:00:51
May 13th: 02:53:19
May 15th: 02:54:56
Time is GMT+2 (CET)
@Naesstrom does your BPL recover by itself? Mine just falls back to the address of the AP mode and stays there. I'm not sure if this is just a coincidence or in fact related. My problems with the wifi connection started soon after I enabled remote logging to ubidots on the BPL. As a next step I'll disable the logging again and see what happens.
What is your WiFi signal strength like?
According to the cmd output rssi -75. Could be better I know ...
-75db is not very good. It's similar to mine, which ranges from -80 to -73. Moreover, there are doors and windows between my fermenter and my AP, if I close all the doors and windows, my controller would lose network. You might have similar issues with mine.
Let me explain the design and the problems. Spoiler: I might not be able to help you. As the framework of Arduino/ESP8266 upgrades, the implementation of underlying WiFi changes. We don't have access to the WiFi implementation underlying. In the begging, I have to code to recover the network when lost. Then, after some version, there is a new function setAutoReconnect() that seems to do recovering from the underlying part of code. I changed to use that function. Unfortunately, the behavior changed after a few upgrades. I found ESP8266 will use all its resource to recover network if setAutoReconnect() is true and the network is lost, which results in issues of connection under AP mode. My solution is to try to recover for a while, say 10 seconds, and then wait for a period, say 5 or 10 minutes, to enable AP connection. It's not a very good solution, but is the only solution I can think of. The latest framework seems to introduce another problem, which the last update addresses. In previous version, the WiFi credentials is saved by the underlying WiFi library, but it seems that saved WiFi data would be lost for some unknown reason. Therefore, the latest modification try to save the network information, SSID and password, "manually".
If your BPL connects back to AP after some time, it means the new modification works as expected. Your lost of WiFi can't be solved by any software. Please be aware of it. When BPL loses WiFi connection, it will try to recover for a while. When recovering, AP connection is usually unavailable. If your iSpindel connects to BPL via AP mode, it would have trouble. If your iSpindel connects to the same WiFi network BPL connects to, still BPL is not connected when it loses the WiFi connection. That explains the blank period of iSpindel data.
Many thanks for your explanation. That explains a lot. My fridge is outside in garage at the moment and there are at least two walls in between to the AP. That explains of course the weak signal and the fact it cannot recover as you described. I was just surprised that it stopped working after a couple of days without any problem. Maybe I just had luck.
@Naesstrom does your BPL recover by itself? Mine just falls back to the address of the AP mode and stays there.
No mine just stays as an AP to until reboot!
What is your WiFi signal strength like?
Is that included somwhere in this?
12:38:5 ↑ output rssi
12:38:5 ↓ D:{"logType":"W","logID":1,"V":[111]}
12:38:5 ↓ D:{"logType":"W","logID":1,"V":[117]}
12:38:5 ↓ T:{"BeerTemp": 25.36,"BeerSet": 30.00,"BeerAnn":null,"FridgeTemp": 30.19,"FridgeSet": 30.00,"FridgeAnn":null,"State":0}
12:38:5 ↓ D:{"logType":"W","logID":1,"V":[112]}
12:38:5 ↓ D:{"logType":"W","logID":1,"V":[117]}
12:38:5 ↓ T:{"BeerTemp": 25.36,"BeerSet": 30.00,"BeerAnn":null,"FridgeTemp": 30.19,"FridgeSet": 30.00,"FridgeAnn":null,"State":0}
12:38:5 ↓ D:{"logType":"W","logID":1,"V":[114]}
12:38:5 ↓ S:{"mode":"p","beerSet": 30.00,"fridgeSet": 30.00,"heatEst": 0.000,"coolEst": 3.453}
Should be good, have a unifi outdoot AP just a few meters away and not much blocking the signal!
@vitotai maybe one more question. I don't use the local AP mode for the time being. What happens if I config the BPL for just station mode and the wifi signal gets too weak? Does the BPL just keep trying to reconnect?
We can use a board with better WIFI antenna like Wemos D1 mini Pro if WIFI signal is weak
Many thanks for your hint. I was just about to google in how to improve the wifi reception of a D1 :-)
@vitotai maybe one more question. I don't use the local AP mode for the time being. What happens if I config the BPL for just station mode and the wifi signal gets too weak? Does the BPL just keep trying to reconnect?
Entering AP mode when failed to recover is intentional, so that we have access to the controller. In latest version, the controller should keep recovering network.
Instead of a D1 you can use a ESP07 with external antena
El sáb., 16 de mayo de 2020 12:48, vitotai [email protected] escribió:
@vitotai https://github.com/vitotai maybe one more question. I don't use the local AP mode for the time being. What happens if I config the BPL for just station mode and the wifi signal gets too weak? Does the BPL just keep trying to reconnect?
Entering AP mode when failed to recover is intentional, so that we have access to the controller. In latest version, the controller should keep recovering network.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/vitotai/BrewPiLess/issues/235#issuecomment-629665995, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXBW4OF26QI5IY7AS3JOWLRR2YUJANCNFSM4M7SXFNA .
@lalo-uy thanks for the hint. Next time that could be really an alternative. For my actual situation the D1 pro would be the better solution cause that one is pin compatible and I can just swap the modules.
I'm curious to know what signal level would prevent the disconnects? I've flashed my two brewpiless controllers back to 3.5.1, because I found 4.0r1 too unstable (would disconnect at least once per day, sometimes several times per day, and not recover). When my controllers are connected, they are showing signal levels between -58 and -63.
-58 ~ -68 should be relative good. I am now considering roll back to old framework, which seems to behavior better.
I'm curious to know what signal level would prevent the disconnects? I've flashed my two brewpiless controllers back to 3.5.1, because I found 4.0r1 too unstable (would disconnect at least once per day, sometimes several times per day, and not recover). When my controllers are connected, they are showing signal levels between -58 and -63.
Sounds like what I've been experiencing, atleast once a day it disconnects and WiFi shouldn't be an issue! I'm ready to test a 4.0r2 @vitotai if you change the framework!
The whole story is strange. I went back to 3.6 something for a short period and now I'm running 4.0r1 again. This one is stable since a couple of days with a short interrupt yesterday where it recovered automatically. RSSI levels are alway above -72 in my case which is bad as we know ...
I actually can't find the way to store wifi credentials. Everything is good until router or BPL reboots. Only AP mode and entering new options works...
uploaded a trial version, which I am trying. You might try if interested. It takes time to verify this issue. (Mine lost after over 10 days for 4.0r1)
I will try, of course. Unfortunately, only v2.6 works great for me.
On Wed, Jul 1, 2020, 06:02 vitotai [email protected] wrote:
uploaded a trial version, which I am trying. You might try if interested. It takes time to verify this issue. (Mine lost after over 10 days for 4.0r1)
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/vitotai/BrewPiLess/issues/235#issuecomment-652175777, or unsubscribe https://github.com/notifications/unsubscribe-auth/AP6SPK43EEELWNMOEHWPR4LRZKYNNANCNFSM4M7SXFNA .
This is what is happening after I try to save wifi credentials. Will see how long it works and let you know.
Or, to try something else? How can I wipe device memory, totally? I tried something with some empty bin files according to one post from your forum's thread but I'm not completely sure it worked.
One more thing could be noticed, too. Only when I use v2.6 BPL shows itself as "brewpiless", otherwise as on screenshot below.
Some news from me... it seems that newest version remembers wifi setting. I lost wifi and internet for half an hour at least and BPL connected successfully after fixing. But (always but) there is another issue now, time and temperature difference on graph, and left and right side of screen. Screenshot below.
The chart data is logged every MINUTES, while the data shown on left is updated every 5 or 6 seconds. It's normal to have different values.
Regarding the time, we don't have RTC on board and relying on time server for correct time. SNTP seems to fail after some version, I will need to check this.
You might try start a log, and then stop to see if the time synchronizes.
Some more news from here. It seems that BPL actually "remembers" wifi data but can't reconnect if wifi signal is lost, router rebooted or whatever reason. After restart it connects automatically and I don't have to enter wifi data again in system config.
I'll have to use some kind of smart socket for it so I'll be able to reboot it remotely.
EDIT: have you guys tried to use other port than 80? 80 is "taken" by router and I can't change access management settings on it.
@Naesstrom does your BPL recover by itself? Mine just falls back to the address of the AP mode and stays there. I'm not sure if this is just a coincidence or in fact related. My problems with the wifi connection started soon after I enabled remote logging to ubidots on the BPL. As a next step I'll disable the logging again and see what happens.
Mine reboot in loop after activating log to thingspeaks.com :(
