Next: Usage Instructions, Previous: Tax Benefit, Up: Top [Contents]
The following pieces of the GNU remotecontrol architecture are necessary:
The following pieces of the GNU remotecontrol architecture are optional:
The following versions for the GNU remotecontrol architecture are required:
An abbreviated set of installation instructions for GNU remotecontrol as a whole is available in the INSTALL.md file, located in the /PATH-TO-YOUR-SVN/remotecontrol/doc/ directory.
Please make certain you have the required software versions, as listed in the beginning of this section.
GNU remotecontrol is configured with the minimum level of security necessary for a Web Server. You are responsible for setting up your security on your Web Server.
GNU remotecontrol can operate on any platform capable of running PHP with cURL and MySQL. GNU remotecontrol works with either Basic or Digest authentication. GNU remotecontrol works with either Apache mod_PHP or FastCGI Process Manager. Follow the requirements stated by the Web Server you so choose to use.
GNU remotecontrol runs without any known problems on Apache, Nginx, and IIS. Running GNU remotecontrol on a lightweight Web Server versus a complete Web Server is possible, but not recommended. This is due to the security benefits of a complete Web Server. Again, you are responsible for setting up your security on your Web Server.
GNU remotecontrol is configured within the config.example.php file. This file is located in the /PATH-TO-YOUR-SVN/remotecontrol/ directory. Copy config.example.php to config.php. This file contains all necessary parameters to connect your Web Server to your Database Server, after you have initially installed and configured each server.
GNU remotecontrol will not work with anonymous users. This is because of how GNU remotecontrol is designed and for security purposes. You must add at least a single user in your GNU remotecontrol database, which is checked against an identically named user account configured in your website. GNU remotecontrol authentication is aligned with Web Server authentication, by keeping user names between the two identical. Follow the requirements stated by the Web Server you so choose to use.
Here is what you need to run GNU remotecontrol on Apache, after you setup your security on your Web Server.
DocumentRoot /var/www/remotecontrol <Directory /var/www/remotecontrol> Options FollowSymLinks -Indexes AllowOverride None Order allow,deny allow from all </Directory> <Location /> AuthType Basic AuthName "GNU remotecontrol v2.0 - USER AUTHENTICATION REQUIRED" AuthUserFile /etc/apache2/.remotecontrol_passwd Require user tstat_admin tstat_test_user_1 tstat_test_user_2 </Location>
register_globals = Off auto_globals_jit = On
Please make certain you have the required software versions, as listed in the beginning of this section.
GNU remotecontrol is configured with the minimum level of security necessary for a Database System. You are responsible for setting up your security on your Database Server.
GNU remotecontrol runs without any known problems on MySQL. Running GNU remotecontrol on a lightweight Database Server versus a complete Database Server is possible, but not recommended. This is due to the security benefits of a complete Database Server. Again, you are responsible for setting up your security on your Database Server. Follow the requirements stated by the Database System you so choose to use.
There are both complete and partial automation options available to setup your GNU remotecontrol database. The files for these options are located in the /PATH-TO-YOUR-SVN/remotecontrol/dbscripts/ directory. The complete automation option is an all-inclusive interactive script called make-db.sh. The partial automation option is the same all-inclusive script broken into individual SQL scripts. Follow the requirements stated by the Database System you so choose to use.
Command-line arguments for the make-db.sh file are sequential:
Execute the individual SQL scripts in the following order:
The README.md file in this same directory contains abbreviated instructions to setup your GNU remotecontrol database. Again, an abbreviated set of installation instructions for GNU remotecontrol as a whole is available in the INSTALL.md file, located in the /PATH-TO-YOUR-SVN/remotecontrol/doc/ directory.
Please make certain you have the required software versions, as listed in the beginning of this section.
GNU remotecontrol is configured with the minimum level of security necessary for a Remote Monitoring application. You are responsible for setting up your security on your Remote Monitoring Server.
Follow the requirements stated by the Remote Monitoring application you so choose to use.
The question must be answered.....why would you not monitor your systems? This is not a judgemental question, simply framing the context of this section. This section has a list of Frequently Asked Questions, at the end. If your answer brings you peace of mind to not have a Remote Monitoring Server, so be it. Perhaps you trust the decisions and work of others enough to not bother with setting up a Remote Monitoring Server. That is often a poor choice.
Running a Remote Monitoring Server is the easy part of having a Remote Monitoring Server. The biggest decision you have to make is.....are you going to run it, or is someone else? Then, and only then, choose the technology combination you want to have for your Remote Monitoring Server. Do not let your skill set alone decide what is best for meeting your needs. Determine what you needs are, count the cost, and then choose your technology.
Popular Options
Note: There are many, many other options to choose.
We have developed plugins for Nagios to round out the Energy Management strategy. Check out the Nagios Plugins.
Follow the requirements stated by the Remote Monitoring application you so choose to use.
We developed a complementary set of plugins to round out the GNU remotecontrol Architecture. The plugins can be implemented either individually or collectively. We developed our plugins in accordance with the Nagios Plugin Development Guidelines. The function of these plugins is to capture and process numerical characters from data obtained from your IP enabled thermostat device and RSS or JSON feeds for weather information out of doors. The measurements of Temperature, Humidity, Wind-Speed, Wind-Chill, and Atmospheric (Barometric) Pressure help to analyze your entire HVAC system and determine if your Energy Management strategy is working for you. Other measurements can be added in as preferred, as shared below.
The need for the Thermostat Plugin - check_ubicom is better understood when the limitations of the native Proliphix alarms are examined. The Proliphix thermostat device has four alarms.
Alarms in the thermostat device were considered for displaying in GNU remotecontrol home.php or another web page not yet developed (perhaps something like a GNU remotecontrol alarms.php web page). Feedback from users during development of GNU remotecontrol showed their preference is to be informed of alarms from a Remote Monitoring Server notification. This approach also provides logging of all monitored information, a feature not available in the thermostat device itself.
The Temperature and Humidity alarms are already provided for in the Nagios checks we have developed. The Filter Change alarm has various pre-determined options to select; 10, 30, 60, 90, 120, 240, 365 Runtime Days. This does not account for dust accumulating on a filter, should the power be turned off to the thermostat device. This logic combination is determined as insufficient to use for monitoring when to change the filter of any HVAC system. Reasoning for this determination includes:
The Proliphix API only supports reading these alarms, not setting an alarm threshold or resetting an alarm event. The user must go to the web page within the Proliphix thermostat device for setting an alarm threshold or resetting an alarm event. Also, there is only a single alarm issued per alarm type until the alarm type event is reset in the thermostat device. This logic combination means a threshold may be exceeded, return to an acceptable level for the user, and then be exceeded again. This example is an excellent illustration of the value gained by having a Remote Motoring Server, with its fully configurable and flexible alarm functionality, watching your network, your devices, and anything else you can monitor.
Finally, since the thermostat device has a threshold of how many read events the unit can support per minute, we did not want to overwhelm the device with multiple read events. An example of this overwhelming of the device is:
The Proliphix API is quite distinct about this cautioning of too many read events per minute through the Proliphix API. The combination of the web server of the thermostat device and GNU remotecontrol home.php is a proper approach to use and not overwhelm the thermostat device. This approach caches the data and avoids repeated Proliphix API calls to the Proliphix HVAC thermostat device.
Please review the documentation provided with the plugin source code for detailed usage instructions. The following is an outline of the detailed instruction.
This plugin will attempt to read temperature and humidity from a thermostat device. Successful reads initially set the response to STATE_OK. If the temperature or humidity falls outside the range set by the warn-temperature or the warn-humidity arguments, then the response is upgraded to STATE_WARNING. If the temperature or humidity falls outside the range set by the critical-temperature or the critical-humidity arguments, then the response is further upgraded to STATE_CRITICAL. Failure to read both values, due to either a timeout or parsing failure, results in a STATE_UNKNOWN response.
check_ubicom! -wt :70 -ct :90 -wh 10: -ch 5: -t 60 -I example.remote-mon.com -u /status.shtml
check_ubicom! -m -wt 0:30 --critical-temperature=-10:50 -I example.remote-mon.com -u /status.shtml
define command{
command_name check_ubicom
command_line $USER1$/check_ubicom -I 10.10.10.22 -p 8264
}
Please review the documentation provided with the plugin source code for detailed usage instructions. The following is an outline of the detailed instruction.
The check_weather plugin checks the wind-chill, wind-speed, humidity, pressure, and temperature received from Yahoo! Weather RSS Feed for a single location. The return value is always either OK or UNKNOWN, as the weather feed either is or is not accessible.
You are certainly free to use any other feed you prefer. Examples of a feed include The Weather Channel and Weather Underground. All of these feeds have free and paid options. Please carefully read their provisions if you select to use their feed.
The performance values returned by the check_weather plugin, in order, are:
check_weather! -d 23424748 -m F -w 0 -c 0
OK|52 8 88 29.68 52
check_weather! -d 23424748 -m C -w 0 -c 0
OK|35 12.8748 88 753.872 35
define command{
command_name check_weather
command_line $USER1$/check_weather -d 23424748 -m F -w 0 -c 0
}
Please review the documentation provided with the plugin source code for detailed usage instructions. The following is an outline of the detailed instruction.
The check_forecast plugin checks the wind-chill, wind-speed, humidity, pressure, and temperature received from Open Weather Map for a single location. The return value is always either OK or UNKNOWN, as the forecast feed either is or is not accessible.
You are certainly free to use any other feed you prefer. Examples of a feed include The Weather Channel and Weather Underground. All of these feeds have free and paid options. Please carefully read their provisions if you select to use their feed.
The performance values returned by the check_forecast plugin, in order, are:
check_forecast! -t -24.91 -n 133.4 -m F -w 0 -c 0 -a [INSERT YOUR API KEY HERE]
OK|52 8 88 29.68 52
check_forecast! -t -24.91 -n 133.4 -m C -w 0 -c 0 -a [INSERT YOUR API KEY HERE]
OK|35 12.8748 88 753.872 35
define command{
command_name check_forecast
command_line $USER1$/check_forecast! -t -24.91 -n 133.4 -m F -w 0 -c 0 -a [INSERT YOUR API KEY HERE]
}
These plugins are developed under the Nagios License.
GNU remotecontrol is configured with the minimum level of security necessary for an Email Server. You are responsible for setting up your security on your Email Server.
The email send function used in the GNU remotecontrol Architecture is for sending email from your Remote Monitoring Server to you, using SMTP. The mail send function will use the server’s Mail Transfer Agent (MTA). Requirements for High Availability of mail sending necessitate the configuration of a secondary MTA to provide service redundancy. You will need to have your own registered Domain Name with its MX record, to be able to send email messages directly to recipients and not be blocked by various Internet Service Providers (ISPs), for fear of spam. Follow the requirements stated by the Email Server application you so choose to use with your Remote Monitoring Server.
Many ISPs block outgoing packets through port 25. This occurs as a matter of course to minimize spam. If you ISP is blocking port 25, then you have the option.....and is STRONGLY RECOMMENDED for security purposes.....to configure your MTA to use SSL/TLS encryption when sending messages to remote mail servers (SMTPS). This configuration would normally use a different port than port 25 for outgoing messages, overcoming the problem of blocked port 25. If your server is not operating under a registered Domain Name, then you have no option but to use a third party SMTP service offered by different ISPs (e.g. DynDNS Email, Gmail, et cetera) to relay messages from your Remote Monitoring Server server to the intended recipients, via your email account on the third party server.
Do yourself a big favor and become clear on these three items:
Then, do yourself a huge favor and become familiar with these four items:
Now, having a familiarity understanding of these items will equip you to have a successful talk with your Email Administrator, or your Internet Service Provider, or a Mail Relay Provider. They will ask you several questions about how you want email handled for your GNU remotecontrol. Prepare beforehand for this discussion. The discussion will go much better if you are familiar with and understand these items.
The Remote Monitoring Server can be configured to send notifications to any number of different recipients. It is advisable you configure the access control list of your Email Server to only allow messages to be sent from the user under which your Remote Monitoring Server is running, as an added security precaution. Follow the requirements stated by the MTA application you so choose to use and the settings provided by any third party SMTP service.
The email you probably want to receive is that which will notify you of a condition occurring. You are notified by email messages sent to you by your Remote Monitoring Server. You do not have to keep these email notifications after you are notified, nor do you need to set any reports to be sent to you in more emails. All of the information you would ever need about notifications, alerts and their history, is being stored on your Remote Monitoring Server, either in log files or in a database. The benefit of receiving an email alert is to be notified in real time, when you need to look into an exception event to mitigate its impact. The benefit of this awareness is priceless.
Note: Don’t use an SMS address when sending email to cell phones. Use the cell phone’s email address via the Free Email To SMS Gateways. Major United States Carriers offer this to both email or SMS users. Look for the same options from cell phone providers where you live. You will be much happier using the cell phone’s email address, as you can easily track if the message went out or not, versus wondering about the SMS system.....in which knowing is often a mystery. Finally, it is one less system to use.
RMS is the acronym of Remote Monitoring Server.
A Remote Monitoring Server regularly keeps track of your chosen networked device (computers, email servers, web servers, routers, thermostat devices, et cetera) and notifies you with alerts of any problems when they occur.
If you want to know the status of any IP addressable device, you need to monitor it. If you do not have the time or effort available to stand there and watch the device yourself, you need something to automatically monitor it and record the results for you to review at your leisure. Ideally, the Remote Monitoring Server will promptly notify you of anything occurring you have defined as a problem. An automated technology which remotely monitors your equipment, commonly referred to as.....stuff.....and alerts you when there is a problem. This is RMS.
Watch your “stuff” and tell you when your “stuff” has a problem. It logs the results of the monitoring of your “stuff” for you to review in a web page based format. This approach will help you quickly figure out if something is wrong and what is wrong with your “stuff”.
Pretty easy, actually. Setup your Remote Monitoring Server and decide what network and devices you want monitored. From there, you receive an email or SMS message to your cell phone when there is a problem.
Yes, it produces graphs providing a visual indication of the measurements taken, in configurable scale and units of measurement.
Yes, you can access your RMS server using your cell phone Internet browser.
No more difficult than receiving an email or SMS message when an alert occurs. Reports of historical events are available on the RMS served website, which includes a summary dashboard and detailed log tables and graphs.
More than enough for you to know if and when there is a problem. A notification system is almost limitless in how it can be configured for you. A good example is not receiving all SMS message in the middle of the night, but only the SMS messages you conclude you must have ’round the clock. When you receive a notification, how many times you receive a subsequent notification for the same failure, and who receives those notifications.....all set up as you want.
Often, there is a primary and a secondary person in a monitoring notification. Each person has an email address and an SMS address, receiving email or SMS notifications to each address.....as you prefer. Or, it is sent to a Distribution List. The combination of options are plentiful to send email, rest assured.
Yes. RMS and GNU remotecontrol work together to help you do just this. Having recorded data for your system usage and outdoors weather information is priceless for testing and balancing. It offers considerable cost savings, in both time and effort, to review recorded data to optimize your system setup. Additionally, you can reduce the number of people necessary to do the testing and balancing down to one person.
Not to sound silly, but RMS prevents a mess. It is impossible to consciously improve anything without first measuring it. You may stumble upon a way to improve it, but is that a pro-active approach to managing anything? Of course not. To help improve things, RMS helps by monitoring the status your resources. The unknown things of life can crop in and cause problems. The faster you know about a problem, the faster you can stop any damage the problem may cause. RMS helps you take advantage of the opportunity to improve how you manage things, so the chance of a problem returning becomes less likely.
If you worry about your “stuff”, and your “stuff” has an IP address, you need RMS.
Next: Usage Instructions, Previous: Tax Benefit, Up: Top [Contents]