Replies: 7 comments 12 replies
-
Would you be able to open that as a separate feature request please? I want to keep this one focused on this specific request. Thanks. |
Beta Was this translation helpful? Give feedback.
-
You can also use the Android app to connect to the Pico W with it's IP. I'm not sure about iOS because I heard in a video that it was Bluetooth only, but I'm not sure if that is still the case, the video was from a few months ago. |
Beta Was this translation helpful? Give feedback.
-
Ah, it's iOS only in the two locations where we have Pico Ws. I can't see a way in the iOS app to connect to a Pico W on wifi or over the local network. Can anyone confirm if this is indeed possible? Possible solutions:
Bottom line - is there any way to access the stats, a node list, send and receive messages, a map, etc, for the Pico W as one might with a Heltec, say, and without it being attached to the computer? In otherwords, using wifi and some combination of network/hotspot/app/browser to achieve this? |
Beta Was this translation helpful? Give feedback.
-
|
The only way I could think of at the moment would be to have a tiny Cellular/WiFi access point in the same enclosure. But at that point you're buying an extra computer/microcontroller and a bigger battery/solar panel to keep it all running. |
Beta Was this translation helpful? Give feedback.
-
|
The workaround I'm thinking of is to connect the Pico to a RPi's USB port and access it over serial using the hosted client via a Chromium-based browser. Then enable VNC/RealVNC/Connect on the desktop and use that from the main computer to view the interface. It does actually have an advantage of being able to access the interface away from the local network, which might be handy for sending test messages during range testing. I'd still prefer the Pico to directly support the web client on the local network however. |
Beta Was this translation helpful? Give feedback.
-
|
What is it in that link that you're specifically referring to, @garthvh? I'm not seeing how it relates to enabling local network access to a Pico W. |
Beta Was this translation helpful? Give feedback.
-
|
The pull request references a documentation change for the arduino-pico library which states that mDNS (needed for hosting a webserver [aparently. I don't know why IP's cant be used...]) does not work with FreeRTOS (the base OS that meshtastic uses) . |
Beta Was this translation helpful? Give feedback.
-
|
What about the Pico W hotspot which was removed? Can't that be put back? What about the desktop app, can't that support it over IP (doesn't have to be web server)? Can't bluetooth capability be restored? I mentioned the web server as an example, since that is present in the firmware, but the bottom line is a request for some means to access the Pico W using its wifi, network or bluetooth capability which doesn't require a direct USB to serial bridge connection, like you can with Heltec, RAK, etc. Alternatively, if the Pico and Pico W are not supported, please say so unambiguously. Perhaps a dev can spell out, in crystal clear language, what the technical issue(s) is (are), or is it just a case that the Pico W represents a small percentage of userbase and so resource is not currently focused there and the firmware is not at the same level as on the other controllers. Communication is the key here folks. |
Beta Was this translation helpful? Give feedback.
-
you can find out much about the history of this platform in the commit history. Sure it would be nice to have a webvserver on there, but development ressources are limited and heavily infuenced by personal interests of the developers. There would not even be Wifi support on there if it wasn't for a developer having a personal need for this. |
Beta Was this translation helpful? Give feedback.
-
|
The hotspot functionality is bad, does not really work off grid and phones behave badly with captive portals without internet. Won't do what you want. |
Beta Was this translation helpful? Give feedback.
-
It's this one from Experimental Engineering. It's hardware equivalant to a Pico + Waveshare LoRa board. It has two charge-controlled 18650 battery holders on the back and supports power from those, a 5V input, a solar input and USB for power and/or Pico W interaction/firmware. https://www.experimental-engineering.co.uk/product/picolora-solar-node/ |
Beta Was this translation helpful? Give feedback.
-
|
Hello caveman99.
I was actually referring to your own comment in a Pico W thread in which you stated it was removed, without this qualification.
Nothing was supported until it was. Is it feasible to enable bluetooth on the Pico W or is there some technical reason why this will never be possible? I'm not asking if you can get it done tomorrow, just literally whether it is possible or not.
The frustration is in trying to separate what is not possible from what has not yet been done, for that perfectly valid reason. My questions are seeking that information.
I've been involved in open-source since 1990 and don't need a lecture on how it works. I help where I can and in this project this will mainly be in the form of detailed bug reports, with as much testing as I can do to assist with fault finding. I can also write technical documentation. As for PRs, unless you accept FORTRAN77, OPL or dubiously crafted bash, don't wait up.
The Pico W is shown as a supported device. My goal is to understand what is not possible vs what has simply not yet been done. There are no demands nor requests to hurry anything up. Conversely, developers who skim-read and skip detail, who don't communicate clearly or who drip-feed information, or who see a project as their own personal playground and who patronise users, are super tedious to deal with. I've encountered some devs like that over the years.
That can be helpful if you know what you are looking for, but if you don't know what you don't know, you won't be able to appreciate the presence or lack of some detail. That why developers have a responsibiility to go a bit above and beyond in communication. Users have a responsibility to try and assist in disseminating that information and amplify their voices to take the load off where they can. The questions I am asking are about what is possible. If a feature is possible but has not yet been done, as more people take it up it may come to fruition and I'd be happy to test and feed back. If a feature is possible but has been set aside due to the personal feelings of a developer, I'd ask the developer to put their personal feelings to one side and look at it objectively. If a feature is not possible then it is what it is and at least we now know. |
Beta Was this translation helpful? Give feedback.
-
|
In embedded platforms, everything is possible. And everything is bleeding edge. Some things that may not be supported by the upstream toolchain can be supported in a few weeks time. I don't want to start bickering, but the comment regarding bluetooth was 'it has never been supported on pico in meshtastic' in answer to your question if it can be resurrected. 'Supported', 'Extended support' and 'unsupported' are only 3 drawers that can't even attempt to communicate what state a platform really is in. There are long-running established mainline platforms like ESP32 and nRF52, rather new ones (in terms of meshtastic AND toolchain) like the RP2040. Even newer ones in terms of meshtastic but not the underlying OS (raspberry/linux) and very new ones that dont even fully work with the core functionality, like stm32, apollo3 and the LR1120 lora chipset support. All this can be evaluated from the commit log. The firmware is quite granulary and you just have to look for the initial commit for a certain platform, not skim through every single commit. The request for timely information still sours me, and also the patronizing comment about who is in open sorce longer and knows hot it really works. Every project ecosystem and climate is different, and we have a very positive and supportive environment here. A good approach would have been asking nicely why things are in a certain way instead of demanding communication (which IS indeed key, but the attitude is in the way you ask) and assuming things that are not even a fact. |
Beta Was this translation helpful? Give feedback.
-
|
tl/dr: what is possible changes on a weekly basis, so there's not a single answer here. Start exploring the toolchains and you'll find out whats possible. |
Beta Was this translation helpful? Give feedback.
-
I've never asked for "timely information", merely any information, as it becomes available, from anyone, about what is possible vs what is not. I'm essentially trying to reverse-engineer just what support this supported Pico W device actually has, could have and is capable of. I have read the release notes for the firmwares over the last year or so, as well as scattered forum posts and reddit threads, to try and piece together what can be done and what was perhaps previously possible and was removed.
Well then please don't make daft comments like "open source works like this: if it itches, you scratch it". I'm looking for facts and information, not lectures on how I need to shut up or learn to code the RP2040. Summary[For those finding this later looking for Pico W access info] It looks like the Pico W does have some more potential for access. However a combination of this being a relatively unexplored microcontroller, plus a relative lack of demand for it at the moment, and limited development resource, means that the current methods of access will remain the only viable options for the time being.
My current favourite approach will be to connect it, via USB, to another Pi running Pi OS with the desktop, and use that for the CLI and hosted web access, and use SSH/VNC/RealVNC/Connect to access it remotely, essentially moving the remote access requirement away from the Pico W. |
Beta Was this translation helpful? Give feedback.
-
Platform
ESP32
Description
This is a feature request for the Pico W RP2040 (not ESP32, dropdown had no option).
I have a Pico W based node, in wifi range but away from the computer. It would be very useful to have access to the web client over wifi, as one can with (say) a Heltec. I believe the firmware supports the web client but there is no web server running to be able to access it.
As it stands the only way to interact nicely with the Pico W is to connect to to a Chromium-based browser and use the hosted web client to access it over serial.
Is it possible to enable a simple web server in order to access the web client over wifi?
Beta Was this translation helpful? Give feedback.
All reactions