Allow using both bme280 addresses simultaneously

[heikomat]

Fixes #2241

• This PR is for the dev branch rather than for master.
• This PR is compliant with the other contributing guidelines as well (if not, please describe why).
• I have thoroughly tested my contribution.
• The code changes are reflected in the documentation at docs/*.

This adds an optional use-alternate-address-parameter to all read-methods of the bme280
module.
if not set, the behaviour is unchanged and the first available device will be used.
If set to true, the device at address 0x77 will be used.

This module is also used for the nearly identical bmp280 (seems to be the same, but without the humidity sensor), and it has an internal flag for that.
I adjusted the code, so that it should work with a bme280 and bmp280 on the same bus, but i only own some bme280, no bmp280, so i couldn't test that.

I tested:

• A single bme280 on address 0x76 without the new option
• A single bme280 on address 0x77 without the new option
• A single bme280 on address 0x77 with the new option
• One bme280 on address 0x76 and one on address 0x77, with and without the new option

This is the code i used for testing:

i2c.setup(0, 7, 6, i2c.SLOW)
bme280.setup()

tmr.create():alarm(350 , tmr.ALARM_AUTO, function(timer)
  temp1, pressure1, humidity1 = bme280.read()
  temp2, pressure2, humidity2 = bme280.read(nil, true)
  print(temp1, temp2, pressure1, pressure2, humidity1, humidity2)
end)

[nwf]

These changes seem sensible, but I wonder if you'd be willing to do some more invasive work and help us dig the project out of technical debt we've accumulated. Specifically, I don't think this needs as much C as it currently uses, and I think splitting the module the way I envision would also solve your problem and let things work with multiple I2C busses or I2C bridge devices. While I am not categorically opposed to C modules, this one strikes me as just begging to be rewritten in Lua+C much as my sntppkt rewrote sntp. (See the in-progress #2819.)

Specifically, I wonder if you could...

• in Lua, do all the I2C transactions with the device: do just enough of the protocol to get the message as a mostly uninterpreted Lua string.
• pass that message down to a C module to do the requisite math and bit fiddling, which is, admittedly, generally easier in C than Lua.
• have C return back a Lua table.

In sntppkt, it was necessary to hold on to multiple response messages, and these became Lua userdata structures. I don't believe that's requisite here, but if it is the same kind of "Lua string -> userdata -> combine/merge/process many userdata -> Lua table" flow seems like a viable strategy.

The upshot of all this is that the C code doesn't need to know about I2C device addresses or busses or platform communication layers or anything like that, it just needs to know how to process sensor reports.

[nwf]

Speaking of digging us out of technical debt, it would also be phenomenal (but not required) if you could propose a test plan for bme280 devices. Something that doesn't depend too much on the actual environment, but is enough to walk the device and our driver through the wire protocol. Something like:

• Put a BME280 on the I2C bus, at 0x76.
• Initialize it, using bme280.init(...).
• Verify initialization successful, by reading back the mumbledefrotz configuration register, using bme280.foobar(...) == 0x123456.
• Ask it to take a reading and verify that the result is within plausibility for a developer's desk on Earth. That looks like bme280.quux(...) and bme280.frotz(...)...

[heikomat]

@nwf I'd be willing to help here, though i'm not sure how long that would take.

I'm neither a Lua, nor a C developer, and am not very familiar with the codebase.
I have worked with both superficially, have years of development experience in general and am a quick learner though.
This means i'm pretty sure that i would be able to do it, but it also means that i'd need a significant amount of (free-)time to learn the codebase, make myself familier with all aspects of the bme280 module and protocol, create a clear plan of what a debt-free implementation would look like and get it right.

I'd suggest the following:

• I do this, but without any promises on when it will be ready, as spending free-time on this would often not be of top priority
• It would be done on a different branch, as the refactor would be out if the scope of this one
• Planning would happen in a separate issue
• In that Issue, you could describe your plan and ideas in detail, and with that as a base, the target architecture and structure can be discussed

[nwf]

👍 SGTM. I see no reason to hold up this PR for that longer-term work. SWIM should probably give things a once-over, tho'; @TerryE?

[nwf]

I've landed a proposal in #3126; commentary would be more than welcome.

And... Looking more at bme280.c for that writeup, I worry that this PR's (forgive me) somewhat "quick-and-dirty" support for two devices is not going to work out well; static variables like bme280_h and bme280_hc appear to persist between measurements and will therefore cross-contaminate the two devices. (We really, really should abolish the word static from non-functions in our codebase. This is terrible.)

[heikomat]

@nwf it's ok, i know that this PR is not a very clean solution -> Because i don't know the codebase very well, it is meant to introduce as few changes as possible, and therefore works with what is there. There is definitely no offense taken here on my part :)

it's now midnight where i live, and i gotta work tomorrow, so i'll probably be able to read through your proposal tomorrow evening

[vsky279]

#3132 should properly fix this issue. @heikomat can you please check? I don't have two BME280 sensors with me.

[heikomat]

@vsky279 that was quick! :o
I can't test it today, but will be able to test it tomorrow!

[marcelstoer]

This needs a make over. Why do we see 77 commits? Did you start from the wrong base branch?

[nwf]

The needed rebasing might be fallout from our dev branch shenanigans a while back.

[vsky279]

Shouldn't we close this one when there's PR #3132. I'm running this one in some application without any issues.

[nwf]

@heikomat Does @vsky279's new module work for your use case? If so, I think we can close this as overtaken by events; if not, we should rebase and merge this as an interim fix and it would be very good to know why the new module doesn't.

[heikomat]

@nwf I haven't worked on my project in months, as it is working fine and not a priority. I understand that having an additional test-case to make sure everything works is beneficial, but I suggest just moving on with the module from @vsky279 :)