No luck with 1.1.20 here. It crashes the same way 1.1.18 did, within a few seconds of opening the app, on two different Android devices. Doesn’t seem to make a difference if the Lora device is connected on BT or not. Obviously I can’t update the firmware past 1.1.18.
LMK if I can provide a log file or something. I already logged issue 206 on Github.
I tried soft power down several times and it appears to work. However, one time the blue led did stay on.
I updated my Android app, python and half my devices. Was able to successfully send messages from a 1.1.20 device using the Android app to all the devices.
I seemed to have issues sending messages using the updated python api. I don’t think they were getting sent. I think this was true for both a 1.1.8 device and a 1.1.20.
I have install the last firmware 1.1.20 with the esphome flasher.
firmware-tlora-v1-EU865-1.1.20.bin
ooh thanks - I missed that report - I’ll look into this tomorrow.
Can confirm, soft power down works on the same ttgo device. Middle button press and hold triggers a fast moving progress bar on the screen. After 10 seconds the device goes dark and my charging station doesn’t register any draw. Left button for about 2 seconds and it pops back to life.
Nice work, and thanks for the clarification on the web side. I haven’t been following that work closely, but I saw the request for beta testers so I jumped in. I’ve got 4 devices here ready to go if there’s other stuff that needs testing specifically.
Ahh. Good find! I don’t check the status of the leds before powering down. I’ll fix that.
Thanks!
I wish we had more control of the left button. It seems a fast “click” works sometimes but doesn’t at other times, but being held down for more than a fraction of a second works every time.
You may also notice some lag before you perceive the board waking up. It has to start a lot of services before showing signs of life. Maybe we can fix that.
i would be happy to alpha test if the binaries are made available on GitHub. i do not have a Google account on my device and Aurora Store does not allow beta channel access.
I’ve 3 TTGO TBeams that I can test.
LORA32 & NEO6M
Firmware: 1.1.20
Currently all three updated firmware successfully via android app.
Two successfully updated seamlessly, one I had to clear the cache and app data on my phone and turn off and turn on the TBeam to complete the update successfully.
Phone 1 connected to Node 1 on Battery
Phone 2 connected to Node 2 on Battery
Node 3 has no phone and will just act as a repeater.
From a messaging standpoint messages entered into phone 1 appear on all three TBeam screens and displays the name of the user.
Phone 1 messages “Hi”
Phone 1 app indicates username P1 sent message
Node 1 Displays Message (Username P1)
Node 2 Displays Message (Username P1)
Node 3 Displays Message (Username P1)
Phone 2 app displays message and displays username P1 (in the user tab both P1 and P2 appear)
If messages are entered into Phone 2, the messages also show on all 3 nodes but Phone 1 does not display Phone 2 message and Node 2 does not display the P2 username.
Phone 2 messages “Hello”
Phone 2 app indicates username P2 sent message
Node 1 Displays Message (Username ???)
Node 2 Displays Message (Username P2)
Node 3 Displays Message (Username P2)
Phone 1 app does not display message and does not displays username P2 (in the user tab only P1 appears and P2 does not appear)
Only other issue I’ve noticed so far is that all of the tbeams go to sleep but do not wake even though the android app says connected. I have to physically press one of the buttons on the tbeams to wake the meshtastic and then reconnect via the apps on the phones.
I’ll post to github soon. I only post bins there occasionally because it is higher friction and I forget 
I’ve updated the handler that if it returns a 404 when requesting the root page, that error page will link to a webpage with information on what’s causing the problem and how to fix it.
Thanks for the report! This fix will be in the next firmware that @geeksville publishes.
I fixed the problem with the LED staying on during the shutdown.
It’ll be in the next build that’s published.
I just went back to the first room again, and connected to the first TBeam, which happens to be my only M8N GPS one. The map has markers on it, but they could be left over from connecting to the other TBeam. My chat now shows my entire chat history being made by the initials of the name on the current M8N TBeam, even though it sent a small minority of the messages, and the app shows all of the messages as being blank, and dated within the last 24 hours, when there was previously months of message history.
Firmware and Android app working great for me once the BT “null” issue was resolved by clearing app data. 
So out of my 3 T-Beams, 1 reports 3 of 3 online, and the other two don’t seem to be aware of the others at all. But messages do kind of come in, but they all will say ??? [message]. Only the one android device seems to see the messages (the one that does report 3 of 3 online). I installed the 1.1.21 update a little bit ago, but no change.
I’m getting the same ??? name issue on one of my devices too.
I have 2 heltec and 2 tbeam devices and updated all of them only via bt since 1.1.0 i think.
At first everything worked well, only one of my tbeams showed up as ??? on the other devices. after some hours the name has updated and everything was fine. Only GPS had some inconsistences between the app and the screen, but this is no reliable information due to bad GPS signal…
Today I tried @mc-hamster 's wifi features and found some issues:
As all devices were updated via BT i thought the SPIFFS is correctly populated with the WiFi files, so I “enabled” wifi via python on one heltec. After about 10 attempts the wifi config screen appeared, but the connection was not very stable (changed the BT sleep intervall, but I don’t know if it affects the wifi connection as well. the helltec kept disconnecting after screen went off. It only reconnected on a hard reset. No difference on my two APs one with a hidden SSID, the other’s not hiding the SSID.).
BTW: The password is shown in the screen in both, the softAP mode and client mode. I think the password should only show up in softAP mode due to secutity concerns. 
Opening the index.html leads to “404 File not found”. After that I first uploaded the three files from the /data folder via the experimental file system browser. It claimed the files are to big and aborted. Nevertheless the files were uploaded, but all were 256B in size. Then the index.html was loaded, but not completely. Same after deleting the files and uploading a .gz compressed version. The Button only showed a “C” and did not respond. Then I went on flashing the SPIFFS via platformIO but always got the 404 error. The SPIFFS differ in size on the tbeam and the helltec, so i thougt heltec isn’t supportet yet and switched over to a tbeam.
Just enabling wifi via python instantly worked and i was connected to my AP. The connection was stable. (tbeam is powered from USB, so it never goes to sleep.) Loading index.html also returned 404. So i flashed the SPIFFS via platformIO and got 404 error, too. After flashing the FW AND SPIFFS via platformIO AND not touching any settings (leave default name and channel) the index.html successfully loaded showing the complete Button “Connecting (… cant remember)”. Then I gave up on this as
After that I freshly flashed all 4 devices via ESPhomeflasher (because it erases the SPIFFS and all settings) and set up my channel and the names. Then I realized that both helltecs instantly published their name to the mesh with the first message sent, the tbeams still show ??? on the other devices. So the ??? issue is rerlated to the tbeams somehow.
I also tested soft power down: works fine on tbeam, does not work on heltec.
After sending some messages from all devices to the mesh i realized, that the tbeams sometimes show random old messages on a hard reset /soft power down.
Sorry for my bad english, normally I try to verify my text, but today I spent so much time for testing and now i am a little bit in a hurry 
@drewsed This is really great! Thank you for the amazing deal you put into the report.
Let me see if I can comment on them.
so I “enabled” wifi via python on one heltec. After about 10 attempts the wifi config screen appeared,
There’s an open bug in the python API for this. I linked you to it on another thread.
the helltec kept disconnecting after screen went off.
This has been reported in : https://github.com/meshtastic/Meshtastic-device/issues/535
It’s an issue in how we’re detecting that you’re powered.
The password is shown in the screen in both, the softAP mode and client mode. I think the password should only show up in softAP mode due to secutity concerns
Agreed. Please open an issue and I’ll get to it.
Scratch that. I was already there and fixed it.
“404 File not found”
I was brainstorming ideas on how else to get files onto the device with @crossan007 and have an idea to be able to point devices to an online manifest which it would then download a new interface. For now, the best way to get everything updated is through the install scripts in the firmware package.
experimental file system browser
I’m really tempted to remove the upload feature, or at least disable it until the web server library we use matures a bit.
index.html successfully loaded showing the complete Button “Connecting
That’s what we have so far. Thank you Mario, but our princess is in another castle.
helltecs instantly published their name to the mesh with the first message sent, the tbeams still show ???
Hmm … Maybe geeksville can comment on that.
As far as (presumably) powered devices for using the WIFI interface go, it might be a good idea to emphasize the LORA32s which come with MicroSD support, instead of having to rely exclusively on SPIFFS. This would be similar to how the disaster.radio project implements this functionality with their swappable hosted webapps and associated resources.
Placing files on the SPIFFS vs the MicroSD (which also runs on SPI) is actually functionally very similar. Whatever is built for one will work on the other.
The system that we have in mind would let you give the embedded application a URL and it’ll swap in another self hosted web app. That in addition to the other ways of writing to the spiffs, that should be very user friendly.
You’re totally spot on about storage capacity. If someone needed to store a whole lot more stuff, then external flash would be needed.