zsup

test

zsup

int motion = 0;
int buzzer = 1;

void setup() {
  pinMode(motion, INPUT);
  pinMode(buzzer, OUTPUT);
  Spark.variable(motion);
  Spark.function(buzz);
}

zsup

/**
 ******************************************************************************
 * @file    spark_wiring_servo.h
 * @author  Zach Supalla
 * @version V1.0.0
 * @date    06-December-2013
 * @brief   Header for spark_wiring_servo.h module
 ******************************************************************************
  Copyright (c) 2013 Spark Labs, Inc.  All rights reserved.
  Copyright (c) 2010 LeafLabs, LLC.

zsup

TCPClient client;

void setup() {
    Serial.begin(9600);
    
    Spark.function("connect", connect_to_my_server);
    
    for (int pin = D0; pin <= D7; ++pin) {
        pinMode(pin, OUTPUT);
    }

zsup

TCPClient client;

void setup() {
    Serial.begin(9600);
    
    Spark.function("connect", connect_to_my_server);
    
    for (int pin = D0; pin <= D7; ++pin) {
        pinMode(pin, OUTPUT);
    }

zsup

TCPClient client;

void setup() {
    Serial.begin(9600);
    
    Spark.function("connect", connect_to_my_server);
    
    for (int pin = D0; pin <= D7; ++pin) {
        pinMode(pin, OUTPUT);
    }

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.

zsup

// The most basic event, without data.
Spark.publish("motion-detected");

// Some events require additional data.
Spark.publish("temperature", "19 F");  

// You can set a TTL to persist data in the cloud...
Spark.publish("lake-depth/1", "28", 21600);

// ...and make events private for secure applications.

zsup

/*
 * Connected sensor
 * Spark.publish() + PIR motion sensor = awesome
 * Thanks to Adafruit for the reference and inspiration
 */

int inputPin = D0;              // choose the input pin (for PIR sensor)
int pirState = LOW;             // we start, assuming no motion detected
int val = 0;                    // variable for reading the pin status
int calibrateTime = 10000;      // wait for the thingy to calibrate

zsup

By default, the Spark Core connects to the Cloud and processes messages automatically. However there are many cases where a user will want to take control over that connection. The following methods are available to control the connectivity of the Spark Core.

System modes

There are three available system modes: AUTOMATIC, MANUAL_CONNECT, and MANUAL. These modes describe how connectivity is handled.

System modes must be called before the setup() function.

System.mode(AUTOMATIC)