I've developed a product using ESP32S2 modules. The client required IoT connectivity so I leveraged Rainmaker's public instance to create a demo (connectivity + smartphone application).
They were very satisfied, so I contacted Espressif support to get a quote on a private instance. Once I got back to my client they asked me what difference there was between my current free demo and the private instance. I realized that I couldn't tell, so I started digging a bit.
I know that older models like the ESP32 that cannot perform self claiming are limited to 5 claims per account when using the public instance, but I verified that this doesn't apply to newer models (like the ESP32S2).
I understand that the private instance comes with an informative dashboard about all deployed devices, but we don't really care about this function.
Is it acceptable to distribute a product that relies on the public instance of rainmaker? Are there any other reasons why I should go through the hassle to install a custom certificate on every device?
What are the downsides of the public instance?
-
- Posts: 309
- Joined: Wed Feb 20, 2019 7:02 am
Re: What are the downsides of the public instance?
First and foremost, the public RainMaker is not intended to be used for commercial purposes and is offered free of cost just to enable the community to build IoT products easily either for hobby or educational purposes, or to evaluate the platform for commercial products. But yes, functionally, it is almost same as the private deployments. Depending on your use case, some or all (or may be none?) of the below could be downsides of using the public RainMaker for commercial products.
1. Since public RainMaker has a concept of quota, you cannot have admin ownership of more than 5 nodes by default. For all the chips that support self claiming, even if there is no limit on the quota, the admin ownership lies with the person who provisions the device from the phone app. So, you won't have access to such nodes via the dashboard to monitor their status or give out OTA firmware upgrades to your end users. You can read more about the user roles here. Also note that, even with self claiming, an admin can have access to a maximum of 20 nodes via the dashboard.
2. You cannot have your own Alexa skills or GVA actions linked to the public RainMaker.
3. You can build your custom Android app, but for a custom iOS app to work reliably, additional configurations would be required in the backend, which isn't accessible.
4. The welcome/forgot password and other emails will have ESP RainMaker branding, which can't be changed.
5. Issues reported by your users could be hard to debug since there won't be access to any backend logs.
6. Collecting usage statistics would not be possible since you would not have (what we call as) super-admin view. (just as a note, we don't analyse any user activity on public RainMaker, apart from excessive messaging, since we follow a strict privacy policy. However, private deployments can optionally do more analysis).
These may or may not be downsides for many use cases, but let's also talk about upsides of private deployments.
1. Since the RainMaker backend would be deployed in your own AWS account, you can easily extend it or link to other services.
2. Your and your users' data stays with you and Espressif wont have any access to it.
3. You can rebrand the service completely (including the phone apps, which are open sourced) as your own offering.
4. Our support team will always be available to help diagnose issues if any. (we help diagnose issues even for public RainMaker, but there would be a limitation because we can't and won't peek much into the data because of the privacy guidelines)
Meanwhile, to simplify the complexity of flashing unique certificates on the devices, we also have a module pre-provisioning service. Any other concerns you may have regarding deployment or manufacturing can also be sorted out via our sales and support channels.
1. Since public RainMaker has a concept of quota, you cannot have admin ownership of more than 5 nodes by default. For all the chips that support self claiming, even if there is no limit on the quota, the admin ownership lies with the person who provisions the device from the phone app. So, you won't have access to such nodes via the dashboard to monitor their status or give out OTA firmware upgrades to your end users. You can read more about the user roles here. Also note that, even with self claiming, an admin can have access to a maximum of 20 nodes via the dashboard.
2. You cannot have your own Alexa skills or GVA actions linked to the public RainMaker.
3. You can build your custom Android app, but for a custom iOS app to work reliably, additional configurations would be required in the backend, which isn't accessible.
4. The welcome/forgot password and other emails will have ESP RainMaker branding, which can't be changed.
5. Issues reported by your users could be hard to debug since there won't be access to any backend logs.
6. Collecting usage statistics would not be possible since you would not have (what we call as) super-admin view. (just as a note, we don't analyse any user activity on public RainMaker, apart from excessive messaging, since we follow a strict privacy policy. However, private deployments can optionally do more analysis).
These may or may not be downsides for many use cases, but let's also talk about upsides of private deployments.
1. Since the RainMaker backend would be deployed in your own AWS account, you can easily extend it or link to other services.
2. Your and your users' data stays with you and Espressif wont have any access to it.
3. You can rebrand the service completely (including the phone apps, which are open sourced) as your own offering.
4. Our support team will always be available to help diagnose issues if any. (we help diagnose issues even for public RainMaker, but there would be a limitation because we can't and won't peek much into the data because of the privacy guidelines)
Meanwhile, to simplify the complexity of flashing unique certificates on the devices, we also have a module pre-provisioning service. Any other concerns you may have regarding deployment or manufacturing can also be sorted out via our sales and support channels.
Re: What are the downsides of the public instance?
Thank you,
This was more or less what I expected. Could you elaborate more on point 3? What kind of backend modifications are required for an Ios application?
This was more or less what I expected. Could you elaborate more on point 3? What kind of backend modifications are required for an Ios application?
-
- Posts: 309
- Joined: Wed Feb 20, 2019 7:02 am
Re: What are the downsides of the public instance?
1. 3P login requires url scheme to be configured in the backend. These url scheme allows user to redirect to only registered apps after successful login.
2. Push notifications require certificates to be configured in backend. These certificates are associated with app id and its enabled for public RainMaker app only.
2. Push notifications require certificates to be configured in backend. These certificates are associated with app id and its enabled for public RainMaker app only.
Who is online
Users browsing this forum: No registered users and 72 guests