WO2017067842A1

WO2017067842A1 - Control system for communicating with devices connected to a bus, and communication method

Info

Publication number: WO2017067842A1
Application number: PCT/EP2016/074587
Authority: WO
Inventors: Jan Joost 'T HART
Original assignee: Philips Lighting Holding B.V.
Priority date: 2015-10-19
Filing date: 2016-10-13
Publication date: 2017-04-27

Abstract

A control system is for communicating with a device over a bus, the control system supporting a first communications protocol over the bus. The system has connection terminals for connection to lines of the bus, wherein the bus lines comprise at least a data line for transferring data and a clock line for communicating timing information. A signal on the clock line is analyzed and from the signal on the clock line, it is determined if the device is of a first type which is compliant with the first communications protocol or of a different second type. Communication with the device then using a communication protocol which depends on the type of device detected. In this system, the type of signal present on a clock line of the bus is used to determine the type of device with which communication is to be made. One type is a device which operates using a clock signal and the other type is a device which holds the clock line e.g. at ground and thus does not make use of a clock signal for communication.

Description

Control system for communicating with devices connected to a bus, and communication method

FIELD OF THE INVENTION

This invention relates generally to the field of communications with devices over a bus, and more specifically to a controller that allows devices of different types to connect to the same bus.

BACKGROUND OF THE INVENTION

There are many different types of networked systems, in which control of a set of devices is managed by a central controller.

There is also an increasing amount of functionality incorporated at the individual networked devices, so that often a networked device is able to connected to local supporting devices, such as sensors, for example to provide automated control features in dependence on sensed conditions. By way of example, a lighting system comprises a set of luminaires connected together over a network, for example a DALI network. There are many systems which include additional (non-lighting) functionality at the luminaire, such as movement detection (using a PIR sensor), remote control sensing (using an IR detector), temperature sensing etc. The luminaries then become part of an overall building lighting automation system.

For this purpose, there are luminaires which include an external connection port in addition to the network connection. In this way, the overall network can include multiple non-lighting devices, such as sensors. The external connection typically comprises a bus, which provides a data communication channel and also provides the power supply for the locally connected device.

There are many different communications standards. However, a bus typically only supports a single communications standard. Thus, if a proprietary high cost

communications standard is used for the external connection port, all devices to connect to the port must also conform to that proprietary standard. Some communications standards command a price premium over others so it would be desirable to be able to use a lower level bus standard for simpler devices at a lower price, as well as the higher level bus standard for the more complicated devices.

One more advanced communications standard known as Inter-Integrated Circuit (I²C) has been used to connect between a luminaire and an external device to be located at the luminaire. One class of sensors known as Intra Luminaire Bus (ILB) sensors make use of the I²C communications protocol. The I²C protocol allows devices to

communicate directly with each other via a simple bi-directional 2-wire bus, plus power and ground. A device connects to each of the two communications wires on the bus, which are a serial data line (SDA) for the communication of data, and a serial clock line (SCL) for the control and synchronization of the communication of data between the devices.

Requiring all devices to be I²C compliant imposes significant cost on those devices. In particular, an I²C compliant device needs a microcontroller able to implement various functions.

To explain this further, the general nature of the I²C protocol will be discussed briefly. The output of an I²C compliant device is configured as an open-collector/open-drain, and one or more pull-up resistors maintain a soft logic high value on the bus while the bus is in a quiescent state. When a device desires access to the bus, the device pulls the bus to a logic low value, via the open-collector/open-drain device that is placed in a conductive state to ground potential.

A device that is connected to an I²C bus is identifiable by an address, and can operate as either a transmitter or a receiver, or both. Data transfers are effected using a master-slave communications protocol. A master is a device that initiates a data transfer and generates the clock signals to permit the transfer; any device that is addressed is considered a slave for this transfer. The data transfer can be initiated by a master to either transmit data to the slave (a write command), or to request data from the slave (a read command). For example, an output device such as an EEPROM memory for non-volatile storage is typically not able to initiate a data transfer, and therefore would be configured to only operate as a slave device. A sensor on the other hand, may be configured to operate as either a master or a slave, as the situation demands.

In the quiescent state, both the SDA and SCL bus lines are in the logic-high state. A master initiates a data transfer by asserting a transition to a logic-low state on the SDA line while the SCL line is high; this is termed a START condition. Thereafter, the master toggles the SCL line to control the synchronization of the data transfer; data value changes occur on the SDA line when the SCL clock is low, and the state of the SDA line is considered valid only when the SCL clock is high.

The data transfer for example comprises an address transmitted by the host (i.e. the device initiating the communication), nominally seven bits, followed by a read/write- not indicator. After transmitting the address and the direction of data transfer, the host releases the SDA line, allowing it to rise to a logic-high level. If a slave device recognizes its address, the slave device transmits an acknowledge signal (ACK) by pulling the SDA line low. The absence of a low signal when the host releases the SDA line, therefore, indicates a non- acknowledgement (NAK). If the address is acknowledged, via a low at SDA, the transmitting device transmits the data.

If the direction of data transfer is a "read" relative to the host, then the slave device is the transmitting device; if the direction is a "write" relative to the host, then the master device is the transmitting device. The transmitting device releases control of the SDA line, and the receiving device acknowledges the receipt of the data by asserting a logic-low value on the SDA line. If the data is acknowledged, the transmitter sends additional data.

This process continues until the entirety of the data is communicated, or until a transmitted data item is not-acknowledged. The master can subsequently reassert a START signal, and repeat the process above, or, can assert a STOP signal to terminate this data- transfer session. This STOP signal is a low-to-high transition on the SDA line while the SCL clock is high. Thereafter, any device may assume control of the bus as a master by asserting a high-to-low transition on the SDA line, as above.

It would be desirable to connect non I²C compliant devices to an I²C bus so that lower cost devices can be used, which do not need to follow the protocols and procedures of the I²C standard. More generally, it would be desirable to connect a low cost device which does not need synchronized clocked communications to connect to a bus which has a clock based (i.e. synchronized) communications protocol.

SUMMARY OF THE INVENTION

The invention is defined by claims.

Examples in accordance with an aspect of the invention provide a controller for communicating with a device over a bus, the controller supporting a first, synchronized, communications protocol over the bus, wherein the bus lines comprise at least a data line for transferring data and a clock line for communicating timing information,

wherein the controller is adapted to: analyze a signal on the clock line; and

from the signal on the clock line, determine if the device is of a first type which is compliant with the first communications protocol or of a different second type; and

communicate with the device using a communication protocol which depends on the type of device detected.

In this system, the type of signal present on a clock line of the bus is used to determine the type of device with which communication is to be made. One type is a device which operates using a clock signal, i.e. has a synchronized communications protocol, and the other type is a device which holds the clock line e.g. at ground and thus does not make use of a clock signal for communication.

The controller may therefore be adapted to detect a DC ground level on the clock line for a predetermined period as an indication that the device is of the second type. This period is a length of time which is not expected for devices of the first type.

Alternatively (and equivalently) the controller may be adapted to detect a transition on the clock line as an indication that the device is of the first type.

The first type of device is for example I²C compliant device and the protocol used for communication with a device of the first type is the I²C protocol.

The system enables the I²C communication standard to be used without modification. Using the typical implementation of the I²C standard, the clock signal may be held at a logical 0 by an I²C compliant device when clock stretching occurs; hence, detecting a DC ground level on the clock line is equivalent to identifying an infinitely stretched clock signal. This may arise in an error situation even with a device of the first type connected, but this invention makes use of an assumption that a device of the second type is in fact connected, in which the clock line is deliberately held at ground.

The protocol used for communication with a device of the second type is for example a general purpose input/output protocol. This enables connection of a lower cost simple general purpose sensor device to the I²C bus.

The bus lines preferably further comprise a ground line and a power supply line.

Examples in accordance with another aspect of the invention provide a luminaire, comprising:

a lighting system;

an external port to which an external device can be connected over a bus; and a control system as defined above, for communicating with the external device over the bus.

This aspect provides the control system in a luminaire, so that different types of external device can be connected to the luminaire.

The luminaire may further comprise the external device connected to the external bus port, wherein the external device comprises:

a motion sensor;

an IR receiver; or

a temperature, humidity or light sensor.

Thus, different type of sensor may be connected to the luminaire, typically for extending the functionality of the lighting system, for example to provide automated control features in response to ambient conditions such as temperature, ambient light level, and presence or absence of occupants in the area which is illuminated.

The external device for example connects the clock line of the bus to ground. This type of external device is of the second type, and does not need a clock signal to communicate.

For example, the external device may comprise a power terminal connected to a power line of the bus, a ground terminal connected to a ground line of the bus and a data terminal connected to the data line of the bus, and wherein the ground terminal is also connected to the clock line of the bus.

Examples in accordance with another aspect of the invention provide a method for communicating with a device connected to a bus using a controller, wherein the bus lines comprise at least a data line for transferring data and a clock line for communicating timing information, the controller supporting a first, synchronized, communications protocol over the bus, the method comprising:

analyzing a signal on a clock line of the bus; and

from the signal on the clock line, determining if the device is of a first type which is compliant with the first communications protocol or of a different second type; and communicating with the device using a communication protocol which depends on the type of device detected.

This method involves using a clock line as a mechanism for sensing a type of device connected to a communications bus.

The method may comprise: detecting a DC ground level on the clock line for a predetermined period as an indication that the device is of the second type; or

detecting a transition on the clock line as an indication that the device is of the first type.

The first type of device is for example an I²C compliant device and the protocol used for communication with a device of the first type is the I²C protocol, and the protocol used for communication with a device of the second type is a general purpose input output protocol.

At a device of the second type which is connected to the bus, a power terminal of the device may be connected to a power line of the bus, a ground terminal of the device may be connected to a ground line of the bus, a data terminal of the device may be connected to the data line of the bus, and the clock line of the bus may be coupled to the ground line.

The invention may be implemented in software at the main control system, e.g. the luminaire controller.

BRIEF DESCRIPTION OF THE DRAWINGS

An example of the invention will now be described with reference to the accompanying diagrams, in which:

Fig. 1 is used to explain the I²C communication protocol briefly; Fig. 2 is used to explain clock stretching in the I²C protocol;

Fig. 3 shows a luminaire with a connected device of a first type, and also shows a device of the second type;

Fig. 4 shows a first communications method; and

Fig. 5 shows a second communications method; and

Fig. 6 shows a computer which may be used to implement the required processing.

DETAILED DESCRIPTION OF THE EMBODIMENTS

The invention provides a control system for communicating with a device over a bus, the control system supporting a first communications protocol over the bus which uses clocked communications. The system has connection terminals for connection to lines of the bus, wherein the bus lines comprise at least a data line for transferring data and a clock line for communicating timing information. A signal on the clock line is analyzed, and from the signal on the clock line, it is determined if the device is of a first type which is compliant with the first communications protocol or of a different second type. Communication with the device then using a communication protocol which depends on the type of device detected.

In this system, the type of signal present on a clock line of the bus is used to determine the type of device with which communication is to be made. One type is a device which operates using a clock signal and the other type is a device which holds the clock line e.g. at ground and thus does not make use of a clock signal for communication.

The device which uses the first communications protocol is typically a more expensive type of device. However, the system can communicate with other general purpose types of device based on analysis of the clock signal.

The invention will be described for a system which uses the I²C protocol as the first communications protocol. It is not sufficient simply to detect the presence of a regular clock as evidence of an I²C compliant device, because a non-regular clock may arise even for I²C compliant devices. In particular, the I²C protocol supports clock stretching.

The invention is based on on detection of a ground level as the clock signal. This could be caused by an infinitely long clock stretch on the I²C bus. However, it would require an I²C device in an error state to bring the bus into this condition. The invention instead assumes that the error condition is not at hand. Even if this assumption happens to be wrong, the sensor function will simply not work (or be considered absent), which can then be discovered and reported on the network.

The I²C protocol will be explained further as well as the clock stretching function. For operating a slave over the I²C, bus only six simple operating codes are required for transmitting or receiving bits of information. These operating codes are: the start bit; a slave address; a read/write bit which defines whether the slave is a transmitter or receiver; an acknowledge bit; message bits divided into 8-bit segments; and the stop bit.

If both the data and clock lines are HIGH, the bus is not busy. To attain control of the bus, the start condition (discussed above) is needed from a master; and to release the lines, a stop condition (discussed above) is required. The start condition is defined as a HIGH-to-LOW transition of the data line while the clock line is in a HIGH state. The stop condition is defined as a LOW-to-HIGH transition of the data line while the clock line is in a HIGH state.

The master always generates the start and stop conditions. After the start condition, the bus is in the busy state. The bus becomes free after the stop condition. After a start condition one data bit is transferred during each clock pulse. The data must be stable during the HIGH-period of the clock. The data line can only change when the clock line is at a LOW level. Normally, each data transfer is implemented with 8 data bits and 1

acknowledge bit and it is acknowledged. The master generates the acknowledge clock pulse.

The transmitter releases the data line (SDA-HIGH) during the acknowledge clock pulse. If there was no error detected, the receiver will pull down the SDA line during the HIGH period of the acknowledge clock pulse.

If a slave receiver is not able to acknowledge, the slave will keep the SDA line HIGH and the master can then generate a STOP condition to abort the transfer. If a master receiver keeps the SDA line HIGH during the acknowledge clock pulse, the master signals the end of data transmission and the slave transmitter releases the data line to allow the master to generate a STOP-condition.

Figure 1 shows a timing diagram for an I²C communication. Data transfer is initiated with a START bit 10 which is represented by SDA being pulled low while SCL stays high.

In step 1 1, the SDA line sets the first data bit level while keeping SCL low. The data is received when the SCL line rises in step 12 for the first bit. The next bits are set and received in sequence (e.g. steps 13,14 and finally 15.16). Each time, the SDA line transitions while SCL is low, and the data is read while SCL is high.

Step 17 represents an acknowledgement ACK.

A STOP bit 18 is represented by the SDA line being pulled high while the SCL line is high.

Slow peripherals and slow microcontrollers might not be able to keep up with the normal clock speed of an I²C bus. Therefore, the I²C bus protocol allows slower devices to stretch the clock at the bit level until they finish their transaction. Therefore, the slower device screens the clock signal SCL and if this signal is low it pulls down the clock signal SCL to stretch the clock pulse until the data is stable on the data lines. A slave will perform bit level clock stretching if the clock speed as applied by the master is too high for the slave to cope with. Typically, the slave would need to apply this sort of clock stretching at every bit.

A clock stretch may also be implemented at the byte level. For example this may be needed if a byte has been successfully received but additional time is needed before the slave device is ready to receive the next byte. An example is shown after the

acknowledgement 17 after which the SCL low state is prolonged.

Figure 2 shows the clock stretching at the bit level, whereby the low phase of The stretch 20 is accomplished by the slave device, and the master detects this clock stretching so that the original clock sequence can be resumed once the clock (which was released by the master device at the start of the period 20) has gone high.

However, a prolonged DC level on the clock line will only arise in the event of an error. It can thus be used to determine that a different type of device is connected.

Figure 3 shows a luminaire 30 which comprises a control system for communicating with an external device 31 over a bus 32.

The luminaire has connection terminals 33 for connection to lines of the bus 32, wherein the bus lines comprise at least a data line SDA for transferring data, a clock line SCL for communicating timing information, a power line Vcc, for example 5V DC, and a ground line GND. The connection terminals 33 for example together form an RJ-1 1 connector.

The luminaire 30 is in preferred examples for implementing the I²C bus protocol, but as explained above it may implement other clocked communications protocols.

The luminaire 30 comprises a light source 34, such as an LED array, a light source driver circuit 36 such as an LED driver, and a controller 38.

The controller 38 enables the luminaire to communicate with other luminaires over a bus 39 so that the luminaire is part of a control system network. The network allows luminaires to communicate and it allows remote upgrading of the luminaire control software, resident in the controller 38. The controller 38 gives the luminaire intelligence. For example the the luminaire can, based on environmental conditions, autonomously change its light output.

To detect the environmental conditions, the controller needs input from a sensing device, and this is the role of the external device 31. Depending on the system floor plan, only a subset of the luminaires may actually need a sensor function. The other luminaires can function based on information that is coming to them from the network bus 39. If a sensing function is needed in a particular luminaire, the RJ-1 1 connector 33 is used to connect a sensing device during installation of the system.

The external device 31 for example comprises a so-called ILB (Intra

Luminaire Bus) sensor. An ILB device has a local microcontroller and communicates using a protocol stack that uses a master-transmitter / slave-receiver I²C protocol in its transport layer. Thus, a known luminaire has a standardized RJ-1 1 bus in the form of the I²C data and clock lines plus ground and sensor power supply. The ILB protocol stack allows multiple (sensing) functions such as occupancy detection, temperature/light level/humidity measurement, infra-red remote control command reception. These make it a powerful and flexible system, but also a complex and expensive system.

For some luminaire sensor functions, the microcontroller and ILB mechanism is actually not needed and thus too expensive.

To modify the system so that non-I²C compliant external devices may also be connected, there is a desire to avoid changes to the hardware of the controller 38, and also to avoid the need to change to the existing ILB external sensor software and hardware.

However, controller software update is acceptable, as this can be implemented even for already installed system. There also no particular need for hot plugin capability, because in this particular application, the full network configuration is established at installation. If system configuration changes are needed, it is acceptable to require a system reboot.

The controller 38 implements the I²C (ILB) system for communication over the bus 32 as well as the network protocols for communicating over the bus 39. In addition, the controller 38 is adapted to analyze a signal on the clock line SCL resulting from the connection of the external device 31 to the bus.

Based on this analysis, the controller can determine if the device is of a first type (which is an I²C compliant type in the preferred example) or of a different second type. The communication with the device may then be selected to use a communication protocol which depends on the type of device detected.

The device 31 is shown an as I²C compliant device, and it has an I²C processor 40. For communication with an I²C compliant device, the standard protocol is used for the communication, without needing any modification. The device 31 has input pins

corresponding to each line of the bus 32. Thus, the device 31 has a power terminal connected to the power line Vcc of the bus, a ground terminal connected to the ground line GND of the bus, a data terminal connected to the data line SDA of the bus and a clock terminal connected to the clock line SCL of the bus.

Figure 3 also shows an external device 41 of the second type. The device 41 of the second type is a simple sensor which does not support the first protocol. Instead, it may for example simply provide sensor data to an output pin "Data". An example is an infrared receiver (e.g. remote control receiver). To receive data from this device, the data line SDA needs to be configured by the control system 30 as a general purpose input/output pin.

The device 41 has a power input pin which connects to the Vcc line of the bus 32, a ground pin which connects to the GND line of the bus 32 and a data output pin. This data output pin connects to the SDA data line. The device 41 does not need to receive an external clock signal.

Instead, the device 41 couples the ground line GND to the clock line SCL. This may be an internal connection within the device as shown, but it may instead be made by an external connector, for example which provides a four-to-three coupling between four pins of the bus 32 and three output pins of the device 41.

This means that a DC ground level is provided on the clock line SCL by the device 41. A DC ground level may be interpreted by the controller 38 as infinite clock stretching, as will be understood from Figure 2, and this is interpreted as indicating that the device is not I²C compliant.

For a device which is determined to be of the second type, for which a general purpose interface protocol is to be used, the data is received as if coming from an on-board sensor.

The controller software is updated to provide a local decoder for the output of the external device, using the SDA pin as as general purpose input output pin (GPIO). This means data can be received in an asynchronous and non-clocked manner.

A monitor is implemented for monitoring the state of the SCL pin. The monitoring takes place during a predetermined time period, for example 50ms. This time period is sufficient to exclude any expected amount of clock stretching of an I²C compliant device.

If during the monitoring period the SCL pin has a transition to a high level, a decision is made to start the ILB protocol stack (i.e. the I²C protocol). If there is no such transition, a decision is made to use the GPIO decoder. Thus, the controller detects a DC ground level on the clock line for a predetermined period as an indication that the device is of the second type; or it detects a transition on the clock line as an indication that the device is of the first type. The default is that the device is of the second type.

Figure 4 shows the method of determining the type of device from which communications are received over the bus. This example is for a method that is carried out at reboot of the controller.

In step 44, the controller 38 is configured to receive data from both the clock and data lines, in the general purpose mode. In step 45, the signal on the clock line is analyzed. This takes place for a maximum time period T such as 50ms.

During the time period T, it is determined if there have been any transitions in the signal on the clock line, in step 46. Thus, it is determined if the clock line is a DC level or if there is information present. As soon as a transition is detected to a clock high, the monitoring can be terminated, so that the full duration is not needed in the case of a device of the first type. Thus, the time period T is a maximum time period.

Based on this determination, it is possible to tell if a communicating device is of a first type in which clocked communication is employed (e.g. an I²C compliant device) or of a different second type (e.g. a simple sensor providing an output on the data line).

If no transitions arise, it is determined in step 47 that the device is of the second type and communication then takes place in step 48 using a general purpose communications protocol (which was already set in step 44). This is communication over a single wire system which is not explicitly clocked.

If a transition did arise (in which case the monitoring was terminated earlier than after time T), it is determined in step 49 that the device is of the first type and communication takes place in step 50 using the first protocol. This is communication over a two wire clocked system.

The devices which operate according to the first protocol, i.e. the I²C devices, for example comprise sensors or other devices with some configurability over the two wire communication system, or devices which combine multiple functions.

The devices which can operate according to the second protocol, i.e. a general purpose communication protocol, are those that require only single wire communication and for example do not need dynamic configurability.

The example above is able to distinguish between two sensor types (I²C and not I²C). However, the idea can be extended to distinguish between different types of second device. For example protocol information may be encoded on the SCL line, of which a permanent LOW-state is only one of the many possible options, to allow detection of what alternate sensor type is connected from those that are available.

This would of course add some complexity to the simple sensors.

For the luminaire example above, it is sufficient for the detection routine (of Figure 4) to take place only at a reboot, which is carried out after a change in the system configuration. For example, in the case of a luminaire, there are not frequent dynamic reconfigurations.

In the initial stage after a reboot, the controller knows a few things. It may have a sensor connected. If so, it needs to take a decision how to service this sensor, but also it must be able to service this sensor within a certain time. This maximum time is the time period T. The longer the period T, the longer it may take for the system to be up and running but also the less chance of a clock stretch of an I²C device being misinterpreted.

However, a periodic test may be carried out for systems which are reconfigured in a more dynamic way. In this case, a modified version of the routine of Figure 4 may be kept running indefinitely, as it then allows the controller to enter any mode at any time, corresponding to the state of the clock line.

Figure 5 shows this alternative monitoring method.

In step 44a, the controller is set to the GPIO mode if the clock line SCL is at GND, otherwise the I²C protocol is set. Note that the latter also occurs without a sensor connected.

If the GPIO mode is set, monitoring is carried out in step 45a to detect if SCL goes high. When it does, then an I²C device is detected in step 49a and the controller is set to the I²C mode.

If the GPIO mode is set, monitoring is carried out in step 45b to detect if SCL remains at DC ground for the time period T. When it does, then a GPIO device is detected in step 49b and the controller is set to the GPIO mode.

The time period T may be longer than for Figure 4, for example 1 second or multiple seconds.

When a GPIO device is detected the method passes to step 45 a (to listen out for an I²C device) and when an I²C device is detected the method passes to step 45b (to listen out for a GPIO device).

This method can thus run continuously.

The response time of the loop part is not critical, as it takes at least a second or so to replace the sensor, and every replacement has an intermediate or prolonged I²C state from the moment the old sensor is unplugged.

The alterations to a standard I²C controller may be implemented as software running on a computer, which is the already existing controller 38 of the system. Figure 5 illustrates an example of a computer 60 for implementing the controller 38 described above.

Generally, in terms of hardware architecture, the computer 60 may include one or more processors 61, memory 62, and one or more I/O devices 63 that are communicatively coupled via a local interface (not shown). The local interface can be, for example but not limited to, one or more buses or other wired or wireless connections, as is known in the art. The local interface may have additional elements, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communications. Further, the local interface may include address, control, and/or data connections to enable appropriate communications among the aforementioned components.

The processor 61 is a hardware device for executing software that can be stored in the memory 62. The processor 61 can be virtually any custom made or

commercially available processor, a central processing unit (CPU), a digital signal processor (DSP), or an auxiliary processor among several processors associated with the computer 60, and the processor 61 may be a semiconductor based microprocessor (in the form of a microchip) or a microprocessor.

The memory 62 can include any one or combination of volatile memory elements (e.g., random access memory (RAM), such as dynamic random access memory (DRAM), static random access memory (SRAM), etc.) and non-volatile memory elements (e.g., ROM, erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), programmable read only memory (PROM), tape, compact disc read only memory (CD-ROM), disk, diskette, cartridge, cassette or the like, etc.). Moreover, the memory 62 may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory 62 can have a distributed architecture, where various components are situated remote from one another, but can be accessed by the processor 61.

The software in the memory 62 may include one or more separate programs, each of which comprises an ordered listing of executable instructions for implementing logical functions. The software in the memory 62 includes a suitable operating system (O/S) 64, compiler 65, source code 66, and one or more applications 67 in accordance with exemplary embodiments.

The application 67 comprises numerous functional components such as computational units, logic, functional units, processes, operations, virtual entities, and/or modules.

The operating system 64 controls the execution of computer programs, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services.

Application 67 may be a source program, executable program (object code), script, or any other entity comprising a set of instructions to be performed. When a source program, then the program is usually translated via a compiler (such as the compiler 65), assembler, interpreter, or the like, which may or may not be included within the memory 62, so as to operate properly in connection with the operating system 64. Furthermore, the application 67 can be written as an object oriented programming language, which has classes of data and methods, or a procedure programming language, which has routines, subroutines, and/or functions, for example but not limited to, C, C++, C#, Pascal, BASIC, API calls, HTML, XHTML, XML, ASP scripts, JavaScript, FORTRAN, COBOL, Perl, Java, ADA, .NET, and the like.

The I/O devices 63 may include input devices such as, for example but not limited to, a mouse, keyboard, scanner, microphone, camera, etc. Furthermore, the I/O devices 67 may also include output devices, for example but not limited to a printer, display, etc. Finally, the I/O devices 63 may further include devices that communicate both inputs and outputs, for instance but not limited to, a NIC or modulator/demodulator (for accessing remote devices, other files, devices, systems, or a network), a radio frequency (RF) or other transceiver, a telephonic interface, a bridge, a router, etc. The I/O devices 63 also include components for communicating over various networks, such as the Internet or intranet.

When the computer 60 is in operation, the processor 61 is configured to execute software stored within the memory 62, to communicate data to and from the memory 62, and to generally control operations of the computer 60 pursuant to the software. The application 67 and the operating system 64 are read, in whole or in part, by the processor 610, perhaps buffered within the processor 61, and then executed.

When the application 67 is implemented in software it should be noted that the application 67 can be stored on virtually any computer readable medium for use by or in connection with any computer related system or method. In the context of this document, a computer readable medium may be an electronic, magnetic, optical, or other physical device or means that can contain or store a computer program for use by or in connection with a computer related system or method.

The invention is not limited to luminaires, but may be applied to other networks of devices, where the devices have an external port for connection of local sensors. The invention may be applied to any control system in which sensing or external triggering plays a role. Home automation, factory automation and transport automation, are examples.

Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measured cannot be used to advantage. Any reference signs in the claims should not be construed as limiting the scope.

Claims

CLAIMS:

1. A luminaire comprising:

a light source,

a light source driver circuit, and

a controller for communicating with a sensor over a bus,

wherein the controller is arranged for supporting a first, synchronized, communications protocol over the bus, wherein the bus lines comprise at least a data line (SDA) for transferring data and a clock line (SCL) for communicating timing information, and

wherein the controller (38) is adapted to:

analyze a signal on the clock line; and

from the signal on the clock line, determine if the sensor is of a first type which is compliant with the first communications protocol or of a different second type; and

communicate with the sensor using a communication protocol which depends on the type of sensor detected.

2. A luminaire as claimed in claim 1, wherein the controller is adapted to:

detect a DC ground level on the clock line for a predetermined period as an indication that the device is of the second type; or

detect a transition on the clock line as an indication that the device is of the first type.

3. A luminaire as claimed in any preceding claim, wherein the first type of sensor is an I²C compliant sensor and the first communications protocol is the I²C protocol.

4. A luminaire as claimed in any preceding claim, wherein the protocol used for communication with a sensor of the second type is a general purpose input/output protocol.

5. A luminaire as claimed in any preceding claim, wherein the external port comprises connection terminals for connection to the data line (SDA), the clock line (SCL) a ground line (GND) and a power supply line (Vcc) of the bus.

6. A luminaire as claimed in claim 5, further comprising the sensor, wherein the sensorcomprises:

a motion sensor;

an IR receiver; or

a temperature, humidity or daylight sensor.

7. A luminaire as claimed in claim 6, wherein the sensor (31,41) connects the clock line of the bus to ground.

8. A luminaire as claimed in claim 7, wherein the sensor (31 ;41) comprises a power terminal connected to a power line of the bus, a ground terminal connected to a ground line of the bus, a data terminal connected to the data line of the bus, and wherein the ground terminal is also connected to the clock line of the bus.

9. A luminaire as claimed in any preceding claim, wherein the sensor enables automated control features of the luminaire in response to ambient conditions.

10. A luminaire as claimed in any preceding claim, wherein data received from a sensor of the second type is received as data coming from an on-board sensor.

1 1. A luminaire as claimed in any preceding claim, wherein a sensor of the second type encodes protocol information on the SCL line, and wherein the controller is adapted to detect a sensor sub type from a set of sensor sub types based on the protocol information.

12. A luminaire as claimed in any preceding claim, wherein the determination of the sensor type is performed periodically.

13. A lighting system comprising a set of luminaires, at least one luminaire according to any preceding claim, connected together over a network.

14. A lighting system according to claim 10, wherein at least one luminaire of the set of luminaires receives sensing data from the at least one luminaire.