Build a step-by-step guide for people who are testing the platform around how to connect your IoT device, add a raspberry or a simulator (python, node, etc)
Step-by-step guide about how to write a python simulator or onboard an IoT "testing" device, such a RaspBerry
Hi Carles, thanks for the feedback. What is the biggest gap you see currently in our platform. I believe there is solid developer documentation on how to connect to our platform using REST or MQTT interfaces (https://cumulocity.com/guides/device-sdk/introduction/).
In my view what is missing mostly, is an easy to use test/simulation device to test the platform features (less to learn how to integrate your own device). The idea here is to extend the IoT Sensor App to also support Device Management functionalities such as Log retrieval, Software/Firmware/Configuration management, Remote access, etc. which are very hard to evaluate currently. We decided for this approach over a purely simulated device or a raspberry Pi as everyone has a smartphone (as opposed to a Raspberry), setup is very easy and yet customers see that it is a real device communicating with the platform (as opposed to simulators).
Hi Carles, thanks for the feedback. What is the biggest gap you see currently in our platform. I believe there is solid developer documentation on how to connect to our platform using REST or MQTT interfaces (https://cumulocity.com/guides/device-sdk/introduction/).
Also there is documentation on how to integrate a Raspberry Pi device (https://cumulocity.com/guides/device-tutorials/raspberry-pi-4/). I admit there is some room for improvement with regards to feature support for the Raspberry Pi.
In my view what is missing mostly, is an easy to use test/simulation device to test the platform features (less to learn how to integrate your own device). The idea here is to extend the IoT Sensor App to also support Device Management functionalities such as Log retrieval, Software/Firmware/Configuration management, Remote access, etc. which are very hard to evaluate currently. We decided for this approach over a purely simulated device or a raspberry Pi as everyone has a smartphone (as opposed to a Raspberry), setup is very easy and yet customers see that it is a real device communicating with the platform (as opposed to simulators).
Is this priority in line with your experience?