One OneWire bus to rule them all

[rschiemann1]

As pointed out in discussion #3, we could start using one oneWire-Bus for all oneWire sensors that one would like to connect to MBusino. This is much different to the current implementation, which has 5 separated oneWire buses (with 5 GPIOs on their data lines).

Advantages:

• arbitrarily many oneWire sensors can be connected to MBusino
• Only one GPIO is used instead of 5

Disadvantages:

• Software needs to handle multiple sensors on the same bus and possibly their adresses
• Somewhat more difficult mapping of sensor values to physical sensors by the end user

Some preliminary ideas for the realization:

1. MBusino could scan the oneWire bus for all connected sensors and their adresses once per boot, or additionally upon request, if needed. From each sensor's adress, a sensor ID is derived, which could read "28-28B1-970E-0000" for example.
2. For each discovered sensor, two mqtt topics are created: mbusino/[sensorID]/measuredValue and mbusino/[sensorID]/offset. Offset can be set via mqtt from the outside to calibrate sensors.
3. Above logic should create a working system without the need to somehow hardcode sensor adresses.

Open questions:

1. Do we need/want to save the known adresses of the sensors to the EEPROM and re-use them on next boot? Is this solution any better than just scanning the bus once per boot?
2. Do we need/want to save the offset values for each sensor to the EEPROM and re-use them on next boot? If yes, how do map in the EEPROM to which sensor ID an offset value belongs to? If no, the offset values need to come from the mqtt broker on the next startup, which can be realized by making these topics retained.

Please let me know your comments, ideas, doubts.

[Zeppelin500]

Answer, see discussions (in german only)