Tasmota: MAX31865 Support

[AlbertoLopSie]

Any chance to add support for the MAX31865 RTD-to-Digital (for PT100/PT1000 probes) ?

Already supported MAX31855 chip is only for thermocuples. Resistive RTD probes are very popular in swimming pool, water heating and ambient temperature sensing .

I'm able to program in several languages (C/C++, Python, JS and others) but am not very familiar with the Tasmota environment and architecture.

If someone can point me in the right direction I'm willing to invest some coding hours in this feature. I even have a swimming pool waiting to test it !! 😀

Thanks!

[meingraham]

https://github.com/arendst/Sonoff-Tasmota/tree/development/sonoff
https://github.com/arendst/Sonoff-Tasmota/wiki/Sensor-API

[ascillato2]

Closing this issue as it has been answered.

---

Support Information (Guide)

See Wiki for more information.
See FAQ for common questions/answers and links if none of your question is in the list.
See Chat for more user experience.
See Community for forum.
See Code of Conduct

[AlbertoLopSie]

Closing this issue as it has been answered.

Support Information (Guide)

See Wiki for more information.
See FAQ for common questions/answers and links if none of your question is in the list.
See Chat for more user experience.
See Community for forum.
See Code of Conduct

Hola Adrian, como andás?

Do you really think it has really been answered? Perhaps the request for further information has, but the feature request has not.

I would suggest to keep this issue opened waiting for more people willing to contribute on it. I realize there were another user asking for the same request some time ago, but his request was also promptly closed with a "_We don't support it. Sorry. You can develop it yourself_" reply. IMHO that's the not the best way of handling "Feature Requests", is it?

I'll start cloning this repo and try to develop the MAX31865 driver perhaps this weekend. Could anyone point me on the steps I should follow to handle you the resulting code in order to be included on future releases the same way MAX31855 is?

Thank you very much!

[ascillato]

Do you really think it has really been answered? Perhaps the request for further information has, but the feature request has not.

Sorry if you have taken that personally. We are a small group of free voluteers for this project and we can't develop all the feature requests. If you are interested on supporting this device and make the driver for it, we are gladly to help.

I'll start cloning this repo and try to develop the MAX31865 driver perhaps this weekend.

Great news! If you need assistance, please, find us in the Tasmota Support Chat.

Could anyone point me on the steps I should follow to handle you the resulting code in order to be included on future releases the same way MAX31855 is?

A pull request is the best way to review the code.

Looking forward to it. Thanks.

[meingraham]

@AlbertoLopSie https://github.com/arendst/Sonoff-Tasmota/wiki/Sensor-API

[AlbertoLopSie]

Do you really think it has really been answered? Perhaps the request for further information has, but the feature request has not.

Sorry if you have taken that personally. We are a small group of free voluteers for this project and we can't develop all the feature requests. If you are interested on supporting this device and make the driver for it, we are gladly to help.

I'll start cloning this repo and try to develop the MAX31865 driver perhaps this weekend.

Great news! If you need assistance, please, find us in the Tasmota Support Chat.

Could anyone point me on the steps I should follow to handle you the resulting code in order to be included on future releases the same way MAX31855 is?

A pull request is the best way to review the code.

Looking forward to it. Thanks.

Thank you Adrian! I'll keep in touch!

[AlbertoLopSie]

@AlbertoLopSie https://github.com/arendst/Sonoff-Tasmota/wiki/Sensor-API

Reading it at this very moment...

Congratulations!! You have made a wonderful documentation work !!!

[AlbertoLopSie]

Adrian,

Having taken a look at the support _Tasmota Support Chat_ it looks more than a _User Support_ chat, not a developer one. It's not threaded, and the messages scrolls with no control. I guess it's intended to short request-reply dialogs than code discussions. Am I wrong?

If you don't mind I'd rather keep code developing discussions on this feature right here, where one can find al the related info gathered together. What do you think?

First developing question:

Looking at the MAX31855 supporting code, my first temptation is to start modifying right over it given it already contains a lot of useful code (SPI, xsns callback func, etc).

One approach would be to generate a brand new _xsns_nn_max31865.ino_ source file. Another one is to try to support both chips with the same code, let's name it _xsns_39_max318x5.ino_.

On the first case it would imply to add a complete new sensor to the already constrained Tasmota code base, with perhaps some necessary UI changes on the GPIO configuration web dialogs, and other yet unknown (for me) changes on code structure.

The second approach would be more surgical, making only a few changes on an already present (and tested) piece of code. It could use less code & RAM space and could reuse existing GPIO assignments. It would, however, potentially breaks existing running code until proper testing.

What do you think about? Is there any coding policy about this?

[meingraham]

it looks more than a User Support chat, not a developer one. It's not threaded, and the messages scrolls with no control. I guess it's intended to short request-reply dialogs than code discussions. Am I wrong?

Not going to disagree. Only suggest that perhaps you could use the private message once you establish a dialog with a "developer" sort of chap.

Otherwise, this forum, yes.

[ascillato]

What do you think about? Is there any coding policy about this?

Your idea is good. The policy from Theo is to use as few RAM and FLASH as possible and modify as few files as possible, so for testing you can make a new driver file, but in the end, having both devices in the same file would be the best.

Thanks for working on this

[AlbertoLopSie]

Good news!! I finally have the MAX31865 fully operating with Tasmota on a Sonoff TH10 !!!

Now, I would like to contribute adding it to the repo. However, I have some work ahead to do it.

1) The integration was achieved modifying over the existing MAX31855 source file (xsns_39_max31855.ino), in order to merging with existing code I have to rename it to xsns_nn_max318g5.ino and modify several (some unknown to me) places on Tasmota code to make it included.

First thing, I would need a new nn XSNS number. How do I produce one? Who assigns them?
What other things do I need to modify to get it included in build?

There's a way of merging the 31865 code inside the 31855 existing one, but i would be a little messy and IMHO the chances of having both chips working together at the same time are almost none (besides the massive needs of GPIO pins necessary for that)

IT COULD be handled by conditional compilation driven by a USE31865 #define in _my_user_config.h_, but I don't see it fitting on the general Tasmota coding style.

Trying to merge both codes into the same source file makes little sense to me. They share very liitle code.

2) Given I'm using a MAX31865 Adafruit breakout module it looked natural to use the Adafruit MAX31865 Library I've noticed several Adafruit libraries already used in the Tasmota code. Is there any problem adding the MAX31865 one?

I had to modify the original library. I had to modify the constructor methods and adding an initialization func to be able to initialize GPIO pins definitions after Tasmota reads them from config and not with a static initialization like the library was primarily intended. (I spent most the debugging time trying to figure out why the statically constructed Max31865 class object wasn't working !! I had to pull my oscilloscope out from my shelf to figure it out !!)

3) Finally, I guess I should produce some doc for the new sensor integration. How do I do that?

Alberto

[ascillato]

Good news!! I finally have the MAX31865 fully operating with Tasmota on a Sonoff TH10 !!!

Great !!!! :+1:

1

You can make a new Pull Request for Theo to review it, with:

A- Adding a new file (_xsns_47_max31865.ino_) with your new driver.

Inside the file remember to change the #define for the driver from

#ifdef USE_MAX31855 to #ifdef USE_MAX31865

Remember to change the callbacks for the driver from

#define XSNS_39 39 to #define XSNS_47 47

and

bool Xsns39(uint8_t function) to bool Xsns47(uint8_t function)

(Tasmota will handle the callbacks automatically)

B- And adding a new key inside the file _my_user_config.h_

//#define USE_MAX31865

(Add the define as disabled by default in order to not make the file size grow for all types of firmwares. If a user needs this driver, he/she can enable it and compile)

Your PR should have only the driver file, the addition key to the _my_user_config.h_ file and the library. The rest of files from Tasmota should not be modified unless it is really needed.

2

About Adafruit libraries, there is no problem with them. The only drawback is that those are made generic for several types of microcontrollers. So, they are not optimized for esp8266 and hence for Tasmota. Sometimes this led to use more flash and ram than required or having more code than needed. That is why, some other Tasmota's drivers has inside everything they need. Anyway, I think we can start with the libraries and in the future they can be optimized.

3

You can add some info in the wiki

[AlbertoLopSie]

Thank you Adrian! I'll start tomorrow (my wife is starting to throw some poisoned looks to me 🤨)

[AlbertoLopSie]

Hi Adrian,

I've got the PR almost ready but before submitting it I have a few things to implement and need advice:

PTD come in several formats, they may have 2, 3 o 4 wires. Additional wires are used by the MAX31865 chip to try to discriminate the resistive effect of long wires and subtract it from the actual PTD resistance.

Besides the differences on the wiring (that are handled with some jumpers on the board) we have to inform it to the chip on the initialization stage in order it could be able to perform the right math.

I'm testing with a simple 2-wire PT100 probe, but in real world applications 3 o 4 wire PTD are more commonly used. It should be a user configuration variable to be stored somewhere and sent to the MAX31865.

Likewise, the standard 0-degree (Celsius) temperature of the PTD is a variable used in temperature computation. A PT100 probe it's supposed to have 100 ohms, and a PT1000 should have 1 KOhm. Real world PTDs not always have the nominal value, leading to some measure errors. In addition, I can't know in advance if the future user of this MAX31865 integration will connect it to a PT100 o PT1000 probe. A variable to store the real 0 degree resistance of a particular PTD would be also necessary.

How do I create those user-defined variables? #defines in my_user_config.h? Or there is any way to allow user to edit them at run time?

BTW... Does it make sense to have this thread still "Closed"?

[ascillato2]

How do I create those user-defined variables? #defines in my_user_config.h? Or there is any way to allow user to edit them at run time?

As a start, you can add them as #defines in my_user_config.h so to let users to use this new driver.

Then, as an upgrade (better in another PR), those can be added to Tasmota settings, adding SENSOR47 command as other drivers use.

[ascillato2]

Thanks for working on this :+1:

[AlbertoLopSie]

Thanks for working on this 👍

👍You are welcome!

[ascillato]

I think it is best from Discord chat (https://discord.gg/Ks2Kzd4) because it is very easy to exchange files and code there and discuss it. You can PM me there. I'm not using Facebook very often. Sorry.

[joba-1]

easier than a preliminary pull request? Then you would have the real code to refer to and add commits as the discussion progresses. Just my 2ct...

[AlbertoLopSie]

easier than a preliminary pull request? Then you would have the real code to refer to and add commits as the discussion progresses. Just my 2ct...

Yeah... you're probably right... Sorry, but the moment I was packing it up to submit the PR, Atom decided to upgrade itself and broke my PlatformIO installation ... 🙄

Coming in a few minutes...

[AlbertoLopSie]

PR submitted. Please review it and give me a hand with those Travis test I don't have a clue about 🤓

[ascillato]

@AlbertoLopSie how is your username on Discord?

[AlbertoLopSie]

@AlbertoLopSie how is your username on Discord?

@ascillato albertols#4351

_{Sent with GitHawk}