Stability problem

Moderators: grovkillen, Stuntteam, TD-er

Post Reply
Message
Author
przemek63
Normal user
Posts: 13
Joined: 16 Feb 2020, 16:10

Stability problem

#1 Post by przemek63 » 28 Feb 2020, 20:38

Hello

This is my first message and attempt to run espeasty.

I have to admit I am a little disappointed with this software because it seems to me very unstable and not suitable for production applications.

Please, let someone direct me what I do wrong and why my lab behaves badly.

scheme:

MCP23017 relay --- --- espeasy (mcp8266) --- --- wireless Domoticz

In espeasy I set the "domoticz" controlers and devices "Switch input - MCP23017". And in domoticz Dummy switch (on / off) with parameters:
http://172.16.70.200/control?cmd=mcpgpio,10,1
http://172.16.70.200/control?cmd=mcpgpio,10,0

And it works, but very unstable, at domoticz pressing the button turns on or off the relay but sometimes with one click the relay closes and bounces back
and sometimes with a single click on domoticz it gets on-off-on-off-on-off and so many times. Only reboot esp stops this state.
And sometimes everything works very well.

I guess espeasy is very good soft and I have a problem somewhere but I don't know where.

I am asking for help in this topic.

Thank you all for your attention.

User avatar
grovkillen
Core team member
Posts: 3621
Joined: 19 Jan 2017, 12:56
Location: Hudiksvall, Sweden
Contact:

Re: Stability problem

#2 Post by grovkillen » 28 Feb 2020, 21:47

I never use the GPIO commands directly, instead I use rules to do it. Send an event command instead.
ESP Easy Flasher [flash tool and wifi setup at flash time]
ESP Easy Webdumper [easy screendumping of your units]
ESP Easy Netscan [find units]
Official shop: https://firstbyte.shop/
Sponsor ESP Easy, we need you :idea: :idea: :idea:

Wiki
Normal user
Posts: 413
Joined: 23 Apr 2018, 17:55
Location: Germany

Re: Stability problem

#3 Post by Wiki » 29 Feb 2020, 03:47

For me it looks like as if there are missing some pullup/pulldown resistors to get stable and well defined signal/state for switching the relays.

I have several self-soldered relays controlled by several Wemos D1 boards running ESPEasy and never ever encountered a behaviour like the one you described. You should check your wiring and the needed pullup/pulldown resistors.

I am sorry to not be able to give you a more detailed advice without knowledge of your electrical layout.

Code: Select all

pi@raspberrypi:~ $ man woman
No manual entry for woman
pi@raspberrypi:~ $

przemek63
Normal user
Posts: 13
Joined: 16 Feb 2020, 16:10

Re: Stability problem

#4 Post by przemek63 » 29 Feb 2020, 08:54

Thank you for the answer, it looks like this:

I tried the "event command" like this:

on ToggleGPIO do

if [relay-led-duze#State]=0
mcpgpio,%eventvalue1%,%eventvalue2%
delay,1500
endif

if [relay-led-duze#State]=1
mcpgpio,%eventvalue1%,%eventvalue2%
delay,1500
endif

endon

However, it behaves in the same way as before, i.e. on-off-on-off-on .....

As for pullup / down, MCP23017 controls the high state (+ 3.3V per pin - ON on the relay 0V on pin = OFF on the relay.)
I connected 10kOhm between the output pin and ground so that it would not hang in the air in a low state.
However, this was unsuccessful.

I think, though I may be wrong, it is like this:

EspEasy sends all the time (every 1000ms) to the domoticz status (on or off). If domoticz sends an url to esp with a change of state, esp changes the state of the pin but the mechanism sending it every 1000ms the state of the pin sends back to the domoticz the previous outdated state from before the change. Domoticz receives this as another state change and sends it back to esp. esp receives and changes the status to this, and the 1000ms mechanism sends the previous status anyway ...

I might be wrong.


by the way, I would like to ask if it is normal that espeasy sends to domoticz all the time the status of a given pin, even if it has not changed? it causes flood

djelau
Normal user
Posts: 45
Joined: 08 Nov 2019, 15:33
Location: France

Re: Stability problem

#5 Post by djelau » 29 Feb 2020, 09:43

Hello,

do you check if the power supply is sufficient to supply everything? Isn't it a reset of the espeasy due to weak power supply ?
If you try to drive a simple LED, does it work correctly ?
Do you have free wheeling diodes ?

Same than Wiki, never have such behavior with my wemos.

przemek63
Normal user
Posts: 13
Joined: 16 Feb 2020, 16:10

Re: Stability problem

#6 Post by przemek63 » 29 Feb 2020, 13:49

Uptime is a few days and the system consumes max 110mA (powered from the laboratory power supply)
 
I analyzed network communication and it seems that this is not an ESP problem but Domoticz.

My observations:
Initial state: state 0 is OFF, state 1 is ON.
Analyzes incoming traffic to domoticz:

Correct action:

Code: Select all

13:19:56.382283 IP 172.16.70.200.60651 > 172.16.70.234.http-alt: Flags [P.], seq 1:179, ack 1, win 2144, length 178: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=Off&rssi=9 HTTP/1.1
13:19:56.603085 IP 172.16.70.234.32906 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,0 HTTP/1.1
13:19:57.404266 IP 172.16.70.200.62879 > 172.16.70.234.http-alt: Flags [P.], seq 1:179, ack 1, win 2144, length 178: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=Off&rssi=9 HTTP/1.1
13:19:57.625579 IP 172.16.70.234.32908 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,0 HTTP/1.1
13:19:58.425396 IP 172.16.70.200.61294 > 172.16.70.234.http-alt: Flags [P.], seq 1:179, ack 1, win 2144, length 178: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=Off&rssi=9 HTTP/1.1
13:19:58.649209 IP 172.16.70.234.32910 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,0 HTTP/1.1
13:19:59.447107 IP 172.16.70.200.52537 > 172.16.70.234.http-alt: Flags [P.], seq 1:179, ack 1, win 2144, length 178: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=Off&rssi=9 HTTP/1.1
13:19:59.673860 IP 172.16.70.234.32912 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,0 HTTP/1.1
13:20:00.469410 IP 172.16.70.200.51164 > 172.16.70.234.http-alt: Flags [P.], seq 1:179, ack 1, win 2144, length 178: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=Off&rssi=9 HTTP/1.1
13:20:00.696068 IP 172.16.70.234.32916 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,0 HTTP/1.1
13:20:01.496942 IP 172.16.70.200.60926 > 172.16.70.234.http-alt: Flags [P.], seq 1:179, ack 1, win 2144, length 178: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=Off&rssi=9 HTTP/1.1
13:20:01.722907 IP 172.16.70.234.32918 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,0 HTTP/1.1
13:20:02.521960 IP 172.16.70.200.57130 > 172.16.70.234.http-alt: Flags [P.], seq 1:179, ack 1, win 2144, length 178: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=Off&rssi=9 HTTP/1.1
13:20:02.745792 IP 172.16.70.234.32920 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,0 HTTP/1.1
13:20:03.545504 IP 172.16.70.200.59458 > 172.16.70.234.http-alt: Flags [P.], seq 1:179, ack 1, win 2144, length 178: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=Off&rssi=9 HTTP/1.1
13:20:03.767035 IP 172.16.70.234.32922 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,0 HTTP/1.1
13:20:04.346506 IP 172.16.70.234.32924 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,1 HTTP/1.1 <--- Manual click on dashboard domoticz
13:20:04.711828 IP 172.16.70.200.55265 > 172.16.70.234.http-alt: Flags [P.], seq 1:178, ack 1, win 2144, length 177: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=On&rssi=9 HTTP/1.1
13:20:04.929846 IP 172.16.70.234.32926 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,1 HTTP/1.1
13:20:05.745427 IP 172.16.70.200.62283 > 172.16.70.234.http-alt: Flags [P.], seq 1:178, ack 1, win 2144, length 177: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=On&rssi=9 HTTP/1.1
13:20:05.951962 IP 172.16.70.234.32928 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,1 HTTP/1.1
13:20:06.769863 IP 172.16.70.200.62309 > 172.16.70.234.http-alt: Flags [P.], seq 1:178, ack 1, win 2144, length 177: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=On&rssi=9 HTTP/1.1
13:20:06.980259 IP 172.16.70.234.32930 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,1 HTTP/1.1
13:20:07.794851 IP 172.16.70.200.49702 > 172.16.70.234.http-alt: Flags [P.], seq 1:178, ack 1, win 2144, length 177: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=On&rssi=9 HTTP/1.1

bad action:

Code: Select all

57341 > 172.16.70.234.http-alt: Flags [P.], seq 1:179, ack 1, win 2144, length 178: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=Off&rssi=9 HTTP/1.1
13:17:35.287842 IP 172.16.70.234.60822 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,0 HTTP/1.1
13:17:36.074030 IP 172.16.70.200.56717 > 172.16.70.234.http-alt: Flags [P.], seq 1:179, ack 1, win 2144, length 178: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=Off&rssi=9 HTTP/1.1
13:17:36.311713 IP 172.16.70.234.60824 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,0 HTTP/1.1
13:17:37.096274 IP 172.16.70.200.63070 > 172.16.70.234.http-alt: Flags [P.], seq 1:179, ack 1, win 2144, length 178: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=Off&rssi=9 HTTP/1.1
13:17:37.335083 IP 172.16.70.234.60826 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,0 HTTP/1.1
13:17:38.120304 IP 172.16.70.200.56294 > 172.16.70.234.http-alt: Flags [P.], seq 1:179, ack 1, win 2144, length 178: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=Off&rssi=9 HTTP/1.1
13:17:38.360037 IP 172.16.70.234.60828 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,0 HTTP/1.1
13:17:39.144789 IP 172.16.70.200.65472 > 172.16.70.234.http-alt: Flags [P.], seq 1:179, ack 1, win 2144, length 178: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=Off&rssi=9 HTTP/1.1
13:17:39.381415 IP 172.16.70.234.60832 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,0 HTTP/1.1
13:17:40.168345 IP 172.16.70.200.49471 > 172.16.70.234.http-alt: Flags [P.], seq 1:179, ack 1, win 2144, length 178: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=Off&rssi=9 HTTP/1.1
13:17:40.288035 IP 172.16.70.234.60834 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,1 HTTP/1.1<--- Manual click on dashboard domoticz
13:17:40.389568 IP 172.16.70.234.60836 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,0 HTTP/1.1
13:17:41.192290 IP 172.16.70.200.51673 > 172.16.70.234.http-alt: Flags [P.], seq 1:179, ack 1, win 2144, length 178: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=Off&rssi=9 HTTP/1.1
13:17:41.414347 IP 172.16.70.234.60838 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,0 HTTP/1.1
13:17:42.216287 IP 172.16.70.200.61865 > 172.16.70.234.http-alt: Flags [P.], seq 1:179, ack 1, win 2144, length 178: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=Off&rssi=9 HTTP/1.1
13:17:42.445251 IP 172.16.70.234.60840 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,0 HTTP/1.1
13:17:43.243672 IP 172.16.70.200.54300 > 172.16.70.234.http-alt: Flags [P.], seq 1:179, ack 1, win 2144, length 178: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=Off&rssi=9 HTTP/1.1
13:17:43.466332 IP 172.16.70.234.60842 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,0 HTTP/1.1
13:17:44.266651 IP 172.16.70.200.52717 > 172.16.70.234.http-alt: Flags [P.], seq 1:179, ack 1, win 2144, length 178: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=Off&rssi=9 HTTP/1.1
13:17:44.490884 IP 172.16.70.234.60844 > 172.16.70.200.http: Flags [P.], seq 1:241, ack 1, win 64240, length 240: HTTP: GET /control?cmd=event,ToggleGPIO=10,0 HTTP/1.1
13:17:45.289092 IP 172.16.70.200.50281 > 172.16.70.234.http-alt: Flags [P.], seq 1:179, ack 1, win 2144, length 178: HTTP: GET /json.htm?type=command&param=switchlight&idx=1&switchcmd=Off&rssi=9 HTTP/1.1
This means that domoticz, although he received the manual ON command and sent it to ESP, he responded to the previous request from ESP which was OFF.



So the question arises whether it can be done so that esp after receiving a given variable get for some time (xxx ms) to ignore subsequent get requests?

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

Re: Stability problem

#7 Post by TD-er » 29 Feb 2020, 16:14

First of all, just a rule of thumb.
If you ever need to use delay() in the rules, you're bound to mess up some time.
It means you will define something based on timings you once noticed and those will not always be the same.
So almost always, if you have to rely on timings, you will eventually into issues.

Apart from that, the delay command in rules is also blocking code.
It means the ESP will do nothing other than making sure it stays connected to the network and not run into watchdog reboots.
But since ESPEasy is meant to so several things at the same time, you will mess up other tasks on the ESP and maybe also miss updates of communications between Domoticz or other network communications.

What you can do, is select a "factory default" (can also be done on another unit) and select a unit in the combobox which does contain a switch + relay as it will generate a configuration for you.

For example the rules + config generated on one of my Sonoff modules:

Code: Select all

on Button1#switch do
  if [Button1#switch]=1
    gpio,12,1
  else
    gpio,12,0
  endif
endon
Push button is connected to GPIO-0 and it you should select "Push button active low" in the switch plugin. (and name it "Button1")
I also have switched on the pull up resistor.

The switch is added and I called it "Relay1", but as you can see, the relay is switched via the GPIO pin.
Internal pull up is also checked there.

The button one is also the one you need to couple to Domoticz (as described here: https://www.letscontrolit.com/wiki/inde ... noff_basic )

przemek63
Normal user
Posts: 13
Joined: 16 Feb 2020, 16:10

Re: Stability problem

#8 Post by przemek63 » 29 Feb 2020, 16:30

forgive me for not writing earlier, but I only put in the delay for a moment, if it is not there then what I have pasted in the logs is happening.

My idea is that you need the "rules" code which after receiving the GET will perform on or off actions and wait a moment to ignore the next GET coming from domoticz

  TD-er - I don't need a physical button with a pull-up resistor, so Button1 # switch is not needed.

I will try to write rules that after receiving a get from a domoticz other than the previous one will do it and ignore the next one for a specified time (500ms)

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

Re: Stability problem

#9 Post by TD-er » 29 Feb 2020, 16:59

The general idea is that you act on the "button" task and changes of that task will result in rules events switching the GPIO.
If you only use a single task for it, you will see the on/off/on/off events.
What happens then is:
- state change is reported to Domoticz
- Domoticz reacts on the state change by sending a state change
- Task will react on the Domoticz command by changing the state and thus report the changed state to Domoticz.
- ... etc.

przemek63
Normal user
Posts: 13
Joined: 16 Feb 2020, 16:10

Re: Stability problem

#10 Post by przemek63 » 29 Feb 2020, 18:25

Thank you very much for taking up the topic and for your patience, but I would like to ask you to clarify the principle of operation again.

From the beginning:

in domoticz I have On action: ... control? cmd = mcpgpio, 10.1 and Off action: ... control? cmd = mcpgpio, 10.0

and now when I press the bulb in domoticz, the relay connected to ESP works correctly, unless I press the bulb at the moment when domoticz sends a response to ESP with the status from before clicking the bulb. Then the relay does on and off immediately. pressing the bulb again if it is not at the moment of sending by the status will work correctly and activate the relay.

As he wrote several kilos above, I understand the principle of the physical button and the pasted code, but I do not use such a button.
I only have a relay connected to esp and I want to control it only via the network.

In espeasy I have configured to send the contactor status to the controller, and in the controller settings I have "Minimum Send Interval" for 1000ms. and approximately every 1s network connections are generated. (both ways esp to domoticz and domoticz to esp)

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

Re: Stability problem

#11 Post by TD-er » 29 Feb 2020, 22:43

You don't need to use a button, but just a layer in between
The switch plugin will act on the true state of the relay/GPIO.
So if you change it, the state of the GPIO pin and what Domoticz assumes, then you may get this behavior.

This means you must make sure the state of the button remains in sync with Domoticz.
To do this you must make sure you will always toggle the switch in a single way and only this way.
So only switch via the switch plugin, not by flipping the gpio pin directly.

Now we move to 2 different concepts of switching a GPIO pin, each with their own approach.
It sounds very simple, just switch a pin state, but as it appears, this is way more complicated than you may think.

Basically we have "normal" and "toggle".

The "normal" one is probably the easier one to figure out why it is acting as it does.
Imagine your plugin is set to "1" and the GPIO pin is also "1" (open/close may be a bit confusing, so I will just refer to it as 0 and 1)
From Domoticz you will send "0" to the plugin, so it will switch the GPIO to "0".

If you send the switch command to the switch plugin, it will send an update to Domoticz, so its state in Domoticz will be in sync with the GPIO state.

Now you're switching the GPIO state directly and not via the switch plugin.
So the GPIO state will differ from the switch state and as soon as Domoticz will send out a command, it will see a different state.
Even worse if there are 2 systems here trying to control the output.

By controlling it via the switch plugin, it will send out an event which we can use in rules to act on it.
So you can keep track of the actual state (or just make it toggle) in the rules and just let the switch plugin receive the command to switch which may be as simple as "now toggle the GPIO" and the actual state of the pin will then be returned to the connected controller (e.g. Domoticz)
So by using a switch plugin as abstraction layer (doesn't have to be connected to an actual pin), it may trigger an event which you can use in the rules to do the actual switching.

It's a lot of text and I'm not sure it will clear the conceptual differences for you.
You have to realize there is a state of the logic (plugin and in the controller like Domoticz), and the actual state of the GPIO pin.
They don't need to be in sync and sometimes it is the better solution to consider the "logic state" as something that you just need to toggle.
So it doesn't matter if you have to flip the switch "off" or "on", as long as the light goes "on" because it is now dark.
This also means you need some system to get the true state of the GPIO pin (the switch plugin on the GPIO pin) and something to toggle the state if needed. (the switch called "button", which doesn't need to be connected to a button)

przemek63
Normal user
Posts: 13
Joined: 16 Feb 2020, 16:10

Re: Stability problem

#12 Post by przemek63 » 01 Mar 2020, 06:40

You are the best: D

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot] and 26 guests