Differentiate between GPIO Boot State and real Push Button?

Moderators: grovkillen, Stuntteam, TD-er

Post Reply
Message
Author
Oetsch
Normal user
Posts: 195
Joined: 13 Jul 2020, 12:10

Differentiate between GPIO Boot State and real Push Button?

#1 Post by Oetsch » 12 Feb 2021, 17:10

Hello,

sadly I learned that my solution doesn´t work and because of a reboot of D1 mini a GPIO acted like a push Button and the pump started to overfill a tank in the cellar.

As already discussed before viewtopic.php?f=5&t=7940#p46537 I tried to use other GPIOs for the push button (start & stop) but according known information this other GPIOs are not so different to the current GPIO_12 for Start push button and GPIO_13 for stop push button.

So to be 100% sure I´m looking for a software solution to differentiate between high from reboot and a real high from a manual push.

Do you have a recommendation?

All states are transfered via Mqtt.

Do you think it make sence to transfer an additional value via MQTT and this value is changed based on a timer which is reset at reboot. But in that case I see a problem in the moment the ESP8266 reboots. The additional value is old and still unchanged but the start push state is set high by reboot and the logic will recognise that high value as ok and start the pump, mmmh.

Do you have an Idea how to solve?

Thank you very much!

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Differentiate between GPIO Boot State and real Push Button?

#2 Post by TD-er » 12 Feb 2021, 22:14

One thing you always (always!!!) need to keep in mind is that a computer (ESP's are also a computer) may fail.
They may crash, halt, reboot or the software may have a bug.
Cables may become loose, a sensor may get dirty or fail otherwise, etc.

So you must always anticipate for worst case scenario.
If all fails, what will happen and what is worse?
For example, a flooded cellar or a dry running pump.

The best way is to have some very simple hardware stop.
For example a floater on a water level pressing a button which disconnects the pump.

After those emergency stops are implemented, you can have a look at the rest.

One of the things that can go wrong very easily with switches is that they are connected to some (long) wire and start acting as an antenna, giving false activity.

The best way to keep track of a state is either set it yourself, or read it somewhere.
For example to check if a pump is running, you may want to read the used current.
Or make sure you are the one to start the pump.
Also make sure the pump is in the best state when powering on the ESP.
Not only can an ESP crash and reboot, but you may also have a power failure.
Should the pump stop if the ESP looses its power?

Oetsch
Normal user
Posts: 195
Joined: 13 Jul 2020, 12:10

Re: Differentiate between GPIO Boot State and real Push Button?

#3 Post by Oetsch » 13 Feb 2021, 10:31

Hi
Thank you very much and I´m checking carefully what you suggested.

With regard to the start of the pump there is always some logic needed because the pump also has 2 valves. In case the tank in the cellar has a high limit it can also be wanted to start the pump because the valve is in position to the garden and not to fill the tank.
Image
So what I did (by implemented logic), in case the tank water level is >90% the logic checks the valve position and in case of tank-filling-position it will stop the pump.
In addition there is a logic in case the tank water level is >92% the valve is automatically turned into garden-position. Because as mentioned the tank is in the cellar and by gravity the tank will further be filled even if the pump has stopped and the pipe is open.

But this 2 logics has not worked because connected to the rebooted ESP the are also 2 further push buttons connected which are the selector push buttons for the 2 valves. I´m not sure if either the signal from these push buttons/ESP during reboot has confused the logic or the markers in the system for the position have been wrong/old. So now I changed the logic not to use these markers and they now use the end_position_signals of the valves directly. Only if the valve is in end position to the garden the pump will not stop.The pump stops working in case it is not properly connected to the system anyway (auto off timer).
In case of water level >92% the valve will be pushed/forced as long as the end position "garden" is confirmed/reached.
But these end_position_signals (valve) are also connected to a wireless device (shelly 2.5) and when this device is offline the signal might be wrong or old in the system.
In addition, the level information from the tank is generated by an ultrasonic measurement (HC-SR04). In general it works but to be 100% sure i would not agree that this is the right device.

I like the idea of emergency level switch at the top of the tank but have to check how the signal can be used in most reliable way. The pump itself is started/stoped by a shelly 1pm. Have to check if the switch input at the shelly 1pm can be used in a reverse logic to stop the pump without having a need to use the cloud from shelly. Think this would be most reliable way at the moment. In case this does not work, I´m thinking of implementing an additional relay to cut of the pump from power.
Still have to avoid filling by gravity but in case this emergency level switch will act the level of the tank is far over 90%/92% so really heavy actions could be done and also alarms to my smartphone . Like this very much thank you!


This will protect against the worst cases but the ESP reboot will/can further on cause unwanted starts of the pump. Do you have an idea how to differentiate.
My problem is still the start signal.
Part of the problem is using this push buttons. Switches will not have this problem or better will only cause very short starts of the pump until ESP is back to "normal" after reboot.

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Differentiate between GPIO Boot State and real Push Button?

#4 Post by TD-er » 13 Feb 2021, 11:57

I think in your setup it is best to use actual toggle switches instead of push buttons for multiple reasons.
The most obvious is of course the ability to read the state as intended compared to a state that gets lost when rebooting or power loss (different situation!)
Make sure not to use GPIO-0, 2 or 15 for these switches as those pins need a specific state during boot of the ESP.

The less obvious reason to use toggle switches is that they can be used with a long debounce time and thus filter out a lot more noise which can be picked up on the lines between the switch and the ESP.

Oetsch
Normal user
Posts: 195
Joined: 13 Jul 2020, 12:10

Re: Differentiate between GPIO Boot State and real Push Button?

#5 Post by Oetsch » 13 Feb 2021, 12:33

Thx, have to think about the setup by using toggle switches.

The local panel with buttons isn´t the only operator interface and the system can also be operated from screen. For this I´m struggeling how to handle in case the pump start toggle switch is turned on at the local panel but then operation is done by screen. Could be "overuled" but then toggle switch position does no longer fit to the current state of the system and it is getting difficult to handle.

I´m thinking at the moment about the handling of espeasy "long push configuration". I would generate a special datapoint in the automation system (mqtt) which is only set by longpush start button of the local panel (ESP unit). Short pushes of start of the panel like also done by reboot aren´t used from the system anymore to start the pump.

In addition I will have a usable "short push start" in the system which is only used for screen operation but is not linked to the ESP unit.

But this would mean that I have a clear knowledge that configured longpush is not /cannot be done by reboot of the esp unit.
If you agree this an alternative, I´m struggeling how to configure within espeasy. Wiki seems to be at an older status before longpress was implemented for switch input. Will try to find how to use but not sure at the moment.

Rest of the short pushes from panel like stop or selection of valve position I do not really see critical at the moment because stop is a safe state and valve positions are overruled by emergency logic.


Edit:

Regarding the Longpress configuration. The push buttons are pushed to GND. I use Inversed logic in the configuration of the input switch as follows:
Image

What does this mean for the longpress configuration?
docu says:"Active only on low: this means that the unit will only be triggering the long press event if the signal is low"
Is this now real Low or also inveresed logic?

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Differentiate between GPIO Boot State and real Push Button?

#6 Post by TD-er » 13 Feb 2021, 17:35

The author of the GPIO extensions, longpulse etc. started a PR which also contains the (long awaited) documentation.
https://github.com/letscontrolit/ESPEasy/pull/3431
However I have not yet merged it as I still have to review it.
But maybe it can be helpful for your understanding.

Oetsch
Normal user
Posts: 195
Joined: 13 Jul 2020, 12:10

Re: Differentiate between GPIO Boot State and real Push Button?

#7 Post by Oetsch » 13 Feb 2021, 19:43

TD-er wrote: 13 Feb 2021, 17:35 The author of the GPIO extensions, longpulse etc. started a PR which also contains the (long awaited) documentation.
https://github.com/letscontrolit/ESPEasy/pull/3431
However I have not yet merged it as I still have to review it.
But maybe it can be helpful for your understanding.
Sorry, have not understand/found the relation to longpress. For the GPIO extensions I can see some information regarding longpulse.
This seems to explain a little bit but I´m unsure if this is still up to date and I should try like the given rules to publish via MQTT
https://github.com/letscontrolit/ESPEasy/issues/2696

Code: Select all

on Switch1#switch1=1 do
 timerSet,1,1
EndOn

on Switch1#switch1=11 do
 Publish sometopic/switch1,long
 timerSet,1,0
endon

I will do some testing, of course. But this does not mean that it´s "safe" to use. Like to find out if my understanding is right that longpress is detected by a fully loaded espeasy after reboot and measures the time as long a push button is pushed before switching it´s state.

I´m assuming that this Datapoint isn´t and cannot be set to 10/11 by rebooting of an esp unit because the plug in isn´t loaded during reboot and the GPIO HIGH from reboot is "only" a short signal sent by 0 or 1 to controller. Longpress is sent as 10 or 11 to controller. Therefore I´m assuming longpress is not influenced by reboot, right?

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Differentiate between GPIO Boot State and real Push Button?

#8 Post by TD-er » 13 Feb 2021, 20:06

Longpress is part of P001_Switch.
So it may indeed not be part of that specific PR (like I said, have not yet reviewed that PR), so sorry for the confusion it may have caused.

Just some more info on the 'states' of task values.
The values shown on the "Devices" tab of the web interface are all values of a task.
Those values will be stored in a special memory (RTC) which is kept during a crash/reboot as long as the power is applied.
So after a "cold boot" (power loss) these values are lost.

A task with the "switch" plugin may also do this, but since its value may get updated almost immediately it is of no real use at reboot.
What you can do, is store some values in a "dummy" task, so they are restored at boot.
In the rules you can try to evaluate the values stored in a "dummy" task to see if you need to take action.
But like I said before, this will not be useful on a power cycle. Therefore it may be best to use toggle switches as they do keep their intended state even after a power cycle.

Oetsch
Normal user
Posts: 195
Joined: 13 Jul 2020, 12:10

Re: Differentiate between GPIO Boot State and real Push Button?

#9 Post by Oetsch » 15 Feb 2021, 10:32

Thx, from my point of view I don´t have a need to restore states/values after reboot.

I´m looking for a push signal that is 100% coming from a button/ manual action. Therefore I thought of using longpress for the start signal of the pump.

During reboot all values/states of the switch plugin might get lost (no problem), but I must be sure that a High/Low value from GPIO because of reboot will never activate longpress.

I do not know how this plugin or the reboot act together.

I like to configure e.g. 5 seconds for longpress and because reboot will never take 5 seconds I guess reboot will never cause a longpress signal. This I like to understand and ask for your understanding if this is a plausible conclusion and solution?

Post Reply

Who is online

Users browsing this forum: No registered users and 17 guests