Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
Moderators: grovkillen, Stuntteam, TD-er
Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
Hello
I'm using the following board : Two Canal ESP32-WROOM-32E. See Picture. I use it to close my garage door if it's left open.
I use a relay that sends pulses to open or close the door.
The problem is when the boot card the two relays make a small pulse. In my case, this activates a door movement.
How can I configure ESPEasy so that when it starts up, nothing happens to the relays?
For information here my Rules:
// Info : See Rules 2 / Stand vom : 04.12.2023 /Ho
on System#Boot do
notify 1 //Send Email System Boot
TimerSet,1,0 // Stop Loops
TimerSet,2,0 // Stop Repeat
AsyncEvent,PIR#State=[PIR#State] // Let the PIR eventhandler take care of the logic
LCD,4,1,%ip% // Show IP
endon
on Door#State=0 do // Door is open
TimerSet,1,0 // Stop Loops
event,Progress
LCD,1,1,""
LCD,2,1,"Das Tor ist offen "
endon
on DelayButton#State=1 do // Set Delay ON
TaskValueSet 5,1,40 // Slow Prog.Bar 40s
event,Progress
LCD,4,1,"Pause ist EIN V[Delay#Value]"
endon
on Progress do
let 1,%eventvalue1|20% // Display with 20 characters
LoopTimerSet,1,[Delay#Value],%v1% // Repeat timer 1 every x sec. for n times
endon
on Rules#Timer=1 do
LCD,1,1,{substring:0:%eventvalue2%:********************} // Timer Line 1
if %eventvalue2%>15 // Reached 70%?
Pulse,17,1,1400 // Pulse Alarm
end
if %eventvalue2%=%v1% // Have we reached 100%?
lcdcmd,clear
LCD,1,1,"Die Tor geht zu!"
Pulse,16,1,400 // Pulse on GIPO 16 to close the Door
TimerSet,2,20 // Timer to check it door closed after 20s else repeat
endif
endon
On Rules#Timer=2 do // Door timer
if [Door#State]=0 // Door still open?
LCD,1,1,"Tor schliessung !.."
Pulse,16,1,400 // Pulse on GIPO 16 to close the Door
TimerSet,2,20 // Repeat wait timer 2 until door closed
else
TimerSet,2,0 // Stop timer 2
endif
endon
on PIR#state do // Will be triggered when PIR state changes
if [Door#State]=0 // Door open?
if %eventvalue1%=1
TimerSet,1,0 // Stop countdown
LCD,1,1,"ACHTUNG PIR Meldung!"
notify 1 //Send Email
AsyncEvent,Progress // Using default
endif
endif
endon
On DOOR#State=1 do // Door closed
lcdcmd,clear
LCD,2,1,"Das Tor ist zu"
LCD,4,1,"ATEHO 03.12.23 V[Delay#Value]"
TimerSet,1,0 // Stop Loops
TimerSet,2,0 // Stop Repeat
TaskValueSet 5,1,10 // Set to fast Prog.Bar 10s
Endon
I'm still improving my Rules. I'm a beginner. But so far it's working pretty well.
My devices: Regards
Otto
I'm using the following board : Two Canal ESP32-WROOM-32E. See Picture. I use it to close my garage door if it's left open.
I use a relay that sends pulses to open or close the door.
The problem is when the boot card the two relays make a small pulse. In my case, this activates a door movement.
How can I configure ESPEasy so that when it starts up, nothing happens to the relays?
For information here my Rules:
// Info : See Rules 2 / Stand vom : 04.12.2023 /Ho
on System#Boot do
notify 1 //Send Email System Boot
TimerSet,1,0 // Stop Loops
TimerSet,2,0 // Stop Repeat
AsyncEvent,PIR#State=[PIR#State] // Let the PIR eventhandler take care of the logic
LCD,4,1,%ip% // Show IP
endon
on Door#State=0 do // Door is open
TimerSet,1,0 // Stop Loops
event,Progress
LCD,1,1,""
LCD,2,1,"Das Tor ist offen "
endon
on DelayButton#State=1 do // Set Delay ON
TaskValueSet 5,1,40 // Slow Prog.Bar 40s
event,Progress
LCD,4,1,"Pause ist EIN V[Delay#Value]"
endon
on Progress do
let 1,%eventvalue1|20% // Display with 20 characters
LoopTimerSet,1,[Delay#Value],%v1% // Repeat timer 1 every x sec. for n times
endon
on Rules#Timer=1 do
LCD,1,1,{substring:0:%eventvalue2%:********************} // Timer Line 1
if %eventvalue2%>15 // Reached 70%?
Pulse,17,1,1400 // Pulse Alarm
end
if %eventvalue2%=%v1% // Have we reached 100%?
lcdcmd,clear
LCD,1,1,"Die Tor geht zu!"
Pulse,16,1,400 // Pulse on GIPO 16 to close the Door
TimerSet,2,20 // Timer to check it door closed after 20s else repeat
endif
endon
On Rules#Timer=2 do // Door timer
if [Door#State]=0 // Door still open?
LCD,1,1,"Tor schliessung !.."
Pulse,16,1,400 // Pulse on GIPO 16 to close the Door
TimerSet,2,20 // Repeat wait timer 2 until door closed
else
TimerSet,2,0 // Stop timer 2
endif
endon
on PIR#state do // Will be triggered when PIR state changes
if [Door#State]=0 // Door open?
if %eventvalue1%=1
TimerSet,1,0 // Stop countdown
LCD,1,1,"ACHTUNG PIR Meldung!"
notify 1 //Send Email
AsyncEvent,Progress // Using default
endif
endif
endon
On DOOR#State=1 do // Door closed
lcdcmd,clear
LCD,2,1,"Das Tor ist zu"
LCD,4,1,"ATEHO 03.12.23 V[Delay#Value]"
TimerSet,1,0 // Stop Loops
TimerSet,2,0 // Stop Repeat
TaskValueSet 5,1,10 // Set to fast Prog.Bar 10s
Endon
I'm still improving my Rules. I'm a beginner. But so far it's working pretty well.
My devices: Regards
Otto
Re: Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
Some pins always do send out some undefined pulses when the ESP boots.
See: https://espeasy.readthedocs.io/en/lates ... e-on-esp32
Not sure if this also applies to your setup.
It is best to pick the state which is the default state at boot for the most harmless situation.
I assume the most harmless situation is to not have a motor running.
Or do you need to trigger a short connection to simulate a button press of an existing garage door opener?
You can have a look at the boot states on the Hardware tab, to see if you can select a state which will not trigger a pulse during boot.
But keep in mind this selected state will only be set after loading the settings, which takes roughly 300 - 400 msec after boot.
See: https://espeasy.readthedocs.io/en/lates ... e-on-esp32
Not sure if this also applies to your setup.
It is best to pick the state which is the default state at boot for the most harmless situation.
I assume the most harmless situation is to not have a motor running.
Or do you need to trigger a short connection to simulate a button press of an existing garage door opener?
You can have a look at the boot states on the Hardware tab, to see if you can select a state which will not trigger a pulse during boot.
But keep in mind this selected state will only be set after loading the settings, which takes roughly 300 - 400 msec after boot.
Re: Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
I have the same issue with GPIO 17. It´s pulled low for a split second.
The relays on your board seems to be attached to GPIO 16 & 17. Do both relays turn on at boot. (my relay on GPIO 16 is fine)
Setting the boot state didn´t help me. but using another GPIO
(which is a bit more complicated with a ready made board but not impossible
)
But the strange thing is, that your relays seem to be active on high. Mine are acting on low. Your relay on GPIO 17 shouldn´t theoretically turn on at boot...
The relays on your board seems to be attached to GPIO 16 & 17. Do both relays turn on at boot. (my relay on GPIO 16 is fine)
Setting the boot state didn´t help me. but using another GPIO


But the strange thing is, that your relays seem to be active on high. Mine are acting on low. Your relay on GPIO 17 shouldn´t theoretically turn on at boot...
Re: Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
GPIO 16 and 17 on a classic ESP32 (not the -S2/S3/C2/C3/C6) are sending out some 80 MHz signal during boot as those would be used for PSRAM if it was present.
So the ESP tries to find the PSRAM and thus sends out some quite high frequency pulses to these 2 pins at boot.
So the ESP tries to find the PSRAM and thus sends out some quite high frequency pulses to these 2 pins at boot.
Re: Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
I couldn´t find any issues related to that. I would be strange to sell boards that trigger the relay every time at boot. Could this be an ESPEasy-only problem?TD-er wrote: ↑04 Dec 2023, 16:24 GPIO 16 and 17 on a classic ESP32 (not the -S2/S3/C2/C3/C6) are sending out some 80 MHz signal during boot as those would be used for PSRAM if it was present.
So the ESP tries to find the PSRAM and thus sends out some quite high frequency pulses to these 2 pins at boot.
Edit: no, it isn´t

Re: Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
Ok, i was testing...GPIO 16 is HIGH and GPIO 17 is LOW for fraction of time at boot.
Re: Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
Thank you very much for your help.
I also tried setting the GPIO boot states to Output Low, but that didn't solve my problem.
I will try to put a small capacitor between pins 16 and 17 to ground.
I also tried setting the GPIO boot states to Output Low, but that didn't solve my problem.
I will try to put a small capacitor between pins 16 and 17 to ground.
Re: Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
Just for information. I just received the same card and took the opportunity to do some additional tests.
If I erase all the ESP32 software and power up the board. Then the relays have absolutely no reaction. As soon as I download ESPEasy, without any configuration, then again I have this problem where the relays switch on for a few milliseconds on power-up.
If I erase all the ESP32 software and power up the board. Then the relays have absolutely no reaction. As soon as I download ESPEasy, without any configuration, then again I have this problem where the relays switch on for a few milliseconds on power-up.
Re: Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
Try adding a delay at the beginning of your on System#Boot rule.
Re: Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
Just for your information:
I've gone back to my card to redo a test with the latest version of ESPEasy: Git Build: mega-20240414
I also added the suggestion of setting a delay at boot time.
// System#Boot rule with a delay using the Delay command
On System#Boot do
delay,3000 // Pause for 3000 milliseconds (3 seconds)
endon
But this didn't solve the problem, which can only be solved when the card is powered up with ESPEasy. Both relays close for a few milliseconds. This does not happend without ESPEasy Firmware.
I've gone back to my card to redo a test with the latest version of ESPEasy: Git Build: mega-20240414
I also added the suggestion of setting a delay at boot time.
// System#Boot rule with a delay using the Delay command
On System#Boot do
delay,3000 // Pause for 3000 milliseconds (3 seconds)
endon
But this didn't solve the problem, which can only be solved when the card is powered up with ESPEasy. Both relays close for a few milliseconds. This does not happend without ESPEasy Firmware.
Re: Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
Just to be clear, your relais are using either GPIO-16 or -17?
I can make a build with disable PSRAM support for ESP32-classic, so there should not be any checking on those pins at boot.
The signals on those pins are of quite high frequency though, so I am a bit surprised the relais do react to it, unless this 80 MHz signal is levelled out to be like somewhat "half" the logic level.
I can make a build with disable PSRAM support for ESP32-classic, so there should not be any checking on those pins at boot.
The signals on those pins are of quite high frequency though, so I am a bit surprised the relais do react to it, unless this 80 MHz signal is levelled out to be like somewhat "half" the logic level.
Re: Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
Hello TD-er,
Yes you are right this board with the two Relay are using GPIO 16 and GPO17.
Best Regards
Otto
Yes you are right this board with the two Relay are using GPIO 16 and GPO17.
Best Regards
Otto
Re: Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
Which build type do you need?
I can make a test build for you with PSRAM disabled so you can test if that's the fix.
I can make a test build for you with PSRAM disabled so you can test if that's the fix.
Re: Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
I used the following build : ESP_Easy_mega_2024xxxx_normal_ESP32_4M316k.bin
Re: Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
Hmm that's odd, as I apparently already disabled PSRAM for ESP32-classic builds back in January.
See: https://github.com/letscontrolit/ESPEas ... dfd09294b1
So in build 20240229 and later this was disabled.
Maybe you can test with the latest test build I made about a week ago:
https://td-er.nl/ESPEasy/latest/
You can also download the all.zip file which has all the bin files in a single download.
Maybe you could also try flashing the normal 4M LittleFS ETH build?
But be aware that you should backup all files first as the file system and settings will be deleted when switching from SPIFFS to LittleFS.
So maybe best to first upgrade to a SPIFFS build from this latest testbuild.
This will then add a recently added feature to store WiFi credentials outside the file system. (make sure to check all relevant checkboxes on the tools->Factory Reset page so these settings will be stored outside the file system)
You can also download a .tar file with all files on the file system from the tools page. (Chrome will prompt you whether you want to keep the file. Make sure to confirm this)
After upgrading to a LittleFS build, ESPEasy should be reconnecting to WiFi automatically. Then via the Tools->File Browser page you can upload the just downloaded .tar file and reboot ESPEasy. Then all the settings as before are present but on the completely new ESP-IDF/Arduino SDK.
See: https://github.com/letscontrolit/ESPEas ... dfd09294b1
So in build 20240229 and later this was disabled.
Maybe you can test with the latest test build I made about a week ago:
https://td-er.nl/ESPEasy/latest/
You can also download the all.zip file which has all the bin files in a single download.
Maybe you could also try flashing the normal 4M LittleFS ETH build?
But be aware that you should backup all files first as the file system and settings will be deleted when switching from SPIFFS to LittleFS.
So maybe best to first upgrade to a SPIFFS build from this latest testbuild.
This will then add a recently added feature to store WiFi credentials outside the file system. (make sure to check all relevant checkboxes on the tools->Factory Reset page so these settings will be stored outside the file system)
You can also download a .tar file with all files on the file system from the tools page. (Chrome will prompt you whether you want to keep the file. Make sure to confirm this)
After upgrading to a LittleFS build, ESPEasy should be reconnecting to WiFi automatically. Then via the Tools->File Browser page you can upload the just downloaded .tar file and reboot ESPEasy. Then all the settings as before are present but on the completely new ESP-IDF/Arduino SDK.
Re: Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
Hello,
Many thanks for your help. Now it works great.
In fact, with ESPEASY, there are so many versions that I'm lost. I don't really understand the idea of all these variants.
Only with the name LittleFS_ETH, I get 26 options...
But with the version you suggested, the problem is solved.
Many thanks for your help. Now it works great.
In fact, with ESPEASY, there are so many versions that I'm lost. I don't really understand the idea of all these variants.
Only with the name LittleFS_ETH, I get 26 options...
But with the version you suggested, the problem is solved.
Re: Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
Which version/build do you now actually use?
To give some insight in the builds...
When I started implementing support for ESP32 for ESPEasy, there was only one mature option for the file system: SPIFFS.
We did also use it on ESP8266 and it just works.
However, since there has been no development for SPIFFS in years, and SPIFFS does get really slow when using larger file systems (large as in > 2 MB), people started working on a new file system LittleFS.
There are many ESP32 variants, like the ESP32 (classic), ESP32-S2, ESP32-S3, ESP32-C2, ESP32-C3, ESP32-C6 and more are coming.
You need a different build per model as they are all quite different and some don't even use the same CPU architecture.
So to make sure I also don't need to add a lot of my own code to manage all differences, we use the ESP-IDF platform.
This has recently been upgraded from ESP-IDF4.x to ESP-IDF5.x
This was a HUGE change and took me about 10 months to make it all work.
Since SPIFFS support is removed from the ESP-IDF5.x packages I use, I did make the decision to have all builds based on ESP-IDF5.x use LittleFS and all builds based on ESP-IDF4.x use SPIFFS.
So this way it is clear what platform is being used.
The switch to IDF5.x is needed to add support for the newer platforms like ESP32-C2/C6 and SPI Ethernet chips, just to name a few.
Other reasons to switch: IPv6 support, Thread/Matter support (in the near future), support for specific ESP32-S3 models with larger and much faster PSRAM, etc.
Then there is the difference in flash size which is important as I have fixed partition tables included in the builds.
And for 4M flash units, there isn't enough space to include it all so we need to make separate collections as not everyone can (or wants to) make their own builds.
To give some insight in the builds...
When I started implementing support for ESP32 for ESPEasy, there was only one mature option for the file system: SPIFFS.
We did also use it on ESP8266 and it just works.
However, since there has been no development for SPIFFS in years, and SPIFFS does get really slow when using larger file systems (large as in > 2 MB), people started working on a new file system LittleFS.
There are many ESP32 variants, like the ESP32 (classic), ESP32-S2, ESP32-S3, ESP32-C2, ESP32-C3, ESP32-C6 and more are coming.
You need a different build per model as they are all quite different and some don't even use the same CPU architecture.
So to make sure I also don't need to add a lot of my own code to manage all differences, we use the ESP-IDF platform.
This has recently been upgraded from ESP-IDF4.x to ESP-IDF5.x
This was a HUGE change and took me about 10 months to make it all work.
Since SPIFFS support is removed from the ESP-IDF5.x packages I use, I did make the decision to have all builds based on ESP-IDF5.x use LittleFS and all builds based on ESP-IDF4.x use SPIFFS.
So this way it is clear what platform is being used.
The switch to IDF5.x is needed to add support for the newer platforms like ESP32-C2/C6 and SPI Ethernet chips, just to name a few.
Other reasons to switch: IPv6 support, Thread/Matter support (in the near future), support for specific ESP32-S3 models with larger and much faster PSRAM, etc.
Then there is the difference in flash size which is important as I have fixed partition tables included in the builds.
And for 4M flash units, there isn't enough space to include it all so we need to make separate collections as not everyone can (or wants to) make their own builds.
Re: Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
I don't compile ESPEasy, I use the binaries offered on the https://github.com/letscontrolit/ESPEasy/releases website.
Many thanks for all your explanations.
I think that for the ESP8266 you should also use the LittleFS versions?
I like ESPEasy for its simplicity and web interfaces.
A specific variant for ESP32-CAM would be nice.
Best regards
Many thanks for all your explanations.
I think that for the ESP8266 you should also use the LittleFS versions?
I like ESPEasy for its simplicity and web interfaces.
A specific variant for ESP32-CAM would be nice.
Best regards
Re: Two Canal ESP32-WROOM-32E. Relais send pulses when booting!
Nope, I tried LittleFS on ESP8266 and it does make writing quite a bit slower.
Also moving from SPIFFS to LittleFS on existing nodes in the field does involve quite a lot of actions from the user without any clear benefit for ESP8266.
And there will very likely be no new SDK for ESP8266 anymore as Espressif has marked ESP8266 as end-of-life a few years ago.
Also moving from SPIFFS to LittleFS on existing nodes in the field does involve quite a lot of actions from the user without any clear benefit for ESP8266.
And there will very likely be no new SDK for ESP8266 anymore as Espressif has marked ESP8266 as end-of-life a few years ago.
Who is online
Users browsing this forum: Ahrefs [Bot], Semrush [Bot] and 13 guests