Premium · for people who already have a setup

Letting your thermostat send the readings

If you already own a WiFi thermostat or hygrometer, there is no reason to retype the numbers. Squamy gives you a key and an address: your setup sends the reading, and you find it in the app at the next sync.

Why it works backwards

The natural question is: why don't you read my thermostat yourselves? Two reasons, and neither is solved by writing code.

The first is that to read your sensors we would have to keep your SmartLife account credentials. Those would be the most sensitive data in the whole product — more than your enclosure data, which harms nobody if lost — and a leak would be our responsibility.

The second is that the free tier of the Tuya APIs, the ones behind SmartLife and most twenty-euro thermostats, is explicitly «for development only». Using it for real requires a commercial contract, at a cost that does not stand up for a €3.99/month subscription.

Reversing the direction removes both. In exchange the coverage is no longer «the brands we managed to integrate» but anything that can make an HTTP request — a much bigger set than any list we could have built.

Getting started

1. In the app: menu → API & integrations. Requires Premium.
2. Switch «Ingestion on». While it is off no key can write: it is the switch that stops everything at once if you ever need it.
3. Create a key and name it after where you put it («Home Assistant», «Living room Pi»).
4. Copy it right away. It is shown only once: the server keeps only its fingerprint, so not even we can show it to you again. If you lose it, generate another — that costs one tap.
5. The same screen has examples already filled in with your enclosure, and a «Try the call» button that sends the real request without storing anything.

Sending a reading

One POST, with the key in the header and three fields in the body:

curl -X POST https://<project>.supabase.co/functions/v1/api/v1/readings \
  -H "Authorization: Bearer sqk_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"enclosure": "Desert 120", "parameter": "temp_hot", "value": 31.4, "unit": "°C"}'

You name the enclosure the way you call it in the app — nobody wants to paste an identifier into a config file. Ids and aliases work too. If you have two enclosures with the same name the request is rejected rather than guessed: two different enclosures house different species and have different temperature bands, so a reading in the wrong place is not a crooked chart — it is an alert that never fires.

The unit is optional (without it, the parameter's reference unit is used) and can be written loosely: C, celsius, °C. The value accepts a comma too: "31,4" is fine, because that is what an Italian-locale template produces.

The parameters

Key	What it is	Units
temp_hot	Basking spot	°C · °F · K
temp_cool	Cool side	°C · °F · K
temp_night	Night temperature	°C · °F · K
substrate_temp	Substrate temperature	°C · °F · K
humidity	Humidity	%
uvi	UV index	UVI

If you created your own parameters, those work too, with their own unit.

Home Assistant

It is where most integrations will come from: if you run it, you already have your Tuya, Zigbee and Bluetooth sensors inside. In configuration.yaml:

rest_command:
  squamy_temp_hot:
    url: "https://<project>.supabase.co/functions/v1/api/v1/readings"
    method: POST
    headers:
      Authorization: "Bearer sqk_YOUR_KEY"
      Content-Type: "application/json"
    payload: >-
      {"enclosure": "Desert 120", "parameter": "temp_hot",
       "value": {{ states("sensor.temp_hot_enclosure") }} }

Then an automation calling it every hour. The app gives you this very block already filled in with your enclosure's name: copy it from there.

How often

Parameter	One reading every
The four temperatures and humidity	60 minutes
UV index and your own parameters	24 hours

Faster serves no purpose: a value every five minutes adds no information, it adds rows and unreadable charts. Temperatures and humidity sit together because they are the two things a setup really measures continuously — and humidity in an enclosure swings through the day more than temperature does, between misting and air exchange. UV index, on the other hand, is measured with a meter you point by hand, now and then.

There is also a cap of 500 requests per day per key. At the rates above you use a few dozen: it is there to stop a runaway automation, not you.

If you send too fast the answer is 429 and it tells you how many seconds to wait. A reading typed by hand in the app does not count: the check only looks at ones that arrived through the API, because they are two different gestures that can coexist in the same day.

When something goes wrong

Response	What it means
401 invalid_token	The key does not exist, or was revoked.
403 api_disabled	The switch is off in the app.
403 premium_required	The subscription linked to the key is not active.
400 unknown_enclosure	No enclosure by that name. List them with GET /v1/enclosures.
400 ambiguous_enclosure	Two enclosures share that name: use the id, which the response gives you.
400 bad_measured_at	The date is in the future or over a year old. Almost always the device clock, or an epoch in seconds read as milliseconds.
429 too_soon	Too early for that parameter: the response says how long to wait.

Every response carries a message written to be read by a person: if an automation is not working, that is where to look.

The questions everybody asks

If I cancel Premium, do I lose the key? No, the key stays: it simply stops writing. If you renew, your integrations start again without touching your config files.

Can I see which readings came from the sensor? Yes. Every reading keeps its source, and in the history you can tell the sensor's from your own.

Can I revoke a key? Any time, from the app. And switching ingestion off stops them all at once, immediately, without revoking them one by one.

Back to the FAQ