Have seen various projects. The Blynk provisioning in the Plant demo too.
Consider this scenario:
We roll out an app which has dynamic provisioning through blynk.inject or WifiManager.
The customer does connect to the device and configures it.
He then uses the app where the UI is defined apriori.
If he adds another device, a new app needs to be rolled out.
This is not scalable. Can we add a UI for a device remotely from the device once it is added? If so, how do we do this. We could do this from the server too but that is not open for tinker with when we use the public server.
I understand from a developer or DIY viewpoint, what you are saying is correct. Take an end user. He wants to activate a device and the UI must be available.
The customer must not be creating the interface. How do we then get the interface for the new device added?
The Blynk app creation is easy but a developer would use it to define the interface, not the customer. If we hand over an app (packaged) to the customer and ask him to install a choice of 3 devices depending on how many endpoints and what he wants to control, how would the interface be defined by the user? He would not the pins and other stuff that we talk of.
We have 5 apps all contained within a single app on Google Play and iTunes. End users simply scan a different QR code image from within the app to access any of the 5 sub apps.
I understand this. Maybe I failed in conveying the need properly. Let me try by expanding on the use case.
I’ve a 4 switch relay module with its associated 4 button interface.
I give the module and app to a customer with the 4 button interface. The customer provisions the device using the workflow.
Later, the customer wants to add another 4 switch relay device and buys one more. He will want to see all the buttons for the second device too along with the first as both run in his home. He will want to register the device in the same account as the first.
This would apply to other devices or automation endpoints one would like to sell. Pert and eWelink are good examples of products that cater to this scenario. They sell the endpoint devices, the app and have a cloud service tied in for life.
Should we have multiple 4 switch apps defined beforehand which are deactivated and activated on adding a device? It would be wonderful if the button on the app can be defined by the device in some form. Then as the device gets added, its interface will come up automagically!!
Thanks. I have edited your earlier post and taken the translation as “beforehand” for apriori (it could simply be prior). Edit: how dumb am I, turns out apriori is an English word. Think beforehand fits reasonably well though.
Latin was a compulsory subject for me at school. At the time I thought why can’t I be doing something worthwhile like hacking the “ZX”. How wrong I was.
Yes, perfect replacement and easier to understand Latin words that are used in English text is something I use often.
sorry @Costas. No one here is dumb. We come from different backgrounds and experiences, thats all.
It is Latin and a priori means “what comes first.”.