First post, from a Mesh newbie, so please forgive me if I've posted in the wrong place :D
I'm wondering if there is, or has been considered, a "safe and well" type application which could be run on a local mesh, without the internet back haul ( at least temporarily) to the Red Cross, where the information could be collected locally, searched locally by the appropriate folks, and then perhaps distributed nationally/globaly via other links (winlink, internet, etc) when they come back online?
And if nobody's started anything of the like, might there be anyone interest in helping develop such a thing? (I'm an EE, and while I can design the hardware for GbE links all day long, I am saddled with the typical EE brain that struggles with the software-authoring side of that equation!). My brother (N5BKV in Dallas, TX) and I (KB5ZVP in Austin, TX) are both interested in seeing if we could help with such an effort.
I'm happy to discuss further ideas if it's appropriate and there's interest in it.
73 de KB5ZVP
[Side note: the "What now?" question I think is of great importance! I've got this cool high-speed ham network - how do I make it useful when its needed! And if it's a great idea, how can we help get the message out that it exists!]
https://github.com/google/personfinder
It's written in Python, and only requires Python and a few supporting tools (or so it looks like).
Ben
KK6FUT
ps. I've been working on some similar efforts, and so far have a mapping app (offline capable) which maps fire, earthquakes, power outages, and APRS on our mesh (also able to plot police calls... but boy too many to keep up with). Also can track airplanes separately, for what it's worth.
I think about all the resources I use daily that actually do rely on the internet - and how frustrated I get when I turn off the wifi card on the laptop and try and get something else done.
Tnx
Monroe - K4RQ
Unfortunately while I could design the 'puter it runs on, all that python code and files looks overwhelmingly like cryllic to me :( Could it be implementeded small enough to run on the appliance, or would it need it's own server? And I suppose the database would/could grow big enough to really wanna be on it's own application server of some type? My ideal vision would be an app run directly on a mesh node, but if necessity dictated having a laptop/raspberry pi would be all right as well. (I'm a hardware designer - I've gotta let the software folks tell me what's the more reasonable approach).
Figuring out how to collect it is the first step - being able to upload it to google/ and or the red cross for further dissemination once a reliable internet/backbone is back in place.
Scott
kb5zvp
In fact... wouldn't it be cool to have an EMCOMM Mesh Raspian Distro with:
Asterisk
MeshChat
VideoChat
"PersonFinder"
internet Proxy (SOCKS) server for authenticated internet access (instead of the "mesh gateway" all-or-none option)
etc...
:-)
You don't need the full version of untangle ... the demo have enough options and it have a fully functional firewall.
73
Matt - VE9MDB
https://github.com/google/personfinder/wiki/DataAPI
I suspect someone familiar with Python could throw this onto a RPi and have it running fairly quickly.
I'm a little familiar with the "spin" concepts of Fedora (what I run at the house) - where you can package the OS with the applications for a custom distribution. I assume it would be relatively simple to create such an animal for Debian/Raspbian??
So, maybe this could spawn a separate discussion/thread, but what would be the most popular/useful utilities to include in such a RPI?
fyi:
https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=41520
http://kk6fut-nb2-one.local.mesh:8000/aredntest
If I read it correctly, Google AppEngine is around 193MB, the PersonFinder code around 306MB... The Google AppEngine stuff is a development server which simulates the cloud Google AppEngine environment, but on a local server. Not sure on the resources it would require -- I think a higher Pi B+ and plenty of flash drive space would be useful for that, it's in Python so a high level language not optimized for speed.
It's an exercise for someone to install on RPi and see how it performs. (seeing as my current RPi is a Pi 1, running APRS traffic... with only a minimum 4GB flash.. not gonna happen here soon!).
On the upside, it's all 100% Python code, so should run on RPi no problem if resources are not an issue.
Ben
KK6FUT
Awesome! I've got an RPi 2 laying around here somewhere. As soon as I get rid of this pesky requirement to generate $'s, I'll see if I cant find it, load up a fresh distro on a bigger card, and see if I can't get it up and running as well. And if that doesn't work, I'll see about getting my hands on a RPi 3 - which I've wanted a reason to procure anyway!
Scott
KB5ZVP
It does run! It's not blazingly fast, and as I'm not an expert at all the server setup stuff I can only access it locally (ie //localhost:8000/, and not across my network, which is probably just my configuration? At this point maybe I've outstretched my knowledge base and need to grow that? Help??
Scott
KB5ZVP
My run command:
nohup tools/gae run app --port=8000 --host=192.168.1.12 &
I also agree it does not run blazingly fast (quite a slowpoke, actually). However, perhaps we can take the core of this and make it run more efficiently for a node (at least, support the backwards compatibility into whatever disaster systems standards there are). They have all the screens and data, maybe just some reimplementation in a faster and cleaner way would help.
I think the idea app would actually be:
1. A lot slimmer, code-wise (i.e. not rely on the cumbersome Google App Engine emulation). I'd vote MySQL (open, not proprietary, easy to implement) and PHP.
2. Mesh-aware and mesh-updating (i.e. allow multiple instances to run across a mesh, and auto-sync when mesh nodes come and go) -- allowing for different centers (for example, multiple Red Cross shelters) to immediately start populating data -even before a network is reliable or set up--and allow those records to merge when meshes are joined. I'd use a scheme similar to MeshChat (autodiscovery, autosync) -- someone should probably publish a low level mesh sync protocol which is optimized for AREDN or similar mesh networks -- peer-to-peer, latency tolerant, able to handle mesh joins and slow links, implement some store and forward support, etc. etc. --- if there isn't already one out there.
3. Support the export format and procedures (backwards compatibility) for the EMCOMM systems people are already using (ie. the PeopleFinder stuff and format they've published).
I think their framework is fine, but a slim, mesh-version port probably would be more desirable.
Ben
KK6FUT
BTW Does anyone know why this is the case for MeshChat? Seems like a better idea to just use a preconfigured multicast address unless I don't quite understand multicast (which is perfectly likely).
What about checking with your served agency? The Red Cross (for one example) probably already has an app to do this. All we need to do is provide communication infrastructure.
--Dan Meyer / n0kfb