sumnerboy12 commented on Apr 14, 2016

…but clicking the reset button on the D1 boots back into normal mode. Is this expected behaviour? Tried with two different D1s, same thing. As soon as I unplug the USB cable and re-connect, the device goes back into configuration mode.

Owner

marvinroger commented on Apr 14, 2016

This is not an expected behavior. I guess the USB is connected to a computer, can you try with a charger?

Contributor

jpmens commented on Apr 14, 2016

@sumnerboy12 I’ve just checked for you with the Homie version I’m running (Github pull pre 1.3.0): works as advertised, i.e. I can cold-boot (also via USB) and device starts publishing.

Contributor

jpmens commented on Apr 14, 2016

@sumnerboy12 it just occurs to me that I didn’t configure via WiFi, instead preferring to write the config directly to the file system. (Note the commented SPIFFS.format() which you might need to uncomment.) https://gist.github.com/jpmens/d674114400c1dd7ba169403afb7d1ea1

Owner

marvinroger commented on Apr 14, 2016

@jpmens if configuring via the API is successful, then the FS is in the exact same state as if it was written directly during flash or using your sketch, so this should not be the issue here.

marvinroger added the bug label on Apr 14, 2016

Owner

marvinroger commented on Apr 14, 2016

Can you also post the debug output on the Serial monitor? There should be a message like ✖ Cannot mount filesystem.

dholmen commented on Apr 14, 2016

I’ve had the same problem with at least one of my NodeMCU’s. There are no error messages in the serial monitor, it just looks like a normal config mode boot.

sumnerboy12 commented on Apr 14, 2016

Yes same here – there is nothing appearing on serial when it reboots into configuration mode. I will need to have more of a play this evening, but it is good to know this is not expected behaviour. I will endeavour to do some more digging and report back here. On 15/04/2016 9:00 AM, dholmen wrote: I’ve had the same problem with at least one of my NodeMCU’s. There are no error messages in the serial monitor, it just looks like a normal config mode boot. — You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub #64 (comment)

Owner

marvinroger commented on Apr 14, 2016

The configuration mode is started when the Config.load() method returns false. If you look at the sources, you will see that everywhere false is returned, there is a log message, I don’t see any codepath where this would not be the case. I might be wrong!

sumnerboy12 commented on Apr 15, 2016

after some debugging with @jpmens we discovered this was caused by Windows it seems – as soon as I unplug/re-plug the Wemo into my Windows laptop it resets the device back into config mode – if I flash the Wemo, un-plug and plug into a wall wart, it boots up fine. This can be repeated with no issues. As soon as I plug the Wemo back into my Windows laptop, it is reset and reverts back to config mode. Very odd, but I don’t think this is a Homie issue so I will close this issue.

sumnerboy12 closed this on Apr 15, 2016

Contributor

jpmens commented on Apr 15, 2016

I’m confident @marvinroger knows a tonne more about these devices than we do, and can maybe say whether he’s encountered similar resets with Windows and/or whether it’s a known Windows driver issue.

Owner

marvinroger commented on Apr 15, 2016

WeMos D1 boards embed a CH340G USB serial chip. I have a NodeMCU v2, which embeds a CP2102 chip, and I had this problem once or twice, so it is way more stable. Maybe try to install this driver, if not already done. I am sorry, I can’t help more on this! But yes, definitely not an Homie issue.

sumnerboy12 commented on Apr 15, 2016

updating to that driver seems to have resolved it – thanks a million @marvinroger!!!

Owner

marvinroger commented on Apr 16, 2016

Awesome! You’re welcome!

DavidStacer commented on Apr 16, 2016

I had this problem too on a Wemos D1-mini. Updating the driver did not solve it. To diagnose this and see all the message, I connected up another USB serial port adapter. Then connected the RX from the second serial board to the D1-mini TX pin and tied GND to the serial board. I then used Termite terminal program to monitor the serial traffic. I changed the default Homie baud rate to 74880 – that is ESP8266 default boot baud rate. This allowed me to see the ESP8266 boot up messages too. Now I could see all of the messages. When I pulled the main D1-mini USB cable and plugged back in, the majority of the time I would see: • SSL: no • OTA • Enabled: no Flagged for reset by pin Device is in a resettable state Configuration erased ↻ Rebooting in config mode My theory: When pinMode(this->_interface->reset.triggerPin, INPUT_PULLUP); is executed, the onboard D1-mini USB Serial adapter may not let the GPIO0 pin go high right a way. If you look on the D1-mini schematic, the RTS is connected to the GPIO0 pin via resister and NPN transistor. I’m speculating that the PC driver needs to give it a command to change (high or low don’t know which). Placing a delay(50); after the Homie.setup() and before the Homie.loop(); seemed to solve the problem too but I didn’t like that as a solution. Looking much deeper into the bounce code for the switch I found the default state is set to 0 meaning the switch is closed – requesting configuration mode. In Bounce::attach I changed it to be state=1; as the default. I have cycled the D1-mini with the USB cable many times and it seems to have fixed the problem of going into configuration mode without pressing and holding the switch.

Owner

marvinroger commented on Apr 16, 2016

@DavidStacer so what can I do at Homie’s level? There is no way to programmatically set the default value of the state in Bounce2. So changing this line to state = 1; fixes the issue for you? Maybe I can add this in the in troubleshooting in the docs?

DavidStacer commented on Apr 16, 2016

Changing that line did fix it for me because Bounce attach() sets the default to 0 but 1 would be a better default for this application. When _handleReset call is made to _resetDebuncer.read() it just returns the current Bounce::read() value. The current state is still low because update() has only been called one time, so we really are not getting a debounced reading but just the initial reading. I think its hard to fix in Homie but maybe don’t call the _resetDebuncer.read() until the DEFAULT_RESET_TIME has passed since boot up but that is just another way of delaying. I guess we are delaying the time before getting the switch value vs. holding up the rest of the program. I will test out that idea and see if it works.

DavidStacer referenced this issue on May 21, 2016

Closed

wemos d1-mini: cannot get in configuration mode #71

Contributor

clough42 commented on Aug 8, 2016

I was having a similar problem and came across this issue. The solution wasn’t immediately clear, so I’m summarizing to help others who also get here and are confused: If your WeMos D1 Mini loses its configuration when you plug it into your computer with USB, it is probably erroneously detecting the RTS/DTS wiring in the WeMos as a request to reset and delete the configuration. You can disable the reset trigger completely with Homie.disableResetTrigger() and it will stop deleting the config. If you want the reset trigger behavior, you may be able to move it to another pin. I have not attempted this.

NikosVlagoidis commented on Sep 26, 2016

I have the same problem but only whenever i plug it on my power bank. the problem occurred after many uses of the power bank. any thoughts?

NikosVlagoidis commented on Sep 27, 2016

actually Homie.disableResetTrigger() worked for my pc the first time but now does not work anywhere and i don’t know what to do

Source: hard reset (un-plug USB on Wemos D1) reboots into configuration mode · Issue #64 · marvinroger/homie-esp8266 · GitHub