You really should disable the rotary encoder if you don't have it. Otherwise, the LCD backlight will be turned off after 3 minutes, and you have no way to turn it on again.
BrewPi@ESP8266, no need of RPI and Arduino.
- Thread starter pocketmon
- Start date
Help Support Homebrew Talk:
You really should disable the rotary encoder if you don't have it. Otherwise, the LCD backlight will be turned off after 3 minutes, and you have no way to turn it on again.
I wont have a rotary encoder - the one I installed on my arduino version is barely used. The web front-end is much easier to use and I have a computer nearby.
Thats interesting - it connected to my secure wifi by itself...
maybe not so secure methinks....
Did you ever use that specific NodeMcu before?
The WiFi credential is stored in a special area on the flash. It won't be erased after re-flashed, or even format of SPIFFS.
![Craft A Brew - Safale BE-256 Yeast - Fermentis - Belgian Ale Dry Yeast - For Belgian & Strong Ales - Ingredients for Home Brewing - Beer Making Supplies - [3 Pack]](https://m.media-amazon.com/images/I/51bcKEwQmWL._SL500_.jpg)
stbernts
Well-Known Member
- Joined
- May 20, 2016
- Messages
- 257
- Reaction score
- 43
It`s not related to this, it happens on new - unused NodeMcu also.
This is what I tried to explain some weeks ago.
I did one flash of my first NodeMcu, the number two and three just connected. So there is something realy strange going on with this.
Those two boards had never been on my wifi before.
Well, then something I don't know happened.
As far as I know, ESP8266 will use saved WiFi information to connect on power on. If there is no information there, it should not connect anything.
By no means ESP8266 knows anything about your network.
When I get time I'm going to look into the details of this project more; I dropped the rotary encoder from my Arduino project due to the complications of debouncing it. I guess I should have wrote some functions to handle interrupts from the rotary encoder input, but it was going to make the sketch a lot bigger, so I went with push buttons. I tried some caps, a quality rotary encoder, and even a schmitt trigger, but still had lots of problems. I think think the software control is where I'm headed eventually anyway since I'm better at web design.
IMO, rotary encoder is hard to handle.
First, it can't be processed in polling mode, unless the system runs nearly nothing.
Second, the debounce capacitors are needed, but even with the debounce capacitors, it doesn't feel like silk smooth.
The solo advantage I know is that only one small opening is needed.
I've supported the rotary encoder by IO expander, but I would rather use the web interface, which is easy and simple.
That's not strictly true. Debouncing capacitors are not needed as the output of the encoder is a Gray code, where only one bit changes at a time. So a bounce will move you between two valid states, eventually settling on the new state. Also, the software can be polled or interrupt-driven. Polling with a rate of a few milliseconds is fine (my code sleeps 1ms between polling).
My rotary encoder has about 12 or 16 physical clicks per revolution, but each click cycles through all four Gray codes. So I track the codes to get direction and an 'internal' count, then I divide the internal count by four for the reported count.
Ah, yes, hundreds of ms would be too long. I think less than 10ms would probably be ok.
Is there any internal timer interrupt you can use? Set it to roll over every few milliseconds and then sample the encoder independently of the main loop?
Per my last survey, it's not possible to use timer interrupt for rotary encoder, but I lost the link. It seems like that the ISR will result in heavy loading of system and affect the WiFi functionality. It really doesn't mater, because rotary encoder can be supported by interrupt of RA, RB, and PushDown button. The problem for ESP8266 is lack of available PINs.
I just bought one of these things to play with the "3 button" method of emulating the rotary encoder:
https://chicagodist.com/products/membrane-1x4-keypad-extras
I figure we have 2 free pins plus the unused buzzer pin, so why not?
If it works, I'll try to come up with something less ugly hardware wise.
I see no reason why it won't work.
I have that keypad and had thought about it, but I don't really need it.
Allow me to remind you that the menu handling uses another loop which will result in WDT timeout. The solution is simple by adding a "delay(1)" in the loop. It's strange that reseting the WDT doesn't seem to work.
Interesting. I know I had that issue when first porting the controller code over - hence why I have yield(); all over the place. Thanks for the heads up on the second loop - I almost certainly would have missed that and would be back here complaining about how nothing works.
It's interesting that I had managed to add WDT to my Arduino build but I didn't handle the menu loop. When the WDT timeout happened on ESP8266, it's all familiar to me, and I felt comfortable for a while before I realized that I didn't handle the WDT.
SandroRibeiro
SandroRibeiro
Some pictures !!
Holy crap, that's awesome! Good job!
Very nice! Are you saving space on the front for the LCD, or are you going "headless?"
The newer is available.
- local logging
- flexible remote logging format. It works fine with ubidots.com & thinkgspeak.com.
terragady
Well-Known Member
there is nice ESP board with 16M - https://www.aliexpress.com/item/Nod...-16M-flash-USB-serial-CP2102/32779742446.html
They have also other versions of the ESP in their shop there. I was using their Arduino Nano clones with microUSB which are great and great quality as well.
They have also other versions of the ESP in their shop there. I was using their Arduino Nano clones with microUSB which are great and great quality as well.
SandroRibeiro
SandroRibeiro
Yes. I'll put an LCD in the future.
Old NodeMcu(V1.1) and WeMos D1 mini use ESP-12E while this "V3" NodeMcu and WeMos D1 Pro seem to use ESP8266 directly. The BOM cost should be reduced, and they can use a larger FLASH.
IMO, one advantage of using ESP-12E is the shielding. I am not sure how the WiFi works without shielding on this "V3" NodeMcu. (I do buy a WeMos D1 Pro, but I am too lazy to solder the header PINs.)
The rumor I read had the WeMos D1 Pro's WiFi actually underperforming the WiFi on the D1 Mini in terms of signal strength. I'd be curious how the "V3" NodeMCU compares in that regard. I've got both the mini & pro soldered up & flashed, and haven't noticed much of a difference. That said, my apartment is also tiny, so there's not much room to test.
Additionally, not that it matters much to anyone in this thread I'm sure, but the D1 Pro/V3 NodeMCU don't have the FCC stamp the D1 mini has.
terragady
Well-Known Member
I have no problem with those new versions in my other projects at all, not sure if they perform better but at least not worse. I think there is new ESP chip which should be much better but I didn't test it yet.
Are those relays http://sc01.alicdn.com/kf/HTB1p7ZlK...ngle-Relay-SRS-05VDC-SL-C-SRS.jpg_350x350.jpg
enough for the project? Or SSR would be better? Also using a transistor is recommended or it is completely fine to run them directly from ESP gpios?
Are those relays http://sc01.alicdn.com/kf/HTB1p7ZlK...ngle-Relay-SRS-05VDC-SL-C-SRS.jpg_350x350.jpg
enough for the project? Or SSR would be better? Also using a transistor is recommended or it is completely fine to run them directly from ESP gpios?
I worked in Wireless industry as a software engineer. The only thing I know about RF is that it is hard to design. Most of the products with RF I have seen use shielding. My concern isn't really about the WiFi performance but the RF interference. If it works fine for others, I bet I am cool with it.
The relay in the link is 10A capability, which is fine for most fridge and freezer. You, however, have to check your own fridge or freezer.
As far as I know, compared to mechanical relay, SSR is more expensive and bulkier with heat sink. However, it has some important advantages:
- larger current support, like 25A~40A.
- (usually) zero-crossing switch, so less interference. Some people, like me, have scrambled LCD issues caused by switch of mechanical relays.
To drive relay or SSR, enough driving voltage and current is required. The SSRs I have require 3~32VDC and around 10mA(?) driving current. They work fine with ESP GPIO. Mechanical relays seem to require higher current. You have to check the specifications to find out. I would suggest to use relay modules instead of relays to go with ESP GPIOs.
terragady
Well-Known Member
But the mechanical ones I can fit in my PCB Relay module is just with transistor and diode and LED which I can design on my own PCB without a problem. Just wanted to ask if there is any potential harm with them like for ArdBir they are not perfect with PWM signal and not fast enough (?) and also LCD problem which you mentioned. For BrewPi(Less) this should be a problem as there is no LCD
Relay module is just with transistor and diode and LED which I can design on my own PCB without a problem. Just wanted to ask if there is any potential harm with them like for ArdBir they are not perfect with PWM signal and not fast enough (?) and also LCD problem which you mentioned. For BrewPi(Less) this should be a problem as there is no LCD Similar threads
