I’ve been playing with a proof-of-concept WebUI; it’s not ready for prime-time yet, but if you’re adventurous (and have very low expectations) you may try it: https://github.com/crossan007/meshtastic-web/releases/tag/0.1.1
You sneak!
On your instructions, “delete all files” … where does the Meshtastic Javascript library get brought in?
I bundled the meshtasticjs library inside my app.js.gz
That’s incredible.
You win all the Internet credits!
Hi, just hit the report bug. I have one node reporting blank messages every so often. Quite regularly actually.
Both nodes updated to 1.1.20 and app to 1.1.21
Same here with Raspberry Pi OS feeding a LoRa32.
It’s working, I install it and seems to work.
But the page doesn’t scale well in small screen like a phone.
Yep - it’s a very rough work in progress - I’ve only been playing with the Meshtastic project for about a month at this point
Feel free to peruse the list of open issues for the web app in GitHub: https://github.com/crossan007/meshtastic-web/
If you see something that’s missing, feel free to open a ticket there or comment on an existing open ticket.
Hi I am running two tbeams (both T22_V1.1 20191212 with 6M and M8N gps’s on device versions 1.1.0 and 1.1.20). My tablet runs android 7.0.
I found that app v1.1.20 was fine but I cannot BT to either devices at present with 1.1.21. I sent in a bug report.
Thanks @mc-hamster for opening the issue and the instant “fix” I really appreciate all your comments and links. Due to a new job and corona home-office regulations i’m very busy and i’m in over my head. Also my desk is full of hardware and cables and unfortunately there is no space for my personal projects, haha, damn it.
I will definitely test @crossan007’s web interface on the weekend. Let me cite Borat: "Verrrry niiiiice!! "
Thank you for your efforts!
Then I also will set up a WSL (linux subsystem) to test the firmware flashing scripts and to investigate further on the heltec SPIFFS image, which i could not get to work flashing with platformIO.
I have updated two devices… and it seems to work.
On the map it seems sometimes I see two devices, and sometimes I see only one. For me that is confusing…
The radio sleeping is an interesting thing… I’m not sure what all wakes it up.
The two-D bar-code for the channel is curious… for now I’ve left them all default. It’s not clear to me how that gets moved to others who want to be on the same channel. If we made more than one channel, could we hop around and basically have different conversations with different groups of people?
Forgive me, I’m very new here. Hopefully at some point I can use the build instructions to build this project and then dig in and perhaps contribute.
Crazy question: Are there plans to do a relay of messages over the internet? I saw that somewhere, but then could not find it again.
Thanks for your time…
@geeksville From the perspective of user experience feedback, I see this a lot – people see meshtastic devices sleeping. The device sleeping is actually not a bad thing, it preserves battery life.
Connected mobile devices have access to the meshtastic device’s configuration. Maybe we can display a metric of when we predict the radio will come back up. That may reduce the perceived anxiety of “when will this come back?” or “I think it’s always sleeping”.
Any other ideas (from anyone)?
I’d make sleeping intervals configurable: notwithstanding local regulations, shorter intervals make tracking mobile nodes actually meaningful, while longer intervals are more suitable for building a network of solar-powered fixed nodes.
yes - to elaborate how on how radio sleep works:
on esp32 nodes we need (unless the board is powered by USB) the ESP32 to sleep most of the time (because otherwise its power draw is quite high). This drops the bluetooth connection to the phone. The phone copes with this (and will queue any text messages you send until the next time the radio wakes bluetooth - by default this happens every 5 minutes).
The LORA radio is always awake and listening (this costs very little power - see our power spreadsheet). If something comes in over lora it will wake the ESP32 and the message will immediately appear in the app (and any queued messages in the app will go out)
The bluetooth sleep intervals are configurable, we mostly need someone to sign up to spend the time to make a nice doc for the python command line tool. If someone wants to sign up for this, mesh.proto has detailed (more programmer friendly) docs on each of the adjustable user settings.
(btw - nrf52 based nodes don’t have this problem - they can have bluetooth up 100% of the time for essentially zero power cost. alas, no one is shipping these in mass (yet))
@Everlanders thanks for the great alpha feedback on 1.1.20 and the new “blank messages occasionally appear when idle” problem. I’ll work on this later in the week:
Great initiative! Sign me up!
I don’t know exactly how to conduct testing but if you can provide some instructions I can do it!
Does it matter which equipment/device, power source/proximity temperature I’m using?
I be in. What’s the protocol : is it a new Android device install ?
What’s the deal on the Arduino api ? Got .ino sample ?
re: alpha testing
mostly that just means installing the 1.1.x series of device loads on devices and using the alpha/beta channel of the android app. To get the test android builds opt-in here. Then the play store will update your app.
It would be great if you want to try the on device API, there is a (rough) tutorial referenced here (corrections eagerly accepted): (You still build with platformio)