WO2008155545A2

WO2008155545A2 - Off site monitoring/control of electrical equipment

Info

Publication number: WO2008155545A2
Application number: PCT/GB2008/002082
Authority: WO
Inventors: Darryl Mattocks
Original assignee: Domia Ltd
Priority date: 2007-06-18
Filing date: 2008-06-18
Publication date: 2008-12-24
Also published as: GB0711770D0; WO2008155545A3

Abstract

A system for reporting the energy usage of a plurality of electrical appliances (10a, 10b, 10c) to an off-site location (6) is disclosed. Recording means are associated with the power supply of each appliance (10a, 10b, 10c) for recording the energy consumption of that appliance and reporting the energy consumption to a local controller (2). The local controller (2) is adapted to communicate with an off-site server (6).

Description

Off Site Monitoring/Control of Electrical Equipment

This invention relates to methods and systems which can be used for monitoring controlling electrical equipment, e.g. in an office or domestic home, from another location, e.g. an electricity supplier.

There is an increasing awareness nowadays of the need to reduce the consumption of energy wherever possible. One area in which it is considered that a significant impact in energy usage can be made is in reducing the number or electrical appliances which left switched on and consuming power when they are not being used. In recent times there has been a growing awareness of this, particularly in relation to appliances which feature a 'standby' mode. Whilst many consumers think of appliances being left in standby mode as 'off, the reality is that the power consumption in standby mode can be significant; it is not uncommon for devices to consume of the order of 80% of their 'on' power in standby; it has even been reported that some devices consume almost the same power in standby as they do when left fully on.

For some consumers behaviour can be changed by providing greater information on energy usage; others however cannot or will not change their habits regardless of the amount of information they are offered.

When viewed from a first aspect the present invention provides a system for reporting the energy usage of a plurality of electrical appliances to an off-site location comprising recording means associated with the power supply of each appliance for recording the energy consumption of that appliance and reporting said energy consumption to a local controller; said local controller being adapted to communicate with an off-site server.

The invention also extends to controller software for reporting the energy usage of a plurality of electrical appliances to an off-site location comprising means for receiving information relating to the energy consumption of a plurality of devices and for reporting said energy consumptions with an off-site server.

Thus it will be seen by those skilled in the art that in accordance with the invention a report of energy usage at a particular site can be provided via the local hub to an off-site location which could, for example, be an electricity supplier. This would allow the energy supplier to monitor usage on behalf of a customer and, for example, provide a cumulative periodic report of such usage which might include advice to the customer on how to reduce their usage. It might also be used for example for more sophisticated billing arrangements than are currently available. By off-site is meant a server to which it is necessary to communicate over a public network.

It is expected that the availability of information on energy usage by individual devices will lead to a reduction in the overall amount of energy used, both by altering user behaviour and by increasing the demand for more energy efficient devices. However in accordance with preferred embodiments of the invention the system further comprises means for controlling the energy usage of, typically by switching off, one or more of the devices being monitored from off-site. Although not essential, conveniently such control is performed using the local hub which is used to report energy usage. In such preferred embodiments of the invention significant savings in energy are anticipated since they allow an off-site entity such as an energy supplier to exercise control to reduce the unnecessary use of energy. Depending on the relationship between the off-site entity and the local user such control could be exercised in accordance with an agreed set of rules such as switching off equipment at a certain time of day); if certain other conditions are met (for example if an intruder alarm is set by the local user indicating that they are not at home); or simply in accordance with an overall policy. The latter might be applicable for example where the respective sites are part of the same commercial organisation. Conveniently but not essentially the control means for controlling the power supply to individual devices is integrated with the energy recording means. In one set of preferred embodiments these could be physically housed in a plug and socket unit which is fitted between the mains plug of the device and the mains electrical outlet - e.g. a wall socket. However there are many other possibilities. For example these means could be built into a mains wall socket or even built into future appliances. Equally they could be installed into a light switch or other part of a lighting circuit. As suggested above the energy recording and energy supply control means could be physically separate.

What may be appreciated is that preferred embodiments of the invention allows an off-site entity to monitor and/or control the usage of energy at a site which means that it is not necessary to exercise control at the local site level. In the context of domestic energy consumers for example this means that the benefits of an active energy management regime can be achieved without the user having to purchase, install or maintain a locally operated control system. The local hub can simply be a 'black box' so far as the user is concerned which needs only to communicate with the local devices and an external network to permit communication with the remote server. Importantly for mass consumer acceptance it means that in accordance with preferred embodiments it is not necessary for users to install or configure software on their personal computer (PC) or even to own a PC. When viewed from a further aspect the invention provides a controller comprising means for wirelessly sending instructions to and receiving information from a plurality of electrically powered devices and further comprising means for receiving instructions from and sending information to an off-site server, thereby allowing the controller to act as a relay for information from said devices to said off- site server and as a relay for instructions from said off-site server to said devices, The controller could communicate with the individual devices, e.g. their recording means and/or supply control means, in any convenient way. One possibility would be to apply a higher frequency signal over the mains electricity supply itself as is well known per se in the art for small scale data communications, e.g. using the XlO protocol. Alternatively an existing data network such as an ethernet could be used. Presently preferred is to use radio frequency (RF) communications. Any suitable protocol could be used such as Bluetooth, Zigbee, WiFi etc.; or a proprietary solution could be used instead.

In accordance with the invention monitoring and controlling of individual devices in a domestic house or commercial premises can be carried out off-site e.g. by an energy supplier. However by making the relevant server available on the World Wide Web, the consumer can themselves perform the monitoring and/or exercise control. This need only require a standard Web browser and thus offers benefits even if it is conducted at the same site as the devices being monitored/controlled by obviating the need to install or set-up software associated with a local system. It also means that control can be effected from a suitably enabled mobile device such as a mobile phone. Communication between the local controller and the off-site server could be conducted in any appropriate way. In preferred embodiments such communication is conducted over the public Internet, e.g. using an Internet Protocol such as (but not limited to) hypertext transfer protocol (HTTP) with e.g. extensible Markup Language (XML) messages. However the Applicant has devised a particularly beneficial communication scheme between the local controller and the off-site server. In accordance with this scheme the local hub is arranged to initiate communication with the off-site server using a first communication protocol, preferably a packet-based protocol, more preferably an Internet Protocol such as HTTP; but thereafter to switch to a second, preferably streaming protocol for subsequent communication with a second server application.

This is considered to be novel and inventive its own right and thus when viewed from a further aspect the invention provides a controller for controlling a plurality of electrical devices, and adapted for data communication with a plurality of server applications of different types, wherein said controller is arranged to communicate with a remote server application using a first communication protocol and thereafter to switch to a second protocol for subsequent communication with a second server application.

The invention extends to server software adapted, when executed on a suitable computer, to communicate using a first communication protocol with a controller for controlling a plurality of electrical devices, said software being arranged to send a message automatically to said controller including an instruction to initiate communication with a server application of a different type using a second communication protocol.

The invention further extends to controller software adapted, when executed on a controller for controlling a plurality of electrical devices, to communicate using a first communication protocol with an off-site server application, said software being arranged on receipt of a message automatically from said server application, to initiate communication with a server application of a different type using a second communication protocol.

As previously mentioned above, in preferred embodiments of this aspect of the invention the first protocol is a Web protocol such as HTTP which is relatively reliable in terms of being able to establish connections robust but which is relatively inefficient in terms of bandwidth. The second protocol is preferably a streaming protocol which requires a more reliable connection but which can offer far more efficient data transfer By establishing a connection initially over the first e.g. packet-based protocol and then switching when appropriate to the streaming protocol, highly reliability in establishing connections can be achieved whilst optimising bandwidth use.

What the Applicant has found particularly is that communication schemes in accordance with at least preferred embodiments of the invention can be reliably scaled up to large systems where a large number of controllers are required to communicate with remote, e.g. off-site, servers. This is an important consideration when it is desired to implement an off-site device monitoring/control system as outlined in accordance with the first aspect of the invention to a large number of consumers.

At least preferred arrangements in accordance with the second aspect of the invention allow network load balancing to be achieved more effectively since the switch to the second server application can be done such that a more local server to the controller is selected. This also leads to a reduced average communication latency.

The use in preferred embodiments of a packet-based, e.g. Web protocol to initiate communication means that a connection can be established under a greater number of circumstances than if a streaming protocol were used exclusively. For example some Internet connections do not support or allow under certain types of streaming but will of course allow the web connection. It may be therefore that in specific applications the controller can only communicate with the remote server via the first e.g. Web protocol. It is the flexibility of the controller which allows it to be deployed for a wide variety of setups. Preferably the controller is configured to initiate communication with the server by sending a message, i.e. the controller operates in a 'push' mode. This allows it to operate behind a firewall or router. If it is established that a streaming connection can be set up the controller can then send an initiating message to the second server. In one set of preferred embodiments the controller receives from the first server the address of said second server.

The flexibility of the communications scheme set out herein also gives a greater robustness to connection failure since if the steaming connection drops out, the controller can be configured to revert to the first protocol (e.g. HTTP). In some preferred embodiments of the invention the controller is in data communication with a camera, preferably a video camera, installed at the site. This allows pictures to be recorded, either locally or at the off-site server, and/or relayed to a user via a browser. This would therefore allow a system in accordance with the invention to be used a security system. The data link could be one-way or some control thereof might be possible via the controller, e.g. to switch it on, or to change the direction or zoom.

Similarly other sensors such as proximity sensors, glass break detectors, door switches etc. could be connected to the controller. In some preferred embodiments the off-site server could contain pre-defined alert conditions, such as any of the security sensors being triggered, which could alert the user or a security service, e.g. by email or SMS text message.

Certain preferred embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings in which: Fig. 1 is a schematic diagram showing the main elements of an embodiment of the invention;

Fig. 2 is a schematic block diagram of a device monitoring/control unit of the embodiment of Fig. 1 ;

Fig. 3 is block diagram showing the architecture of an embodiment of the invention;

Figs 4 to 10 are flow diagrams illustrating a communications scheme in accordance with an aspect of the invention; Fig. 1 1 is a block diagram showing elements of a camera module which can be provided

Turning to Fig. 1 the main elements of a home automation and energy monitoring system embodying the invention are shown. The elements above the dashed line are located at a house whilst the elements below are located away from the house. A central feature of the system is the controller 2. This is connected to an ADSL router 4 which is connected to an off-site server 6 via the Internet 8 over a broadband connection. The off-site server 6 could for example belong to an electricity supply company. Although an ADSL router is shown as an example it will be appreciated that any broadband or other data network connection could be used.

The controller is small consumer device physically resembling a modem, that contains an embedded microprocessor with a custom operating environment, solid state memory, a network controller such as an ethernet controller and a radio frequency transmitter and receiver. The latter allows the controller to establish a two-way wireless data link to a plurality of switched socket units 10a, 10b, 10c; and/or to a camera 12, motion detector 14 etc.

As shown schematically in Fig. 2, the switched socket units 10 each comprise: a mains electrical plug 16; a current measurement circuit 18 linked to a microprocessor control circuit 20; an electrically operated switch 22 controlled by the control circuit; and a mains electrical socket 24. An RF transceiver and decoder 26 is also connected to the circuit 20.

The mains plug 16 of each socket unit 10 is plugged into a standard mains outlet socket (not shown) whilst the mains plug of an electrical device is plugged into the socket 24 of the socket unit. This means that energy consumption of the electrical device can be measured and reported back to the controller 2 via the inbuilt radio transmitter 26. It also means that on receipt of an appropriate message from the controller 10, the control circuit 20 can be made to open or close the switch 22 to switch power to the electrical device on or off. If required a manual switch (not shown) could be provided on the socket unit 10 in order to override the operation of the in-built switch 22. At the controller 2, the energy consumption profiles of the individual electrical devices are collated and periodically passed to the off-site server 6. This allows the energy supply company to provide detailed reports to its customer on energy usage down to individual devices and therefore allows highly specific advice to be offered regarding the use of a particular device or its inherent efficiency. For example the advice could to substitute a low-energy bulb for an filament one, or to turn down the thermostat on a heater.

The control functionality also allows the off-site server to switch electrical devices in the customer's home on or off. This could for example be to a pre-agreed schedule such as turning off any controlled appliances during daytime when the house is unoccupied, or turning off audiovisual equipment left on standby at night. Temporary schedules could also be set up - e.g. to switch on lights whilst a customer is away on holiday. Additionally or alternatively the customers could themselves monitor and control their devices by using a Web browser e.g. to switch heating on before they get home or to check that they have not left the iron on. This could be effected from any Internet access point including an Internet-enabled mobile phone or PDA.

The energy supplier could offer the automatic control of a customer's devices as an additional service either free or on a subscription basis. The energy usage reporting functionality would allow the supplier to indicate e.g. on a bill, exactly how much saving the customer had made by subscribing to such a service.

It will be appreciated that an energy supplier might have millions of customers and thus the bandwidth requirements for connecting to each customer's controller will be significant. However the scheme described below allows bandwidth use to be minimised without sacrificing connection reliability or robustness.

Fig. 3 is a high level architecture diagram of an example system in accordance with the invention. This is based on an n-tier web service delivery model, and an enterprise scale asynchronous message bus 100, to provide the linkage between the server side controller services 102, 104, 106, 108, 100 and the user devices. The solution uses a combination of Java/J2EE technologies for the backend services and PHP/SOAP services to provide the user application environments. The user front end web site is built on PHP.

The message bus 100 is the heart of the system, providing an enterprise scale distributed capability, that enables the solution to handle multiple connections (tens of thousands) from many controllers across a wide hardware estate. It uses the JBoss Messaging (registered trade mark) product to implement an industry standard JMS service. The message bus 100 provides a provider/subscriber style of messaging, connecting controllers ( in the customer's home/office ) with the database 1 12 and application services. Turning to the PHP (Personal Home Page Hypertext Preprocessor) Web services 110, these provide application and business logic for user functions. The PHP Web Services module 110 provides a SOAP (Simple Object Access Protocol) interface for the Web or client application ( e.g. mobile application ) to provide all functionality, business logic and data services. The PHP Web Services 110 are hosted inside an Apache Web server.

The User Action Service 108 provides a PHP/JAVA/JMS (Java Messaging Service) interface for the business logic in the PHP Web Services to communicate with the controllers ( via the controller services ) and the backed application services ( alert service, scheduler service etc ). This is the interface for the business logic to the message bus. The User Action Service is a J2EE application that runs inside the JBOSS application server.

The Scheduler Service 106 is a J2EE application/service that runs inside a JBOSS server. It monitors the user-defined scheduled actions for switching devices on/off etc. which are defined in the user database 112, and at the appropriate time initiates device changes via the message bus 100. The Scheduler Service 106 communicates with the host controller 2, placed in the customer's home of office, via the message bus 100 to the Http / Stream Controller Services 1 14, 116. These in turn communicate via XML: 80 over HTTP in the case of the HTTP service 114 or XML:21 over a streaming protocol in the case of the stream server 1 16. The Alert Service 104 monitors change activity, which can either instigated by the user ( via the Web client or mobile client ) or reported by the device/controller 2 located in the home, e.g. if a device is switched on or a motion detector is triggered. Change messages are placed onto the message bus 100 and, through a publisher/subscriber model, the Alert Service 104 compares these changes with user-defined alerts. If the service identifies an alert, then it will instigate user notification ( via email or SMS ) and, if defined, one or more user-defined device changes can also be effected. Again, messages to the controllers 2 and so the devices is via the message bus 100, communicating with the HTTP or Stream Controller Services 114,116. The Alert service is a J2EE application/service that runs inside the JBOSS Server.

The customer database 112 provides application data for the system. The database is based on a MySQL database, which can be clustered/ distributed across multiple machines to provide scalability and redundancy. An LDAP service ( a Lightweight Directory Access Protocol e.g. OpenLDAP ) provides user credentials management, and this is backed to the MySQL database, to enable easy access and manipulation as required. The Database Service 102 provides connection to the message bus 100. The Database Service 102 supports a number of application requests to store controller and device information ( such as device and controller status change ).

All communications to the controllers 2 is via one of the two Controller Services using a different protocols over the TCP/IP stack. As controller's 2 are often positioned behind routers/firewalls, it is the controller 2 that has to instigate communications to connect to the Controller Services 114, 116.

All messages are XML messages. The controller and controller services supports two messaging channels. The first is HTTP messaging, which involves the controller 2 sending an HTTP 'GET' message with an attached XML message. The server 114 responds with an XML document response that contains the reply to the request. The second channel is stream messaging, which uses a character-based, persistent end to end TCP/IP socket, enabling server 116 and controller 2 to remain in constant communications.

All controllers 2 instigate communications via the HTTP messaging service with the HTTP Controller Service 114. With this working, the HTTP Controller

Service 1 14 will instruct the controller 2 to switch to stream messaging, and supply a URL for the controller 2 to use. The controller 2 will then attempt to connect to - l i ¬

the Stream Controller Service 116. If it fails or the path is blocked, the controller will return to the HTTP Service 114. This procedure is described in more detail below with reference to Figs. 4 to 10.

The Controller Services 114,116 connect to the message bus 100 as can be seen. Instructions for controllers 2 (and devices in communication with them) are placed onto the message bus by the PHP Web Services 110, Alert Services 104 and Scheduler Services 106. If a Controller Service 114, 116 is connected and talking to a controller 2 (via HTTP or stream ), it will grab the instruction and pass it onto the controller 2. Similarly, if the Controller Service 114, 116 receives a notification of a device change ( from a controller 2), the Controller Service 114, 116 will place this change onto the message bus 100 to update the database of known device states. The Alert service 104 listens to this traffic to determine if an alert condition has been triggered.

All controller messages and responses are designed to fit within one TCP/IP packet to support the limited controller operating environment and to keep the communications overhead to a minimum. The HTTP Controller Service is one half of the Controller Service supporting communications between the message bus 100 and the devices via the controllers 2. The HTTP Controller Service 114 is a J2EE service running inside the JBOSS application server, which can be distributed across multiple JBOSS ( and server ) instances.

The Stream Controller Service 116 is the second half of the Controller Service supporting communications between the message bus 100 and the devices via the controllers 2. The Stream Controller Service 116 is also a J2EE service running inside the JBOSS application server, which can be distributed across multiple JBOSS ( and server ) instances. The stream service uses a 'character' stream device to send XML requests and responses via an open socket, bi- directionally. Once established, the connection remains open. A light weight heartbeat message is sent every few seconds to confirm the devices are in contact. The controller 2 is a custom-built IP-enabled device that connects to the off- site server via the Internet. It is designed to sit on a standard intranet/LAN, gathering DHCP and IP details from automatic services provided by the local infrastructure such as a home ADSL router (see Fig. 1). The controller has an embedded microprocessor, RAM and EPROM, and ethernet connection. The application software contained within the controller 2 connects to the Controller Services 114, 116 via TCP/IP sockets (including HTTP requests), and to local devices (lights, hi - fi, television, heating etc.) via a radio transmitter. This radio device also includes a receiving capability, able to detect radio messages from devices (and device controllers like motion detectors ), and relay them back to the off-site server. The controller 2 supports 433 & 868 Mhz devices, as well as other home automation protocols like XlO, Z- Wave etc.

The controller 2 also contains an internal web service, that enables debug, local control and status to be handled from a browser session running locally to the machine.

Figs. 4 to 10 are functional block diagrams giving more details of the communication scheme which are divided into functions of the controller in the upper section; an HTTP server in the middle section; and a stream server in the lower section.

The controller supports four different messaging protocols:

1 ) push messages, where the controller instigates an XML message, via an HTTP request (i.e. HTTP-push);

2) listen messages where the controller responds to an XML message, sent via HTTP, and received to a URL by the device by its internal web server. (

HTML/SOAP style );

3) stream messages where the controller and a server open a TCP socket/stream, where XML messages are exchanged in a push/respond manner ( i.e. each side can instigate a message); and 4) UDP (User Datagram Protocol) in which the controller listens for messages on the UDP port 53003 and broadcasts all push messages on that port as well through other channels

The messages use a simple XML structure. All messages have a maximum size of 1500 bytes ( i.e. one ethernet packet size ). The controller has a unique MAC/GUID address printed on the casing, used by the controller/server to identify the device. All messages use the MAC/GUID address to identify which controller (and hence customer) the message corresponds to. All messages have a simple request format, and a corresponding response.

The controller is designed to work from behind a firewall/router with no configuration. The default mode is therefore to use push messages, where the device instigates communications with the off-site server over HTTP. If push messaging is working, the server can request to the controller to start a stream based communication. For performance reasons, this will be the preference. If the stream is broken, or communication fails, both server and controller will return to push messaging. The Controller & Server do not need to support both protocols at the same time. If an error occurs, and a controller or server is confused about which protocol is in use (for example if it detects both - i.e. a push message is received while a stream service is open) then both devices will resort to the push messaging service, and re-attempt to establish messaging. All messages include a date time and a message number. The controller / server will check that the request message sent matches the response message received by checking the message number is the same. The controller/server that sends a request responds within a certain time, after which it will ignore the message (e.g. timeout 1 minute). Responses received after the timeout will be ignored, and the controller/server will resend a message three times, after which it will drop the action/message attempt.

If a controller receives a message with an incorrect MAC/GUID address (i.e. it is an address of another controller) then the message is ignored. The controller will have an initial address that it always use to initiate communications with the server, although the server can request that the controller moves to a new/another address in subsequent communications. The controller in preferred embodiments only reverts to this hard-coded server address after a significant time-out period ( e.g. 8 hours). If the controller is rebooted however, it will revert to the hard-coded URL. Push messages are sent via HTTP, using either GET or POST methods sending a message / parameter 'request' as an XML message. The response will be an XML document response message, e.g.: http://controller.harmonyhome.eu?request=<xml>....</xml>

Heartbeat messages are sent periodically by the controller to the server. The default might for example be 15 seconds, although the server can request more frequent heartbeats. In the preferred embodiments the controller does not initiate a heartbeat more frequently than once per second, and does not initiate a heartbeat if another message is outstanding ( i.e. only one message is sent at any one time). Looking firstly to Fig. 4 the process of establishing a connection will be described. At step 30 the controller is booted, reset and initialised. At step 32 the controller sends a heartbeat message request 34 to the HTTP server over the ADSL connection to the Internet. If the HTTP server request was unsuccessful the controller waits and retries at step 36. If it was successful it waits at step 38 for a response. At the off-site HTTP server when the heartbeat request 34 is received at step 40 a heartbeat response 42 is sent at step 44. If the controller does not receive the response 42 it returns to step 32 to send another heartbeat request 34. If it s received however then a connection is established, at step 46.

It will be seen that the procedure described above only opens an HTTP connection. However as soon as soon as such a connection has been established, the HTTP server sends a response to a message from the controller telling it to switch to stream mode. This is shown in Fig. 5. The 'switch to stream¹ instruction is sent as soon as communications are established over HTTP and can occur as part of the first (heartbeat) message that is sent.

The first part of the 'switch to stream' procedure shown in Fig. 5 is almost identical to that described with reference to the previous figure and thus similar (but primed) reference numerals are used. The only difference is that when the HTTP server sends the heartbeat response 42' at step 44' it includes a command to switch to stream mode with the address or other identification of a suitable stream server. Thus when the heartbeat response 42' is received at step 38' then at step 48 a connection 49 is opened and a further heartbeat request 50 is sent, this time to the stream server. As long as the connection 49 was opened successfully the controller awaits a heartbeat response from the stream server. At the stream server the heartbeat request is received at step 52 and a response 54 is sent a step 56. If this is not received then the controller reverts to step 30' and sends another heartbeat request to the HTTP server. However if the heartbeat response 54 is successfully received the controller and stream server get into a loop of exchanging periodic heartbeat requests 50 and responses 54. This is shown on the left hand part of Fig. 6. Thus as long as the streaming connection is working, heartbeat requests 50 and responses 54 are exchanged between the controller and the stream server. However if the stream server heartbeat response 54 is not received, e.g. as a result of the connection failing, then at step 60 a connection to the HTTP server is opened and an HTTP heartbeat request message 34 is sent. If the connection is opened successfully, a heartbeat response 42 is sent at step 44 and received at step 38. It will be seen that this part of the procedure is the same as that described with reference to Fig. 3. It means that if the stream connection fails, the system can still revert to an HTTP connection which, although less efficient, is clearly preferably to the connection dropping out completely.

Fig. 7 shows the procedure for reporting a change in the status of a device monitored by the controller while it is operating in stream mode. Such a change in status could be an electrical device being switched on (and so starting to consume energy), a motion detector detecting movement or a button press on a control keypad. In preferred embodiments such changes are reported by the individual devices over their wireless (e.g. radio frequency) connection. When the controller detects such a change at step 62 it sends s 'ReportDevice' request message 64 to the stream server using the previously opened connection. Assuming that this is properly received, the stream server then sends a 'success' response 66 back to the controller. If the stream server's response 66 is received then the controller goes back into the heartbeat loop on the left hand side of Fig. 6. If the response 66 is not received the controller switches to HTTP mode at step 60 of Fig. 6.

Fig. 8 shows the corresponding procedure for reporting a device status change when the controller is operating in HTTP mode. It thus similarly at step 67 sends a ReportDevice HTTP request message 68 and looks for a response 70 from the HTTP server. If the response 70 is received the controller returns to the normal heartbeat loop, but if it is not a heartbeat request is sent at 32 (i.e. as in Fig. 4) but the ReportDevice message is queued so that when the heartbeat is received the controller returns to step 67 to retry sending the ReportDevice message.

Figs. 9 and 10 show the procedure for a user changing a device status in stream mode and HTTP mode respectively. These Figures have an additional row showing the interaction of a user. Thus in Fig. 9 a user can change the status of a device at step 72 by sending a message 74 to the stream server . This could be from a direct interaction with the server, e.g. by an employee of an energy company, or by a customer logging on via a browser either at a fixed terminal or suitable mobile device. The stream server in turn sends a message 76 to the controller which receives it at step 78 and then at step 80 sends a response 84 to the stream server; and at step 82 actually sends an instruction to the relevant device to make the relevant change, e.g. turning an appliance off or on. At step 86 the stream server sends a heartbeat response to return to the heartbeat loop. Fig. 10 shows the corresponding HTTP mode procedure. Here the user request 72 results in a message 74' going to the HTTP server which receives it at step 88 together with an ordinary heartbeat request message 34. The HTTP server responds at step 90 with a heartbeat response 92 which includes the request to change the device. When this is received by the controller at step 94 the device is changed at step 82 just as in the stream mode case.

Fig. 11 shows how the system shown in Fig. 3 can be expanded by the addition of a camera service which provides an online security solution. Customers can manage and maintain a number of distributed 'IP' cameras 118, that stream messages to a Camera Server 120. These images are then available to the user from their remote browser or mobile phone. Images are uploaded at a regular intervals to the Camera Server 120, using FTP, into a user specific directory. Each camera 118 has its own directory, enabling different cameras to be distributed across multiple machines. 1

The Camera Service 124 is a separate collection of SOAP service calls that enable the ( remote/separate ) user's browser and/or the PHP Web Services 110 to interact with the Camera Storage Service 122 and the stored images. The Camera Service 124 runs on its own Apache instance, and written in PHP. User sessions from a browser, will connect directly with a Camera Service 124 to retrieve the latest image(s). Images are re-sized to fit the target screen/image size before being transferred back to the calling device. Where provided a Mobile Phone Application also uses this interface to provide images on the move, providing a 'live' feed from a remote camera to a user's phone.

The Mobile Phone Application (not shown) is a J2ME 'Midlet' that provides remote access to a Harmony Enterprise instance. This application connects to the PHP Web Services interface 110 to enable a remote authenticated user to control devices, monitor cameras, and set scenes within their home/business. The Java application is downloaded from the website ( prompted by an SMS message to the user's phone with the location ), and runs on current/modern JAVA enabled and internet capable mobile phone ( GPRS or 3G, with J2ME 2.0/MIDP 2.0 ).

It will be seen that the preferred embodiment of the invention described above can provide a home and or office automation service, that enables families and businesses to control their electrical devices (lights, PCs, curtains, monitors etc.) from anywhere in the world using a standard 'browser'. With the addition of the mobile interface, users are able to also control their homes from their GPRS/internet-enabled mobile phone. With the addition of the camera services, users are also able to monitor their home visually from any location, including on the move via their mobile phones.

The embodiment described is designed to require no location PC, or computer knowledge. A simple controller can be plugged into an Internet connection, providing all the local communications with the applications/services. The user can then use a local browser (i.e. local to their home) or remote ( e.g. at their office or anywhere ) to access the services, control the devices, and view the cameras. The design enables the system to be scaled to many tens of thousands of multiple users, enabling it to be promoted and sold to mass-retail style markets. The architecture uses distributed and asynchronous technologies to enable the simple scaling of the available service bandwidth. The architecture enables the system to present different brands (or 'skins') simultaneously, so different organisations can promote, 'white label' and resell the service. The system can also enables users to define alerts, where the system detects changes in a device (light, curtain, door etc.), and responds with a message. Messages can then be sent to either a mobile phone or via email. On detecting an alert, the user is also able to define a set of actions that they want the system to perform . For example if a specific door is opened, all lights can be turned on,

The system also enables scheduled actions to be defined, in which repeated tasks are performed at set times ( e.g. opening the curtains at 8 am every day). Scenes enable the user to consolidate multiple actions into a single action, for example 'Close All Curtains' instructs many devices simultaneously.

Claims

Claims:

1. A system for reporting the energy usage of a plurality of electrical appliances to an off-site location comprising recording means associated with the power supply of each appliance for recording the energy consumption of that appliance and reporting said energy consumption to a local controller; said local controller being adapted to communicate with an off-site server.

2. A system as claimed in claim 1 further comprising means for controlling the energy usage of one or more of the devices being monitored from off-site.

3. A system as claimed in claim 2 wherein such control is performed using the local controller.

4. A system as claimed claim 2 or 3 comprising control means for controlling the power supply to individual devices, said control means being integrated with the energy recording means.

5. A system as claimed in claim 2 or 3 wherein said control means and said energy recording means are housed in a plug and socket unit adapted to be fitted between a mains plug of an electrical device and a mains electrical outlet.

6. A controller comprising means for sending instructions to and receiving information from a plurality of electrically powered devices and further comprising means for receiving instructions from and sending information to an off-site server, thereby allowing the controller to act as a relay for information from said devices to said off-site server and as a relay for instructions from said off-site server to said devices,

7. A controller as claimed in claim 6 adapted to communicate with said plurality of electrically powered devices wirelessly.

8. A system or controller as claimed in any preceding claim wherein said controller is adapted to communicate with said off-site server using a communication scheme comprising: the local controller initiating communication with the off-site server using a first communication protocol; thereafter switching to a second protocol for subsequent communication with a second server application.

9. A controller for controlling a plurality of electrical devices, and adapted for data communication with a plurality of server applications of different types, wherein said controller is arranged to communicate with a remote server application using a first communication protocol and thereafter to switch to a second protocol for subsequent communication with a second server application.

10. A system or controller as claimed in claim 8 or 9 the first protocol is a packet-based protocol.

11. A system or controller as claimed in claim 8, 9 or 10 wherein he second protocol is a streaming protocol.

12. A system or controller as claimed in any of claims 8 to 11 wherein the controller is configured to initiate communication with the server by sending a message.

13. A system or controller as claimed in any of claims 8 to 11 wherein the controller is configured to receive from the first server the address of said second server.

14. A system or controller as claimed in any preceding claim wherein the controller is in data communication with a camera

15. A system as claimed in of claim 1 to 8 or 10 to 14 wherein the off-site server contains pre-defined alert conditions for alerting a user or a security service.

16. Controller software for reporting the energy usage of a plurality of electrical appliances to an off-site location comprising means for receiving information relating to the energy consumption of a plurality of devices and for reporting said energy consumptions with an off-site server.

17. Server software adapted, when executed on a suitable computer, to communicate using a first communication protocol with a controller for controlling a plurality of electrical devices, said software being arranged to send a message automatically to said controller including an instruction to initiate communication with a server application of a different type using a second communication protocol.

18. Controller software adapted, when executed on a controller for controlling a plurality of electrical devices, to communicate using a first communication protocol with an off-site server application, said software being arranged on receipt of a message automatically from said server application, to initiate communication with a server application of a different type using a second communication protocol.