To make the stuff modular, we need to choose the interfaces.
We need a way to discover newly connected modules and to communicate with them.
The obvious choice is I2C, but it has one disadvantage - one node can block the bus.
We can of course add bus switches to mitigate such case.
Another thing is its speed. It is not that critical in case of sensor readout, but if you have several such modules, that can become a bottleneck. Good thins is that here are plenty of sensors with I2C interface. But they cannot be placed too far from the controller.
Another popular IFC is SPI.
It's high speed, only one slave is selected at a time.
UART is yet another interface. It's problematic in case of multi-channel controller because needs that much UART peripherals. Sending data is trivial, but reception is not because some sensors (air quality, thermometers, GPS) transmit data asynchronously. There are chips that one can hook up to the SPI or I2C and have as many UART channels as needed. One need a MCU to hook up another type of sensor, however there are ICS that support UART -I2C/SPI conversion
MODBUS RTU is much better in this sense because it responds only when requested. It's great and nice to have because one can use COTS components like energy meter, relays, motor controllers, etc. To hook up a sensor one needs to use MCU.
Analog signalling - some sensors still use analog signalling, i.e. 4-20mA loops, temperature sensor, 0-10V industrial controllers. But this can be easily mitigated using little MCU, I2C/SPI ADC/DAC chip.
CAN - popular in automotive industry, there are some sensors that use this interface, but I don't know low cost MCUs that supports it.
So I have two ideas:
Use SPI + I2C within same connector. I2C is for readout of tiny EEPROM that holds ID and description table of the sensor proprieties which is then transferred to the MQTT broker.
It may also contain binary of the driver that is loaded to the main MCU memory and is responsible for sensor readout. Instead of I2C, we can use SPI memory as well. On every sensor side we use dedicated SPI to anything converter chip.
Use MODBUS. Advantage is very simple connectivity - just 2..3 wires which are shared among all devices. Since tiny CPU cost is roughly quater of $, it's not a big deal to add such CPU to every node. Then type of interface we use is secondary thing and everything gets standarized because all complexity is hidden in this tiny MCU. Other MODBUS devices can be connected directly. For devices that use UART to asynchronously transfer messages, MCU does buffering or even some processing.
From cost point of view, second approach is cheaper because bridges that convert UART, I2C, 1Wire, analog, to SPI are roughly 2$ per piece. The only complexity is code maintenance, but it needs to be maintained anyway either as dedicated MCU code or main controller sensor driver.
To make the stuff modular, we need to choose the interfaces. We need a way to discover newly connected modules and to communicate with them. The obvious choice is I2C, but it has one disadvantage - one node can block the bus. We can of course add bus switches to mitigate such case. Another thing is its speed. It is not that critical in case of sensor readout, but if you have several such modules, that can become a bottleneck. Good thins is that here are plenty of sensors with I2C interface. But they cannot be placed too far from the controller.
Another popular IFC is SPI. It's high speed, only one slave is selected at a time.
UART is yet another interface. It's problematic in case of multi-channel controller because needs that much UART peripherals. Sending data is trivial, but reception is not because some sensors (air quality, thermometers, GPS) transmit data asynchronously. There are chips that one can hook up to the SPI or I2C and have as many UART channels as needed. One need a MCU to hook up another type of sensor, however there are ICS that support UART -I2C/SPI conversion
MODBUS RTU is much better in this sense because it responds only when requested. It's great and nice to have because one can use COTS components like energy meter, relays, motor controllers, etc. To hook up a sensor one needs to use MCU.
Analog signalling - some sensors still use analog signalling, i.e. 4-20mA loops, temperature sensor, 0-10V industrial controllers. But this can be easily mitigated using little MCU, I2C/SPI ADC/DAC chip.
CAN - popular in automotive industry, there are some sensors that use this interface, but I don't know low cost MCUs that supports it.
So I have two ideas:
Use SPI + I2C within same connector. I2C is for readout of tiny EEPROM that holds ID and description table of the sensor proprieties which is then transferred to the MQTT broker. It may also contain binary of the driver that is loaded to the main MCU memory and is responsible for sensor readout. Instead of I2C, we can use SPI memory as well. On every sensor side we use dedicated SPI to anything converter chip.
Use MODBUS. Advantage is very simple connectivity - just 2..3 wires which are shared among all devices. Since tiny CPU cost is roughly quater of $, it's not a big deal to add such CPU to every node. Then type of interface we use is secondary thing and everything gets standarized because all complexity is hidden in this tiny MCU. Other MODBUS devices can be connected directly. For devices that use UART to asynchronously transfer messages, MCU does buffering or even some processing.
From cost point of view, second approach is cheaper because bridges that convert UART, I2C, 1Wire, analog, to SPI are roughly 2$ per piece. The only complexity is code maintenance, but it needs to be maintained anyway either as dedicated MCU code or main controller sensor driver.