Correct task architecture under Laravel?

Question

Laravel

Good afternoon, I am making a small smart home system on laravel, thus getting acquainted with the framework and orm.
There is a task to add sensors and devices to the database, they are divided into 3 types:
1. relays - they can only be turned on and off
2. temperature, humidity and other sensors that return values, for them it is necessary to lay the possibility of setting a timer, according to which survey
3. instantaneous sensors, for example, motion sensors, they need to lay a special property that will say that the sensor is without a timer
. And the question arises of how to correctly design such a bundle, I imagine using the collective farm classical method, but I don’t understand how to put all this into the laravel paradigm.
Now there is an understanding that you need to create 3 models:
1. Units - a general table of all possible sensors
2. UnitProperties - the properties of these sensors (timer, instant polling, turn on off)
3. DeviceUnits - the ratio of the smart home board and the unique sensor
itself ? How to correlate at the end the functionality of a separate each sensor and directly the behavior of the sensor on the board.

Answer 1

The link model is not required.
The connection is already created inside the models using the
BelongTo
HasOne HasMany
methods,
etc.
And yet, it seems to me it would be more convenient to have your own controller and your own model for each sensor.
Since they perform quite different functions and their meanings are also different. If we are trying to connect a thermometer that has the same value in degrees in a single table with an IR motion sensor that can already have 5 properties and naturally in completely different values. Which forces us to either break all possible NF, or produce a bunch of connected tables. or even worse, use the EAV model
In general, I see the situation like this
I think that it is unlikely that the system will have sensors and boards added every day -> nothing prevents each sensor from being considered a separate entity with its parameters and functions
in the same model controllers in the database we store the behavior of the sensor on the board again everything is simple and easy
in the end, SQL is good when we need data integrity) and here you can generally push everything in a key-value pair into REDIS and not take a steam bath at all + it will work faster)