Tag Archives: services

Using RPi-Monitor with your own webserver (Nginx)

Leave a reply

As I recently moved this site to a RPI for hosting purposes, I though it would be a good idea to have a nice web page to monitor the current status of the box. Some googling later and I found the excellent RPi-Monitor.

By default it has it’s own webserver, and it is not recommended to use anything other then that, but running a second webserver seemed a little bit untidy to my thinking so I set it to run on Nginx instead.

The actual changes were quite simple, with one or two gotcha’s.

RPi-Monitor stores the webpage in /usr/share/rpimonitor/web by default. Rather then play with that I just created a symbolic link between the root of the webserver and that point:

ln -s /usr/share/rpimonitor/web /var/www/rpimonitor

and that is sorted.

Next up is the configuration change to the rpimonitor daemon – config file located in /etc/rpimonitor/daemon.conf. We need to set it into no-server mode and also change the user, as I’ve disabled the default ‘pi’ account on this box.

# daemon.noserver=1
# Define that rpimonitor shouldn't start web server (default:0)
# Note: A symbolic link from /var/lib/rpimonitor/stat to
# /usr/share/rpimonitor/stat may be required
daemon.noserver=1

# Define user used to run the server process (default:pi)
# Note: If user is not existing, process will run with uid=1000
daemon.user=rpi-monitor
#
# daemon.group=pi
# Define group used to run the server process (default:pi)
# Note: If group is not existing, process will run with gid=1000
daemon.group=rpi-monitor
#

Restart the service, and you should be able to access it from http://my-website.com/rpi-monitor

$ sudo service rpimonitor restart

RPI-Monitor StatusHowever there is a slight issue in that the datastore is inaccessible to the webserver, so statistics are unavailable with error “File stat/uptime.rrd is not a valid RRD archive”. To resolve this we need to go back to the daemon.conf file and move the datastore to somewhere under the root directory of the website

# daemon.datastore=/var/lib/rpimonitor
# Define the data storage directory (Default:/var/lib/rpimonitor)
daemon.datastore=/var/www/rpimonitor

Restart the service again and all is worky.

$ sudo service rpimonitor restart

RPI-Monitor StatisticsNote: you could also just move the webroot in the same way, rather then using the symbolic link.

Internet of Things – Potential Architectures & Drawbacks

Leave a reply

The Internet-of-Things or IoT (terrible name since everyone knows that IoT stands for Inter-operability Testing) seems to be quite the buzzword around lately – replacing the previous version which of course was Machine-to-Machine [M2M]. Nest and other home telemetry/automation tools seem to be quite the cliche-du-jour for the digirati.

Consider what Nest actually does – local (in house) temperature compared with external (nearest location/airport) temperature and a few interesting algorithms to handle temperature differentials, learn preferences, awareness of presence and away type scenarios. Of course  given that it seems to automatically download updates, I’m sure it’s logging and submitting lots of information ‘to improve the product’

Likewise, we have hubs finally coming onstream to try and manage all the possible combinations of hardware and software for home sensors and everything else (or so they promise).

Think home sensors/lightbulbs/whatever – currently we have a plethora of specs to choose from for household comms and telemetry: X10, Zigbee, Z-Wave, Lightwave RF. Telldus, etc. Currently each manufacturer has their own choice of spec, controller software, etc.

Fortunately the Open Source/Open Hardware groups are are already experimenting with options to handle this – a good example is the Home Automation Hub (HAH) project which sets out to turn an Orange Livebox router into a home automation server, with an extra bit of hardware that – like the TellStick – allows it to control a range of gadgetry, and even keep an eye on energy consumption too. Likewise the dovado routers I’ve raved about before have the beginnings of some interesting Home Automation features with integration with Telldus sticks and the use of GPS to determine sunrise and sunset times for the location.

Open Source Open Hardware Hub

Home Hub - Internet of ThingsKey features as I see them are:

  • Compact
  • Reliable
  • Minimum Downtime
  • Low power
  • Open

Publish & Subscribe

So, assuming that we can get all these sensors talking to our hub, and that data recording (and potentially taking local actions based on that – heating, lighting, etc.) what do we do with it.

The hobbiest answer is to put it up on a website for your own entertainment. The more interesting options are open to the hub provider, and I see a few possible approaches here:

  1. Act as a relationship broker: making partnerships with different consumers of the telemetry e.g. allow the hub to submit information of the users choice to projects of their interest e.g. SmartCities, utility providers, etc.
  2. Act as a centralised clearing house: store all users data, sell it in bulk (users are the product) and plan to be bought at some point by Google/IBM/whoever
  3. Act as a centralised broker – grouping your users according to, for example, energy usage patterns and negotiating (optional) bulk deals from utility providers. For example, contacting the Power company and saying here is aggregate usage data for 30k ‘night owls’ – can we get a special deal, since they are offsetting the base load cost, but not adding to peak loads.

 

Providers/Website subscribing to the date

Contrail Discovery Service

Leave a reply

Configuration nodes also provide a discovery service that the clients can use to locate the service providers (i.e. other nodes providing a particular service).  It is used as a directory service. e.g. the control nodes are designed to scale horizontally: the vrouter agent can use the discovery service to determine which control-nodes to connect to (as that list may change as the cluster grows).

For example, when the vRouter agent in a compute node wants to connect to a control node (to be more precise: to an active-active pair of Control VM’s) it uses service discovery to discover the IP address of the control node. The clients use local configuration, DHCP or DNS to locate the service discovery server.

Service providers e.g. DNS, IF-MAP, etc. register with the discovery service as they come online, and anything requiring the use of the services subscribes. Usefully for debugging node issues you can take a look at the discovery service, by connecting to the server at port 5998 e.g. http://x.y.z.230:5998/services and see what services are registered:

contrail-discovery-publishersAnd who are using them:

contrail-discovery-clientsSo you can see, for example, that the the vRouters are subscribed to the XMPP service, and the dns-server.

As more services/nodes are brought online they are registered with the discovery service and will be used. Likewise, if a service stops responding to heartbeats, the discovery will remove that service from the active list, and the clients will use the alternatives.