Home sensors database - optimising model
Quick Note
You probably want to ensure that a measurement of 760 mm Mg is not accidentally identified as a Temperature measurement.  As such, you really want to keep the two values in different columns (with appropriate CHECK constraints).
Now What?

Temperature IS A measurement
Humidity IS A measurement
Pressure IS A measurement

There are a few ways to build &quot;IS A&quot; relationships in a database.
The method I am recommending has a one &quot;master&quot; measurement table and a &quot;specific&quot; table for each type of measurement.  You'll need to decide if you can group some measurements together; in which case, they'll go into the same &quot;specifics&quot; table.
-- pseudo code.  Actual would be RDBMS specific

create table measurements_meta (
  measurement_id  int primary key, -- &quot;Specifics&quot; tables get the same ID.  therefore, the same column name.
  sensor_id       int not null references sensors(id), -- I dropped the unnecessary TBL_ prefix
  room_id         int not null references rooms(id),
  time_of_measure datetime not null default now()
);

create table measurements_temp (
  -- this enforces the 1:0 or 1 relationship
  measurement_id int primary key references measurements_meta( measurement_id ),
  temperature    number not null check ( temperature between -40 and 150), -- F
);

create view temperature
as
select a.*, b.temperature
from measurements_meta a
  join measurements_temp b on a.measurement_id=b.measurement_id;

-- RDBMS Specific
create trigger temperature_tr
instead of insert or update or delete
on temperature
before each row
-- fill in code here to do the actual DML

grant select, insert, update, delete on temperature to my_app_user_role;

In this design, the data Model remains hidden from the application.  The application will View the data through the VIEW. Control of the data (DML) is done through simple CRUD operations on the VIEW or through APIs (stored PROCEDURES).  TL;DR - I suggest you use the MVC design pattern.
If you can take multiple (simultaneous) readings (eg 2 thermometers for 1 device), the individual readings would go into a child table under that &quot;specifics&quot; table.  The &quot;specifics&quot; table would record the average.  You would need to use an API (instead of CRUD on the VIEW) which can take in the required number of reading in one call (eg an array of temperatures).