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

improve mqtt documentation #2967

Merged
merged 1 commit into from
Nov 21, 2019

Conversation

stromnet
Copy link
Contributor

@stromnet stromnet commented Nov 20, 2019

  • This PR is for the dev branch rather than for master.
  • This PR is compliant with the other contributing guidelines as well (if not, please describe why).
  • have thoroughly tested my contribution.
  • The code changes are reflected in the documentation at docs/*.

The existing documentation invalidly states that the offline callback is same as the connection-failure callback. I had reconnect code only in my 'offline' callback, which made the system fail to reconnect when mqtt connection was not immediately possible after it was disconnected (i.e. timeout did not trigger offline callback)

@marcelstoer
Copy link
Member

If the documentation is inconsistent with the code you can always ask yourself which of the two describes the intended behavior. I'm merging this so they're at least consistent.

@marcelstoer marcelstoer merged commit e3935de into nodemcu:dev Nov 21, 2019
@stromnet
Copy link
Contributor Author

Yes, I was contemplating that.. But the current behaviour makes sense I think, if we where never connected, then we cannot go offline (and thus should not call the "offline" callback).

@marcelstoer marcelstoer added this to the Next release milestone Nov 21, 2019
vsky279 pushed a commit to vsky279/nodemcu-firmware that referenced this pull request Dec 27, 2019
nwf added a commit to nwf/nodemcu-firmware that referenced this pull request Dec 28, 2019
This makes it just like all the other callbacks in the module and is a
revision of behavior called out in
nodemcu#2967
nwf added a commit to nwf/nodemcu-firmware that referenced this pull request Feb 2, 2020
This makes it just like all the other callbacks in the module and is a
revision of behavior called out in
nodemcu#2967
nwf added a commit to nwf/nodemcu-firmware that referenced this pull request Feb 2, 2020
This makes it just like all the other callbacks in the module and is a
revision of behavior called out in
nodemcu#2967
nwf added a commit to nwf/nodemcu-firmware that referenced this pull request Feb 3, 2020
This makes it just like all the other callbacks in the module and is a
revision of behavior called out in
nodemcu#2967
nwf added a commit to nwf/nodemcu-firmware that referenced this pull request Feb 23, 2020
This makes it just like all the other callbacks in the module and is a
revision of behavior called out in
nodemcu#2967
nwf added a commit to nwf/nodemcu-firmware that referenced this pull request Feb 23, 2020
This makes it just like all the other callbacks in the module and is a
revision of behavior called out in
nodemcu#2967
nwf added a commit to nwf/nodemcu-firmware that referenced this pull request Feb 25, 2020
This makes it just like all the other callbacks in the module and is a
revision of behavior called out in
nodemcu#2967
nwf added a commit to nwf/nodemcu-firmware that referenced this pull request Feb 25, 2020
This makes it just like all the other callbacks in the module and is a
revision of behavior called out in
nodemcu#2967
nwf added a commit that referenced this pull request Mar 14, 2020
* mqtt: expose "connfail" callback via :on()

This makes it just like all the other callbacks in the module and is a
revision of behavior called out in
#2967

* mqtt: clarify when puback callback fires

* mqtt: Don't reference stack buffers from the heap

The confusingly-named "mqtt_connection_t" object is just a triple of
  - a serialized mqtt message pointer and length
  - a buffer pointer (to which the above can be written)
  - a message identifier

The last of these must be passed around the mqtt state machine, but the
first two are very local and the buffer is always sourced from the C
stack.  Unfortunately, because the entire structure is persisted in the
heap, some callers assume that they can always use the structure without
reinitialization (see mqtt_socket_close), which will trash the C stack.

Sever the pairing between message id and local state, punt the local
state entirely out of the heap, and rename things to be less confusing.
marcelstoer pushed a commit that referenced this pull request Jun 9, 2020
marcelstoer pushed a commit that referenced this pull request Jun 9, 2020
* mqtt: expose "connfail" callback via :on()

This makes it just like all the other callbacks in the module and is a
revision of behavior called out in
#2967

* mqtt: clarify when puback callback fires

* mqtt: Don't reference stack buffers from the heap

The confusingly-named "mqtt_connection_t" object is just a triple of
  - a serialized mqtt message pointer and length
  - a buffer pointer (to which the above can be written)
  - a message identifier

The last of these must be passed around the mqtt state machine, but the
first two are very local and the buffer is always sourced from the C
stack.  Unfortunately, because the entire structure is persisted in the
heap, some callers assume that they can always use the structure without
reinitialization (see mqtt_socket_close), which will trash the C stack.

Sever the pairing between message id and local state, punt the local
state entirely out of the heap, and rename things to be less confusing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants