Make use of MQTT Persistent Sessions

[bam80]

The app communicates via the MQTT push server only. The MQTT push server monitors the MQTT messages for the specified accounts and sends push messages via Google (Android) and Apple (iOS) to corresponding mobile devices connected to this account. In addition, the server keeps the last 100 MQTT push messages for each account.

Do you think we could utilize MQTT Persistent Sessions for that?
100 MQTT push messages restriction (and the restriction of 256 bytes per message) is quite a shortcoming. As well as relying on 3rd party server user can't control.

So I would propose communicate with the MQTT push server only when it strictly necessary (for it's purpose - push notifications themselves). In all the other cases, use MQTT broker normally.

[helmut64]

First of all 100 MQTT queued/persistent push messages up to 255 bytes are more than sufficient for most use cases. Normally the queued 100 messages are not needed because all push messages (e.g. silent once without a notify popup) are sent to the app, this means only a copy of the last 100 messages are saved on the server.

The concept is that our Push Server listens for the app subscribed topics for messages and forwards this messages to the app in the background. The app does not talk to the MQTT server at all. Only the server listens permanent for new messages and forwards this to the mobile app. Only in case where mobile phone is turned off or unavailable for a longer period the last 100 messages are cashed and supplied when the phone is connected to the Internet again.

I believe you concept is wrong when you need so many and very large messages. Again, use the short messages only, for large stuff lets the Dash pull the data from somewhere else (not our Push Server) via JavaScript.

[bam80]

First of all 100 MQTT queued/persistent push messages up to 255 bytes are more than sufficient for most use cases.

I wish that be true but apparently, it's not. Did you read our conversation in the original issue?

there are sensors, sending a lot of keys(for example the ones with accelerometers or the pollution ones), 256 is quite low for the json size. I would encourage to contact the app developer to increase this limit.

theengs/gateway#193 (comment)

I'm sorry but 100 saved messages apparently are not sufficient either:
they seem accumulated in the app indeed (even more than 100) but that persists as long as you keep your dash open only - as soon as you leave it and open again, all your data more than the 100 messages long is lost. Can be seen on the graphs very clearly.

The concept is that our Push Server listens for the app subscribed topics for messages and forwards this messages to the app in the background.

Thanks for the clarification. I can argue with such design though:
One probably would not be interested to receive that "hidden" pushes (even if they are completely silent) every 5 minutes or so while the app is closed - as they influence the battery anyway.
Only the notifications the user explicitly subscribed to should be pushed to him. All the other data can be pulled from the server when the app is opened.
Does it make sense?

Only in case where mobile phone is turned off or unavailable for a longer period the last 100 messages are cashed and supplied when the phone is connected to the Internet again.

That seems quite a common case to me. Why would I lose all the data more than 100 messages long then?

[helmut64]

Dear Andrey Butirsky, we have a couple of thousand accounts, and this is how it works and how it is designed, and all users are fine with this. We don't destroy our design for your requests.
You need to look for another solution or develop your own Push Server and App development.
Regards Helmut