Scheduled restart? #803
Comments
|
For some reason, one of the devices decided to use it's hostname as AP name, instead of ESP_* Is this related to the issue? Devices are all Sonoff's:
And after every week mileage varies, most times, atleast 2 devices have lost their connection. |
|
It's a good idea but it's also very bad news you are having all these troubles with all (?) of your devices. There must be something going on. One question: if I understood you correctly, you can still connect to the device's own AP, right? Have you noticed if it was running in safe mode? What was the uptime of the device? |
|
I can connect almost all devices apps. From list shown, 3 were in state that they refused the connection.
Lähetetty iPhonesta
… On 23 Apr 2018, at 10.46, Xose Pérez ***@***.***> wrote:
It's a good idea but it's also very bad news you are having all these troubles with all (?) of your devices. There must be something going on. One question: if I understood you correctly, you can still connect to the device's own AP, right? Have you noticed if it was running in safe mode? What was the uptime of the device?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Most propably in sade mode because they are named ESPxxxx - if I remember correctly, they should use hostname from settings as name.
Didn’t check uptime. I recompiled new firmwares with platform.io and chose newer esp-idf, now they use core version 2.4.0 - we will see at weekend if my effort was productive.
Lähetetty iPhonesta
… On 23 Apr 2018, at 10.46, Xose Pérez ***@***.***> wrote:
It's a good idea but it's also very bad news you are having all these troubles with all (?) of your devices. There must be something going on. One question: if I understood you correctly, you can still connect to the device's own AP, right? Have you noticed if it was running in safe mode? What was the uptime of the device?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
If the problem regarding connectivity persist, a schedule for reboot is a must. +1 |
|
@oskarirauta Do you still have this connectivity issue? I had a Belkin wemo switch before that would not connect to my wifi network. I changed the wifi mode from 802.1n only to 802.1g/n mixed and it started connecting. I don't know what your wifi router settings are, but if it is restricted to "n" then, perhaps try changing the mode to "g/n" or even "b/g/n" to determine whether it is a compatibility issue. Not all wifi routers are built the same. |
|
I got issue worked out by compiling against newer Core version.
… On 15 May 2018, at 14.49, law1964 ***@***.***> wrote:
@oskarirauta <https://github.com/oskarirauta> Do you still have this connectivity issue? I had a Belkin wemo switch before that would not connect to my wifi network. I changed the wifi mode from 802.1n only to 802.1g/n mixed and it started connecting. I don't know what your wifi router settings are, but if it is restricted to "n" then, perhaps try changing the mode to "g/n" or even "b/g/n" to determine whether it is a compatibility issue. Not all wifi routers are built the same.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#803 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABRSHpKoFigNlKedo5PysfTf58OBqlEOks5tysDigaJpZM4Td-12>.
|
|
@oskarirauta Can you confirm it was due to Core 2.4.0? 2.4.1 works fine for you? What lwIP version you compiled against? |
|
Unfortunately at the moment, I cannot confirm (away from site) - But I did not upgrade or change a lot, at platform.io <http://platform.io/> there was version that enabled 2.4.x which I uncommented. It seemed that I was using pretty outdated stuff before that. Since then, my devices have been running very smoothy :)
Otherwise, with firmware compiled against this newer core version- shows promising results, days of my troubles seem to have passed- they have been running for few weeks now without any issues.
… On 16 May 2018, at 0.58, Xose Pérez ***@***.***> wrote:
@oskarirauta <https://github.com/oskarirauta> Can you confirm it was due to Core 2.4.0? 2.4.1 works fine for you? What lwIP version you compiled against?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#803 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABRSHrSgISYCJPkw0EOKtFjkOElgN5wQks5ty091gaJpZM4Td-12>.
|
|
Hello, My two cents on this topic, I have been experiencing random disconnects from the network of my sonoffs (Basic and Dual), pretty much as mentioned on this post. I opened a post about this back in the day and we tried different test but the problem was still there. I use my sonoffs via MQTT with node-red, usually these sonosffs stopped being visible for the mqtt broker, if you try to logon to it "sometimes" it would be reachable, and the the fix was easy restart the mqtt service to force the sonoff to be visible again, in the case it is not reachable (not even to ping), restarting the router seemed to sort the problem. For some reason there are some sonoffs in my house that happen to hang more often than others i assume this would be related to the wifi coverage, but just guessing. After reading this post I updated a few of the sonoffs I had to core version 2.4.1 from 2.3.0 with espurna 1.13.1 as @oskarirauta mentioned earlier. will be happy to provide more input. So far these changes have been running for two days with no issues which is already promising as I never went through two full days without an issue. If there is something you would like me to test just let me know. Thanks @oskarirauta for the tip! |
|
Closing via #2417, impl. changed to use terminal commands |
I STILL have connectivity issues - every week, multiple devices loose connection to access points and they never re-connect.
One of these devices (POW) is in proximity of 3 meters from access point. And it seems - that more you use the device (switch on and off) - more often this happens. This POW I mentioned is used to control power outlet which is used by my spouse to pre-heat her car, and because it's still cold, this is every day. I have scheduled it, but this schedule is elsewhere, it's done with home assistant, because I have created a script, that turns pre-heating off always after it has been on for 3 hours, even when started manually with the button.
When device has lost this connection, I can connect to AP created by device itself, and press either re-connect, or reboot and then it's possibly usable again. Most of the times, reconnecting only renders device to not connect to Wifi, and to not make AP either (in this case, I need pull the fuse to manually restart it).
Anyway, as this seems to be very difficult to debug or replicate according to previous conversations ( at the old site ) - I have come to think about a work around solution for this.
Now when there's scheduling-
Could we get some more options? Instead of controlling relay, I'd like to control the device itself, and here are my ideas about missing options that possibly could solve my issue...
And we have discussed about this issue before- there's some sort of automatic functionality that re-connects to chosen AP after loss of connection/error/etc... I have been trying to find that part of code to see if I could do something about it (probably not, you seem pretty capable), but could you give me some pointers to the code, where are located following parts:
Thanks :) Still, even though I have these issues; great work, this is most certainly the best firmware available :)
I have included a screenshot of available wifi AP's after 5 days ( I drive a truck, so I am not at home at the week, and idea is that I have control over my devices through VPN from distance )
As you see, most devices are once again in the state of self-AP.
The text was updated successfully, but these errors were encountered: