Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MQTT message retain state doesn't get saved #843

Closed
lativl opened this issue Feb 10, 2018 · 3 comments
Closed

MQTT message retain state doesn't get saved #843

lativl opened this issue Feb 10, 2018 · 3 comments
Labels
Category: Controller Related to interaction with other platforms Type: Bug Considered a bug
Milestone

Comments

@lativl
Copy link

lativl commented Feb 10, 2018

NOTE: This is not a support forum! For questions and support go here: https://www.letscontrolit.com/forum/viewforum.php?f=1

Steps to reproduce

  1. Enable option "MQTT Retain Msg" in Advanced menu
  2. Submit
  3. Execute command in rules (like " Publish home/alarm,disarmed")
  4. Check message in MQTT client (retained=false)

Does the problem presist after powering off and on? (just resetting isnt enough sometimes)
yes

Expected behavior

Tell us what should happen?
no

Actual behavior

Tell us what happens instead?
MQTT message sent with flag "retained"

System configuration

Hardware:

Software or git version:
Git Build":"v2.0-20180206", Wemos Mini D1

@Grovkillen Grovkillen added Type: Bug Considered a bug Category: Controller Related to interaction with other platforms labels Feb 10, 2018
@Grovkillen Grovkillen added this to the 2.0.0 milestone Feb 10, 2018
@TD-er
Copy link
Member

TD-er commented Feb 10, 2018

The retained flag is actually stored correctly within ESPeasy.
Up-to the point where the PubSubClient::publish() is being called, the retained flag is still how it should be.
The bug seems to be in the PubSubClient library.

I will continue digging.

@TD-er
Copy link
Member

TD-er commented Feb 10, 2018

Ah, found it...
It is actually working just fine :)

The retain bit is just a bit for sending to the broker.
The broker will then keep the last message in that topic with a retain flag. As soon as someone subscribes to that topic, it receives immediately the last retained message.
That's useful when the sender has some large interval for sending values.

So send a MQTT message with 'retain' flag set and a long enough interval to the broker.
Then -before a new message is sent- subscribe to that topic and the first message you'll get is marked 'retained'. All later messages are not marked 'retained', since you get them immediately from the broker.

For more information: https://www.hivemq.com/blog/mqtt-essentials-part-8-retained-messages

As 'proof' the two messages I received: (bottom one received first)
image

Using these rules:

on System#Boot do
  timerSet,1,10
endon

On Rules#Timer=1 do
  Publish %sysname%/IP,%ip%
  timerSet,1,30
endon

@lativl
Copy link
Author

lativl commented Feb 11, 2018

Yes, it seems you are right. Thanks for your efforts and good analysis!

@lativl lativl closed this as completed Feb 13, 2018
TD-er referenced this issue Feb 22, 2018
* [issue #869] Added 'LWT' to last will topic and improved CPU load

See #869 for discussion on Last Will Topic.
Also changed the way it tried to reconnect to make it return a lot faster when connection is not (yet) possible and call the PubSubClient::loop() at a much slower pace to reduce CPU usage. (See #847)
This higher CPU load was probably introduced when fixing #683.

* [MQTT] Fix error reporting success status with longer payloads

Applied PR https://github.com/knolleary/pubsubclient/pull/360/files

* made MQTT_CALLBACK_SIGNATURE for esp32 functional

Applied PR knolleary/pubsubclient#336
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: Controller Related to interaction with other platforms Type: Bug Considered a bug
Projects
None yet
Development

No branches or pull requests

3 participants