Тема: household
-
Журнал температуры компоста: фиксированные точки замера, фиксированная глубина, температура воздуха рядом с кучей и каждое перемешивание как событие
Предлагаемый протокол наблюдения для садовой компостной кучи или бокса: термометр с длинным щупом, показания которого снимаются в отмеченных точках замера на заданной глубине по фиксированному расписанию, температура воздуха рядом с кучей в тот же момент, а каждое добавление материала, перемешивание или полив заносятся в журнал отдельной строкой-событием, — чтобы подъём, плато и спад температуры кучи можно было сопоставить с тем, что с ней делали; никакая целевая температура или результат не утверждаются.
-
Запись показаний бытового термометра в ледяной бане: журнал смещения показаний для каждого прибора
Предлагаемый протокол, ограниченный только записью показаний и следующий описанию точки таяния льда по NIST (дроблёный лёд из дистиллированной воды, смесь лёд-вода сверху донизу, заданная глубина погружения), чтобы фиксировать, что показывает каждый бытовой термометр при номинальных 0 °C, вместе с датой, деталями подготовки и временем, за которое показание стабилизировалось; протокол ведёт историю смещений по каждому прибору и не даёт никаких рекомендаций по калибровке или по применению для пищевых продуктов.
-
Как нужно ставить домашнее сравнение всхожести семян, чтобы результаты двух разных домохозяйств можно было сопоставить?
Открытый вопрос: лаборатории проверяют семена по Международным правилам испытания семян ISTA, но у домохозяйств, сравнивающих две партии семян или два подоконника, нет общего протокола; какие размеры выборки, правила подсчёта, длительность и записи об условиях делают такие домашние сравнения информативными и сопоставимыми между разными домохозяйствами?
-
Which household records fix the start and end of a power outage after the fact, and how far have they disagreed?
Open question: after a power cut a household has several clocks of the event, such as the utility's notice, a UPS log, a router's uptime, a home server's reboot records (the last(1) manual page states that last reboot produces a record of reboot times, and journalctl can list boots with the timestamps of each boot's first and last message), a battery clock that kept time and a mains clock that flashes; which of these have households actually used, how far did they disagree, and which gave the earliest and latest bounds?
-
Inventorying a home library or toolbox: identifiers, locations and a check cycle
Keeping a home inventory of books or tools as a plain table: a stable identifier per item (the ISBN for books, a self-assigned code for tools), location codes with a legend, condition in a fixed vocabulary, lending fields and a periodic walk that marks what is missing instead of deleting it; no valuation or insurance advice is given.
-
A grocery price log with the unit price computed from the pack: barcode identity, pack quantity, shelf price and promotion flag per observation
A proposed record-only protocol for logging grocery prices in which each observation carries the product's barcode number as its identity, the pack quantity as printed, the shelf price and any promotion or loyalty condition, and a unit price computed by the household in a stated unit, following the definition in EU Directive 98/6/EC of the unit price as the final price per kilogramme, litre, metre, square metre or cubic metre; a changed pack size becomes a new product row, and no purchasing advice or inflation figure is given.
-
Household log entries written from memory at the end of the day show more rounded values than entries written at the moment of reading
Hypothesis: when a meter, scale or thermometer reading is written down hours later from memory, the recorded value is more often a round number (ending in 0 or 5, or with fewer decimals) than when it is written at the instrument; a proposed within-household test with alternating days and photographs as the reference, with no claim about which value is closer to the truth.
-
Checking a kitchen scale with coins of published mass: a repeatability, range and corner-load record
A proposed record-only protocol for a household scale: use new coins whose nominal mass the issuing mint publishes as reference masses, log readings for single coins and stacks across the scale's range, repeat placements, test the four corners and a timed hold, and keep the sheet per scale; no adjustment and no pass or fail judgement is part of it.
-
A watering and growth log for houseplants: fixed measurement points and photographs
A proposed observation log for potted plants: measurement points defined once (height from the pot rim, leaf count above a stated size, largest leaf length), watering recorded by volume or mass, position and events, and a weekly photograph under the same conditions, so that growth can be compared over time and between plants; no care advice is given.
-
Two consumer hygrometers in one room disagree less on dew point than on relative humidity
Hypothesis: two consumer temperature-humidity devices placed at different spots in one room report relative humidity values that differ mainly because their temperatures differ, so the dew points computed from each device's own pair agree more closely than the raw RH readings once the fixed inter-device offset is removed; no measurement is reported.
-
Measuring home internet throughput repeatably: a fixed-path, fixed-schedule protocol
A proposed protocol for a household throughput and latency series: hold the device, the wired or wireless path, the test tool and the server constant, run three consecutive tests in three fixed daily slots for two weeks, log connection count and household activity with each run, and read RFC 6349's bandwidth-delay product and single-versus-multiple-connection points as reasons why tool settings change the number; nothing is claimed about any provider.
-
An expense categorisation log as a method: frozen category list, numbered edge-case rules and a re-coding check
A proposed documentation method for household spending records: freeze a category list with definitions before coding, keep one row per transaction with amount, currency, payee as printed and a rule identifier, turn every edge-case decision into a numbered rule, and re-code a blind sample monthly to measure self-agreement; it produces interpretable category totals and gives no financial advice.
-
A heating-season log: heating input, indoor temperature and degree days on one timeline
A proposed protocol for one heating season: read the household's heating input (a heat, gas or electricity meter or thermostat runtime) at a fixed time, log indoor temperature and setpoint changes beside it, derive heating degree days from logged daily highs and lows with a stated base, and keep a conditions column so that a month's consumption can be checked against weather and events; no target temperature or saving is asserted.
-
Reading a household electricity meter on a fixed schedule: an observation protocol
A proposed protocol for logging the cumulative kWh reading shown on a household meter at fixed times, together with the register followed, the display resolution and the household conditions, so that daily differences are comparable between logs; nothing but the display is looked at, and no consumption figure is claimed.
-
How comparable are phone light-meter app readings of indoor plant positions between phones and apps?
Open question: phone apps report illuminance in lux for a windowsill or shelf, reading either the ambient light sensor that Android documents most manufacturers use to control screen brightness, or an estimate from the camera; what is known about agreement between two phones at the same spot and time, the effect of orientation and screen glass, and which logging conventions would let two households compare plant positions?
-
Logging a consumer PM2.5 sensor: what to record beside each reading and what the number cannot say
A consumer particulate sensor reports an estimate of the mass of particles 2.5 micrometres and smaller; the EPA states that such sensors come with lower accuracy and higher uncertainty than regulatory monitors, describes collocation with reference instruments as an effective way to assess them, and notes that an outdoor correction may not apply indoors and that changing temperature and humidity may affect some sensors. A household log therefore stores the raw value, the averaging interval, placement, indoor events and the nearest official monitor's value with its distance.
-
A home weather diary: what a garden or balcony sensor records and why it differs from the official station
A home weather diary is only comparable with other records when the sensor's exposure is written down: the Met Office measures air temperature in a naturally ventilated Stevenson screen 1.25 m above the ground, while a sensor on a wall, under an eave or in sunlight measures its own surroundings; the article describes the diary columns, the exposure description and the home-minus-station difference series.
-
A houseplant leaf-condition and pest-sighting log with tagged leaves and fixed photographs
A proposed observation protocol for houseplants: tag three leaves per plant, photograph upper and lower surfaces weekly against the same background, record spots, edge condition, residue, webbing and counted visible insects in a fixed vocabulary, count dropped leaves between visits, and keep identification attempts separate from the observations; no treatment is stated.
-
Mass versus volume in cooking: which cup is meant, and how to record the conversion actually used
A cup, tablespoon or teaspoon is a volume whose definition differs between the US customary units listed by NIST and the rounded values used on US nutrition labels, and the mass it holds depends on the ingredient and how it was filled; a household that converts between mass and volume records the definition it used and its own weighed values so that a recipe can be reproduced.
-
A parcel delivery time log: order, dispatch, tracking and door timestamps on one row, with the carrier's scan and the observed arrival kept apart
A proposed record-only protocol for logging each parcel's timeline as timestamps in the RFC 3339 Internet Date/Time Format with UTC offsets, taken from the order confirmation, the dispatch notice, the carrier's tracking events and the household's own note of the arrival, with the carrier, service, delivery place and each attempt recorded; the carrier's delivered scan and the observed arrival are separate columns, and no carrier comparison or delivery-time claim is made.
Машиночитаемо: JSON