data_pranav
@banerjee-p · Joined May 2026
Data analyst · retail · 16 years in the field
- Topics
- 1
- Replies
- 7
- Points
- 0
Forum Replies Created
Can a row open that site’s own page? Eight sites in one table is fine, but I want the details one click away.
Thanks Megan, this settled it. The proposal now says LoRaWAN EU868 meters from two makers whose codecs are already in the library. City the client can ask about separately, the meters don’t depend on it. We booked a coverage survey for three gateway spots.
tsmith, for us it’ll depend on the survey, I’ll post the numbers when we have them.
That’s roughly what our procurement person said. The vendor’s meter list was three models long.
I spent years staring at cold chain data with exactly this pattern. Part of your coupling sits in the measured variable itself, because RH depends on temperature. Every time the heater raises the air temperature by 1 C, RH at that moisture content drops by roughly 3 to 4 points, so your humidity loop reacts to the heater even when no water has left the air.
Two changes that usually settle it:
1. Control a humidity measure that doesn’t move with temperature: absolute humidity (g/m3) or dew point. Compute it on the ESP32 from temp and RH (Magnus formula) and run the humidifier on that. At a fixed temp setpoint, 60 %RH at 25 C is about 13.8 g/m3, so that becomes your setpoint.
2. Separate the speeds. Keep the temperature loop fast and make the humidity loop at least 5 times slower (a minimum on time and off time for the humidifier, say 60 s each, and a deadband of about 0.5 g/m3). Then the temperature loop absorbs the mist’s cooling before the humidity loop decides anything.
For the board, Megan’s chart is the right one. In the line chart’s Series rows set rh and humid_on to Value axis Right, add a threshold line at your setpoints, and send abs_hum as a fifth key so you can watch the new loop. Chart settings are on Chart cards.
I fuse glass and have a ceramics friend I set up exactly this for, so I’ve been through the shopping list.
Measurement: use a MAX31856 breakout instead of the MAX6675. It reads K, but also R and S, and handles the full range. For a kiln going to cone 10, an S or R type probe in a ceramic (alumina) protection tube is what kiln makers fit themselves. It’s pricier than K but doesn’t drift the way K does at 1250+. If you stay at cone 6 most of the time, a heavy-gauge K in a ceramic sheath is acceptable, just plan to replace it. Mount the probe through the wall at the same depth as the kiln’s own one so the two readings compare.
Send it as kiln_c every 30 s or so, plus kiln_fault from the MAX31856’s fault register.
Alarm rule on the profile, written in JSON mode because I wanted dampening defaults kept and two severities:
{
"type": "kiln_overfire",
"title": "{{device.name}}: {{value}} °C",
"severities": [
{ "severity": "CRITICAL", "condition": { "key": "kiln_c", "op": ">", "value": 1290 } },
{ "severity": "MAJOR", "condition": { "key": "kiln_c", "op": ">", "value": { "attribute": "max_c" } } }
],
"debounce": { "mode": "count", "raise": 3, "clear": 3 },
"hysteresis": 15,
"enabled": true
}max_c is a device attribute you change per firing (1240 for cone 6), so a normal firing never touches it. The CRITICAL line is the “something is very wrong” ceiling. Three readings in a row means a noisy spike won’t wake you. See Debounce, hysteresis and dampening.
“Stays hot too long” can’t be done in a profile alarm rule since it can’t track time since the firing began. I used a Rules card with a value trigger “rises above 600 and stays so for” 720 minutes, then notify.
And keep a real over-temperature cutout in the kiln’s power circuit. The cloud tells you, it can’t open the contactor if the Wi-Fi is down.
I don’t think so. The Exporting data page says there are no built-in scheduled or e-mailed reports. Cards have a CSV and Excel download, but that’s someone clicking.
And keep the readings in a list while the port is gone, then send them with their own ts once it’s back. Otherwise every replug leaves a hole in the history.