Hi,
We are considering using revolution pi modules in our system, but we are using resin.io and the resinos operating system. I however miss support for your devices there and believe I need to make a custom version. The resinos is based on yocto and therefore a BSP for yocto would be a good start.
Do you already have plans for supporting resin.io? I believ it would be a valuable addition to your offering.
Best regards
Pär
Support for resin.io
Hi Pär,
as there are dozens of IoT solutions for Linux (we've just come back from the IoT world congress in barcelona where we had a booth) our strategy is to be neutral and leave the task of implementing these solutions to our platform to the companies and organizations who offer the solutions. Several solutions have already been implemented including AWS, Azure, and ubidots. I'm not aware that resin.io has plans to do so.
besides these solutions we also offer our own cloud solution based on the Australien Ardexa cloud.
Is there any particular reason for you to aim for resin.io (they seem to not be the cheapest)?
as there are dozens of IoT solutions for Linux (we've just come back from the IoT world congress in barcelona where we had a booth) our strategy is to be neutral and leave the task of implementing these solutions to our platform to the companies and organizations who offer the solutions. Several solutions have already been implemented including AWS, Azure, and ubidots. I'm not aware that resin.io has plans to do so.
besides these solutions we also offer our own cloud solution based on the Australien Ardexa cloud.
Is there any particular reason for you to aim for resin.io (they seem to not be the cheapest)?
Unser RevPi Motto: Don't just claim it - make it!
This timing is pretty funny, I was just coming on here to see if anybody had asked about Resin support yet 
I would absolutely love to use the Revolution Pi on Resin.io. They work on the RPi3 itself and it's reported that they work fine using the RPi3 compute module too: https://forums.resin.io/t/official-laun ... dule-3/503
As for the reasons I would use them, it's a great, reliable platform that doesn't require me to run any infrastructure myself. Though ResinOS is OSS and I could run the support infrastructure for it if I choose to do so. Resin gives me a reliable way to update devices, containerized applications, SSH proxying into my devices, logs, and a solid security model for my use case.
Given that ResinOS functions with the RPi3 compute module, it might also be pretty straightforward to make it work on a RevolutionPi Core3: https://docs.resin.io/hardware/meta-res ... rd-support https://github.com/resin-os/meta-raspberrypi
We would be starting with a handful of Core3s but scaling up to several of them per month by early 2018.
I would absolutely love to use the Revolution Pi on Resin.io. They work on the RPi3 itself and it's reported that they work fine using the RPi3 compute module too: https://forums.resin.io/t/official-laun ... dule-3/503
As for the reasons I would use them, it's a great, reliable platform that doesn't require me to run any infrastructure myself. Though ResinOS is OSS and I could run the support infrastructure for it if I choose to do so. Resin gives me a reliable way to update devices, containerized applications, SSH proxying into my devices, logs, and a solid security model for my use case.
Given that ResinOS functions with the RPi3 compute module, it might also be pretty straightforward to make it work on a RevolutionPi Core3: https://docs.resin.io/hardware/meta-res ... rd-support https://github.com/resin-os/meta-raspberrypi
We would be starting with a handful of Core3s but scaling up to several of them per month by early 2018.
I also opened an issue for this on Resin's device support repo: https://github.com/resin-os/resin-os-de ... /issues/59
Think this is the rigth way to support your interest in resin.io.
Please understand that most of the time when people view at the physical computing abilities of a Raspi they are talking about things being connected to the pin header (GPIO, I2C, 1wire, UART, SPI etc.). But these interfaces are exactly what Revpi distinguishes from the original Raspi. Because all of these interfaces are not reliable in industrila automation we've chosen a different way to connect to industrial sensors and actors which is compatible to EN61131-2 and also includes all the industrial field busses like Profibus or profinat, Sercos, etc.
So if IIoT is all about getting such industrial sensors and actuators in the cloud then any Raspi based solution will fail to do so with the RevPi. With RevPi such data is stored in a cnetral RAM sector called "process image" just as in any PLC. Any IIoT solution would need a driver to exchange the data between that process image and the service / agent which exchanges this data with the cloud. This implementation work needs to be also done with a solution like resin.io. But even if anyone will do that integration work I fear that you might chose a system which will lead you in a complete seperated pathway cutting you off from the current RevPi World:
Please note that AWS has much more possibilities and is able to do everything resin.iio can do. AWS has alrea<dy done some of the integration work (greengras is running on our system). With this solution you would not need to exchange the complete RevPi World. You can use every existing solution for RevPi because the OS with its sophisticated Kernel patches to make RevPi more "real time" as well as the Kernel drivers for the backplane bus PiCtory does not need to be replaced by solutions which would cut yourself off from future compatibility to new IO modules and virtual modules (like our RevPi7 bridge software to exchange data with the Siemens world which will be launched at SPS/Drives Show in November).
Please understand that most of the time when people view at the physical computing abilities of a Raspi they are talking about things being connected to the pin header (GPIO, I2C, 1wire, UART, SPI etc.). But these interfaces are exactly what Revpi distinguishes from the original Raspi. Because all of these interfaces are not reliable in industrila automation we've chosen a different way to connect to industrial sensors and actors which is compatible to EN61131-2 and also includes all the industrial field busses like Profibus or profinat, Sercos, etc.
So if IIoT is all about getting such industrial sensors and actuators in the cloud then any Raspi based solution will fail to do so with the RevPi. With RevPi such data is stored in a cnetral RAM sector called "process image" just as in any PLC. Any IIoT solution would need a driver to exchange the data between that process image and the service / agent which exchanges this data with the cloud. This implementation work needs to be also done with a solution like resin.io. But even if anyone will do that integration work I fear that you might chose a system which will lead you in a complete seperated pathway cutting you off from the current RevPi World:
Please note that AWS has much more possibilities and is able to do everything resin.iio can do. AWS has alrea<dy done some of the integration work (greengras is running on our system). With this solution you would not need to exchange the complete RevPi World. You can use every existing solution for RevPi because the OS with its sophisticated Kernel patches to make RevPi more "real time" as well as the Kernel drivers for the backplane bus PiCtory does not need to be replaced by solutions which would cut yourself off from future compatibility to new IO modules and virtual modules (like our RevPi7 bridge software to exchange data with the Siemens world which will be launched at SPS/Drives Show in November).
Unser RevPi Motto: Don't just claim it - make it!
-
pardegerman
- Posts: 2
- Joined: 12 Oct 2017, 11:44
Sure thing. I guess that the modules that come with the core is an integral part of your offering and thus it will also have to be supported if any resin.io solution can be comparable to the other services you mentioned. Where can I find more information on the "native" revolution pi cloud solution?
As I understand it, the modules will require a patched kernel, drivers and a user space daemon to function. Is that correct, or are there more things that is needed?
As I understand it, the modules will require a patched kernel, drivers and a user space daemon to function. Is that correct, or are there more things that is needed?
Hi Pär,
this is correct. Anyone could go and programm his own driver for the backplane bus and the IO modules as we have published source code for both sides on GitHub. You would also not need to use the RT patch on the Kernel. But without this patch you need to accept a huge jitter in the IO cycle as USb and Ethernet processes could stop any IO cycle for more than 100 ms. This is why we have modified the kernel and applied the RT patch to it. The backplane bus driver "PiControl" should also be part of the kernel for the same reason. So we programmed it as a kernel driver.
With most of the cloud deamons / servers / agents / sewrvices (however you want to call them) they would be user space sw. Like our KUNBUS cloud: It uses a small agent running in the background. It has 3 methods to push data: using timer controlled bash commands to access data (e.g. PiTest command to get data from the process image), observing files adn send any appended data and last but not least using Linux sockets which it observes and send any data which is written to the sockets. All threee methods can be used in parallel and all these functions are normally configured on the web interface in the cloud. As soons as the device is connected the agent does synchonize the local configuration with the one it finds in the cloud (and vice versa). Any data which can't be sent due to an offline status is buffered and sent as soon as the device is reconnected. You can deicde to which cloud table the data will be written and also give it some additional semantic information along (units, symbolic names, etc.). On the cloud there are several possibilities to set up dashboards and to search and evaluate historical data. of course you can store the data in the cloud and export it to any browser PC.
So to get the data into the cloud you would not need to programm a single line but just would need to configure the agent by giving him several bash command lines to be executed cyclically. If you want to pre-filter or pre-calculate you could use a python script and write the results in a Linux socket. The agent does the rest for you if you configure it the right way.
The cloud surface on the web also alows to up- and download files to your devices and also to send bash to the command line. So there are also ways to remotely maintain your devices.
You could also use Teamviewer RevPi to get remote access to any websurface you've porgrammed on the device (being output by the device's webserver) without the need to publish your device openly to the internet (it only needs the ability to connect from LAN to WAN with http(s) ports).
With Azure and AWS you can realize a full remote SSH session to access your devices from all over the world. AWS has also many services related to remote Linux device maintainance.
Hope this has given at least an impression of what is already realized. If you have specific interest in one of the solutions please contact me on PM as we not yet have set up an out of the box Web-shop product which you could buy in our Revpi Shop. We would need to discuss your specific needs and data volume to calculate the costs for these solutions.
this is correct. Anyone could go and programm his own driver for the backplane bus and the IO modules as we have published source code for both sides on GitHub. You would also not need to use the RT patch on the Kernel. But without this patch you need to accept a huge jitter in the IO cycle as USb and Ethernet processes could stop any IO cycle for more than 100 ms. This is why we have modified the kernel and applied the RT patch to it. The backplane bus driver "PiControl" should also be part of the kernel for the same reason. So we programmed it as a kernel driver.
With most of the cloud deamons / servers / agents / sewrvices (however you want to call them) they would be user space sw. Like our KUNBUS cloud: It uses a small agent running in the background. It has 3 methods to push data: using timer controlled bash commands to access data (e.g. PiTest command to get data from the process image), observing files adn send any appended data and last but not least using Linux sockets which it observes and send any data which is written to the sockets. All threee methods can be used in parallel and all these functions are normally configured on the web interface in the cloud. As soons as the device is connected the agent does synchonize the local configuration with the one it finds in the cloud (and vice versa). Any data which can't be sent due to an offline status is buffered and sent as soon as the device is reconnected. You can deicde to which cloud table the data will be written and also give it some additional semantic information along (units, symbolic names, etc.). On the cloud there are several possibilities to set up dashboards and to search and evaluate historical data. of course you can store the data in the cloud and export it to any browser PC.
So to get the data into the cloud you would not need to programm a single line but just would need to configure the agent by giving him several bash command lines to be executed cyclically. If you want to pre-filter or pre-calculate you could use a python script and write the results in a Linux socket. The agent does the rest for you if you configure it the right way.
The cloud surface on the web also alows to up- and download files to your devices and also to send bash to the command line. So there are also ways to remotely maintain your devices.
You could also use Teamviewer RevPi to get remote access to any websurface you've porgrammed on the device (being output by the device's webserver) without the need to publish your device openly to the internet (it only needs the ability to connect from LAN to WAN with http(s) ports).
With Azure and AWS you can realize a full remote SSH session to access your devices from all over the world. AWS has also many services related to remote Linux device maintainance.
Hope this has given at least an impression of what is already realized. If you have specific interest in one of the solutions please contact me on PM as we not yet have set up an out of the box Web-shop product which you could buy in our Revpi Shop. We would need to discuss your specific needs and data volume to calculate the costs for these solutions.
Unser RevPi Motto: Don't just claim it - make it!
Hi @volker, for AWS Greengrass support - did you use imagebakery to modify the Greengrass Jessie download? Do you have any information for how to set this up?
Thanks
Thanks
HI,
the current Jessie Image should be fine for greengrass and you do not need to change anything in the kernel. Greengrass should install without trouble. I have not done this personally but I know that colleagues from AWS Luxembourg have done it on several of our devices as proof for customers that this would work fine.
the current Jessie Image should be fine for greengrass and you do not need to change anything in the kernel. Greengrass should install without trouble. I have not done this personally but I know that colleagues from AWS Luxembourg have done it on several of our devices as proof for customers that this would work fine.
Unser RevPi Motto: Don't just claim it - make it!
Thanks @volker, I've taken a look at Greengrass and I think it's important to point out that what AWS provides with their IOT stack is very, very different from what Resin.io provides. After reviewing AWS, here's why we are not going to use it:
1. AWS Greengrass is architected to execute AWS Lambda functions on devices. While Lambda is great, it requires software to be designed with this in mind. Most applications are still built using client/server topologies, which are easily ported to Docker containers, and thereby run seamlessly on top of Resin OS. So Greengrass really isn't a solution unless the software can be boiled down to simple Lambda functions. Yes, you can create custom jobs for Greengrass to run which could theoretically be anything, but then you'd be getting into a really complex custom solution.
2. AWS IOT Core is great for single-purpose devices. It provides a messaging and communication framework that you would otherwise have to build. For temperature sensors and other similar use-cases, it makes a lot of sense. However, in our case we are communicating with industrial robots and PLC's, and we've designed our own solution using websockets (vs MQTT), so their IOT solution isn't applicable.
Resin allows us to isolate our software into containers and easily provision them to a variety of device architectures and update them through a simple Github workflow, while providing a slick user interface where we can view logs, remotely shell into devices, and manage them individually or as a group. Their container-based approach is a far more sophisticated and flexible (and way easier to use) than what AWS provides.
For those reasons, we'd like to have a serious discussion with you about adding support for Resin OS. I've tried to use imagebakery to combine Resin with RevPi but wasn't able to get it working.
We've already begun shipping RevPi devices with Resin OS (replacing the RevPi OS) to large automotive manufacturers within the US and we would like to have the ability to use the RevPi I/O and Ethernet/IP modules, however they won't work until we can get your device drivers running with Resin.
We are working with the Resin development team already and can make introductions for you that will expedite the process. Please contact me so we can continue using your hardware, which we really like!
1. AWS Greengrass is architected to execute AWS Lambda functions on devices. While Lambda is great, it requires software to be designed with this in mind. Most applications are still built using client/server topologies, which are easily ported to Docker containers, and thereby run seamlessly on top of Resin OS. So Greengrass really isn't a solution unless the software can be boiled down to simple Lambda functions. Yes, you can create custom jobs for Greengrass to run which could theoretically be anything, but then you'd be getting into a really complex custom solution.
2. AWS IOT Core is great for single-purpose devices. It provides a messaging and communication framework that you would otherwise have to build. For temperature sensors and other similar use-cases, it makes a lot of sense. However, in our case we are communicating with industrial robots and PLC's, and we've designed our own solution using websockets (vs MQTT), so their IOT solution isn't applicable.
Resin allows us to isolate our software into containers and easily provision them to a variety of device architectures and update them through a simple Github workflow, while providing a slick user interface where we can view logs, remotely shell into devices, and manage them individually or as a group. Their container-based approach is a far more sophisticated and flexible (and way easier to use) than what AWS provides.
For those reasons, we'd like to have a serious discussion with you about adding support for Resin OS. I've tried to use imagebakery to combine Resin with RevPi but wasn't able to get it working.
We've already begun shipping RevPi devices with Resin OS (replacing the RevPi OS) to large automotive manufacturers within the US and we would like to have the ability to use the RevPi I/O and Ethernet/IP modules, however they won't work until we can get your device drivers running with Resin.
We are working with the Resin development team already and can make introductions for you that will expedite the process. Please contact me so we can continue using your hardware, which we really like!
