Juju is described as "An open source application modelling tool. Deploy, configure, scale and operate your software on public and private clouds". I was particularly interested in the "Deploy" capability and that it works over a number of different Cloud Hosting providers. My understanding of Juju so far is that it allows you to define groups of applications to be deployed to dynamically expandable (or contractable) groups of Cloud Hosted Servers within containers. It's own controlling application (the "Controller") is also deployed in the same manner.

My first attempt to start playing was to try and getting Juju running on my MacBook because it looked like that was possible. You can install Juju itself (brew install juju) and you can connect to a remote Juju Controller (juju register) but trying to use the localhost as a Juju Controller proved difficult. Trying to create a localhost (juju bootstrap localhost) resulted in an error saying that lxd (the container system) was not installed, which it wasn't. Trying to get lxd installed on OSX turned into a bit of a deep Rabbit Hole experience. So I tried bootstraping (juju bootstrap aws) an Amazon EC2 instance as the controller. This was remarkably simple after setting setting up API Authentication on the Amazon EC2 console and then adding the credentials to Juju on OSX (juju add-credential aws).

Not wanting to keep an Amazon EC2 instance running while I experimented, I decided to create a VMWare Virtual Machine on OSX to run Ubuntu 16.04 to host the Juju Controller.

Install from ISO of Ubuntu Server 16.04
logon 
sudo -i
apt update
apt upgrade
apt install openssh-server
apt install lxd
apt install juju
dpkg-reconfigure -p medium lxd
(take all the defaults but No for IPv6 subnet)
juju bootstrap
(lxd on localhost)
juju gui
(gives the internal lxd container IP, port, URL, login username and password user the IP and port in the following)
iptables -t nat -A PREROUTING -p tcp -i ens33 --dport 17070 -j DNAT --to-destination 10.112.34.247:17070
(Needed to port forward to the lxd container, ens33 is the interface name from ifconfig)
browse to https://ip_of_vm:port/url-path

End of Part 1

The Electric Imp range of IoT devices offer a simple means to interface with a number of different physical data collection devices and connect back to a central controlling Server Platform via built-in WiFi. Code can be written and deployed from the central Server Platform that controls how the collected data is made available. In the following example I have used the built-in light level sensor data and exposed it via a simple web interface on the Server Platform. This data is collected and stored by a Zabbix Server and presented via a Grafana Dashboard.

The Electric Imp itself is packaged in an SD Card like enclosure which can be plugged into a number of different SD Card type sockets to give connectivity to power and physical interfaces. The Electric Imp has a light level sensor inside the SD Card type package that is used to read configuration instructions from a Smart Phone App (BlinkUp) to setup the WiFi parameters and can be used as a Light Sensor at run-time. Once configured and connected to a WiFi Network with Internet connectivity, the Electric Imp connects to the central Imp Cloud from which it will download any updates and Device code created for the device. The Imp Cloud will also have Agent code that runs on the Imp Cloud and controls communication between the Imp Cloud and the device.

The Imp Device code used simply registers a function to be called when and Agent message of type "queryLight" arrives. When the function is called by the arrival of the message it reads the hardware lightlevel and sends that back to the Agent.

The Imp Agent code used is a little more complicated but all it does is to get triggered when a http get request arrives (the URL to use for the specific device is shown in the Development environment on Imp Cloud), sends a message to the device and passes the reply back as the http response. There is also code to handle timeouts communicating with the device. If there is any error communicating, a zero value is returned on the http response.

At the Zabbix Server, the local Zabbix Agent is used to send the https request to the Imp Cloud on the specific URL for the device and extract the Light Level data by using a "web.page.regexp" item (xxxxxxxxxxx replaced with the specific value from the Development Environment);

web.page.regexp[agent.electricimp.com,xxxxxxxxxx/?queryLight,80,"([0-9]+)$"]

The data is then held on the Zabbix Server and used by a Grafana Dashboard to show a graph of the level and a status panel which shows red if there is a problem communicating with the device.

Part two here.

The Electric Imp range of IoT devices offer a simple means to interface with a number of different physical data collection devices and connect back to a central controlling Server Platform via built-in WiFi. Code can be written and deployed from the central Server Platform that controls how the collected data is made available.

My original article on the Imp was based on a simple implementation that just used the internal light sensor in an Electric Imp passing back data via Cloud Servers to Zabbix and visualising on a Grafana Dashboard. Using the same infrastructure of the Imp, the central Cloud Servers, Zabbix and Grafana, I extended the data collection capabilities by adding a temperature sensor and GPS receiver.

Interestingly, when you put all this together there are no external electronic components as it's all constructed from the Imp itself and the sensors which are just wired together. In the above picture this is done using a "Breadboard" with fly leads but this could easily be constructed in a case with battery power.

The Grafana Dashboard was also extended to show the temperature and GPS data. The position from the GPS receiver is also showed on a map.