Re: Possible replacement MQTT library
Posted: Sun Sep 27, 2020 3:30 am
The clearify once more, I don't have the intention to use a broker or receiver in the cloud myself. If I am going to use MQTT to push my sensors' reading, it will be towards a receiver in my own network and eventually, after assessing the protocol implementation is correct, I will make my own receiver. But it should be compatible to those cloud services and local receivers for other people to use.
So the question remains: people that are using cloud services or ready-made receivers, what services/receivers are you using and how are the messages formatted (content).
If it turns out every cloud service or receiver define their own content format, I think it's a futile excercition to try to make a "generic" interface to them. Then indeed you'd need just a library and the end user needs to write the code to insert the content. Or use something like Arduino, not really my kind of thing.
Also if no standard (either real or defacto) exists for sending sensor readings, then I struggle a bit to see the added value for the extra burden of the MQTT encapsulation, one could almost just as good put the content into a raw UDP datagram. Or use TCP for more reliability but then you'd have to create a record structure with a length field, kind of MQTT does, as TCP has no concept of records/boundaries.
Just brainstorming here...
So the question remains: people that are using cloud services or ready-made receivers, what services/receivers are you using and how are the messages formatted (content).
If it turns out every cloud service or receiver define their own content format, I think it's a futile excercition to try to make a "generic" interface to them. Then indeed you'd need just a library and the end user needs to write the code to insert the content. Or use something like Arduino, not really my kind of thing.
Also if no standard (either real or defacto) exists for sending sensor readings, then I struggle a bit to see the added value for the extra burden of the MQTT encapsulation, one could almost just as good put the content into a raw UDP datagram. Or use TCP for more reliability but then you'd have to create a record structure with a length field, kind of MQTT does, as TCP has no concept of records/boundaries.
Just brainstorming here...