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

MQTTBinding: Add configuration for publishing retained messages. #147

Open
ezequiel-umu opened this issue Sep 16, 2016 · 2 comments
Open
Labels

Comments

@ezequiel-umu
Copy link

ezequiel-umu commented Sep 16, 2016

At

https://github.com/telefonicaid/iotagent-ul/blob/master/lib/bindings/MQTTBinding.js#L257

could there be a configuration flag for retained messages. It may be useful for low-consumption devices that are not listening at the moment of updates (many devices may only power on themselves once or twice a day).

@dmoranj
Copy link
Contributor

dmoranj commented Sep 16, 2016

It may be useful, indeed. We are currently implementing polling commands for the HTTP binding, precisely for the same reason (this issue was an old one). It seems to me retained messages will have a similar effect for MQTT.

@ezequiel-umu
Copy link
Author

I've seen this may get in conflict with how commands are designed:

If a low-consumption device is not listening at a time, and any component in this time sends two or more different cmds in this time, only last one will reach the device.

For example, if you want to play one sound then shutdown alarm:

topic               message
/myRealm/alarm1/cmd emitsound@time=20|sound=1
/myRealm/alarm1/cmd shutdown@time=5

Lets think that alarm check status every 5 seconds to save battery. If those two MQTT messages gets to the server between those 5 seconds, the first one will be lost. The alarm will be shutdown without playing any sound.

A solution with different design for MQTT binding may be:

topic                          message
/myRealm/alarm1/cmd/emitsound time=20|sound=1
/myRealm/alarm1/cmd/shutdown time=5

Or:

topic                          message
/myRealm/alarm1/cmd/emitsound <timestamp>@time=20|sound=1
/myRealm/alarm1/cmd/shutdown <timestamp>@time=5

By looking at timestamp this hypothetical device could check which command got first, in case of order being important.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants