[stevestrong – Mon Feb 26, 2018 2:40 pm] –
10 seconds effort to search the forum: viewtopic.php?f=15&t=525&p=13507&hilit=dht22#p19187
I think its not official because it didnt exist in the github from roger. and the post was old already but anyways thanks for the confirmation steve ![]()
The DHT example uses 1-wire on one pin set up here: https://github.com/markruys/arduino-DHT … st.pde#L11
Please use the PXY notation for that (PA1, PB10,…).
[peeknot – Mon Feb 26, 2018 2:49 pm] –[stevestrong – Mon Feb 26, 2018 2:40 pm] –
10 seconds effort to search the forum: viewtopic.php?f=15&t=525&p=13507&hilit=dht22#p19187I think its not official because it didnt exist in the github from roger. and the post was old already but anyways thanks for the confirmation steve
![]()
Let me make this clear: There are no “Official” anything: cores or libraries or other resources in the STM32duino environment around this core:
https://github.com/rogerclarkmelbourne
Please reference this disclaimer: https://github.com/rogerclarkmelbourne/ … M32#notice
All support is provided on a best-effort forum basis.
There is a STM supported core for Nucleo boards here: https://github.com/stm32duino however my current understanding is that the support is a “best effort” and the core is evolving over time.
The way a library is added is that someone must validate the library works as-is or someone must port the library and validate. These user tested/ported libraries should be announced to the forum under Libraries & Hardware: http://stm32duino.com/viewforum.php?f=9
There is even a sub-forum where users can request that a library be ported. If there is enough interest, perhaps some of the senior members will have a look at the effort required.
Bottom-line is that forum members are expected to be self-sufficient. When “we” broke away from Arduino.cc and Roger started the forum, the number of members was very small and everyone that came over was a seasoned Arduino user; that is, self-sufficient. Over time, the membership has grown but everyone here must understand that what we have in-place today could be the full extent of the forward effort. Said another way, continued progress is not guaranteed.
I fully expect that STM will continue and refine their support for their portion of the Arduino_Core_STM32 core and libraries. We are very fortunate to have a resource individual who is highly trained and knowledgeable regarding the ArduinoIDE implementation in fpiSTM. In many regards, I think that Arduino_Core_STM32 is the future of STM32duino; however, many of our advanced members have forked Roger’s version of the core which we inherited from LeafLabs and have evolved collectively. These forked implementations have a life of their own.
Ray
[mrburnette – Mon Feb 26, 2018 6:22 pm] –
There is a STM supported core for Nucleo boards here: https://github.com/stm32duino however my current understanding is that the support is a “best effort” and the core is evolving over time.
I would just highlight that it is not only for Nucleo boards. I know the first cores versions were very limited and designed for Nucleo. But now it is generic and is designed to support all board based on STM32 Fx/Lx series.
[mrburnette – Mon Feb 26, 2018 6:22 pm] –
I fully expect that STM will continue and refine their support for their portion of the Arduino_Core_STM32 core and libraries. We are very fortunate to have a resource individual who is highly trained and knowledgeable regarding the ArduinoIDE implementation in fpiSTM. In many regards, I think that Arduino_Core_STM32 is the future of STM32duino; however, many of our advanced members have forked Roger’s version of the core which we inherited from LeafLabs and have evolved collectively. These forked implementations have a life of their own.
Ray
Thanks Ray, It still lot of work to do to enhance basic features and add more ones. It only has one year of existence ![]()
[electrobling – Tue Feb 27, 2018 5:55 am] –
I hope this isn’t off topic, but the Si7021 sensor is now cost competitive with the DHT22, smaller, and uses I2C which has a better chance of porting easily because the Wire library already exists.
$2.11 U.S.D. from AliExpress.com quantity==1 on a break-out board seems reasonable.
https://www.aliexpress.com/item/Tempera … 86556.html
I will have to order a few just to have on-hand. The DHT22 was better than the DHT-11 which was fairly close to being worthless. If anyone has experience with the Si7021 around the accuracy and ease of integration, they should start a new topic so we do hijack this thread.
Ray
The AM2320 seems to compare reasonably well with the Si7021 and is available (maybe.. or maybe they will ship an SHT10 ) for about $1.57 shipped.
https://www.ebay.com/sch/i.html?_from=R … 20&_sop=15
https://www.ebay.com/itm/AM2320B-AM2320 … M2x75szpFw
[stevestrong – Tue Feb 27, 2018 3:47 pm] –
According to this comparison, it seems that SHT31 is the winner, although it costs double that much.
It’s hard to argue with the price of a well engineered temp/humidity sensor, but for $4.50 each from AliExpress.com does seem a bit on the high side: https://www.aliexpress.com/item/SHT31-T … 76082.html
In “new math” terms, this cost represents 2.5 blue pill equivalents! That is a big chunk of humidity to swallow.
$4.50/$1.80 = 2.5
I saw the review thru this hackaday post:
https://hackaday.com/2017/01/03/humidit … -shootout/
I had already ordered an HTU21D, but plan to order at least a BME280 to check it up since I haven’t started writing my application yet.
I run 10 BMP280 based sensors around various parts of the house and garden, the variation between them is more than one degree C.
This is within the manufacturers spec of Plus or minus one deg, but may not be accurate enough for some people.
PS. I should really rewrite my firmware to include a calibration absolute offset, but 1 deg absolute error is acceptable for my domestic use of these devices
I have a rather expensive digital thermometer and it is NIST traceable (was, the cert is out of date now) but even it is +/- 0.5 degree C. The better temperature sensors are thermocouples but accuracy comes down to the purity of the hot junction and the implementation of the cold junction and trans-conductance amplifier. Again, not just one sensor, but the “system” must be engineered.
Those of you who have spent good money to purchase smart thermostats for the home may be surprised by the large degree of deviation these design allow for correct temperature. A friend of mine purchased one from Honeywell and was shocked to find that the temperature was only guaranteed to be 3 degrees accurate (plus or minus). Of course he sent it back for a refund, but had to get an RMA number based on some criteria other than wrong temperature. (He finally found a unit that gives a +/- 1 (2 degree F) swing.)
Ray
I think a lot of people get misled by the “relative” accuracy displayed to them on things like digital thermometers and weather stations, as its often displayed to 0.1 deg C accuracy (probably the same on the deg F units)
So they assume its Absolute accuracy is to 0.1 deg, which it definitely isnt.
I have a weather station (where everything except the T & H has broken, as they had moving parts and don’t last well under the Australian sun / UV conditions), and I compared the inside and outside sensors, side by side, and the outside read 0.3 deg higher than inside.
So that one is not that bad.
I think my BMP280 based sensors are all within 1 deg of each other i.e +/- 0.5 deg, but I’ve not taken the time to calibrate them against each other.
I’m really only interested in whether its hotter indoors or outdoors, or hotter in the pantry (walk in cupboard) than in the kitchen, as temperature control of the house is quite important to us in the summer, to keep the cooling costs down.
e.g. Last night when we went to bed the I think it was 28 deg outside and probably 29 indoors, and the pantry was around 24 as the door is kept closed.
If I get up in the night and can be bothered, I open the pantry door if the kitchen is cooler than the pantry.
However when I checked at 6am it was still 25 in the kitchen and 24 deg outside, so no point opening the door.
Ideally houses here would be built with the climate in mind, and have large thermal mass and plenty of exterior shading, but the building codes are woefully bad, and most houses (including ours) are built assuming that you can run the aircon day and night and don’t care about the cost.
That may have been true 10 years (or even 5 years ago) but energy costs here have gone up a great deal in the last 5 years, and even new houses have not kept pace with the changes in climate and the cost of energy.
We are now between 1 and 2 deg above the long term average temperatures and also experiencing sustained heat waves, e.g. week long.
Total rain this month is 1.4mm long term average rain is 46mm
However the averages fail to tell the complete story, as the weather here is becoming increasingly variable, so although the averages sometimes don’t seem so far out of the norm, the stats that created those averages ie peaks and troughs are abnormal in terms of the data for the last 100+ years
https://www.phanderson.com/picaxe/lin_thermistor.html
Ray
https://www.edn.com/design/sensors/4429 … ew-formula
http://www.ecircuitcenter.com/Circuits/ … m_ckt1.htm
It all depends I guess on how linear, how precisely, and in what part of its range, you require the answer.
You can of course also “linearise” the results in software, but this too assumes you only need the results over a fairly narrow set of operating temperatures, and are prepared either to buy a bunch of closely matched thermistors for your devices, or if more precision is required, are willing to calibrate each one at the production stage (which in turn assumes you have access to a suitably calibrated heat source, and/or a suitably calibrated thermometer).
https://en.wikipedia.org/wiki/Steinhart … t_equation
.. or if all else fails, and assuming such a thing exists, check the datasheet for the device you have purchased. Obviously, if you are a cheapskate like me and have bought the cheapest thermistors you can find on ebay, then your mileage in this case most certainly will vary. ![]()

