|Product Performed to Expectations:||8|
|Specifications were sufficient to design with:||8|
|Demo Software was of good quality:||9|
|Product was easy to use:||8|
|Support materials were available:||10|
|The price to performance ratio was good:||9|
|TotalScore:||52 / 60|
The testing procedure will consist in implementing on the BB-40 device the part of data collection, processing and uploading into a cloud platform for a system of solar panels part of a photovoltaic park near our university.
This original collection process was implemented using a PC with CentOS that was collecting data from the solar panels inverter and charge controllers. The problem I faced was that due to power cuts in the building hosting the PC, large amount of data was lost making data analysis difficult if not impossible. As a solution I moved the data collecting application on a RPi whose energy consumption was much lower and hoped to be able to power from the mains with a backup from a USB power bank. The problem was not easy to solve because normal power banks are not designed to be charged and supply the load at the same time. I bought a special power bank that was supposed to be used in CCTV application but, though specification was indicating a high current output, it was not able to power the RPi in order to finish its booting process. The BB-40 seems to have Redundant DC Dual Power Inputs and also an integrated UPS based on supercapacitors.
The testing procedure will consist in porting the collecting application from RPi to BB-40. The freed RPi will be transformed into a sensor node that will also communicate with the BB-40 by being connected to the same network using the Ethernet connection. The sensor node that will be mounted on a solar panel with dual-axis tracking system will include a light sensors for sun tracking, 3-axis accelerometer for determining solar panel position, temperature and humidity sensors for measuring environment temperature and humidity. Measured weather data will be compared with data collected from local weather station that publish freely their data on the internet. In this respect an application will be developed in node-red running on BB-40 device.
In order to display the collected data in real-time, I will try to use a dashboard. There are different platforms that provide data uploading and displaying in a dashboard, the solution I want to try is using the Freeboard.io dashboard that can be installed on the local storage drive (in the case of BB-40 it should be the eMMC Flash).
The box from BrainBoxes contents the following:
Using the Quick start guide is a good way to get started. We can find there the information to make it work and start the basic functionality of the controller.
In order to do that, ones needs a CR1220 battery for the real time clock and a power supply to power the controller.
The battery must be placed inside the controller so we have to open the controller, which give us the possibility to see what's inside this yellow case.
First step before doing some changes in the BB-400 system is to make a backup of the system. During the road test, additional packages may be installed and it is better to have a back-up of the system if something goes wrong. Two FAQ articles describe fully the back-up and the restoring procedures. The only problem is that form making the back-up one has to open the case of the device in order to change a jumper selecting the device modes (in this case it should be set to FLASH mode), and also to remove a part of the case to access the usb connector that will be used to read/write the flash memory storing the device system.
BB-400 has a dual redundant power supply which means we can power the device from two different power supplies that can provide a voltage in the range 5-30V with a minimum requirement of 4W and a maximum of 15W (rated current minimum 0.625 @ 24V and minimum 3A @ 5V). As the data sheet was not very clear, I asked supporting team from Braiboxes.com some additional information regarding this feature. What I was interested in was if it is possible to power BB-400 from two different power supplies and even more, if the two power supplies can have different output rated voltage. The answer was yes, with the above conditions regarding the provided power.
I decided to test different powering configuration as I have available the following power supplies:
- the main one, which was used for most part of the road test, is a DIN mounted power supply from Siemens used in powering PLC based systems which provides 24V @ 2.5A rated current, covering thus the maximum power demand of the device.
- the second is a Mean Well power supply also DIN mounted and used for powering PLC systems. The power supply provides 24V @ 1A rated current and has overload and over voltage protection.
- the third one is a mini UPS model UPS502A used for CCT video systems that provides a voltage supply of 5V @ 2A rated current. It has a rechargeable battery with capacity of 14.8 Wh.
The video bellow shows the following tests:
- test starts with BB-400 connected to two power supplies, the Siemens one and the mini-UPS, both switched off.
- the mini-UPS (5V) is switched on powering the BB-400. As can be seen the power supply provides the necessary power to charge the supercapacitor, boot BB-400 and also provides enough power to sustain communication through the WiFi connection. BB-400 web interface is accessed from the an RPi with touchscreen.
- the mini-UPS is switched to UPS mode as the power adaptor of the mini-UPS is pulled-out from the mains. Current supplied by mini-UPS is measured with a DMM.
- Siemens power supply (24V) is switched on which cuts supply from the mini-UPS (current goes to 0 A).
The video bellow shows the following test:
- test starts with with BB-400 connected to two power supplies, the Siemens one and the Mean Well one, both switched off. Both power supply provide 24V output voltage, but the output voltage can be adjust on each power supply using a potentiometer.
- we switch on the Mean Well power supply and measure its output voltage using a DMM. Supercapacitor is first charged and then BB-400 starts booting. The second DMM is used to measure the current provided by Mean Well power supply.
-we switch on the Siemens power supply and measure its output voltage. The output voltage is lower than of Mean Well power supply, therefore BB-400 remains powered by Mean Well power supply.
- we adjust Mean Well power supply lowering its output voltage. When the output voltage goes bellow that of Siemens power supply, the supply from Mean Well power supply is cut, BB-400 is powered by Siemens power supply.
One way to connect to BB-400 is using a terminal. My preferred tool is putty. The BB-400 being connected to my local wireless router, it receives an IP from the DHCP service. In order to find which is the address I had to enter my router administration software where I can get the DHCP client list. The name in the list is Unknown, I will have to see where it can be changed to something relevant.
With this occasion I make an address reservation so it can receive the same IP each time it connects to the network.
What I found is that in /home directory there are two folders, bb and pi. Asking the support team from Brainboxes, I learned that "the /pi directory is a symlink of the /bb directory which we left in place in case anything should reference the /pi directory".
The web admin interface for BB-400 can be access using a web browser. If we know the IP of the BB-400 we can access the web interface through port 9090. After we provide the login and password we can access the interface as we can see in the figure bellow.
The interface allows user to access different functionalities and device status organized in several tabs: Status, IOs, WiFi, BT, Serial, Apps and Help.
The IO tab shows the status of IOs and allows user to change functionalities of IOs (input or output) and attributes of IOs counters. The IO interface allows user to change IOs status by clicking on visual elements associated to IOs. If we set one IO as input, its graphical symbol is grayed and can no more be changed through the interface.
The IO tab is useful as we can see the status of the IO remotely. This can be of great help when debugging an application that involves the IO of the device.
I used the WiFi tab in order to configure the BB-400 to connect to the newtork using the WiFi connection. In this way I can spare a wired connection for another RPi device that has no WiFi connection.
The BB-400 runs a REST server that listens at port 9000. Sending REST commands we can read the status of the IO lines and also can set the inputs of BB-400.
In order to communicate with the BB-400 using the REST server we can use the cURL tool that can be run either on the computer running Linux or Windows. In this road test I will use cURL running from the PC to read the BB-400 IO lines and also running from one of the other RPi nodes. One of the FAQs related to BB-400 (http://www.brainboxes.com/faq/items/how-to-communicate-with-the-rest-api-on-the-bb-400-using-curl ) details how to read BB-400 IOs and how to set output states of input lines.
The following screenshots show using curl running on PC to read inputs, outputs and set output states.
The effect of the command setting outputs states is visualized on the BB-400 web interface
The following screenshots show using curl running on one RPi connected to the same network as BB-400 in order to read inputs, outputs and set output states.
The following screenshot shows setting active output state for line 5.
One use case for sending REST commands to BB-400 is the following. If BB-400 is the edge controller for several RPi nodes (in my roadtest I have used 3 devices), each node can signal that it is active by sending periodically a curl command, setting on one of the BB-400 IO line. The BB-400 can clear the lines with the same period, so if one line is not set anymore, it means the device is not active or the path to the curl command is not reached anymore that can be a sign of wrong operation.
Brainboxes provides a tutorial on how BB-400 can communicate with IBM Cloud (http://www.brainboxes.com/faq/items/how-do-i-connect-my-bb-400-to-ibm-cloud). Unfortunately, after several attempts, I could not get the BB-400 communicate with the IBM cloud. In my first attempt I had problems in creating the node-red app in IBM cloud. After several messages exchanged with the support team I somehow managed to create the node-red app. Then I was blocked sending BB-400 status to the IBM node-red instance. I have decided to continue with other tests and come back later. I made second attempt, trying to follow more carefully the steps given in the tutorial. Surprise, I could not connect to the IBM Watson IoT Platform getting a invalid session message. I contacted the support team and still waiting for a solution to go further. I will post this roadtest and if lucky, I will update it when I will have more luck (or IBM Cloud knowledge).
Brainboxes provides a tutorial on how to connect BB-400 to the Amazon Web Services (http://www.brainboxes.com/faq/items/how-do-i-connect-my-bb-400-to-amazon-web-services). The connection is based also on MQTT protocol. After two attempts, I succeeded to connect the BB-400 and test communication of IO status from BB-400 to the AWS Platform. The figure bellow shows the successful test. Status of IO changed when changed using the web interface was received by the AWS plaftorm.
I didn't succeed to communicate from AWS to BB-400 and I have no idea for the moment why. Figure bellow show that the "Message from AWS" outputs nothing when publishing something from AWS platform (only RawAWS debug node is enabled in the debug window).
In the first attempt I had problem of connecting BB-400 to AWS and I think it was because of the security certificates. The node-red node implementing the connection to the MQTT broker was trying to connect but never completing the connection.
Next step is to store and use data coming from BB-400 using AWS platform (store in a database, display using some graphs, doing some analytics etc). I am new to this platform so I have to read the docs and watch some tutorials in order to see how can this be done.
One way to communicate between two IoT devices is by using MQTT protocol. The protocol is based on a publish/subscriber model and is extremely lightweight. The communication needs a message broker to which different clients can subscribe in order to receive messages of interests. One of the common used MQTT brocker is mosquitto. In order for the two devices to communicate, the broker must be installed on one of the device, normally the one with more processor and memory resources.
In my roadtest, I have installed mosquitto broker on the BB-400 and tested communication with an RPi. The process of installing and testing mosquitto on BB-400 is similar to installing on a RPi and is well documented at different web links. I used the tutorial found here.
Afteer installation, I verify that mosquitto is installed on the BB-400.
In my test I will subscribe BB-400 to receive messages on topic testBB400 and the RPi device will be the one sending the messages. Bellow are the screenshots of terminal windows of the two devices showing the messages sent by RPi and received by BB-400.
dweet.io is a simple messaging system based on a publisher/subscriber model that can be used to connect devices to the Internet. Devices (things) can publish data through messages denoted as dweets while other devices (things) can get data by subscribing to things and reading their dweets. The messaging system is free in its basic plan and has a simple HAPI (Humanized API). Developed by the same team is the Freeboard.io which provides a real time interactive dashboard where data from things can be presented in a easy to use interface. When I started to use Freeboard.io, some years ago, the platform was free to use for limited number of registered data sources. Now, you can used for free only a limited time after which you need to decide if you want to used it and choose a paid plan. The good thing is that the platform is open source available on Github and one can install it for free on a server and use it as desired. What's available on Github is the client client part of the platform, not including the server-side code needed for user management or for saving data to a database.
In this road test I chose to install Freeboard platform on an RPi and established a communication between the RPi and BB-400. The communication is done using dweet.io.
First, Freeboard.io is installed on the RPi (installation instructions are given on github (https://github.com/Freeboard/freeboard ) and it can be access through a webserver. So I installed a web server using How to set up a web server on raspberry pi and other posts related to how mysql can be installed on RPi and how mariadb has replaced mysql on the latest LAMP set.
When all is set, the platform can be access using a browser and the dashboard can be configured. One must configure the data sources through which data are coming from the things, and the graphical elements of the dashboard used to visualize data (text, gauges, sparklines etc). In this road test I configured the data source to be a subscription to the dweet.io for data from a thing named my_bb400. The dweets are created by BB-400 in a node-read flow and contains the status of the inputs, outputs and the value of counts.
The flow used to read status of BB-400 IO lines, create the message (dweet) and to send it as a http request is given bellow.
In the next picture we can see the configuration of the http request node as a GET request to dweet.io messaging system to write a dweet for the my_BB400 thing.
Bellow we can see the result on changing the status of inputs of BB-400 from its web interface and the freeboard dashboard running on RPi that mirrors the status of the BB-400 inputs visualized using text elements and the number of counts that are visualized using gauges.
Initially the idea was to install Freeboard on BB-400. Because if somethings goes wrong it is more difficult to restore the BB-400 from a backup than for the RPi, I decided to install it on the RPi. As BB-400 is based on RPi, as the installation on RPi was successful, I see no problem to install it on the BB-400.
As in the github repository for Freeboard there is a Dockerfile file, I guess the platform can be run in a Docker container. I have tried to create a container for Freeboard but I didn't succeeded as my knowledge of containers and their creation is just at the beginning.
Using an RPi, I have created a sensor node which consists of an RPi, a PmodTMP3 temperature sensor from Digilent, a light sensor TCN34725 from AMS and an MPU9250 Inertial Measuring Unit (IMU) from Invensense. The three sensors have in common the fact that they can be read using I2C protocol and can be connected to the same I2C bus. For two of them we can find tutorials on how we can connect them to an RPi and how we can read them using python scripts (https://learn.adafruit.com/adafruit-color-sensors/python-circuitpython and https://maker.pro/raspberry-pi/tutorial/how-to-interface-an-imu-sensor-with-a-raspberry-pi). For the PmodTMP3 we have created a python script using the SMBus python library (https://www.abelectronics.co.uk/kb/article/1094/i2c-part-4---programming-i-c-with-python). Different other sources are available on the Internet on how to connect and read I2C sensors using an RPi.
Following figures show the BB-400 and RPi and sensors connected using a breadboard. The RPi used for this roadtest has also a touch screen and connects to the network using the WiFi connection. The BB-400 is powered by a 24V power source from Siemens I am using for my PLC roadtests.
In figure bellow is given the flow run on the RPi sensor node which reads the three sensors and sends data to MQTT broker run on the BB-400.
In figure bellow is given the flow run on the BB-400 to receive data from the RPi sensor node using MQTT protocol.
The dashboard used to display data in different format (gauge, graph) is presented bellow.
Part of the roadtest is gathering data from different sources, store them and display them in a dashboard. One source of the data is the related to photovoltaic panel and is coming from the PV panel inverter and controller. The PV panels I am trying to monitor are connected to OutBack Power inverter and charge controllers that can output in a webpage format different operation parameter of the system. These parameters are gather from these webpages using phantomjs software which is in fact a scriptable headless browser. More than 35 parameters are read from these pages such as currents generated by PV panels, voltages at input and output of the inverter, voltage of battery used to store generated energy, accumulated values for generated power, operation modes etc. Figure bellow shows the cvs files created with phantomjs and data that is also publish to the MQTT broker.
Data are saved in files in CVS format, one for each inverter and charge controller and also published to the MQTT broker running on BB-400. A node-red flow was created on BB-400 to subscribe to this kind of data from one inverter and charge controller in order to be displayed in the dashboard alongside with data from the RPi sensor node.
Figures bellow show the node-red flow for subscribing to this data, extracting values for some of the parameters in order to be displayed in chart or text format and, the dashboard integrating data from PV panel inverter and charge controller (first column) and RPi node sensors for temperature, light, acceleration, magnetic field and gyroscope. From PV panel data were selected current values for channel a and b, inverter input and output voltages and, battery temperature and inverter operation mode. If needed, several dashboard panels can be created to display all PV panel parameters. In this test, a dark theme was selected for the dashboard.
The ui_chart node in node-red should allow the display of several data series on the same graph. I have tried this following a post explaining how to do this but it didn't work. Therefore I used a separate node for each data series thought some should be displayed on the same graph (ex. currents on the same graph, voltage on another graph).
BB-400 is a device with a lot of features characteristic to an edge controller. Testing some of them took more time than expecting even though I have some experience with Raspberry Pi used in different type of applications and using different software platforms. Brainboxes offers in the FAQ section of their web site a lot of documentation and tutorial on how to set-up, back-up or configure the BB-400 and how it can be accessed and how it can communicate using different communication channels and protocols. Only trying to replicate these tutorials would take more than the time allocated for the roadtest but, in order to better understand the device and to use it at it full power is recommended to do them all.
I succeeded to fulfil by now only part of what I planned but, in order not to delay to much the posting of the roadtest, I will finish the review and publish it and I will try to add more information as I will go through the remaining tests.