hi folks,
i have a ESP32 C3 board with mega-20241222 which drives two Relays, on gpio5 and 6. Relays as usal triggered by low.
now what i found out is, that the relays both get triggered once I start or change the mqtt controller (openHab Home assistant)
So boot is completely normal (no triggering of the relais) if the mqtt controller is not enabled, once I enable it or if its enabled during boot, the relais will be triggered.
mqtt then works like a charm except during the start of the mqtt controller.
Any idea why?
thanks
esp32C3 activating mqtt controller activates relais on gpio's
Moderators: grovkillen, Stuntteam, TD-er
esp32C3 activating mqtt controller activates relais on gpio's
Last edited by lumajo on 26 Jan 2025, 14:35, edited 1 time in total.
Re: esp32C3 activating mqtt controller activates relais on gpio's
Getting the base value of something as simple as a relay or a switch state right is impressively more complex then what you might expect.
This is an example specifically written for Domoticz, so it will not work exactly like this for Home Assistant.
However it may give you some insight in how to make it work for HA: https://espeasy.readthedocs.io/en/lates ... #p029-page
The general idea is to try and keep a single point of 'truth' and from there update the rest.
For example, if you have a push button and a relay, you typically configure the push button as a toggle switch.
So this makes it already tricky to keep its state in sync as the toggle state may not reflect the relay state.
I think the relay state should be the 'source of truth' and thus you should send the boot state of the relay to each listener.
And also if you bind the button and the relay, you should not be interested in the button state, but just toggle the relay when it gets pressed.
This also means the relay state is the state that should be kept in sync with HA and not the button.
I know this is not really intuitive and I'm open for alternative approaches as it also frustrates me that something as basic as GPIO handling easily becomes so incredibly complex.
This is an example specifically written for Domoticz, so it will not work exactly like this for Home Assistant.
However it may give you some insight in how to make it work for HA: https://espeasy.readthedocs.io/en/lates ... #p029-page
The general idea is to try and keep a single point of 'truth' and from there update the rest.
For example, if you have a push button and a relay, you typically configure the push button as a toggle switch.
So this makes it already tricky to keep its state in sync as the toggle state may not reflect the relay state.
I think the relay state should be the 'source of truth' and thus you should send the boot state of the relay to each listener.
And also if you bind the button and the relay, you should not be interested in the button state, but just toggle the relay when it gets pressed.
This also means the relay state is the state that should be kept in sync with HA and not the button.
I know this is not really intuitive and I'm open for alternative approaches as it also frustrates me that something as basic as GPIO handling easily becomes so incredibly complex.
Re: esp32C3 activating mqtt controller activates relais on gpio's
many thanks, I will have a look into this.
just some more insides as to why i am going to do this. It is for my two Garage doors, which should be triggered by either a button, or RFID (weigand). Now esphome is the only code, which works with Weigand , and I used this many years already.
the interesting thing is that if I use Tasmota or esphome with HA, the Relays are never triggered by anything else than the code (and ultimately the button or anything else which i have under control)
I am really thinking out loud now it, that i use 2 esp32, one for the Weigand protocoll, which than only triggers two gpios, which then trigger another esp32 to utlimtely switch the relay. the first esp has espeasy, the second one either tasmota or esphome.
With this I have the relays safe under my control and the RFID will be processed by the first esp32.
it snot much of an effort, but not really a smart way using two esp32 for a safe Garage Door controller.
anyway I will have a deep look into your proposal.
just some more insides as to why i am going to do this. It is for my two Garage doors, which should be triggered by either a button, or RFID (weigand). Now esphome is the only code, which works with Weigand , and I used this many years already.
the interesting thing is that if I use Tasmota or esphome with HA, the Relays are never triggered by anything else than the code (and ultimately the button or anything else which i have under control)
I am really thinking out loud now it, that i use 2 esp32, one for the Weigand protocoll, which than only triggers two gpios, which then trigger another esp32 to utlimtely switch the relay. the first esp has espeasy, the second one either tasmota or esphome.
With this I have the relays safe under my control and the RFID will be processed by the first esp32.
it snot much of an effort, but not really a smart way using two esp32 for a safe Garage Door controller.
anyway I will have a deep look into your proposal.
Re: esp32C3 activating mqtt controller activates relais on gpio's
Now i again had a deeper look into this and found out the mqtt payload is causing the issue.
I send a payload "1 to espeasy and this triggers the Relais. No I have created a rule that then triggers the switch for 3 seconds. However the payload"1" still remains as a Value in the mqtt input device. if this is not cleard to 0 the Relais gpios will be triggered at reboot.
Now I need to check how to clear the value properly...
I send a payload "1 to espeasy and this triggers the Relais. No I have created a rule that then triggers the switch for 3 seconds. However the payload"1" still remains as a Value in the mqtt input device. if this is not cleard to 0 the Relais gpios will be triggered at reboot.
Now I need to check how to clear the value properly...
Re: esp32C3 activating mqtt controller activates relais on gpio's
I think you should have a rules block to validate the RFID as some kind of override when for whatever reason your HA is not reachable.
Or maybe even some mechanical key lock.
So then you have the RFID reader and the keylock which can validate whether the door should be operated.
I guess you also would like to sync this with HA.
However this presents the following race condition:
- RFID/keylock activates door
- RFID/keylock notifies HA, which also triggers to activate the door.
The local (via rules initiated) activation will probably arrive first. So when HA handles the RFID/keylock event it may act on the new situation where the door is no longer closed and thus open, so it will start closing it again.
So I think ESPEasy should keep track of the last state change and also make clear to HA what the state was when the key was presented.
Possible states:
- Door closed & open sequence initiated
- Door fully opened & close sequence initiated
- Door somewhere between fully closed and fully opened
- timeout
The last one may be the most difficult to handle like some timeout happened between while executing the open/close sequence.
What to do then?
I guess there is also some force detection on the motors to make sure nobody gets crushed.
And there are probably mechanical switches at the start and end to immediately turn off power to the motor?
I think this should all be done locally on the ESPEasy node using rules and then HA should get notified of each state change.
Also HA should be able to send a command to open/close the door, but then ESPEasy should act on it based on the current state.
To know the actual state, you need to have a switch at the end and one at the beginning and preferrably some signalling of whether the motor is running.
I don't like mechanical switches in such a setup for detecting the beginning and end as they always cause issues. (you should absolutely have one to mechanically disable power to the motor)
However for low current signalling with long cables, it is always hard to use.
So better use some Hall-effect sensor plus a magnet and twisted cable from the ESP to the Hall effect sensor.
This can also be setup to always draw some minimal current so you experience less noise and those don't show a bouncing signal like those mechanical switches do.
Power to the motor can be detected using some bridge rectifier and an optocoupler (essentially a LED) or maybe even 2 optocouplers so you know the direction the motor is running (assuming it is a DC motor)
Or maybe even some mechanical key lock.
So then you have the RFID reader and the keylock which can validate whether the door should be operated.
I guess you also would like to sync this with HA.
However this presents the following race condition:
- RFID/keylock activates door
- RFID/keylock notifies HA, which also triggers to activate the door.
The local (via rules initiated) activation will probably arrive first. So when HA handles the RFID/keylock event it may act on the new situation where the door is no longer closed and thus open, so it will start closing it again.
So I think ESPEasy should keep track of the last state change and also make clear to HA what the state was when the key was presented.
Possible states:
- Door closed & open sequence initiated
- Door fully opened & close sequence initiated
- Door somewhere between fully closed and fully opened
- timeout
The last one may be the most difficult to handle like some timeout happened between while executing the open/close sequence.
What to do then?
I guess there is also some force detection on the motors to make sure nobody gets crushed.
And there are probably mechanical switches at the start and end to immediately turn off power to the motor?
I think this should all be done locally on the ESPEasy node using rules and then HA should get notified of each state change.
Also HA should be able to send a command to open/close the door, but then ESPEasy should act on it based on the current state.
To know the actual state, you need to have a switch at the end and one at the beginning and preferrably some signalling of whether the motor is running.
I don't like mechanical switches in such a setup for detecting the beginning and end as they always cause issues. (you should absolutely have one to mechanically disable power to the motor)
However for low current signalling with long cables, it is always hard to use.
So better use some Hall-effect sensor plus a magnet and twisted cable from the ESP to the Hall effect sensor.
This can also be setup to always draw some minimal current so you experience less noise and those don't show a bouncing signal like those mechanical switches do.
Power to the motor can be detected using some bridge rectifier and an optocoupler (essentially a LED) or maybe even 2 optocouplers so you know the direction the motor is running (assuming it is a DC motor)
Who is online
Users browsing this forum: No registered users and 3 guests