Closed ropemaster closed 7 years ago
What version are you using. Does changing wificonfig to option 4 help to eleviate the problem?
How many devices are connected to the access point?
I will check ver. when back home. With the Sonoffs, I have 6-7 devices sitting at the AP. The AP could also be configured to act as a extender, if that would help, but it really shouldn't matter, I guess.
I mean all devices (not just sonoffs). Look at the client list of the access point.
are you still having problems with this?
Sry bout that - got called on duty. Problem still remains. They loose connection every now and then. The AP is configured as an extender and has 7 devices connected (not just Sonoffs) 1 Sonoff was back on and the info looks like this:
Sonoff
Basic Module
Sonoff-PC
Program version 3.9.14 Build Date/Time Feb 15 2017/14:29:55 Core/SDK version 2_3_0/1.5.3(aec24ac9) Uptime 475 Hours Flash write count 132 Boot count 41 Reset reason Software/System restart Friendly name 1 Sonoff-PC
AP1 SSId (RSSI) NETGEAR (36%) Hostname sonoff-4282 IP address 192.168.1.101 Gateway 192.168.1.1 MAC address 5C:CF:7F:95:90:BA
MQTT Disabled Emulation Belkin WeMo mDNS Discovery Enabled mDNS Webserver Advertise Enabled
ESP Chip id 9801914 Flash Chip id 1327328 Flash size 1024kB Program flash size 1024kB Program size 452kB Free program space 484kB Free memory 16kB
I wonder why the signal is at 36%, as the Sonoff is less than 3 feet from the AP. The Sonoff is in a plastic box made for electric connections, for safety, but a 60% drop in signal seems a lot? Any tips on how to improve the stability is greatly appreciated :)
that's 36% of theoretical maximum, and it is low enough to cause problems. But that also assumes that your repeater is transmitting at full power
is your repeater using the same channel/ssid for both the connection to the main network and the local network it's providing? If so, that's always going to be a poor quality connection (I could go into all sorts of technical details on this, hidden transmitters, etc, contact me separately if you want to go into those sorts of details)
David Lang david@lang.hm
On Sun, 19 Mar 2017, ropemaster wrote:
I wonder why the signal is at 36%, as the Sonoff is less than 3 feet from the AP. The Sonoff is in a plastic box made for electric connections, for safety, but a 60% drop in signal seems a lot?
Or maybe problems with WiFi antenna on sonoffs. I got 3 ( basic model ) and today ( after a few weeks of work ) one died ( RSSI 8% ). I put another one in the same location and RSSI shows 40% and is working fine. This broken is working fine but with case removed in front of router RSSI shows 50%.
Any further info on this?
I change some setting on the wifi. Went from an AP to Extender. This seems to have solved the problem. Also removed the DHCP option from the AP. Since this, it seems stable and it would seem that it was not the Sonoff´s failing, but the wifi. I have no fughter - ty for the advice and the help :)
Well, I am struggling with this problem too. I noticed it about 2 weeks ago since then I reflashed several times with different config options. I can access the web interface where it shows 8% Wi-Fi Signal Strength where before it was about 47%.
Program version 4.1.2 Build Date & Time 2017-04-08T19:33:08 Core/SDK version 2_3_0/1.5.3(aec24ac9) Uptime 1 Hours Flash write count 285 Boot count 109 Reset reason Software/System restart Friendly name 1 Sonoff AP1 SSId (RSSI) LARAA (10%) Hostname sonoff-3593 IP address 192.168.1.111 Gateway 192.168.1.1 Subnet mask 255.255.255.0 DNS server ---.---.---.--- MAC address 5C:CF:7F:95:EE:09 MQTT Host 192.168.1.105 MQTT Port 1883 MQTT Client & Fallback Topic DVES_95EE09 MQTT User mqtt-user MQTT Topic sonoff MQTT Group Topic sonoffs Emulation None mDNS Discovery Enabled mDNS Advertise Webserver ESP Chip id 9825801 Flash Chip id 1327328 Flash size 1024kB Program flash size 1024kB Program size 464kB Free program space 472kB Free memory 27kB
The funny thing I have a custom device build on ESP8266 chip connected to the same AP that is 2m further from Sonoff and it never hangs or lost signal (based on MQTT monitoring)
I have the same issue. Both my sonoffs ( basic ) suddenly lost WiFi connection. In place where they worked RSSI was about 40% and after a few weeks - no WiFi connection. When I put them in front of WiFi router both showed RSSI about 50%. And 4m away from router signal drops to 20%.
it sounds like there is probably something defective in those units (a cold solder joint on a capacitor or similar)
do they work in the same location when powered by 3.3v?
kkk
I assume it's something related to Sonoff hardware. Perhaps the chip is under current provided by the circuitry. As I mentioned I have my other ESP8266 chip that is powered by an Li-Ion battery and it picks the signal flawlessly.
probably, we have seen similar reports from some other users from time to time. check for bad solder joints on the board, a poor connection to a capacitor could cause this sort of thing
The same issue when powered from 3V3 ( RSSI 50% when 1m from router )
I had wifi issues, but the cause was that I had the sonoff flat on the floor. As soon as I lifted the sonoff, wifi reception came straight up. I guess the son off antena is pointing towards the bottom of the device and it gets blocked if placed on a non transmitting surface.
So, has anyone come up with a resolution for this issue?????
I have 9 out of 10 Sonoff Basic(s), that started performing, as discribed above. 4 of the SB's are 4 months old and have their original Firmware and were working OK. 6 are about 3 weeks old, which I have updated to "ESP Easy Mega 2.0.0 dev 11, normal 1Mb".
1 of the first 4 SB's, is still working but on the edge. What I mean by "On The Edge", I can turn it On & Off, a couple of times, then it goes OFFLINE. Eventually, it will come back Online, and this SB is only 10 feet away from the Router.
If more Info is needed, let me know.
what shows up in the log?
He's not using Tasmota. He uses ESP Easy and EWElink.
what shows up in the log? " Nothing in either, the HASSIO or the MQTT(add-on).
He's not using Tasmota. He uses ESP Easy and EWElink." The first 4 Sonoff Basic(s), are running on there Original Firmware, ver. 1.5.
If you aren't running tasmota, we can't help you here. You will need to work with whoever wrote the firmware you are running.
I am having a similar / perhaps even the same issue. I have 2 Sonoff-Basics, 1 Sonoff dual, 1 Sonoff POW, all with the latest release of Tasmota. (Another 10 basics and 4 Duals being shipped).
All 4 installed units keep losing connection.
I installed Grafana to try see what is going on by logging the RSSI value (using MQTT), and the network connectivity (using openHAB network Binding) openHAB is logging RSSI change and Network Online/Offline status.
What I see is that the RSSI stops reporting...I suspect MQTT loses comms, 20 Minutes later the network pig fails. The button can still be used a few times to operate the relay, but is erratic. Sometimes there is a 3 to 5 sec delay between button press and relay operation for 2 or 3 presses. Then suddenly there is no delay for subsequent presses. (One of the posts I read indicates that this could be a wifi that is available, but cannot be connected to??) The dual seem to confirm this as its light flashes for a bit, then goes off, then flashes again, repeating the cycle over and over. The Web interface is not reachable. Connectivity is only restored by cycling the power to the Sonoff.
Once power is restored, the Grafana RSSI graph shows further oddities. The RSSI of the restarted device stays at 100% whilst the device a few feet away shows varying RSSI. About an hour or 2 later, the recycled device's RSSI updates then seem to normalise and follow the patterns of the other devices. For the month prior to flashing the devices with Tasmota, I did not notice these connectivity issues. (Perhaps the issue did exist, but the connectivity was restored automatically? I cant say).
I will share my Grafana graphs and Tasmota configs later today when I get home. (I will try the settings mentioned above, above a bit later in the week once I have a better view of the graph results.)
Further research has found that folks are experiencing the same issue with standard (unflashed) Sonoff switches. See Itead link below. http://support.iteadstudio.com/support/discussions/topics/11000000747/page/2?url_locale=
I have a stock NodeMCU esp12-e board that I will also flash with Tasmota tonight to see if the same phenomenon exists. When I ran Souliss on this board, it did not give me these problems, so could be a good test to see if I am battling Tasmota configs, or faulty Sonoff switches.
Thanx ScottyDS for sharing your experience. Based on my own experience with faulty Sonoff, I just had to change my faulty with another Sonoff that happens to be faultless for about 6 months. As someone mentioned in this thread, the issues can lie in a cold join. I've tried to fix by myself but I couldn't find any cold join so I just change it for another Sonoff.
I have seen this issue with original Itead Firmware on 4 of my Sonoff Basic's that have been running for several months. And 6 Sonoff Basic's which I have changed to the latest ESP Easy firmware, which worked fine for about 3 weeks. Both sets went south at the same time. I have noticed that 2 of my Amcrest Wireless Cameras, are also losing the wireless connection. I am trying to locate someone that has a RF analyzer, to see if I may have a Higher then normal level of RF Noise, in my house. As soon as I get the results, I will publish my findings...
the delay to local control when mqtt is down is a known problem. The Arduino TCP library has a bug that when something is in the middle of establishing a connection, nothing else can take place, including local actions.
@davidelang 👍 Thanks David, I do believe it was one of your other posts that I had read that explained this. It is also why I am really intrigued by the issue.
Thanks for the other replies folks. I was having a hard time believing that all 4 units could be dodgy, but the more I read, the more I am starting to think that I may have to re look at my Sonoff strategy. But before I do that, let me first apologise for the long post, and then share a more detailed experience.
Here are my graphs for 2 of the devices that I started logging yesterday.
The red text was maybe not a good idea so here are the comments for each of the arrows.
This morning both devices had lost comms, and this evening all 4 devices had lost comms. (I plugged 2 more in before I left for work this morning.)
I must say, I am a tad disheartened by the instability / unreliability of the devices. I have a flat roofed house, with no access into the ceiling so cannot monkey about with wiring without major renovations. The Sonoff solution would have been ideal, if only for its convenience factor.
Here are the details of the most problematic device. Any help / guidance / insight would be most appreciated.
Program Version | 5.8.0p |
---|---|
Build Date & Time | 2017-10-28T20:18:23 |
Core/SDK Version | 2_3_0/1.5.3(aec24ac9) |
Uptime | 2 Hours |
Flash write Count | 144 at F4000 |
Boot Count | 19 |
Restart Reason | Software/System restart |
Friendly Name 1 | JordansLamp |
AP1 SSId (RSSI) | ScottNetB (90%) |
Hostname | JordansLamp-7225 |
IP Address | 192.168.1.10 |
Gateway | 192.168.1.1 |
Subnet Mask | 255.255.255.0 |
DNS Server | 192.168.1.1 |
MAC Address | 5C:CF:7F:B4:FC:39 |
MQTT Host | 192.168.1.201 |
MQTT Port | 1883 |
MQTT Client & | DVES_B4FC39 |
Fallback Topic MQTT User | openhab MQTT Topic | JordansLamp MQTT Group Topic | sonoffs MQTT Full Topic | JordansLamp/cmnd/ | Emulation | None mDNS Discovery | Enabled mDNS Advertise | Web Server | ESP Chip Id | 11861049 Flash Chip Id | 1327198 Flash Size | 1024kB Program Flash Size | 1024kB Program Size | 450kB Free Program Space | 552kB Free Memory | 25kB
the quality of individual devices does vary, we have seen a number of them with bad solder joints on the 3.3v power supply, this makes the devices much less reliable. you can examine the bad devices, or you can just buy a few more and not bother with the bad ones (that's the beauty and problems of buying $5 devices)
I had problems with the loss of communication. The problem is not in the devices, but in the settings of the local network. I have a rather complex network structure. One of the problems was the support of IPV6
My problem is Solved!! @AlexTransit You were correct in that it is a local network issue. Since my last post,, in utter frustration I was trawling the Net for a solution, and chased many options, such as overheating of the Voltage regulator (Sonoff LED Issue), testing the different versions of Tasmota that I had downloaded over time etc, I could not believe that all 4 devices were exhibiting the same poor quality bug/issue.
Friday last week, I had "Fibre to the home" installed, and was provided with (according to numerous posts) a really bad ASKEY RTL0030VW LTE WIFI Router. Compared to my TP-Link TD-W8961N ADSL router, the Askey wifi signal was 10db lower at the same range. But to my surprise, all 4 Sonoff's as well as a Chinese clone NodeMCU 12-e are now rock solid. They no longer lose connection, and the eratic RSSI pattern is almost gone. Even with an RSSI as low as 8%, the Sonoff Basic stays connected.
Today, an extended power outage, and a subsequently corrupted SD card on the Pi, has messed up the graph stats that I wanted to share. I have since restored the Pi and will share the graphs in about 3 days time once a decent amount of stats have been collected.
Thanks for all the advice. My faith in the Sonoff product has been restored. Sad about the TP-Link though. I really need the range, but this is a problem to be solved another day.
Here is the graph that I mentioned above. As you can see the only device having some issues is the PoolLight switch. It is the further-est away (25 meters with 3 brick walls between it and the Wifi router.) It fails the openHAB, network binding ping quite often, but never loses connection to the point that it needs to be restarted. It sometimes takes a while to respond to an on/off command, but this is to be expected due to the intermittent network response. It has an RSSI average of 23, a min of 8 and a max of 28. When I move it 5 feet closer, the problem goes away.
Side Note: The low vcc, is a Node MCU loaded with Tasmota. Its regulator is damaged due to a supply voltage overload. But it still works and drives 2 relays perfectly.
one thing to consider is adding a directional antenna to the router if you can. Even a mild one will let you direct more signal towards the problem area (assuming you can afford to loose signal the other direction)
Im also having this problem on two of my sonoffs basics, I found once the drops occurred on either of the sonoffs I couldn't ping it throughout my network however I am using a raspberry pi as a dns server, I managed to ping the device without an issues while my other devices couldn't, as well as nmapping the ports successfully (port 80 was open) through the dns server however this failed on other machines.
I have a problem with my sonoff-basic, that is presumably caused by a faraday cage: My sonoff is placed inside a metal piece of a lamp. I will try to solve it by soldering a wire to the wifi antenna and let that out of the cage.
i just saw a youtube video about the wifi antenna wire solder, looks like it works for most. i will be trying that myself this weekend, will post results once i get to it.
@PrathikGopal Did you succeed?
@maciboy , it did not work infact it reduced the reception a little further below
I’m seeing this behaviour now within 5feet from the router
I put the Tasmota firmware on 3 different Sonoff a month back. All 3 are the standard Sonoff, single outlet, no temp or humid. After about a week thay all started failing in reaching the wifi. All 3 Sonoff are within 10 feet of an Acesspoint and all other devices are not having trouble, seeing the wifi. All devices have a static ip. There has been no changes to the the setup on Router, AP or Sonoff. Has anyone got the same problem or maybe a solution to try out?