zeppelin500 / mbusino Goto Github PK

Most DS18B20 are faked and out of specifications.
A new code is in development, that build the average of the connected sensors and add an offset to every sensor. After the calibration, all sensors will show the same value.
Calibration will be initiate by a published MQTT message.
You have to bring all connected sensors to the same environment, wait a little bit and send the calibration message.

Next step is calibration to a connected BME280 or a transmitted value.

Originally posted by @Zeppelin500 in #8

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.

Hello,

thank you for the solution. It is exactly what I am looking for and helps me get my planned meters into HA.

I want to setup my house using four Engelmann Sensostar U. (Basement --> start, ground floor, first floor, second floor)

In the readme it says we are limited to three devices? What causes these limitations? Could it be avoided or do I just setup a secondary esp to tackle the problem?

"Das Shield ist ein mit Fritzing konstruiertes Board. Der M-Bus wird über einen aufsteckbaren M-Bus Master bereitgestellt. https://de.aliexpress.com/item/33008746192.html --> der Master!"

This link points to a different board with at least partielly different pinning (only two pins for MBUS.
I found offers on aliexpress to the correct board, eg.:
https://www.aliexpress.com/item/1005004664326197.html?spm=a2g0o.cart.0.0.140338dajc8E4F&mp=1

Describe the bug
mqtt password exposed in plain text in topic MBusino/settings/pswd.

Expected behavior
a password should never be actively exposed

Additional context
I guess it should be self explainatory that this behaviour is a no-go from a security perspective. I guess is was implemented for debugging purposes not nevertheless there should be at least an option to disable this behaviour.

Apart from two or three stumbling blocks, the setup was very simple and Mbusino reports to the MQTT server. I'll have to make sure that I connect the mBus master in the next few days and read out real values.

I have noticed several things:

1. I entered the wrong MQTT password during AP setup. I then wanted to change it. I read the IP of the board from the router and accessed it in the browser. I entered the MQTT data correctly. I did not enter anything for WiFi as I did not want to make any changes here. However, this resulted in the board being kicked out of my WiFi and after a short time the AP was unblocked. I suspect that the SSID and WiFi PW were overwritten with empty characters.
2. a little hint that you should only enter the IP (without https) for the mqtt server would be helpful.
3. my FritzBox shows the board as "ESP-6752EB" and not as the entered name "Mbusino". With other D1 mini boards the naming works.