Multiple SHT30 sensors on a single I2C bus with Sonoff-Tasmota
I have a hankering to measure the input and output temperatures of my condensing boiler, in order to determine if it's likely to be actually condensing at any time. I have lots of SHT30 sensors, which attach handily to NodeMCU units. However, running 2 separate rigs, one each for input and output, means that temperature measurements will not be synchronised, which doesn't account for the action of the boiler and its heat output rate of change.
It appears that the SHT30 has two I2C addresses (0x44 and 0x45), which are available on the Wemos D1 knock-offs that I have. So I started out by modifying one to use a different bus from the standard one - this is easily done by bridging a link with solder. I then used 2 NodeMCUs running together to check that the newly addressed device is actually detected and works. It does.
So, let's see what we can do, eh? I'm a complete newbie at Github, so I've just copied the xsns_14_sht3x.ino module from the original Github into my own repository. This is, like most maintenance/modification work, moderately non-trivial, requiring a reasonable understanding of the entire programme really, or at least, how all the interfaces from this module rely on other modules and assumptions about what they do.
It appears that the SHT30 has two I2C addresses (0x44 and 0x45), which are available on the Wemos D1 knock-offs that I have. So I started out by modifying one to use a different bus from the standard one - this is easily done by bridging a link with solder. I then used 2 NodeMCUs running together to check that the newly addressed device is actually detected and works. It does.
Pair of NodeMCU/SHT30 setups in action |
Close-up of SHT30 devices -RH(44) has soldered address link (circled) |
Right. Did that. Believe it or not, it actually works! At least, I am getting MQTT messages with my new JSON in:
16:53:37 MQT: tele/sonoff/SENSOR =
{"Time":"2018-02-18T16:53:37",
"SHT3X":[
{"Address":"0x44","Temperature":22.8,"Humidity":41.0},{"Address":"0x45","Temperature":22.6,"Humidity":41.9}],
"TempUnit":"C"}
Getting all the pins connected was a bit boring, because the PCBs are so wide there's no extra holes beside the pins. I had to use the nominal +/- power strips, for power and for SCL/SDA pins respectively.
However, I seem to have broken the Web interface, which is no longer showing the SHT3X Temp/Humidity in the header of the main page. And it crashes when I ask for the Main Menu, a memory fault (of course!! Sodding C++ and its horrible implied mallocs... all Strings are BAD!).
I hadn't used the programme's preferred approach of putting all formatting strings into const PROGMEM variables, just on the basis of expediency. I think I might purge my code of inline strings altogether, but since it uses fragments (because it has a header, a loop, and a trailer) it won't use a single formatting string like the existing ones.
Looking at the actual content, the interesting thing is that these sensors are very close in value. When they were connected to separate NodeMCUs, they were at least 1 deg / 2% different, consistently. I guess operating them from a single ESP8266 and its single power supply ensures the closest match.
A few tweaks, mostly to the dratted strings used to drive the Web formatting and the Main Menu display is working. It's very clever! It uses a JS function to perform HTTP GETs to load a table at the top of the page, with the required variable values with <tr>, <th> values interspersed to form rows.
Twin bussed SHT30s in action!! |
However, I seem to have broken the Web interface, which is no longer showing the SHT3X Temp/Humidity in the header of the main page. And it crashes when I ask for the Main Menu, a memory fault (of course!! Sodding C++ and its horrible implied mallocs... all Strings are BAD!).
I hadn't used the programme's preferred approach of putting all formatting strings into const PROGMEM variables, just on the basis of expediency. I think I might purge my code of inline strings altogether, but since it uses fragments (because it has a header, a loop, and a trailer) it won't use a single formatting string like the existing ones.
Looking at the actual content, the interesting thing is that these sensors are very close in value. When they were connected to separate NodeMCUs, they were at least 1 deg / 2% different, consistently. I guess operating them from a single ESP8266 and its single power supply ensures the closest match.
Hurrah!! Multiple Sensors on Main Menu page |
Now I need to fix that darned crash...
Comments
Post a Comment