A Berry application for DS18B20 temperature sensors

[wjohn007]

This application

• scans the 1-Wire bus looking for DS18B20-sensors
• captures the ID of each existing sensor
• acquires the temperature values from the sensors
• checks the validity of the values
• detects fault situations
• each sensor value can be adjusted via offset
• shows a nice UI with the sensor data and some controls
• transmits the temperature-values ​​via sensor-message

More Information in the Repository.

[sfromis]

You're productive :-)

One suggestion to enhance this driver would be to support the standard Tasmota options for temperatures in C/F (SetOption8), number of decimals (TempRes) and maybe temperature offset (TempOffset, yes I know you have a per-sensor variant there).

This driver has an example of how those settings can be processed to create a function to format and convert values.
https://github.com/TomsTek/tasmota-berry-TMP117-driver/blob/main/tmp117.be#L37-L50

[wjohn007]

@sfromis
Thank you very much for the comment and the tips. I'll take a look at this.
John

[wjohn007]

As per @sfromis' suggestions, the following has changed:

SetOption8 is now supported

• The sensor values ​​are adjusted immediately after acquisition
• The Value of 'TempOffset' is used as default offset for non-registered sensors

According to the documentation, “TempRes” is used in the sensor acquisition phase.
This cannot currently be changed, so it doesn't make sense to use it.

The user can anyway adapt the UI to their own needs. (take a look to file DallasTemp01.be).

dallasTemp.onBuildWebView = 
def() ...

---

My recommendations to the developer of temp117.be:

• The rules created should be released again in the destructor, otherwise the instance will never be released by the GC.
• This can be a unit testing nightmare.

John

[sfromis]

Both TempRes, SetOption8 and TempOffset can be changed dynamically, to update how sensors are displayed, without restarting. Not sure where you saw something about "sensor acquisition phase", but the values are "acquired" all the time, as in Tasmota calling the driver to provide the JSON with values, also when the values will not actually be displayed or published. Usually every second.

With sensor drivers, my preference is to use standard Tasmota options as far as practical, which works great for both TempRes and SetOption8. Of course, with your driver TempOffset is "less practical" to use.

As all 3 options can be changed anytime, with TMP117 it was a deliberate choice to keep the matching rules around while Tasmota is operating with the driver, and the act of the class adding itself as a driver means that it will not be released unless removed again, which is not expected as the driver includes no self-destruct mechanism. No problem with unit-testing really, you can either restart Tasmota, or with current Tasmota versions, use a build including a "Restart Berry VM" button in the "Berry Scripting console".

Anyway, for a smoother workflow, my preference is indeed to have the driver init() include self-replacement code like:

    var id = 'SampleDriver'
    tasmota.remove_driver(global.SampleDriver_instance)
    tasmota.remove_rule('TempRes', id)
    tasmota.add_rule('TempRes', /values, trigger, payload -> self.processUpdate(values, trigger, payload), id)
    tasmota.add_driver(global.SampleDriver_instance := self)