Anyone know of module for SHT3X sensor? There seems to be quite a few modules for BMP280 and BME280, but have yet to find any for the SHT3X?
On what device are you using this sensor and what does the device output ?
Using node red on a Raspberry Pi. The device is another popular temperature/humidity/pressure sensor. There are many such, including the SHT3X series, MCP9808, SI7021, MPL1115A2, etc. I have python scripts to support all of these. My hope is that they will all be supported in node red like the BMP280 and BME280 are now. Given they are all i2c based, using the existing BMX280 code as starting point, example of, we could establish support for the additional devices. I also want to revisit the PCF7485 GPIO expander support in node red as a longer term goal.
While they may all be I2C based, they all work differently.
The best place to start with a problem like this - assuming you've already checked the flows site for a candidate node - is to look on npmjs.org to see if anyone has written a JavaScript package for it.
If they have, then there are various possibilities to be able to use it. From loading it into a global variable on startup (from settings.js) and then referencing it in a function node, right through to building a custom node for it (which generally isn't that hard).
Of course, most of us put our sensors on Arduino's or, more commonly these days, on ESP8266 or ESP32 devices since they are better suited to the kind of real-time processing of sensor data. You can then access the data either via serial (in the case of a stock Arduino) or via MQTT.
I should also say that SHT's don't seem to be anywhere near as popular as the Bosch BME/BMP sensors. Though they do seem to be gaining some ground recently.
The raspberry pi has native support for many sensors:
1 Like
Yeah, I already started working on creating my own custom nodes, a bit of practice if you will. Since I have all the sensors working via python scripting, I could cheat and just call python scripts from node-red, but no, not what I want. Really, the big effort is just going to be converting my existing python solution to something node.js compliant with node-red wrappers to integrate to same.
2 Likes
I'm also keen on this. The SHT3x family specifically and Si7021, any progress or want help?
-- Edit --
The Readme link suggests I can enable the overlays for the sensors, I guess I wonder what happens next.... To the internet batman...
I have written my own version of the SHT3X support module. I am still testing it, but so far so good. In a few days, I plan to post the module to git.
I am working on a support module for si7021 as well, but it is still incomplete at this point, but it is next in the queue.
3 Likes
Be keen to have a look, ended up setting up devicetree overlay entries for my other sensors (dht, si7021, bmp280) which then means I can just CAT(read) a file for latest results.
That Readme sent me down a dark wonderful path to the murky world of devicetree overlays, and I loved it 
in case anyone wants to start device tree overlays
Mine has these additions (the DHT22 are listed as 11s):
3 Likes
But this raises a good question... which is better? And when? Writing code to talk to the i2c bus, to devices, in the transitional, past, manner? Versus, once you have the overlays in place, NR via an exec node, can interrogate the device tree, right? Not sure which is better or why? For various calculations, say with bme280, a simple cat (query) maybe insufficient.
There is no "better" way, just different ways. I use the file in node to read the locations BTW, you may find it easier.
[{"id":"3d7d5b4a.6c18e4","type":"file in","z":"9dcf23c2.6c9ca","name":"raw Pressure BMP180","filename":"/sys/devices/platform/soc/20804000.i2c/i2c-1/1-0077/iio:device0/in_pressure_input","format":"utf8","chunk":false,"sendError":false,"x":300,"y":140,"wires":[["f25ef5c8.43e148"]]}]
1 Like
The sample flow you posted is cool. I was thinking of using exec node and cat route. Maybe not the most efficient, but it would mimic the same steps as cli method.
For specific sensors, if you need different mode, sampling, etc. than what the dtoverlay supports or defaults as. One example is bme280, to get to the extra data the bme280 can generate or return, for example. So in that case it maybe better... to go the direct code method, versus dtoverlay. Don't get me wrong I like the dtoverlay methods. The other issue, is I have a lot of sensors that are not as yet supported by dtoverlays.
1 Like
Never needed overlays before so happy to play. I think it will be less cpu intensive leaving to kernel drivers and I have many I2C sensors planned, but the code/node-red route is very user/configuration friendly particularly if the system involves multiple sensors of same type or in diff physical locations which is only known to end user. Minor implementation detail though.
Was a bit of an pain to find how to read everything (bmp280 has errors in dmesg and doesnt show UU meaning kernel has driver loaded in i2cdetect like expected but works) as they don't show up as obviously as Dht11/22's (location in /sys ) so ended up searching for temp things or driver name in a cat file to aid understanding, but the find command is all anyone needs (change address if reqd):
tree /sys/ > sys.txt
cat sys.txt | grep temp -n15
cat sys.txt | grep sht3 -n15
sudo find /sys/ -type d -name "1-0044"
cat /sys/devices/platform/soc/3f804000.i2c/i2c-1/1-0044/hwmon/hwmon2/temp1_input
28950
Thinking about it, I can adjust sample rate through same system (using ECHO), plus they include all possible values in another file:
pi@rpi3b:~ $ cat /sys/devices/platform/soc/3f804000.i2c/i2c-1/1-0076/iio\:device3/in_temp_oversampling_ratio
2 # in_temp_oversampling_ratio
pi@rpi3b:~ $ cat /sys/devices/platform/soc/3f804000.i2c/i2c-1/1-0076/iio\:device3/in_temp_oversampling_ratio_available
1 2 4 8 16 # in_temp_oversampling_ratio_available
I guess I would have a JS init function doing setup similar to a cli init section in the flow, so similar effort/effect, making the choice even harder. Torn about going back to Python, but the overlays will help me more in future.
For reference the sht3x overlay provides the following:
2 Likes
In a word, slick. I was playing around with this last night and came to similar issues:
-
How to only enable the overlays needed, in config.txt
-
Scan slow down issue can still result on the i2c bus... I tripped over this some time ago, and overlay can suffer the same scenario. This can happen with an address conflict or when a sensor is present but falls off the bus. there does not seem to be an easy way to do a i2c bus reset?
-
Consistent path to overlay sensor inputs? Not only is there multiple ways to find them in the file system paths, but depending on how many sensors you have configured the paths change? For example, iio:device0 versus iio:device1? Still researching this one.
-
And the big issue, how to get more sensors in the supported list? I have already started talking over the in (official) Pi forum how this can be requested, encouraged to be done.
-
I would really like a method to have a flow determine which sensors exist, so that only the needed flows are imported or otherwise activated. Deterministic flow execution is something I am really interested in. Such as:
A) Run a specific flow at NR shutdown, restart, etc.
B) Run or enable flow based on some trigger criteria, say sensor found, for example
C) Selective flow or node initialization, this is really a node design scope thing however
Some of the above is in the works already possible (start NR for example), some just ideas at this point, but do have use cases in mind for each.
1 Like
For my 'production' Pi devices, I use a python script that sends, receives MQTT as a listener service to NR, so I can request a sensor measurement on demand or schedule (via cron-plus). I have a lot of hours in the python scripts, which support many more sensors than the overlay list now. So, the near term, the python is used. I also wrote a couple of nodes for NR for a few sensors, because the original contributors seem to have abandoned their projects. Should have these on github in the next few days.
Not a sensor, but I have a new PCF8574 node project as well I will put on github. I just need to finish the documentation (read MD) for it. What else? Have beta for a MAX7219 node as well, plan to put it on github soon too.
1 Like
Just for reference... something like the following https://eightbar.eu-gb.mybluemix.net/2014/01/19/node-red-flows-that-make-flows/ is bit where I want to go at some point, so that only the flows needed are loaded/present for the sensors present. And, only the dtoverlay directives in the config.txt file are present/configured for sensors present, etc.
Does any one know why the dtoverlay based device paths change? On one boot the path was...
/sys/bus/i2c/devices/1-0077/iio:device0
After another reboot, but no hardware changes, the device path was...
/sys/bus/i2c/devices/1-0077/iio:device1
Maybe the scan of the i2c bus finds devices in a different order? This is bit of a pain, having the flow have to find the devices each time something changes. I guess I could use wildcarding, but that seems like cheating.
Cheating?? I think it is brilliant! 
I think you aught to be able to use udev rules to make an I2C device always mount at a defined point, in the same was as you can for usb devices, though I have to admit that google is not very forthcoming on the issue. Worth some investigation though I think.
1 Like
