Mqtt support for local use

[miloit]

Hey there is it possible to directly get the data via mqtt from my personal Sensor?

[ricki-z]

We won't provide mqtt support. There are too many different variants of how to transmit data. And we have only a limited amount of RAM and flash memory.

[EckhardM]

We won't provide mqtt support. There are too many different variants of how to transmit data. And we have only a limited amount of RAM and flash memory.

MQTT is much more easy and smaller than a HTTP transmission. MQTT is the standard for IoT devices and IMHO much more open than all the proprietary APIs you support today.

[pjgueno]

We won't provide mqtt support. There are too many different variants of how to transmit data. And we have only a limited amount of RAM and flash memory.

MQTT is much more easy and smaller than a HTTP transmission. MQTT is the standard for IoT devices and IMHO much more open than all the proprietary APIs you support today.

Is MQTT (and the brokers) open source ?
Which proprietary APIs do we use ?

[EckhardM]

Is MQTT (and the brokers) open source ? Which proprietary APIs do we use ?

Yes, MQTT is open source and there are open source brokers (like mosquitto.org).

Okay, the supported APIs are not proprietary but it would be better to add a state-of-the art IoT protocol than the next special HTTP-API. It has been proven that in the most cases MQTT suits much better for IoT then HTTP. (Check with Google: e.g. https://www.neovasolutions.com/2020/07/03/what-is-mqtt-protocol-and-how-does-it-work/)

[ricki-z]

@EckhardM Please read my comment again. It's not the protocol itself that may consume memory. The many different strings for transmission are the problem. Each service is using another format ...
If you conrtol both ends of the transmission then yes, mqtt may be better.

[pjgueno]

@EckhardM feel free to make an instance on internet which would forward data to MQTT. Just use the custom API option in our firmware for it.

[EckhardM]

@EckhardM Please read my comment again. It's not the protocol itself that may consume memory. The many different strings for transmission are the problem. Each service is using another format ... If you conrtol both ends of the transmission then yes, mqtt may be better.

I am not sure if your familiar with the concepts of MQTT. You are free to publish the data to a topic you define to one broker. That's all.

[EckhardM]

@EckhardM feel free to make an instance on internet which would forward data to MQTT. Just use the custom API option in our firmware for it.

That is possible but not the idea of MQTT. It should be used to gather data from the devices.

[ricki-z]

@EckhardM you are free to publish the data to a topic in any format you want. But only as long as there is no tool or service that should subscribe this topic and work with that data that you can't configure to work with the format you defined. Or you would need some kind of proxy script to convert your format to the format needed by the service or application.

[EckhardM]

@EckhardM you are free to publish the data to a topic in any format you want. But only as long as there is no tool or service that should subscribe this topic and work with that data that you can't configure to work with the format you defined. Or you would need some kind of proxy script to convert your format to the format needed by the service or application.

What's the problem? You can put all the measurements into a json (just the same you send to the custom API) and publish it to a topic. Everyone can subscribe this and use the data. I don't see the issue. You only need to specify the broker specification (address, port, login data, ssl) and a topic. Please have a look at other MQTT clients! It's quite easy.