The B4R rMQTT library is based on the well known Arduino PubSubClient library written by Nick O'Leary. It's a subset of this library - with the most important/used methods wrapped. I do have a scenario that requires some of the additional methods to be wrapped as well. Specifically:
In fact the last scenario is exactly what I'm looking to accomplish. On my esp8266 sketch, I'm downloading a jpeg snapshot via HTTP from an IP Camera and temporarily storing it in SPIFFS (the image I don't think would be more than 200KB (in reality it's a max of 120KB). I want to publish the image bytes to an MQTT topic so the receiver (B4J, B4i, etc.) can receive the image and display it.
The advantage of this is that the broker should be able to queue up the chunks and when the EndPublish is receive notify the subscribers as normal - it's then business as usual on the receiving side.
The advantages of this are great - I can have a small esp8266 or esp32 device that's connected to an MQTT broker on the internet (like cloudmqtt or my own broker at a VPS) that pulls images (or anything else) from devices on a local network and publishes it. My receivers don't need direct access to the cameras (no firewalls to worry about) and everything is very secure.
Hopefully I've built the case for this - I don't thin kit would be to terribly difficult to add this.
- boolean beginPublish (topic, payloadLength, retained)
- size_t write (uint8_t)
- size_t write (payload, length)
- boolean endPublish ()
In fact the last scenario is exactly what I'm looking to accomplish. On my esp8266 sketch, I'm downloading a jpeg snapshot via HTTP from an IP Camera and temporarily storing it in SPIFFS (the image I don't think would be more than 200KB (in reality it's a max of 120KB). I want to publish the image bytes to an MQTT topic so the receiver (B4J, B4i, etc.) can receive the image and display it.
The advantage of this is that the broker should be able to queue up the chunks and when the EndPublish is receive notify the subscribers as normal - it's then business as usual on the receiving side.
The advantages of this are great - I can have a small esp8266 or esp32 device that's connected to an MQTT broker on the internet (like cloudmqtt or my own broker at a VPS) that pulls images (or anything else) from devices on a local network and publishes it. My receivers don't need direct access to the cameras (no firewalls to worry about) and everything is very secure.
Hopefully I've built the case for this - I don't thin kit would be to terribly difficult to add this.