Arduino House Monitor – Protocol

This is the protocol I used to transport the raw data. Its not secure, efficient or even quick, however it does work. Its designed to be event driven, but has scope for polling.

To interchange data, you’ve go to know how its formatted, which means making a protocol. This is the simplest part of the whole build, well should have been. If you’ve been following the build, you’ll know I use the Xport Direct to handle IP communications. The library that talks to the Xport has a bug which intermittently corrupts incoming data over 4-9 bytes. This ruled out wordy HTTP style syntax. Instead the following key “words” are used:

For the Client:

  • p:
  • t:
  • d:

For the Server:

  • corr
  • report(not implemented)
  • Yarp? (debug)
  • Narp? (also debug)
Here are the finer, sexier details:
The Power Blip Report (p:)
Example: p:6
Event type, [(Int), Number of event since last update, optional]
The power blip can be used with or with out an argument. Without an argument it represents a single power meter flash, or 1/1000th of a Kilowatt hour.
You can optionally supply an integer which indicates that 24 flashes have occurred since the last update. The server does not properly support this usage and will assume that 24 blips happened at once. It is also not implemented in firmware.
The Temperature Report (t:)
Example: t:28 58 C4 64 1 0 0 99:15.643
Event type,      1-wire address,     (Float)Temperature
All arguments are required. The 1-Wire address comprises of 8 sets of  non padded Hex pairs, separated by spaces. A classy choice. The temperature is expected to be a float, and is delimited from the 1-wire address by a colon “:
The Door Lock Report (d:)
Example: d:2:o
Event type, (Int)Door number, Door status code (must be one of the following o/c/l open, closed, locked respectively)

All Arguments are required. Again arguments are delimited by a colon “:“. The door can be in one of three states: Open, Closed and Locked.

Supplemental notes:

All the client reports are triggered either by an event or an internal timer. After each report the Client expects acknowledgement from the server in the form of a “corr” If acknowledgement is not received in a given time the client will mark it as a “lost report”. If too many lost reports occur then the client physically resets. 

Response (corr)
Acknowledgement of report
Its really that simple. After every report, the server must respond with corr, or the client will mark the report as lost.Response (Yarp?)
Unrecognised report type/syntax
This will only appear when the server has debugging enabled. If you feed the server a malformed report it’ll reply with a Yarp? This is useful for debugging. Its only amusing for the first five minutes, after that it becomes increasingly infuriating.

Response (Narp?)
Notice of disconnection
Again if the server is in debug mode, it will spit out a Narp? if its going to disconnect you. This usually happens when you send to much data, or too many malformed reports.

Response (report)
Send report for all sensors NOT IMPLEMENTED…yet
This, as yet unimplemented command is designed to allow the server to poll the arduino. The idea being that it would cut down the number of duplicated temperature reports, and offer some sort of protection agains transient network links.

So that’s the end of that, for the moment. Have a look for the description of the client/server software.

Leave a Reply

Your email address will not be published. Required fields are marked *