ESP12-E blocked when MQTT broker is lost
Moderators: grovkillen, Stuntteam, TD-er
ESP12-E blocked when MQTT broker is lost
Good morning
I have 2 ESP12-E modemcu programed with ESPEASY and one of the units gets completely blocked and crazy when the connection with the connection with the MQTT server is lost.
I have a raspberry pi running mosquitto broker, if I just reboot there is no problem but if for some reason I stop it for working on it then the this specific module gets crazy.
If I try to connect to it trough HTTP there is impossible to handle as the connection is broken every 3 seconds or so.
The other unit I have shown no problem and when MQTT broker is down I can access the unit and surf fluently trough HTTP.
The only significant difference I find in between booth units is the fact that the one that gives me the problem have some outputs that are mapped (also some inputs) to MQTT to be remotely controlled and the unit is not giving me the fault just have inputs.
That makes the outputs to be energized and released all the time until I get the mosquitto broker up again.
Does anybody have some clue why this happens? Maybe due to some configuration that I'm not able to find? is that behavior normal?
An advice is welcome
Thanks in advance
I have 2 ESP12-E modemcu programed with ESPEASY and one of the units gets completely blocked and crazy when the connection with the connection with the MQTT server is lost.
I have a raspberry pi running mosquitto broker, if I just reboot there is no problem but if for some reason I stop it for working on it then the this specific module gets crazy.
If I try to connect to it trough HTTP there is impossible to handle as the connection is broken every 3 seconds or so.
The other unit I have shown no problem and when MQTT broker is down I can access the unit and surf fluently trough HTTP.
The only significant difference I find in between booth units is the fact that the one that gives me the problem have some outputs that are mapped (also some inputs) to MQTT to be remotely controlled and the unit is not giving me the fault just have inputs.
That makes the outputs to be energized and released all the time until I get the mosquitto broker up again.
Does anybody have some clue why this happens? Maybe due to some configuration that I'm not able to find? is that behavior normal?
An advice is welcome
Thanks in advance
Re: ESP12-E blocked when MQTT broker is lost
Nobody else has this issue?
Re: ESP12-E blocked when MQTT broker is lost
Yes, I've had the same experience of the unit behaving strangely on first boot, when my MQTT broker settings were not set up correctly. Unfortunately I can't remember which version of ESPeasy I was using at the time, but I suspect it was v120. In the end, I managed to correct the settings, one at a time, and when all were done it settled down. HTH.
Re: ESP12-E blocked when MQTT broker is lost
I think I have latest version:
GIT version: v2.0.0-dev11
And have no clue what else can I change into the config to avoid this:
Controller Settings
Protocol:
Locate Controller:
Controller IP:
192.168.1.200
Controller Port:
1883
Controller User:
Controller Password:
Controller Subscribe:
/%sysname%/#
Controller Publish:
%sysname%/%tskname%/%valname%
Enabled: YES
Controller Settings
MQTT Retain Msg:
Message Delay:
300
[ms]
GIT version: v2.0.0-dev11
And have no clue what else can I change into the config to avoid this:
Controller Settings
Protocol:
Locate Controller:
Controller IP:
192.168.1.200
Controller Port:
1883
Controller User:
Controller Password:
Controller Subscribe:
/%sysname%/#
Controller Publish:
%sysname%/%tskname%/%valname%
Enabled: YES
Controller Settings
MQTT Retain Msg:
Message Delay:
300
[ms]
Re: ESP12-E blocked when MQTT broker is lost
I notice a "?" against MQTT protocol in your last post. For what it's worth, I use "Openhab MQTT" (but then, I am using Openhab!)
My understanding is that the "Openhab" protocol also serves as a general-purpose MQTT protocol, but I think that Domoticz, for example, needs its own protocol.
Good luck!
My understanding is that the "Openhab" protocol also serves as a general-purpose MQTT protocol, but I think that Domoticz, for example, needs its own protocol.
Good luck!
Re: ESP12-E blocked when MQTT broker is lost
Hi again,
Just another thought on re-reading your post...
I assume that in your own system you have entries for Controller User and Password, and they were just blankin your post for security?
These need to match the way your MQTT broker is defined. Sorry if I'm stating the obvious!
Just another thought on re-reading your post...
I assume that in your own system you have entries for Controller User and Password, and they were just blankin your post for security?
These need to match the way your MQTT broker is defined. Sorry if I'm stating the obvious!
- grovkillen
- Core team member
- Posts: 3621
- Joined: 19 Jan 2017, 12:56
- Location: Hudiksvall, Sweden
- Contact:
Re: ESP12-E blocked when MQTT broker is lost
These should be the same, standards state that no BEGINNING forward slash should be used. It's no problem using them but in your case you subscribe to the topic WITH "/ " but publish on the topic without.
Controller Subscribe: %sysname%/#
Controller Publish: %sysname%/%tskname%/%valname%
I don't think it's what causing your problem but you may change that...
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
ESP Easy Webdumper [easy screendumping of your units]
ESP Easy Netscan [find units]
Official shop: https://firstbyte.shop/
Sponsor ESP Easy, we need you
Re: ESP12-E blocked when MQTT broker is lost
Thanks I didn't know that, I will try and let you know
-
- New user
- Posts: 7
- Joined: 03 Apr 2018, 14:18
Re: ESP12-E blocked when MQTT broker is lost
Have you found a solution to this problem?
Re: ESP12-E blocked when MQTT broker is lost
The way the MQTT controller is (re)trying to get connection has been changed about a month ago.
So in the last few builds there should be an improvement on this.
However, we are currently experiencing some issues with settings and wifi.
So please archive your settings before trying a newer version.
Or try on a different node using freshly created settings. (no update of settings, start from scratch)
Who is online
Users browsing this forum: No registered users and 28 guests