NodeMCU based MQTT multi-sensor with OLED display

Tags: #<Tag:0x00007fd30f2fee98> #<Tag:0x00007fd30f2fed58> #<Tag:0x00007fd30f2fec18>

(B K) #21

Updated first post with links to overview/how-to videos, current status of design and what I’m working on for these, and fixed PCB links throughout to link to PCBWay as my preferred board house.

(Chris S) #22

Great update! What are the dampers you are using for your registers?

(B K) #23

@QuagmireMan that part of the project is still on the drawing board :slight_smile: For now, I’m manually adjusting the registers when I notice temperatures in a room trending too far out of range (e.g. as seasons change different rooms get varying amounts of sunlight), or when I have guess coming (i.;e. open the guest room registers). It would definitely be nice to automate that, so that project is on my todo list. I’m thinking a small, geared servo, with 3d printed lever arms, might be enough to actuate the standard metal registers (though some of mine require a lot of force to operate). @waspie above mentioned using Vent Miser registers, and those have come down in price considerably, so that could be a viable option, as well. I specifically made the EXT connector servo-friendly (pinout is Signal/VCC/Gnd), so I figure one of my sensors could connect to the servo, and either do localized control based on a setpoint received from OH, or OH could handle the PID/feedback loop control of the servo directly.

Open to any ideas you might have!

(Lucky) #24

I use a MG996R servo to roll my heavy blinds. It has lots of torque. You might wanna check it out. ESP32 has come down in price also. You might want to upgrade :slight_smile: and use the built in sensors

(scott dee) #25

just as @bartus said, vent miser. there’s usually plenty on ebay, unless you need 10x6 then you’re up a creek. they’re super simple to control with an esp and an h bridge.

(B K) #26

Checking in for a progress report on the next step/sensor on the list in my post 1 above. I’ve been trying to use an MPXV7002DP differential pressure sensor to measure the air flow in my HVAC system (I’ve got a handheld DP tester to compare measurements to). The idea is to measure the DP and make sure it’s below 0.5 in/h2o, which is the stated limit for most residential HVAC systems, when opening/closing registers in different rooms of the house. Too much DP can put increased wear & tear on the blower motor so it’s to be avoided. DP can also be used to measure filter life and detect when replacement is needed.

The MPXV7002DP does +/- 8 inches, but I think that wide measurement range is actually causing problems. Even with the sensor in closed loop (both ports connected to each other), I’m getting readings in the range of +/- 0.1 in/h2o, which is pretty crappy of a resolution for what I need. The issue is exacerbated by the NodeMCU/ESP8266 having only a single ADC and requiring a 0-1V input range, with no AREF pin so no way to account for supply voltage fluctuation.

The only solutions I can think of are:

  1. Using a lower-range sensor, but from what I can tell, these are only commercially available and get pricey (~$500 pricey)…or

  2. Using an Arduino Uno with a 5V analog input (and an AREF pin) for the sensor, then sending the read value to the multi-sensor via I2C

I think method 2 is the most feasible, unless anyone knows of a cheap, low-range DP sensor.

(B K) #27

Just another quick update to say I’ve posted a 3rd part of the video series on building/configuring the sensor on my YT channel (, specifically dealing with connecting the MQTT topics for the sensor to openHAB and calibrating the sensor to the HVAC thermostat (so it reports temperature relative to the HVAC system readings).

Also, @luckymallari, I have a few MG996R servos on the way from AliExpress, based on your suggestion - I’m either going to get them hooked up to my registers or my blinds. How did you get yours connected to the blinds? For the register, I was thinking of mocking some sort of lever for the servo in Fusion 360 to mate up to the crappy, standard HVAC register “knob”, but I’d like to keep the servos inside and there’s really no space for that inside the standard registers. I ordered a 10x4 Ventmiser from ebay (@waspie 's suggestion), and I’ll try to make something fit with those,as well as take a trip to HD/Lowe’s and try to find a suitable register there.

As for the ESP32, I was recently looking at the DoIT version of the board, which resembles the NodeMCU (even the pinout), but sadly, they didn’t make it pin-compatible (3v3/Gnd pins on the bottom right are now 3v3/CLK pins), so it won’t work with my custom PCB, unless I spin a new version of it specific to the ESP32…

(scott dee) #28

I never had much luck sourcing a vent to retrofit from lowes/depot. I’d hope you’ll have better luck but then again I think you’ll find servos to be entirely too loud to be actuating vents, particularly at night. In my very early days I had servos in the misers before I knew how to control a motor and while they worked, they were a bit of a disturbance opening and closing at night. The original motor driven at 3.3v is far quieter and won’t wake you up!

I also wanted to do something based on pressures. I went as far as getting a nice manometer that only read -1 to 1 but even as I closed nearly all vents the measurement would barely change. Perhaps it was duct leakage? Perhaps something else. I read page upon page concerning how to take the measurement. Pitot tubes? No pitot tubes. This. That. The other thing. The only thing I got out of all that is the doesn’t reallyseem to be a good consensus of how to even take the measurement! I figured I would be as good off just guessing. That’s also why I took over the fan speed of the furnace. I figure if I do most of my stuff on low i should be safe and should multiple rooms request conditioning I can use higher speeds.

I think perhaps a better way without fancy tubes and pressure sensors would be to monitor amperage of the blower. Open everything , take a measurement. Close everything, take a measurement. Then stay somewhere in the middle :p.

Goodluck to you!

Be careful with esp32 if you plan to use i2c. I designed a new board and started to transition some of my units and havebeen fighting i2c problems. Fortunately I think I’m finally onto a fix (it’s a core problem).

(Patrik Patrik) #29

Nice project. Would it be possible for you to post the sitemap code that you used for displaying the graphs?

(B K) #30

Sure! It is the same sitemap setup as the “DEMO” package of openhab, but here is my specific one:

			Text label="Temperature Chart" icon="line"
				Switch item=Temp_Chart_Period label="Temp Chart Period" mappings=[0="Hour", 1="Day", 2="Week", 3="Off"] icon="line"
				Chart item=Temp_Chart period=h refresh=6000 visibility=[Temp_Chart_Period==0, Temp_Chart_Period=="Uninitialized"]
				Chart item=Temp_Chart period=D refresh=30000 visibility=[Temp_Chart_Period==1]
				Chart item=Temp_Chart period=W refresh=30000 visibility=[Temp_Chart_Period==2]

To add values to the chart, just add the associated item to the chart group in the items file, i.e.:

Number Temperature_Basement "Bsmt Temp [%.1f F]" <temperature> (gBsmt,Temp_Chart) {mqtt="<[broker:home/Basement/temperature:state:default]"}

That’s it, really!

(Ray) #31

Great post.
I am trying to learn all about Openhab, MQTT, NodeMCU and more.
And this post is a nice guideline and very useful.
I only wonder why do you use the Rx (GPIO3) and the Tx (GPIO1) from the NodeMCU for the I2c bus(oled) and not D1 (GPIO5) for SCL and D2 (GPIO4) for SDA?
Just wondering and he… maybe I learn something.

(B K) #32

Ray - two very simple reasons:

  1. Vanity…I like the four wires for I2C (or the 6 for SPI) to be in one single row close to each other (in all seriousness, it just makes the wiring a bit more tidy and easier, and I needed to pick up 3v3 and GND from that corner so I just kept all wires close to it).

  2. Resistance to change…I was already using D2 (GPIO 4) for the onboard DHT sensor, and also picked up D2-D5 for the level-shifted I/O, so I only had D5-D10 left for the OLED screen I/O.

Just for an update, I’m working on the analog input next (attempting to use a differential pressure sensor to monitor the HVAC system load), but the onboard ADC (with 10 bits precision, 0-1V range and voltage spikes every time the NodeMCU transmits) is proving to be useless. I’ll need some of those digital I/O pins back so I can use an external I2C ADC…

(Holger OpenhabUser) #33

Have you tired to block your 3.3V with additional caps to get it more stable? Also add a cap at the analog in. I think your signal is anywys changing slow.
In addition you can implement a SW filter, sample several times and use a running average, this helps also to get stable A/D values.


(B K) #34

Holger - all very good ideas! I did try the caps, but didn’t get to doing a software filter yet…Alll that said, the real problem I have is with resolution. The sensor I have has a range from -8…8 in/h2o, and all I’m really concerned with is the 0…0.5 range. In a 10-bit resolution, that works out to something like 0.09 in/h2o per bit, so not very good for monitoring the system (and even more prone to voltage fluctuations changing the reading). I figure with a dedicated 12 bit ADC, with a full 0-5V range, I can get that down to ~0.02 error.

(Holger OpenhabUser) #35

If your analog range is only 0.5V, then it would be the best to put a OP-Amp in the row with a analog amplification of x10. Then you reach the full A/D Range and get better resolution.

(B K) #36

Interesting solution as well, but I’d still be amplifying the noise of the NodeMCU 5V power supply, wouldn’t I? Also, I’m trying to stay within the current enclosure, if I can. I think with an external ADC board like this one, I can still tuck it inside the box (and if it works, I can likely just add the few ADC components onto my existing NodeMCU carrier board). Bonus of having 4 16-bit analog inputs vs 1 10-bit and an onboard PGA (so I can focus the measurement range to the 0-0.5Vdc, per your suggestion). Thanks!

(Ray) #37

He Bartus,
These are really great device to hook op to OpenHAB. Like them a lot so far. It helped me a lot to understand and to work better with Openhab.
I only have a little thing that I would like to change but don’t know exactly where to do what.
The thing is that the sensor sometimes send a -1.00. Probably because of the DHT (it seems to be a little slow sometimes) or maybe a bad WiFi signal or whatever. The value -1.00 gets to the broker and OpenHAB shows it. The software does what it has to do, but the value -1.00 gives a weird chart display.
I guess that this little problem can be solved at both sides! Make a rule in Openhab or something so a -1.00 value is false or… Or change the sketch for the ESP8266 a little so that the value -1.00 will never be send.
What would be the best solution in your opinion if I may ask?
Any way, thanks for developing this great device.

(B K) #38

Thank you - I’m glad my project is helping you learn openHAB (making it helped me, as well!).

The code will set an output value of -1 when either the temperature or humidity readings become invalid. The only time I’ve seen that was when I was using either a breadboard (testing), or using a proto-board setup, with the DHT22 sensor inserted into pin headers. I’m pretty sure it’s due to an intermittent connection issue. With all of the sensors I’ve put on my PCB I’ve never had any issues. I don’t think it’s your Wifi signal either, because then you’ll just get a non-changing value (openHAB item/MQTT topic will not get an update).

You could disable the logic in the Arduino IDE (just comment out the line that sets the sensor value to “-1” when the value is not a valid number). Then, the value you get over MQTT will just remain steady (stale) until the connection to the sensor is reestablished. That’s much easier to do than handling it in openHAB (though you could do it with a JS transform, I guess).Clearly the best solution is to make sure your sensor connection is solid (those Dupont connectors/headers don’t always work well).

Enjoy your adventure with openHAB!