<commit_before># analogjson

An arduino web server with JSON interface to the digital and analog IO functions of an Arduino.

The idea behind this is you can access the full functionality of the analogRead/digitalRead/digitalWrite etc functions of the Arduino via network operations (assuming you have an Ethernet shield of course). And, of course, it provides a framework for showing you how to implement other simple JSON HTTP APIs.

Licensed under the MIT license for maximum flexibility; see the LICENSE file for details.

## Development Status
I ran test calls in a loop to an Arduino running this code; over a period of roughly 5 days more than 4 million API calls have been executed without any problems (and the test is still running strong). The code should be considered as released and stable at this point.


## APIs implemented

All endpoints start with /v1 to indicate version number (1) of this protocol.

* **GET /v1/analogRead/{PINNUMBER}**

    Performs an analogRead on pin {PINNUMBER} and returns a JSON "pins" list as described below.

* **POST /v1/analogRead**

    Reads any number of pins and returns a JSON "pins" list as described below. The POST data must be a JSON object with this form:

    `{ "pins" : nn }`

    which will read a single pin as indicated by `nn`, or:

    `{ "pins" : [ nn, mm, ... ] }`

    which will read multiple pins as indicated by `nn`, `mm`, and so forth.

    Returns a JSON "pins" list as described below.

    There is an arbitrary compiled-in limit on the number of pins you can read in one operation.

    When reading one or more pins, the server returns JSON that looks like this:

    `{ "pins" : [ { "pin" : nn, "value" : vv } ... ] }`

    where the number of `{ "pin" : nn, "value" : vv }` elements in the array will correspond to the number of pin readings you requested (one for the simple GET form; possibly N for the JSON POST form of request).


* **GET /v1/digitalRead/{PINNUMBER}** ... same as analogRead but digital.

* **POST /v1/digitalRead** ... same as analogRead but digital.

* **POST /v1/digitalWrite**

    Writes any number of pins (digitalWrite). You post JSON that looks like:

    `{ "writes" : [ { "pin" : nn, "value" : vv } ... ] }`

    and the given values are written to the given pins. Values can be the literals `HIGH` or `LOW` (case SENSITIVE), or numbers. By repeating pin/value pairs inside the array you can write multiple pins with one HTTP transaction (they are, of course, still multiple API calls inside the Arduino).

    No data is returned (just HTTP 200 OK).

* **POST /v1/configure/pinmode**

    lets you call pinMode on a given pin. The POSTed data should look like:

    `{ "modes" : [ { "pin" : nn, "mode" : mm } ... ] }`

    the mode values can be numbers or the literals INPUT, OUTPUT, or INPUT_PULLUP. Multiple pins can be configured in a single HTTP transaction. Be mindful of the overall size limits on JSON requests/responses.

    No data is returned (just HTTP 200 OK).<commit_msg>Added IRsend capability. Moved many strings into PROGMEM.<commit_after># analogjson

An arduino web server with JSON interface to the digital and analog IO functions of an Arduino.

The idea behind this is you can access the full functionality of the analogRead/digitalRead/digitalWrite etc functions of the Arduino via network operations (assuming you have an Ethernet shield of course). And, of course, it provides a framework for showing you how to implement other simple JSON HTTP APIs.

Licensed under the MIT license for maximum flexibility; see the LICENSE file for details.

## Infrared Remote Support

The code has been extended to include abilit to send IR codes using the IRRemote library. You can conditionally build the program with just the IR support, just the analog/digital I/O support, or both. You may instead wish to take this code as an example or starting point and fully customize it for your own application as well.

## Development Status
I have tested most of the code but have not written or executed exhaustive tests of every feature. I'm using this code in my own projects and find it useful; your mileage may vary!

## APIs implemented

All endpoints start with /v1 to indicate version number (1) of this protocol.

* **GET /v1/analogRead/{PINNUMBER}**

    Performs an analogRead on pin {PINNUMBER} and returns a JSON "pins" list as described below.

* **POST /v1/analogRead**

    Reads any number of pins and returns a JSON "pins" list as described below. The POST data must be a JSON object with this form:

    `{ "pins" : nn }`

    which will read a single pin as indicated by `nn`, or:

    `{ "pins" : [ nn, mm, ... ] }`

    which will read multiple pins as indicated by `nn`, `mm`, and so forth.

    Returns a JSON "pins" list as described below.

    There is an arbitrary compiled-in limit on the number of pins you can read in one operation.

    When reading one or more pins, the server returns JSON that looks like this:

    `{ "pins" : [ { "pin" : nn, "value" : vv } ... ] }`

    where the number of `{ "pin" : nn, "value" : vv }` elements in the array will correspond to the number of pin readings you requested (one for the simple GET form; possibly N for the JSON POST form of request).


* **GET /v1/digitalRead/{PINNUMBER}** ... same as analogRead but digital.

* **POST /v1/digitalRead** ... same as analogRead but digital.

* **POST /v1/digitalWrite**

    Writes any number of pins (digitalWrite). You post JSON that looks like:

    `{ "writes" : [ { "pin" : nn, "value" : vv } ... ] }`

    and the given values are written to the given pins. Values can be the literals `HIGH` or `LOW` (case SENSITIVE), or numbers. By repeating pin/value pairs inside the array you can write multiple pins with one HTTP transaction (they are, of course, still multiple API calls inside the Arduino).

    No data is returned (just HTTP 200 OK).

* **POST /v1/configure/pinmode**

    lets you call pinMode on a given pin. The POSTed data should look like:

    `{ "modes" : [ { "pin" : nn, "mode" : mm } ... ] }`

    the mode values can be numbers or the literals INPUT, OUTPUT, or INPUT_PULLUP. Multiple pins can be configured in a single HTTP transaction. Be mindful of the overall size limits on JSON requests/responses.

    As a special case the mode can be BUSY. Setting a pin to BUSY causes it to be configured as an OUTPUT and driven HIGH during request processing and LOW otherwise.

    A successful configuration request returns HTTP 200 OK.
{'fraction_non_alphanumeric': 0.07662717341129405, 'fraction_numerical': 0.004616094783812894, 'mean_word_length': 3.458161865569273, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2692413', 'n_tokens_mistral': 1849, 'n_tokens_neox': 1706, 'n_words': 991}