@Oleksii-QA i think you’ve misunderstood @AstroHeat’s requirement.
My understanding is this…
A remote customer has a hardware device flashed with a sketch which uses template A - the fully-featured product with all the bells and whistles.
If that customer then stops paying his premium subscription to @AstroHeat the device firmware needs to be swapped over to a different template - Template B - which gives the minimum amount of functionality, and the customer needs to then see a cut-down mobile and web dashboard.
This firmware update and change of template needs to be done remotely, via Blynk.Air
However, Blynk.Air performs a check and will prevent new firmware being uploaded if the template ID of the new shipment doesn’t match the template ID of the existing firmware.
In a similar scenario, a customer may have the basic functionality (Template B) , and wishes to upgrade to the enhanced functionality (Template A). Once again, a change of template ID is required in the Blynk.Air update.
Another scenario which has come-up is the need to ship a re-designed Beta test firmware to a device, but to allow all other devices using the same template to remain on the old firmware release until testing is complete. As the new firmware will have re-designed dashboards, a new template is needed to achieve this Beta testing setup. However, this updated firmware can’t be shipped via Blynk.Air because the shipment checks to ensure that the existing and new template IDs are the same.
I guess the simple (from our perspective) solution is to allow this template ID check to be overridden by the administrator when performing the Blynk.Air update (maybe a Plus/Pro feature only)?