Thanks for Your response. However, I do not really understand what You mean or maybe my question has caused some misunderstandings. I have full access to the device via webbrowser. The device accepts my password and I can reboot the ESP using the web platform. So that is not my problem. My intention is to send a reboot command via HTTP, without logging into the web platform. If I remove the pwd from the ESP, it works fine with: "http:// /control?cmd=reboot", but of course not if the device is pwd protected. Google AI proposed the following: "http://admin: @ /control?cmd=reboot" but that doesn't work. Why do I want to send a reboot via http? It happens from time to time, that the device doesn't connect to the strongest wifi signal within my wifi mesh. A reboot normally solves the problem, but instead of logging in via web platform, I would like to send the reboot to the ESP from my ioBroker visualisation. And as stated before, that works, when the device ist not pwd protected. I hope this makes more clear what I intend to do.
Let's Control It forum
www.letscontrolit.com/forum ↗phpBB-forum in het Engels. 12 rubrieken gevolgd: ESP Easy Forum, uPyEasy Forum, ESP Easy: Projects / Applications, uPyEasy: General Discussion, uPyEasy: Projects / Applications, uPyEasy: Hardware, uPyEasy: Software, RPiEasy Forum, RPiEasy: General Discussion, ESP Easy: General Discussion, ESP Easy: Hardware en ESP Easy: Software.
- Discussies per dag
- 0
- Opgehaalde discussies
- 72
- Berichten per dag
- 52
- Rubrieken
- 12
- Gevolgde bronnen
- 15
- Software
- phpBB
Laatste discussies
Elke 4 uur opgehaald uit de openbare feed van het forum. Alleen de titel, de link en het begin van het bericht worden weergegeven; elke link wijst terug naar de bron.
I used built : ESP_Easy_mega_20260108_energy_ESP8266_4M1M Jan 8 2026 Same devices, same controllers, same rules. Without any problems. So this issue is cleared (but I do think the beta built) caused te problems. Anyway, thanks for yr help.
You could try to make it crash... For example trying to open lots of concurrent http-calls to for example fetch the JSON stream will likely cause it to crash. However, there is a chance it may 'just' loose network connection and remain unconnected (and thus inaccessible). Maybe if you disconnect it from your access point a few times, it could also start the AP mode, which maybe allows you to do a bit more, though I don't think in the January build there was any difference in how the external command source was being dealt with. (and still I don't think you're allowed to do stuff via AP mode, may have to check the code for this) To be honest, I can't think of any way how to do this if there wasn't already some provision for it in for example the rules.
Hi there, is it somehow possible to reboot an ESP32 device, protected with admin password, via HTTP command? http:// /control?cmd=reboot is not working due to admin pwd and gives back code 401 (not authorized). How can I pass the admin password via the http command? Currently running ESP_Easy_mega_20260121_normal_ESP32c3_4M316k Thanks Stefan
The data packets are faily long and might get "overwritten on air"by other sensors.
I tried with an old built [don't remember which] Used same devices and 1-wire devices. Same rules and then publishing started as expected. But I forgot to leave out the dz idx's. So tomorrow I'll try again.
Hmm not sure this would be a hardware issue, as the reboot reason apparently is a watchdog reboot. Could still be a hardware issue (or maybe power supply issue), as it does reboot quite quickly after a boot. But a watchdog reboot typically has other causes. Can you disable some tasks, to see if it will remain running? You can also give those commands via serial, like this: Code: taskdisable,1 to disable task #1. And "save" to actually save the settings.
Code: Logging: Info (2)00.225: ^^^INIT : Booting version: ESP_Easy_mega_20260922_normal_ESP8266_4M1M, (GitHub Actions) HEAD_868e279 (ESP82xx Core 3.1.2, NONOS SDK 2.2.2-dev(38a443e), LWIP: 2.1.3 PUYA support)00.226: INIT : Free RAM: 2761600.229: INIT : SW Watchdog #1210 - Restart Reason: Software Watchdog00.277: INIT : I2C Bus00.280: INIT : SPI not enabled00.512: EVENT: System#Wake02.877: EVENT: Trapgat_retour#temperature=21.504.074: WiFi : Set state from: STA_Scanning to: Disabled timeout: 10004.348: WiFi : Set state from: STA_Initializing to: STA_Connecting timeout: 1000004.347: WiFi : Set state from: Disabled to: STA_Initializing timeout: 10005.805: WiFi : Set state from: STA_Connecting to: STA_Connected timeout: 006.088: NTP : NTP replied: delay 7 ms round-trip delay: 7 ms offset: 00:00:03.57606.102: Webserver: start06.113: EVENT: Time#Set06.127: firstLoopConnectionsEstablished06.169: EVENT: WiFi#Connected06.186: EVENT: p2pNode#Connected=4,'Espvv_oud','20260922'06.202: EVENT: Trapgat_retour#temperature=21.500.222: ^^^INIT : Booting version: ESP_Easy_mega_20260922_normal_ESP8266_4M1M, (GitHub Actions) HEAD_868e279 (ESP82xx Core 3.1.2, NONOS SDK 2.2.2-dev(38a443e), LWIP: 2.1.3 PUYA support)00.223: INIT : Free RAM: 2761600.226: INIT : SW Watchdog #1211 - Restart Reason: Software Watchdog00.274: INIT : I2C Bus00.277: INIT : SPI not enabled00.509: EVENT: System#Wake00.637: EVENT: System#Boot00.642: ACT : looptimerSet,1,6000.648: ACT : LoopTimerSet,2,5500.655: ACT : LoopTimerSe
Ah yes, good one, looks like the 1-wire temperature measurement is taking up quite a bit of the available time, so it might be that the ESP is loosing connection with the MQTT broker and/or WiFi connection.
Assuming the last logging you sent is from a single session, there are at least 10 reboots during that session. After about 30 to 40 seconds into the boot sequence. The Interval for all these 1-wire tasks seems to be set to 1 sec., that's not very useful, and possibly a cause for these reboots, as those tasks all initiate a read from the 1-wire helper at nearly the same time, but I doubt if even 1 comes with a usable outcome. Suggestion: Start by setting the interval for each 1-wire task to a minimum of 10 seconds, possibly longer, as the interval you use to send data to Domoticz is at least 40 seconds (LoopTimerSet,5,40), and possibly try to achieve an interval that doesn't interfere with the other tasks (you can use prime numbers as the interval, 11, 13, 17, 19, 23, there shouldn't be too much overlapping measurement requests) Do you have other sensors/devices connected to this ESP? As that may also influence the timing available for the 1-wire tasks.
Hmm I also don't see these logs occur in what you posted. Can you try sending a command via either serial or the command field on the tools page: Code: event,Rules#Timer=5
thanks for your message. I followed up your advice but nothing I can see happen. Dus this log make sense to you? Code: 35.923: EVENT: Trapgat_aanvoer#temperature=22.035.935: EVENT: Trapgat_retour#temperature=21.535.948: EVENT: Serre_retour#temperature=21.535.958: EVENT: Huiskamer_retour#temperature=22.036.137: EVENT: Huiskamer_aanvoer#temperature=21.636.188: EVENT: p2pNode#Connected=31,'Vloerverw-Nieuw','20251118'36.398: EVENT: p2pNode#Connected=19,'EspKoelvries','20250430'37.38: EVENT: Verdeler_aanvoer#temperature=22.037.453: EVENT: Verdeler_retour#temperature=22.037.534: EVENT: Keuken_aanvoer#temperature=22.037.545: EVENT: Trapgat_aanvoer#temperature=22.037.557: EVENT: Trapgat_retour#temperature=21.537.568: EVENT: Serre_retour#temperature=21.537.578: EVENT: Huiskamer_retour#temperature=22.038.14: EVENT: Huiskamer_aanvoer#temperature=21.6>> Failed to fetch > Failed to fetch > Failed to fetch > Failed to fetch <<
72 discussies opgehaald sinds 31 augustus 2026. Volg dit forum op zoekwoord →