(The previous alpha-test thread had become quite long, so I’m starting this new one instead)
Hi,
So there are now about 400 1000 regular users. So I should probably become a bit less reckless about pushing out new code so often? Is there anyone out there who would volunteer to be alpha testers? Ideally we’d have a few volunteers so the work any one person would need to do is minimal.
Here’s kinda what I’m thinking (though it would mostly be up to the volunteer testers):
I only release the android app and device code to the alpha test group initially
Then sometime in the fiveish days that follow any of the volunteer testers does a basic “sanity” test. i.e. they could send messages between two nodes and see positions on maps.
If that sanity test passes they post on this thread saying “I just tested 0.6.7 and it seems good to me”
Based on that info (i.e. someone other than me could run the code), we release the build to everyone else.
Sound reasonable? Anyone want to do this (no long term committment required) ?
Version 1.1.20 of the device, android code and python code are ready for alpha testing!
There are many changes in this release, I’d be super appreciative if a couple of brave alpha testers could try it and report back (just basic sanity testing - positions still work, sending text messages still work). In the next couple of days I’ll be posting a different thread (and a new tutorial for how to write device code that uses meshtastic) asking for some feedback on the new ‘on device API’.
YOU WILL NEED TO UPDATE to the alpha/beta android app to talk to this release. It is recommended (but not required) to update the python client as well. It may take a few hours for the new android version to appear in the play store.
Major changes:
@mc-hamster added more to the web UI and wifi fixes
Make a new Plugin api to make it easy to run regular ‘simple arduino API’ code that can send and receive mesh messages. (Tutorial coming soon)
Allow automatically converting protobufs into plugin messages (so devs can either send their own structs, or optionally use protobufs for their custom plugins)
Move the existing position and text messaging code into new TextMessagePlugin and NodeInfoPlugin
Added a ‘RemoteHardware’ plugin that provides easy remote GPIO access from python or other device nodes (tutorial coming soon)
Add deep sleep support for NRF52 boards
Add soft power down. Hold down user (middle) button for 10 seconds to turn board off. Push the power button to turn board on. Works on boards with the power management IC (tbeam 1.0 and above)
Fix bug #513 - this will make faster network settings much faster and more useful. Related to the new IP tunnel feature
Fix #525 - for devices with custom GPSes
Add support for updating SPIFFS over BLE
Fix #536 so that users can set fixed positions for nodes without a GPS
Fix replies to network pings - so that new nodes should learn the initial node DB more quickly.
Hi @geeksville I have two tbeams running 1.1.20 - T22_V1.0 20190612 and T22_V1.1 20191212. I updated the app to 1.1.20 (but have not updated python client - how do you do that?). Both tbeams meshed, connected to the app and were textable. All very quick. They found their location but have not yet appeared on mapbox (20 minutes since startup). Now they have the message no gps lock - this is usual I think.
One thing - the middle button still only changes screen brightness - there seems to be no power down.
I just tried the latest firmware and app. I have seen messages with GPS coordinates show up in the app’s debug panel, but no markers on the app’s map. I went into another room and connected to a tbeam with 1.0 firmware on it. No GPS coordinates at first, then multiple GPS coordinates eventually showed up, from that TBeam’s memory. Maybe I didn’t wait long enough for the first TBeam.
How did you flash the device with the new firmware? What tools did you use? Your screen tells me that the spiffs is on the device, but our new image wasn’t loaded.
I suspect you’ve run into a bug of the Espressif SDK and a bug in our work around of the original bug.
I’m unfortunately still having issues with the bluetooth update on my tbeam (1.1.8), it got about 70% and then failed and went to sleep, and the update button still gets broken requiring wiping the app storage/cache to try updating again - simply restarting the app doesn’t fix the update button.
Edit: Finally got it to update after like the 7th try.
I’m still seeing the behavior I noticed before where old positions (from like a month ago) on nodes that haven’t been plugged in in weeks are showing up on the map.
Hi @mc-hamster I am seeing the 404 behavior for the /static/index.html as well. This is the lilygo ttgo tbeam v1.1.
I had been running the dev-https branch. When I saw 1.1.20 out i just cloned the repo and did a build/upload from within vscode.
After a flash using esphome-flasher (1.3) using the released binaries things are still not functioning. Rather than “unset” in the upper left corner, I see “US” now. So that’s probably something broken in my build environment. Following the flash I had to mess around a bunch to get wifi connected. I thought i had the procedure down but i can’t find an order that consistently works.
However in general I’ve been flashing, then trying to get to a state where the device generates keys. It seems like after that, wifi will connect.
In this most recent test i did a flash, then i set the wifi params with the cli, then pressed button 3 for a reset. after that it hung at the splash screen for several minutes until i hit button 3 again and then it seemed to do the key generation thing, and booted properly.
Still, after getting wifi connected, the 404 persists.
Could you try using the scripts included in the firmware zip file to install the image? There’s actually now two files that needs to be flashed onto the device – the first is the application binary image and the second is the image of the spiffs filesystem.
esphome-flasher doesn’t provide access to the spiffs address area.
Ok. That works. I’m on windows, and overlooked the installs scripts. So now after button3, the delay happens, wifi connects and the webpage renders. A “connect to meshtastic device” button displays. The clicking of it returns “your device has been configured” but nothing following that.
That’s what we have published so far. The work has been put toward the network services and a massive effort toward the javascript library.
I got a preview of the new UI that Charles, Tobias and Sacha are working on. It’s implemented in React, very very cool stuff. Hope to see that soon
You can also go to http://meshtastic.local/static if you want to play around with the file system. There’s a basic file editor there and you can upload new files. Just keep the files small.
Can someone try out the soft power-down feature? It would work on the ttgo boards, v1.0 or newer.
Hold down the middle button for 10 seconds. The device will power down and draw next to no power.
Push the power button (far left) for a moment and the board will come back to life.
This is useful for when you need to swap antennas or if you need to put your board to sleep for storage or transportation.
