ESP IDLE during Wifi Connection

[thalesmaoa]

I'm increasing the number of devices in my network. Two of them has poorly wifi connection.
During boot, node 107 takes almost 10min to establish a connection. Afterwise, it operates smoothly.

I thus have two problems to solve:
1) In case of power failures, 107 is an external light that boots in off state and don't turn on again. I was hopping that retaining flag from MQTT would restore its last state. However, I can't get it to work. Am I wrong, or it MQTT should handle it itself?
2) During those 10min in which ESPEasy is trying to connect, I try to turn the lights on using P2P. However, it doesn't respond to P2P. I try to:

Code: Select all

sentTo 107,"gpio,12,1"

It only answer when wifi is established.

Since this is an external light, I must find a way to get it back on as soon as possible.

Any help is appreciated.

PS: Just to reinforce, since it is an external light, it only turns on during twilight.

[TD-er]

I'm not sure I do understand the topic title, as it seems to be purely a WiFi (re)connect issue.

So let's concentrate on the WiFi part.

Do you have multiple access points with the same SSID?
Are they configured in WiFi mesh?

Settings to check on the tools->Advanced page:
- Have you tried to set the node to use 802.11 b/g only? (this may operate more stable on poor signal strength)
- Have you checked the checkbox to always use max. TX power?
- Have you disabled "ECO" mode?
- Have you checked the "Periodical send Gratuitous ARP" checkbox?

Things you can do to improve WiFi reception:
- Try to rotate the ESP device if possible. The polarization of the antenna should match the polarization of the antenna on the accesspoint for best reception.
- Make sure the antenna of the access point is vertical or at least as perpendicular to the line between AP and ESP node.
- Check to make sure there are no metal parts near the WiFi antenna. (also near the access point)

[thalesmaoa]

Yes. Wifi is one problem. Thank you.

Do you have multiple access points with the same SSID?
Are they configured in WiFi mesh?

No. I have three SSID with different names. All of them are AP.

Settings to check on the tools->Advanced page:
- Have you tried to set the node to use 802.11 b/g only? (this may operate more stable on poor signal strength)
- Have you checked the checkbox to always use max. TX power?
- Have you disabled "ECO" mode?
- Have you checked the "Periodical send Gratuitous ARP" checkbox?

As you suggested, I've checked:
- Force WiFi B/G
- Restart WiFi Lost Conn
- Force WiFi No Sleep
- Periodical send Gratuitous ARP
- Send With Max TX Power
- Extra WiFi scan loops: 2
- WiFi Sensitivity Margin: 3db

Thanks. Now it quickly connects.

About my question about "IDLEling" (not sure if this word exist).
One way to overcome wifi connection is use p2p. However, It doesn't work before wifi connection. Is this correct?

And the last question is how to restore the on state after power cycle.

[igorka]

Hello! I'm just starting to take the first steps in the development of ESP Easy, but maybe I can help you with something.

One way to overcome wifi connection is use p2p. However, It doesn't work before wifi connection. Is this correct?

I think you are right. Priority for wi-fi, and then only P2P. But I have not used P2P yet and I would also be interested in learning about options for using it both with and without a wi-fi network, only P2P communication.

And the last question is how to restore the on state after power cycle.

This is a good question, for automation it is necessary to solve it.Several options come to my mind:
1. The last state can be written to a variable and saved to non-volatile memory.This is not the best option, because the write / erase memory resource is limited.
2. As I understand it, you use an mqtt broker? If the broker is a third-party Internet resource and it is always online, then the state of the latest commands (values) can be stored on it, this is the easiest option. If, for example, you have a local server with mqtt, then you need to provide its back-up power supply and store the latest values ​​on it.

[TD-er]

Is the "On state" time dependent?
If so, then try to evaluate the system time at boot, and/or on the event indicating the time is set.

The suggested idea of using MQTT is also an option.
write the state to the broker using the retained flag.
As soon as someone subscribes to that topic, the last retained message will then be sent to the client.
You can use the MQTT import plugin for this.

One way to overcome wifi connection is use p2p. However, It doesn't work before wifi connection. Is this correct?

That's correct.
The current implementation is using the WiFi connection to communicate with other nodes.

[thalesmaoa]

Perfect. Can you please point a way to debug retain? It is not working. Not sure if is my config.

I'm using Home Assistant (openHAB) MQTT
Options enabled:
- Send LWT to broker
- Will Retain

[TD-er]

The "will retain" is about the LWT (Last Will and Testament)
That's a message which will be kept on the broker and only sent to newly connected users who subscribe to that topic after you (the user that sets the LWT) have lost connection.
The LWT can only be set when connecting to the broker.

What I meant was that Home Assistant maybe can send the state messages you need to act on with the "retain" flag enabled.
This way you can be sure the last state will be available as soon as you subscribe to that topic. (or any other user that may subscribe to that topic)

N.B. there can be only 1 message retained per topic, but for keeping the last state this is perfect.

Right now, I don't think you can publish a retained message from within ESPEasy (other than the LWT)
Have to check the code for this as I'm not sure anymore.

[thalesmaoa]

Ok. Now it is almost clear that I got the idea correct.
I did have the correct idea about MQTT and about the retain flag principle.
I already have a MQTT server with a UPS, so it never turns off.

The way I expect it to work:

MQTT Broker send on state to the module.
MQQT SERVER --> ESPeasy/gpio/12/1

If I reboot (software) ESPEasy, ESPEasy will subscribe again to the topic, and another message will be sent.
MQQT SERVER --> ESPeasy/gpio/12/1

This is not happening. I need some ideas about "how to debug".
Do you know a program that I can sniff MQTT connection, subscribe and retaining? With that I will probably identify if this is an ESPEasy problem or a MQTT problem.

Thanks

[TD-er]

I always use MQTT Explorer, which can be found in the Microsoft Store on Windows.
No idea what other alternatives there are for other platforms.

Your domotica system should send to that topic using the retained flag.
That's not a default setting.

[thalesmaoa]

Just to close this topic, I found the problem. Probably my own ignorance...

The retain flag was not working because QoS in the broker was set to 2. ESPEasy QoS is 0. When I put QoS 1 or 0 in the broker side, it does work.
I appreciate if anyone can explain if this behavior is normal or just a bug.

[TD-er]

When looking for info on MQTT, I always end up reading these excellent tutorials written by HiveMQ.
https://www.hivemq.com/blog/mqtt-essent ... ce-levels/

I suggest to read them all and then you probably can teach me a thing or two about MQTT

But in short, with QoS set to 2, it seems all messages will be dealt with like a retained message does.
Right now there is no setting in ESPEasy to set the QoS level.
Not sure if the MQTT library does support it, I have to look into it.

[thalesmaoa]

Awesome! I will take a look as well. Maybe I can help with something.

[thalesmaoa]

Solved!

https://github.com/letscontrolit/ESPEas ... imitations

It can only subscribe to QoS 0 or 1.

Thanks!