Currently there are no restrictions on the size of sent messages other than the hard limit specified in the protocol (may change in the future).
However, while technically not an issue, we generally discourage sending binary blobs over the public broker in order to keep it fast, snappy and dedicate the bandwidth to data that has more value to edge-apps and other integrations.
Depending a little bit on how many clients potentially needs to receive the image and the frequency of it, it might be a better idea to send it via http to some server for further processing instead.
For example, if there is AI involved, have a separate server process the image and break it into more manageable data that could be sent over the broker in a format that could be easily used by multiple interested parties like edge-apps.
In case this is for display; we don't really save binary blobs (nor do we want to, as this would grow the tsdb considerably faster for data that probably has nearly 0 historical value) and if the frequency is, say every minute, a worst case scenario you'd have to wait for a whole minute before a picture would arrive for the first time.
Things i usually take into consideration when deciding to publish data on broker or process it further is:
- How many could this data be useful to (could edge-apps take advantage of this data in a simple way)?
- Frequency - while one can push quite a lot, usually, 1000 values / s might not be required for the intended application and be overkill and perhaps a mean over 1000 values might suffice (1 value / s).
- Historical value - eg. temperatures could potentially be interesting to look at historically, and maybe do some calculations on (mean, min, max. etc). temperatures and other numerical values are also easy and small to store compared to, say images.
Images may have a historical value if you are doing some security camera implementation, but perhaps there is a better and more optimal way of storing the video somewhere else and maybe annotate the video with data from the platform.