search

telefonicaid / iotagent-json

IoT Agent for a JSON based protocol (with HTTP, MQTT and AMQP transports)
https://fiware-iotagent-json.rtfd.io/
GNU Affero General Public License v3.0
51 stars 88 forks source link

Poll comand implementation for MQTT #270

Closed fgalan closed 5 years ago

fgalan commented 6 years ago

It seems poll comands are only implemented in the case of HTTP binding.

If this issue is finally implemented some day, the functionality should be properly covered by unit and e2e test and the documentation adapted. In particular, the following sentence in the user manual would be no longer correct:

Commands using the MQTT transport protocol binding always work in PUSH mode

M0nikaSharma commented 5 years ago

Hi @fgalan how a command can be poll in MQTT binding?? As in HTTP binding, Command is poll if device is provisioned without the endpoint attribute.

M0nikaSharma commented 5 years ago

Please help me to know ..how a command can be poll in MQTT binding??

fgalan commented 5 years ago

I haven't analyzed this in detail. Maybe poll commands haven't any sense in MQTT.

Thanks for your feedback! The idea of this issue is indeed to gather feedback and analisis. If at the end we conclude that it doesn't make any sense to have pool commands in MQTT, then we will close the issue without any further action.

Please keep posting if you have more ideas or suggestions about this :)

M0nikaSharma commented 5 years ago

Thank you for your response... As per my understanding, MQTT Broker receive subscription from clients on topics, received message from pub clients and forward these based on client subscriptions .. if client is unexpected disconnect from MQTT Broker and not able to received the published data. In that case , these published data will be discard by MQTT Broker ? or should be send after some time to client??

fgalan commented 5 years ago

Thank you for your response... As per my understanding, MQTT Broker receive subscription from clients on topics, received message from pub clients and forward these based on client subscriptions .. if client is unexpected disconnect from MQTT Broker and not able to received the published data. In that case , these published data will be discard by MQTT Broker ? or should be send after some time to client??

That is a MQTT general question, not directly related with IOTA-JSON, but I'll try to provide an answer anyway ;)

By default is as you said. I mean, if the client is not connected to the MQTT broker and subscribed to the given topic, it will not receive anything published on such topic. However, MQTT has a feature named retaineded messages that can be used for this. From https://www.hivemq.com/blog/mqtt-essentials-part-8-retained-messages/:

A retained message is a normal MQTT message with the retained flag set to true. The broker stores the last retained message and the corresponding QoS for that topic. Each client that subscribes to a topic pattern that matches the topic of the retained message receives the retained message immediately after they subscribe. The broker stores only one retained message per topic.

In addition, I think that QoS parameter allows to set some degree of re-publishing.

I recommend you to have a learn about MQTT documentation (for instance, this tutorial: https://www.hivemq.com/mqtt-essentials/) if you are not familiar with it.

M0nikaSharma commented 5 years ago

Hi @fgalan , Thank you for your help. I read below tutorial: https://www.hivemq.com/mqtt-essentials As per my understanding, MQTT provides Clean-session ,Retain flag and LWT( Last Will and Testament) feature which works as poll command. So I think poll command implementation is not required for MQTT.

fgalan commented 5 years ago

Yes, makes sense. Thus probably this issue can be closed with no efect. I'll check internally and eventually do so.

Thanks for the analysis!