The major focus of our mesh network is going to be Emergency Communications. We are looking at, and testing, various implementations of email, chat, VoIP, video, file sharing, etc. to deploy on the network.

One service in particular has been hard to find: Incident Tracking. The few systems I can find are very large, complex and, usually, expensive. What we would like is something lightweight, with web based access and the ability to create reporting groups (like neighborhoods) and targets (like agencies, fire, police, etc.). Input should be easy to manage: subject, description, severity, status, assigned to, expected clearing, expected update.  Reporting should allow input units to see their reports and target unites to see their reports. There should also be minimal dependency on other external software packages and the system should be able to maintain multiple redundant copies of the data with multiple access URLs. (Cloud based).

As I noted above, I have not found anything that is advertised as delivering the requirements I noted above. However, it has occurred to me that software "bug tracking" systems, like the Bloodhound system used by the bbhn team, might actually meet our needs.

So, does anyone here have experience in this type of application and, if so, what are your experiences and what advice would you offer?

Richard - wb6tae

Thanks.  Looks interesting, and more focused on emcomm than a general ticket tracking system. Do you have any experience installing ticketscad on an R-Pi/Debian or other Linux?

Not sure what the nature of the "incident" is, but if it involves Search and Rescue, you might touch base with Vance, KC8RGO on this forum.  He's implementing an Incident Management system called SARTRACK over the mesh:  http://www.sartrack.co.nz

There is also WebEOC which is used by many local emergency agencies.: https://www.intermedix.com/product/product-webeoc/index.php 

Andre

Yeah, I could have been a bit more specific. What we are looking to provide is a means for individual neighborhood CERT teams to report local incidents in a post disaster (that means earthquake in California) environment.  In this situation the local response agencies (fire, paramedics, police, etc.) have been pretty clear that there is no point in trying to contact them in the immediate post quake period - they will be 100% occupied. However, they do want to be able to still collect reports and be able to review or respond later as may be appropriate. At the very least, this data would be of statistical value.

So, there is no real need to manage dispatches and things like that. But, some minimal ability to feedback to the neighborhood that the report was seen, and might be acted on, is important.

I have have installed ticketscad on a R-Pi and it covers the territory, plus much much more. It also runs a little slowly on a Pi b+, I am waiting for a Pi 2 ;-)

I am also in the process of installing Bugzilla to see if it can be customized for our needs.

I wonder if the tidepools system would fit your needs?

Here is a writeup on how it was used during Huricane Sandy, this was part of a community wifi project that is somewhat similar in how Ham Radio would be used in a disaster

http://techpresident.com/news/23127/red-hook-mesh-network-connects-sandy-survivors-still-without-power

http://oti.newamerica.net/sites/newamerica.net/files/articles/rhiwifi_tidepools_casestudy.pdf

http://tidepools.co/

It isn't a ticket system  but maybe it fits the needs of what you want?

Very Interesting. though I don't think it would meed the specific needs of incident reporting. However, one of the more difficult aspects of getting any community effort going is finding the specific set of activities and benefits that keep people "coming back for more."

Adding Tidepools, or something in that vein, might be the "killer app" that gets people involved and make the mesh part of their general day-to-day lives.  Them when SHTF use of the network is second nature.

BTW, I am now looking at the Bugzilla and Redmine bug tracking systems. They both have a structure that could map well onto the CERT communications plans. I need to see which one allows the most customization and is the easiest to use.  I will post my findings back here if there is interest.

Thanks!

Richard - wb6tae

I may have to play with Tidepools. Will have to add it to my list of virtual machines.

Maybe a RPi Docker solution would be pretty cool for these!??!?! hmm...

AE4ML, have you noticed how many commas are in the WebEOC price tag?

There is a reason only governments use it :-)

73

Jim

Just out of curiosity, I went to look for example WebEOC pricing.

Not surprisingly, they list NOTHING on their website.

BUT.....

If you Google "WebEOC pricing", (be sitting down first!) you can find PDF files of quotes for counties/organizations around the nation. Good thing I wasnt taking a drink at the moment I scrolled down to the itemized quotes (one I saw was >$127K!), else I would now cleaning sprayed Mountain Dew off my monitors/keyboard. :-)

So to actually have WebEOC running over BBHN, it would have to be a taxpayer-funded version, unless the ARRL can make some agreement with them... (not holding breath)

73

Jim

After looking around a bit (well, quite a bit) I have settled on using Redmine. At least as a prototype system. This is offered as a bug tracker, but with a little customization (and imagination) it can actually serve as a decent community incident reporting system.

NOTE WELL: I was not looking to create a dispatch or resource tracking system.  My implementation was designed solely to allow neighborhood groups to input specific types of serious incidents to be logged. It was also a firm requirement that this system be able to run solely on the mesh and run on a low-power Single Board Computer (R-Pi).

Getting this to run on the Pi was NOT EASY. But, after a but of fooling around, I got it installed and was able to start with the customizations I needed.

I have attached a screenshot of the input screen. It should give a rough idea of what we trying to accomplish.

Next steps: Since the principal type of disaster we expect to experience here is an earthquake, we must assume that parts of the mesh will fail (for various reasons). So, we need to find a way to get this to run in a distributed (Cloud?) mode so individual groups can still input data locally, even if the data cannot propagate to the responders immediately.  

And, here is a key point: the nature of a significant earthquake is that it will strike a large area at once. Thus, it is very likely that emergency response agencies will be completely overloaded for the first 2 to 4 hours immediately post-quake. They will be neither soliciting, nor accepting neighborhood reports during this period. Local neighborhood CERT groups will be the sole responders.  However, as things settle down, the official agencies will, if only for statistical purposes, want to see the extent of damage in the neighborhoods. and this is the need we are trying to address.

Attachments
 redmine.png [158 KB]