remote reboot ?

[izharm]

is there a way to remotely reboot the device, maybe using the REST API ? I need to be able to remotely reboot the devices until the MQTT reconnection issue (#436) is fixed.

thanks,

[ServerCare]

using putty (or another telnet client) you can issue commands:
https://github.com/xoseperez/espurna/wiki/Terminal

I believe reset does what you want.

[xoseperez]

You can also use the (undocumented) RPC entry point:

curl "http://<ip>/rpc?action=reboot&apikey=<apikey>"

[myounges]

Hello,

Thanks for the reboot info, I have trying different ways of sending this command you mention above and I didn't get it to work.

If you copy paste it on a browser without the curl command I get a "Access denied" if I use curl I don't get any message but the reboot does not happen.

IF I state my credentias --user user/pass it seems to be ok but still no reboot happens.

Any help or ideas?

Thanks Xose!

[myounges]

Nevermind, it seems to be the sonoff I was testing against, seemed to be unresponsive, after power cycling it the command seems to work. For some reason since the last two months or so all these sonoff with espurna installed become responsive randomly.

Here are the symptoms:
Not receiving no MQTT commands nor sending back stats.
I can see the Node-red is up and processes all working.
If i restart mossquitto service on the broker sometimes it becomes responsive again (usually it doesn't as if this happens, other sonoff work neither), if it doesn't I am forced to power reboot the sonoff and fixes the issue.

I will try to create a crontab to reboot all sonoff at home every night just to confirm if they stop this behavior.

If you need logs when the sonoff stalls or think of other tests I can do to reprodice the issue I'm happy to help.

All the best,

[xoseperez]

Yes please, if you happen to find an unresponsive device again try logging into it (telnet or web debug) and check the debug log while sensing an MQTT command or an API request.

[myounges]

Hello,

Yes sure happy to help. In my humble opinion I feel that when I reboot the router wierd things happen like devices that are not reachable. I rebooted the router as part of some troubleshooting and a device that was working, became unresponsive not even to ping.

I had to unplug it to get back to it as Telnet or Http was not working. Once is back up there are no logs I can think of to provide to you a part from rebooting the router again just to confirm if another device enters in that state which are not registering their IP (which is a fixed IP address not DHCP).

I checked flash.dump and crash logs but nothing there apart from Last reset reason: Power on. Is there any post-morten commands I can run once I detect the problem?

Some info if it helps...

[143796] [INIT] ESPURNA 1.13.0
[143796] [INIT] [email protected]
[143796] [INIT] http://tinkerman.cat

[143796] [INIT] CPU chip ID: 0x71D786
[143797] [INIT] CPU frequency: 80 MHz
[143801] [INIT] SDK version: 1.5.3(aec24ac9)
[143805] [INIT] Core version: 2.3.0
[143808] [INIT] Core revision:
[143811]
[143812] [INIT] Flash chip ID: 0x14405E
[143817] [INIT] Flash speed: 40000000 Hz
[143818] [INIT] Flash mode: DOUT
[143822]
[143823] [INIT] Flash size (CHIP) : 1048576 bytes / 256 sectors ( 0 to 255)
[143833] [INIT] Flash size (SDK) : 1048576 bytes / 256 sectors ( 0 to 255)
[143837] [INIT] Reserved : 4096 bytes / 1 sectors ( 0 to 0)
[143846] [INIT] Firmware size : 462224 bytes / 113 sectors ( 1 to 113)
[143852] [INIT] Max OTA size : 561152 bytes / 137 sectors ( 114 to 250)
[143859] [INIT] EEPROM size : 4096 bytes / 1 sectors ( 251 to 251)
[143866] [INIT] Reserved : 16384 bytes / 4 sectors ( 252 to 255)
[143873]
[143874] [INIT] EEPROM sectors: 251, 250
[143877]
[143878] [INIT] BOARD: ITEAD_SONOFF_BASIC
[143882] [INIT] SUPPORT: ALEXA BROKER DEBUG_SERIAL DEBUG_TELNET DEBUG_WEB DOMOTICZ HOMEASSISTANT MDNS_SERVER MQTT NTP SCHEDULER TELNET TERMINAL THINGSPEAK WEB
[143897]
[143897] [INIT] Last reset reason: Power on
[143900] [INIT] Settings size: 1025 bytes
[143905] [INIT] Free heap: 21560 bytes
[143908] [INIT] Power: 3136 mV
[143911] [INIT] Power saving delay value: 10 ms
[143914]
[143915] [WIFI] ------------------------------------- MODE STA
[143921] [WIFI] SSID mine
[143923] [WIFI] IP 192.168.1.25
[143926] [WIFI] MAC 5C:CF:7F:71:D7:86
[143930] [WIFI] GW 192.168.1.1
[143933] [WIFI] DNS 192.168.1.1
[143935] [WIFI] MASK 255.255.255.0
[143938] [WIFI] HOST http://PL0-LR-LIT.local
[143943] [WIFI] BSSID 30:B5:C2:C9:71:92
[143946] [WIFI] CH 10
[143948] [WIFI] RSSI -80
[143951] [WIFI] ----------------------------------------------

crash
[707792] [DEBUG] No crash info

[myounges]

Just did another test, disabling the wifi of my router for a couple minutes.
All Sonoff switched to AP mode and started publishing their WIfi.
Switched back the wifi on and all sonoff (10 devices) started connecting back to the default wifi. No problems detected. :(

The only problem that caught my eye is that in the process one of the sonoff the uptime was 10 minutes which shows it rebooted... Not sure if it has some realtion with the problem..
Collected the logs if it sheds any light.
[641784] [DEBUG] Latest crash was at 10086 ms after boot
[641785] [DEBUG] Reason of restart: 3
[641787] [DEBUG] Exception cause: 4
[641788] [DEBUG] epc1=0x40215520 epc2=0x00000000 epc3=0x00000000
[641791] [DEBUG] excvaddr=0x00000000 depc=0x00000000

The info command shows the last reboot reason:
[897081] [INIT] Last reset reason: Hardware Watchdog

Will keep testing not sure if anyone this could be helpful to connect the dots or it is not related at all.

Cheers,

[myounges]

Hello,

Me again, one of the tests I did was disabling the wifi on the router, rebooting the router (basically ways to simulate wifi cuts to force this unresponsiveness reported). One of my sonoff Touch 2 gang became unresponsive at all, not responding to ping so there is no way I can think of to collect info of what state the sonoff is a part that if you touch the sonoff it still switches the relays. BUT if you look at the LED state it was flashing as if it was connected to the wifi (long period off and then a brief led flash), but if you ping the device it appears as host unreachable.

This makes me assume that the sonoff thinks it is connected successfully and does not try to reconnect even thought it is not. Rebooting the router several times (just to see what happens), eventually made it connect back to the wifi correctly. With this I feel there is some problem with the wifi library that is not reconnecting correctly.

Would be great if someone could reproduce this issue to confirm this or there is something else going on in my network I'm not aware of.

[ServerCare]

Just wanted to chime in to share an observation that may or may not be related. I switched some of my devices from DHCP to fixed IP and it completely messed up my aruba controller (using aruba ap's & controller). It was confused about the mac addresses; it was still assigning the 'old' dhcp ip addresses to the mac addresses. This messed up the arp table, so I could no longer ping my devices, even though the sonoffs seemed to connect to wifi just fine (just like you described)

Frankly I'm unsure what is the root case of this, and I am tempted to point at the aruba controller. However... take a look at your arp tables, maybe something similar is happening to you

[myounges]

Thanks for your comment, that sounds like a good place to start.
Checking I have no rules set in iptables and arp is showing all devices correctly. (haven't confirmed MAC addresses are the right ones but looks good.)
I can change the fixed addresses to DHCP to see if I can reproduce the problem again. Actually I was running out of ideas to test. Will get back once this tested.
cheers,

[myounges]

Usually there is this one sonoff losing the connection all the time and just happened again and of course the arp shows as the device is not available...

? (192.168.1.22) at "incomplete" on eth0

[myounges]

I have been doing some teat configuring the DHCP on all devices, So far I still got some issues with Mqtt not reaching the device, so far I haven't seen devices not reachable via ping, but I would say it is early to discard that problem.
Will keep you posted.

[myounges]

Just for the sake of updating this post, I think I may have found the issue to the problem at issue #803.
Still testing for three days and no issues so far which is a great improvement from where I'm coming from.

[0hax]

Would it be possible to add a feature which would automatically reboot the device if MQTT connection is down for more than a selected timeout?

[mcspr]

ref. #2417

Would it be possible to add a feature which would automatically reboot the device if MQTT connection is down for more than a selected timeout?

dup of #1550