Skip to content

Testing Locus Pocus

Initial Testing

The free tier, IFTTT is limited to 2 Applets. For initial testing, I set up two Applets with the IFTTT service.

  • a "Button" Applet - this would send a specified data message if an IFTTT button widget on the phone's home screen was pressed.
  • a "Location" Applet - I set this up to trigger a location enter/exit message at a location that was close by, but out of the GPS range for my base location.

I used an iPhone with the IFTTT App installed for testing.

The Button applet worked with no issues, both at base and remotely. There was, however, a lengthy delayed response for the location trigger. Also, the entered and exited sense of the location seemed to be opposite of the activity. I considered this might be a GPS granularity issue, since the initial location was relatively close by. So, I reset the location for the trigger to be further away, and several runs were made to the new location by car, with a long pause at the trigger location. This seemed to be a little better for the entered and exited sense, but there still seemed to be a lengthy delayed response.

In resesarching activity Apps, I remembered that the OwnTracks Booklet for the OwnTracks app had noted some operating system limitations with the iOS version. I considered this may also be the case for IFTTT. So, I dug out and old Android phone, which fortunately still worked after several years. I installed IFTTT on the Android phone and re-ran the initial tests. The results were very different. The Android setup provided very good and timely response for the location triggers.

In general, peoples' location changes would likely be over longer periods, with more time spent in each location than in the initial testing. So, I expect either iOS or Android would work. Especially, since it is tricky enough to ask someone to install a location app, never mind asking them to change phones.

But for development, it seems important to note that Android may provide better response - at least for third-pary apps. It may be that working within the Apple developer ecosystem for something like HomeKit could also improve response.

Full Test Run

With success in initial testing, I set up a larger-scale test with multiple locations. In order to test Locus Pocus, I set up 7 locations. These were in neighborhood-level proximity to one another to allow for completing a test run in a manageable amount of time. Testing used the Android phone set up with IFTTT for a single person / clock hand.

The IFTTT free tier is limited to 2 Applets. Since each location trigger is considered one Applet, for more locations (and to keep the button Applet for testing) I did need to sign up for the paid "Pro" plan that allows for up to 20 Applets.

The 7 locations were selected to (1) represent different locations on the Locus Pocus clock face, and (2) have some distance between then to keep location triggers separated. The locations were:

  • Home - a base location for the test run
  • Shopping - food mart
  • Prison - police station
  • Holidays - recreation park
  • Peril - cold blooded & bizarre shop
  • Work - workman's friend establishment
  • Lost - the "Rabbit Hole" venue
  • Transit - having exited a defined location, but not yet entered another

Locus Pocus Test Run Locations

Locus Pocus Test Run Locations

The Locus Pocus system was initialized and calibrated. and The "button" app was used to test that messaging was working from phone to clock. A camera was set up to record Locus Pocus clock activity. The test run was made using a vehicle to visit the locations. I was assisted by a driver, and I took video footage of the locations as they were visited - focusing on entry to the location. For each location, we arrived and paused briefly (on the order of 30 seconds), before moving on to the next. The test run took just over 30 minutes overall.

The test was very successful. The IFTTT app triggered entry/exit for each location accurately, the messages were transmitted, processed, and received by the Locus Pocus system, and the clock updated correctly in response.

Each location had accurate triggers for entry and exit. A location exit would typically set the clock to "Transit". For some of the locations, however, the display moved directly from the previous location to the new location. On review, the Locus Pocus system was working just fine. All trigger events were received and processed, but the travel time from one location to another ("Home" to "Shopping", "Prison" to "Peril", Work to "Lost") was short enough that the hand location redirected to the newly entered location before it had completed movement to "Transit". You can even observe the hand pause slightly for picking up the new destination between "Prison" and "Peril".

The following video shows the test run with location movements and Locus Pocus response. Video resolution for the clock face may not be as crisp, given Fab Academy file size requirements, so I am inclulding a reference image.

Locus Pocus Whereabouts Clock

Locus Pocus Whereabouts Clock

Locus Pocus - Live Testing - Full Test Run

I have also included the status messages from the Locus Pocus Primary Control console. Notably, "exited" type messages from the Adafruit IO broker are translated into "transit" action messages for the clockwork.

Locus Pocus - Primary Control Console Messages
Received location data from Broker
<- h1:home@exited
-- Clock message would be: h1:transit
-- sending update to Clock Peripheral via BLE
--> h1:transit
Received location data from Broker
<- h1:shopping@entered
-- Clock message would be: h1:shopping
-- sending update to Clock Peripheral via BLE
--> h1:shopping
Received location data from Broker
<- h1:shopping@exited
-- Clock message would be: h1:transit
-- sending update to Clock Peripheral via BLE
--> h1:transit
Received location data from Broker
<- h1:prison@entered
-- Clock message would be: h1:prison
-- sending update to Clock Peripheral via BLE
--> h1:prison
Received location data from Broker
<- h1:prison@exited
-- Clock message would be: h1:transit
-- sending update to Clock Peripheral via BLE
--> h1:transit
Received location data from Broker
<- h1:peril@entered
-- Clock message would be: h1:peril
-- sending update to Clock Peripheral via BLE
--> h1:peril
Received location data from Broker
<- h1:peril@exited
-- Clock message would be: h1:transit
-- sending update to Clock Peripheral via BLE
--> h1:transit
Received location data from Broker
<- h1:holidays@entered
-- Clock message would be: h1:holidays
-- sending update to Clock Peripheral via BLE
--> h1:holidays
Received location data from Broker
<- h1:holidays@exited
-- Clock message would be: h1:transit
-- sending update to Clock Peripheral via BLE
--> h1:transit
Received location data from Broker
<- h1:work@entered
-- Clock message would be: h1:work
-- sending update to Clock Peripheral via BLE
--> h1:work
Received location data from Broker
<- h1:work@exited
-- Clock message would be: h1:transit
-- sending update to Clock Peripheral via BLE
--> h1:transit
Received location data from Broker
<- h1:lost@entered
-- Clock message would be: h1:lost
-- sending update to Clock Peripheral via BLE
--> h1:lost
Received location data from Broker
<- h1:lost@exited
-- Clock message would be: h1:transit
-- sending update to Clock Peripheral via BLE
--> h1:transit
Received location data from Broker
<- h1:home@entered
-- Clock message would be: h1:home
-- sending update to Clock Peripheral via BLE
--> h1:home