Home
The TH12 th12 is an internet connected low-power wireless temperature and humidity sensor. It uses 2xAA batteries and has 3 to 5 years of run life with the standard configuration parameters.
The TH12 th12 uses [6LoWPAN] 6lp and RPL rpl to autoconfigure a globally routeable IPv6 address. Once connected, you interact with it using CoAP coap, a RESTful UDP based protocol.
This software is based on the Contiki Operating System and is released under the same open source license.
On power up, the RED led flashes
on. The TH12 then stays awake for wake_time seconds. During this time, RPL rpl is establishing the
IPv6 address for the TH12 th12. Once the routing has been established,
the TH12 th12 will POST it's sensor data as a JSON to the
configured location (default is coap://coap-8.lowpan.com/th12).
An example reading is below:
{"eui":"ec473c4d12bdd1ce","t":" 24.5C","h":"18.7%","vb":"3048mV"}
The eui field is the EUI64 mac address of the TH12 th12 reporting node. t is the current temperature, h is the humidity, and vb is the battery voltage.
The TH12 th12 reports this data at the specified interval and periodically checks that the other end is listening (if not, the TH12 th12 does the best that if can to recover. For details see Recovering from Errors).
If the POST is sucessful, and the TH12 is not in low-power mode, then the GREEN led will turn on.
Most of the time the TH12 th12 is lies dormant with its radio completely off. In this mode it draws a very small amount of current (12 uA) from its batteries and therefore consumes very little power. There are also some very efficient power converters that strive to get the most from your batteries. See the Wake Current analysis for more details.
There are several parameters that can be configured in the TH12. The
are all under the /config resource. You GET or POST to them using
the param=foo query string:
The following example uses coap-client to perform a GET on the
netloc parameter; it returns the host part of the location the TH12
will POST its data to:
coap-client coap://[2002:c63d:eeef:8:ee47:3c4d:12bd:d1ce]/config?param=netloc
returns:
coap-8.lowpan.com
To set this parameter, POST the desired value to it.
| URI | Description | Default |
| /config?param=interval | The time in seconds between data POSTs to the sink. | 120 seconds |
| /config?param=wake_time | The time in seconds to stay awake after power up or reset | 120 seconds |
| /config?param=channel | The 802.15.4 channel to use. POSTing to this parameter will cause the [TH12] [th12] to reset. | Channel 16 |
| /config?param=netloc | the host part of the data sink location. POSTing to this resource will cause an immediate data POST to occur. | coap-8.lowpan.com |
| /config?param=path | the path part of the data sink location. POSTing to this resource will cause an immediate data POST to occur. | /th12 |
| /config?param=ip | An IPv6 address for the sink. This is used instead if 'netloc' is empty | null |
| /config?param=sleep_allowed | Set to 1 or 0. If 0, the [TH12] [th12] will not enter low-power mode | 1 |
| /config?param=posts_per_check | Total number of posts to do for every post that verifies the other end is listening. See details in [Recovering from Errors](#errors) | 4 |
| /config?param=max_post_fails | Total number failed checks allowed before causing the device to reboot. See details in [Recovering f\ rom Errors](#errors) | 3 |
The TH12 th12 does the best it can to recover from errors. Periodically, according to the value of 'posts_per_check', the TH12 th12 sends a "confirmable" POST (using a CoAP CON message). This type of POST instructs the sink that an acknowledgment of the POST should be sent. In addition, CON messages will also be retried 4 times over 60 secs to help ensure that they arrive in a lossy network environment. All other times, the TH12 th12 sends a "non-confirmable" (NON) message which is essentially a single raw UDP datagram.
The 60 second timeout for a CON message is particularly costly as the radio's receiver needs to stay ON during this time. For this reason, the TH12 th12 only performs these "sink checks" infrequently. If 'max_post_fails' number of "sink checks" fail, then the TH12 th12 assumes the worst and reboots.
Also aside from using CON during these sink checks, the TH12 th12 also does a fresh DNS lookup for the sink. In this way, the sink end can change with minimal disruption; the TH12 th12 will get the new address once it has propagated.