Inviting Groups in D4H…

We are a mountain fire department with both a community and significant wildland potential (with urban interface.) Our firefighters train for structural firefighting and wildland firefighting (and more.) We also have a wildland team for additional firefighters that respond to wildland fires.

We’ve created four D4H groups:

  • Full Firefighters (FFF)
  • Wildland Team Firefighter (WLT)
  • (Incident-only) Active Full Firefighters (AFFF)
  • (Incident-only) Active Wildland Team Firefighter (AWLT)

For structure fires, medical incidents, hazardous materials, and such only our AFFF respond. For wildland fires, illegal / unattended campfires, smoke reports both AFFF and AWLT respond. We manage their “requested” status in D4H by adding the appropriate group.


This keeps our memberships’ percentages correctly representing their standing. They are invited (requested) to the incidents they can attend and not those they cannot, nor those they are temporarily unavailable for.

(More precisely – when creating an incident report – we add the personnel that attended and mark them as attended, then use “Quick Add” to add the correct “Active” response groups. Note that the newly added members are added and left “selected”. We then use “Bulk Action” to “Set Status” to “Absent”. )

Our membership are operational (our responders) or non-operational (administration, support.) When a firefighter has to take an absence we do NOT change their operational status but we temporarily move them out of their “Active” group. (We do have a “Temporary non-Operational” group, but that is less important.)

Combining/processing D4H reports

D4H comes with a powerful reporting capability to analyse your team data. Much of the data your organization has gathered in D4H is available via reports. That said, we have custom logic that we need to apply for our firefighter’s annual requirements.  We gather the firefighter’s fire training hours, their medical training hours, their station training hours and more. Each of these come from a separate D4H report. Eight of them. We combine the outputs from a number of D4H reports into one combined report – with our logic and our presentation – for ease of use by our firefighters. That takes a bit of processing…

We use the “Download to Spreadsheet” option on the report page (see below) which creates and downloads a CSV (comma separated variable) text file that can be easily processed by Excel (and other spreadsheet programs) or by scripting languages:


We download the output and rename the file as (say) fire.csv (with one named for each of the others.) We then process these files using a ruby script…

require 'csv';
# Fire
puts "---------------------------------------------------------------------- Fire"
CSV.foreach("fire.csv", :encoding => 'bom|utf-8') do |row|
    if $. > 1
        # Skipped header line...
        raw_name = row[1]     # Name in column 1
        name = raw_name.strip # Trimmed spaces from name
        fire_hours = ( row[5].to_f / 60 ) # Fire hours...

In order to speed the process of generating the report data … by removing the manual steps of selecting the report, selecting the date range (and not making a mistake), remembering to press ‘GO’ to re-run it with the date range, then downloading … we created a local HTML file called edit-to-download-reports.html with links to each report.

To download we (1) login to D4H in a browser (2) open the HTML file with links (anchor tags) for each of these, where you would replace:

  1. The subdomain to your D4H subdomain
  2. The report identifier (get it from the URL of the report)
  3. The start and end dates. We typically have the start of year and the end of the month we are reporting to.

Extract the report ID from the end of the report web address:


Remember to edit the “endDate” if you are running these for (say) a new month:

https://{YOUR SUBDOMAIN}{REPORT_ID}&param%5BstartDate%5D=2018-01-01&param%5BendDate%5D=2018-12-31

We’ve found that by using D4H reporting and then exporting to CSV file format we can extend the functionality to our custom needs.

Response Utilities for D4H (iOS)

I am a volunteer firefighter in the mountains of Colorado, USA. We use D4H – Readiness & Response for managing many aspects of the department. We record incidents, exercises, events and attendance in D4H. We manage our inventory (for multiple stations, apparatus and personnel) and we maintain individual certifications / qualifications, and more, in D4H. Our members use D4H a lot.

D4H is a very powerful system with a lot of features, and its website is somewhat overwhelming on any mobile device, especially a mobile phone. Our membership needed something less powerful, an application for the tasks they perform on the go; viewing activities, setting attendance, communicating with other members, and updating off duty.

I created Response Utilities to allow our membership to interact with D4H. Response Utilities is a simple interface targeted at individual members, allowing them to view upcoming activities (and set their attendance), review past activities (incidents and more), and communicate with other members of the agency. Members who default to “on duty” (e.g. volunteers) are also able to easily set their “off duty” times.

Find out more here:


Beta Testing – please help me improve faster…

I hate breaking apps, especially when I know they are being used in the field. A crash in the field can mean significant lost time and data. Not good! That said, as platforms continually change under the application (and their languages mature) even rebuilding an app (with no changes from me) can break it. I don’t release often enough because of the fear of breaking a production app. Beta testers help reduce that stress, and allow me to make progress. Please participate in beta testing, when you can afford:

Timestamped Field Notes iOS:

Field Triangulate iOS:

Field Triangulate Android:

Notes Collector iOS:

Notes Collector Android:

Android Triangulate Rebuilt


I’ve been working to update Triangulate on Android, and that include porting it to Kotlin (Google / Android replacement for Java.) In sort, I’ve changed every line.

Further I’ve worked to improve handling for offline (it was not as simple as I’d first considered, and testing did not uncover that.) Finally I’ve added a first attempt at allowing the devices sensors to help determine a (rough) bearing, enabling some usage even without the (more accurate) handheld compass.

I would appreciate some help checking it out before I overwrite the existing application with this version. Please check it out at:

What next for Notes Collector?

Notes Collector is progressing for basic usage, both on iOS and on Android. (Beta testers still welcome, and appreciated.)

That said, Notes Collector was developed based on Timestamped Field Notes in order to migrate to more flexible internal infrastructure, to allow some experimentation on new features (without destabilizing TFN), and to more easily support more platforms (iOS, Android and Web.)

Here are some suggestions/requests I’ve heard from you over the years:

  • Allow an optional photograph to be added to a note item.
  • Allow an optional location (latitude / longitude) to be added to a note item.
  • Sharing an event (a set of notes) with other users, in real-time.
  • Create “icon/photo” based keyword buttons.

Please let me know your thoughts on the features / improvements you’d like to see for Notes Collector.