Allow using both bme280 addresses simultaneously #3124

heikomat · 2020-05-24T11:52:38Z

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)

Lua 5.1 to 5.3 realignement phase 1

…cu#2914) This reverts commit 32ad759.

Fixes nodemcu#2920

Fixes nodemcu#2928, nodemcu#2923

The internal implementation already preferentially forwards to the encoder module, so we should just remove these functions as they confuse people into thinking that we don't have their inverses (see the feature request nodemcu#2907). Update the docs to refer to the encoder version and add deprecation warnings to the runtime implementations.

fix lfs upload issue

* clean effects library * Fix several issues in ws2812 and effects * Implement working way of calling shift from callback

* Remove app/include/netif/wlan_lwip_if.h This file appears to be unused in our tree. * New `net.if.info` call to show LwIP information This is a generalization of `wifi.sta`'s and `wifi.ap`'s `getip` and `getmac` calls. I don't propose to deprecate those, but perhaps we should, in the documentation, point users at this function instead. The direct motivation is to permit continued use of DHCP-provided NTP servers in a future where nodemcu#2819 has landed, now that nodemcu#2709 is in the tree. But rather than exposing just that information, a more general interface seems useful.

* Remove stale putative MD2 support This hasn't worked in a while, presumably since one of our upstream merges. Don't bother making it work, since MD2 is generally considered insecure. * Land mbedtls 2.16.3-77-gf02988e57 * TLS: remove some dead code from espconn_mbedtls There was some... frankly kind of scary buffer and data shuffling if ESP8266_PLATFORM was defined. Since we don't, in fact, define that preprocessor symbol, just drop the code lest anyone (possibly future-me) be scared. * TLS: espconn_mbedtls: run through astyle No functional changes * TLS: espconn_mbedtls: put the file_params on the stack There's no need to malloc a structure that's used only locally. * TLS: Further minor tidying of mbedtls glue What an absolute shitshow this is. mbedtls should absolutely not be mentioned inside sys/socket.h and app/mbedtls/app/lwIPSocket.c is not so much glue as it as a complete copy of a random subset of lwIP; it should go, but we aren't there yet. Get rid of the mysterious "mbedlts_record" struct, which housed merely a length of bytes sent solely for gating the "record sent" callback. Remove spurious __attribute__((weak)) from symbols not otherwise defined and rename them to emphasize that they are not actually part of mbedtls proper. * TLS: Rampage esp mbedtls glue and delete unused code This at least makes the shitshow smaller * TLS: lwip: fix some memp definitions I presume these also need the new arguments * TLS: Remove more non-NodeMCU code from our mbedtls * TLS: drop support for 1.1 Depending on who you ask it's either EOL already or EOL soon, so we may as well get rid of it now.

* Add missing globals from luacheck config * Fix luacheck warnings in all lua files * Re-enable luacheck in Travis * Speed up Travis by using preinstalled LuaRocks * Fix more luacheck warnings in httpserver lua module * Fix DCC module and add appropriate definitions to luacheck config. * Change inline comments from ignoring block to only ignore specific line * Add Luacheck for Windows and enable it for both Windows and Linux * Change luacheck exceptions and fix errors from 1st round of polishing * Add retry and timeout params to wget

Also clean-up a nasty `ow` module example.

* fix build * poor mans link which also works on docker under windows * Delete espconn.h * resurecting it as regular file * Add missing newline Co-authored-by: Marcel Stör <[email protected]>

Correct typo in Lua export from updateDispla() to updateDisplay()

* Net_info module exposing ping function initial commit * Ping as a part of net module * Sent callback implemented * Add NET_PING_ENABLE macro Authored-by: vsky <[email protected]> with support from TerryE

Fixes nodemcu#3089

@anod221

Original sources by @anod221

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

nwf · 2020-05-24T20:04:03Z

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 · 2020-05-24T20:10:19Z

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 · 2020-05-24T20:21:39Z

@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 · 2020-05-24T20:33:28Z

👍 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 · 2020-05-24T22:07:26Z

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 · 2020-05-24T22:14:47Z

@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 · 2020-05-29T20:31:31Z

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

heikomat · 2020-05-29T20:34:03Z

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

marcelstoer · 2020-08-29T19:35:13Z

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

nwf · 2020-08-30T02:07:06Z

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

vsky279 · 2020-10-02T22:47:25Z

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

nwf · 2020-10-06T10:26:40Z

@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 · 2020-10-06T10:38:03Z

@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 :)

TerryE and others added 30 commits July 23, 2019 19:16

Lua 5.1 to 5.3 realignement phase 1

14c1b8f

Add telnet example

ba03cb0

Updates following JM review

bc98174

Rebased against current dev

39bb60e

Rebased against current dev, tweaks for clean compile

522b1d0

Merge pull request nodemcu#2836 from TerryE/dev-new-lua.c

fff9f95

Lua 5.1 to 5.3 realignement phase 1

Add streaming support for hx711 device (nodemcu#2793)

32ad759

Revert "Add streaming support for hx711 device (nodemcu#2793)" (nodem…

4c3d45e

…cu#2914) This reverts commit 32ad759.

Remove superfluous module def

81e213a

Fixes nodemcu#2920

Fix invalid smartconfig include

04287ac

Fixes nodemcu#2928, nodemcu#2923

Fix typos

f3044e1

fix lfs upload issue

0e34f7d

Merge pull request nodemcu#2961 from seregaxvm/lfsfix

f3b4984

fix lfs upload issue

Improve MQTT documentation (nodemcu#2967)

e3935de

Improve httpserver documentation (nodemcu#2971)

9a2579d

Update sensor driver for BME680 to 3.5.9 (nodemcu#2969)

c7d0f83

Fixes for ws2812 and ws2812_effects (nodemcu#2953)

b179f30

* clean effects library * Fix several issues in ws2812 and effects * Implement working way of calling shift from callback

Streaming support for hx711 (nodemcu#2915)

4fc2b85

fixed missing forward declaration (nodemcu#2975)

d84da36

Initial version of software UART C module (nodemcu#2673)

52a1587

Add DCC decoder module (nodemcu#2905)

1652c0c

Minor typo and wording fixes (nodemcu#2991)

7ed3d00

Add CRC check (nodemcu#2992)

8c08e76

Also clean-up a nasty `ow` module example.

Fix compile warning and set correct order in module LROT (nodemcu#2996)

5278944

Expose CPU CCOUNT register as tmr function (nodemcu#2906)

1c83f02

Clarify LFS build info is its size (nodemcu#3022)

49f25bd

HHHartmann and others added 11 commits April 30, 2020 03:37

resurecting it as regular file

3d2c989

Add missing newline

b6bfe1c

Fix Windows build (nodemcu#3084)

314ca4f

* fix build * poor mans link which also works on docker under windows * Delete espconn.h * resurecting it as regular file * Add missing newline Co-authored-by: Marcel Stör <[email protected]>

Add another LFS size value

88a33af

u8g2: Fix name of updateDisplay export (nodemcu#3093)

89d268f

Correct typo in Lua export from updateDispla() to updateDisplay()

net_info module - ping function (nodemcu#2854)

2f527cf

* Net_info module exposing ping function initial commit * Ping as a part of net module * Sent callback implemented * Add NET_PING_ENABLE macro Authored-by: vsky <[email protected]> with support from TerryE

Update hook after updating GPIO bits (nodemcu#3091)

2e58471

Fixes nodemcu#3089

Fix binary and chunked HTTP downloads (nodemcu#2985)

6e5edf4

Original sources by @anod221

fix compilation error when disabling startup banner (nodemcu#3103)

5e2ea5a

Update wifi..c to fix nodemcu#3106

50fcd72

heikomat mentioned this pull request May 24, 2020

BME280 module does not allow coexistence of two BME280s on the same I2C bus #2241

Closed

nwf mentioned this pull request May 24, 2020

Rewrite bme280 driver in Lua+C #3126

Closed

vsky279 mentioned this pull request May 29, 2020

bme280 driver in Lua+C #3132

Merged

4 tasks

marcelstoer force-pushed the dev branch from 78ae85b to 8d091c4 Compare June 9, 2020 20:30

nwf added the obsolescence The inevitable march of time gets us all label Oct 6, 2020

nwf closed this Oct 6, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow using both bme280 addresses simultaneously #3124

Allow using both bme280 addresses simultaneously #3124

heikomat commented May 24, 2020 •

edited

Loading

nwf commented May 24, 2020

nwf commented May 24, 2020

heikomat commented May 24, 2020 •

edited

Loading

nwf commented May 24, 2020

nwf commented May 24, 2020

heikomat commented May 24, 2020 •

edited

Loading

vsky279 commented May 29, 2020

heikomat commented May 29, 2020

marcelstoer commented Aug 29, 2020

nwf commented Aug 30, 2020

vsky279 commented Oct 2, 2020

nwf commented Oct 6, 2020

heikomat commented Oct 6, 2020

Allow using both bme280 addresses simultaneously #3124

Allow using both bme280 addresses simultaneously #3124

Conversation

heikomat commented May 24, 2020 • edited Loading

nwf commented May 24, 2020

nwf commented May 24, 2020

heikomat commented May 24, 2020 • edited Loading

nwf commented May 24, 2020

nwf commented May 24, 2020

heikomat commented May 24, 2020 • edited Loading

vsky279 commented May 29, 2020

heikomat commented May 29, 2020

marcelstoer commented Aug 29, 2020

nwf commented Aug 30, 2020

vsky279 commented Oct 2, 2020

nwf commented Oct 6, 2020

heikomat commented Oct 6, 2020

heikomat commented May 24, 2020 •

edited

Loading

heikomat commented May 24, 2020 •

edited

Loading

heikomat commented May 24, 2020 •

edited

Loading