This application is the U.S. National Phase application under 35 U.S.C. § 371 of International Application No. PCT/EP2020/067281, filed on Jun. 22, 2020, which claims the benefit of European Patent Application No. 19183531.3, filed on Jul. 1, 2019. These applications are hereby incorporated by reference herein.
The invention relates to the field of power-on restart systems for wireless network devices, such as—but not limited to—wirelessly connected luminaire devices in Zigbee networks for use in various different applications for home, office, retail, hospitality and industry.
The use of wireless networks with smart network devices (e.g., luminaire devices such as smart light bulbs) makes it possible to automatically adjust a non-network function of devices (e.g. lighting, sensing etc.) based on other devices turning on, remotely controlling non-network functions, linking settings of non-network functions to motion detection, etc.
Such wireless networks of smart network devices may be built on top of the ZigBee protocol. ZigBee itself is built on top of a low-power radio network called IEEE 802.15.4.
United States patent U.S. Pat. No. 9,883,570 B1 discloses a protocol for lighting control via a wireless network, wherein a monitor lighting control device receives a state change event message that includes a payload specifying: (i) a state change event of an occupancy, audio, or daylight sensor, or a switch to turn lighting on/off, dim up/down, set scene or the like; (ii) an identifier of a member lighting control device that detected the state change event; and (iii) a lighting control group identifier of a lighting control group that includes the member lighting control device and the monitor lighting control device. The monitor lighting control device transmits an acknowledgement of receipt of the state change event message to the member lighting control device.
Zigbee devices offer reduced power consumption and cost, together with mesh networking capability, which make them suitable for use in large-scale deployments. Examples of application of Zigbee mesh networks include home automation, building automation, retail services, smart energy, and wireless indoor lighting systems.
However, problems have been faced when the network devices are used in areas with unstable power grids and they are cut from power rather frequently, causing the network devices to return to an undesired default state. For markets such as India this is highly problematic, as power cuts are almost a daily occurrence. But even in markets such as the United States or Australia, this leads to issues as power failures happen frequently (in some areas).
In the case of home lighting networks, most of the complaints are from customers that are woken up in the middle of the night, because the power to the luminaire devices was lost and restored. This causes the light to switch on at maximum brightness, waking up people sleeping in that room. Customers also complain that when they are away from home their bulbs have stayed on for a lengthy period of time, due to a power failure.
However, it was a conscious choice to let the network devices start up at a predetermined default state (e.g. 2700K @ full brightness). A reason may be that the network devices are typically not directly mains powered, but via a “legacy” wall switch. By always starting up at the desired default state, the legacy wall switch can still be used to get the network device to produce a functional output (e.g. functional light level). If the network devices would always go to the previous setting (which might be OFF, or at very low brightness, or at a saturated colour in case of a colour capable luminaire device), it would require usage of e.g. an additional application or remote control to let the network device produce the desired functional out after manual switch-on by the wall switch.
It is an object of the present invention to provide an adaptive restart procedure for network devices in wireless networks.
This object is achieved by an apparatus as claimed in claim 1, by a network device as claimed in claim 11, by a method as claimed in claim 12, and by a computer program product as claimed in claim 13.
According to a first aspect, an apparatus is provided for controlling a restart mode of a network node in a wireless network, wherein the apparatus comprises: a power-up detector for detecting a power-up event of the network node;
According to a second aspect, a network device comprising the apparatus of the first aspect and a non-network function is provided.
According to a third aspect, a method of controlling a restart mode of a network node in a wireless network is provided, wherein the method comprises:
Finally, according to a fourth aspect, a computer program product is provided, which comprises code means for producing the steps of the above method according to the third aspect when run on a computer device.
Accordingly, it can be determined at the network node whether or not the network node has experienced a power-cycle resulting from a power-outage and/or whether or not it is the result of a regular power-cycle, and in line therewith a proper course of action (e.g. restart mode) can be selected. To achieve this, network devices transmit power-up messages when powering on and a concerned network device checks whether there are sufficient of these messages, in which case it was likely a power outage. Based on the result of detection, an expected behavior for end users can be selected, so that the connected network device can behave accordingly.
According to a first option, the plurality of restart modes may at least comprise a safety mode which ensures a proper operation of a non-network function of the network node, which is factory configured and a power failure mode which restores a previous state of the non-network function prior to the power-up event. This ensures that the restart mode automatically selected by the network devices properly matches the expectations of the user.
According to a second option which may be combined with the first option, the network device may be a luminaire device and the non-network function may be a lighting function. Thereby, luminaire devices of lighting networks can be configured to restore a proper and expected lighting behavior in dependence on the reason of a power failure.
According to a third option which may be combined with the first or second option, the control unit may be adapted to initiate a transmission of at least one power-up message to the wireless network in response to the detection of a power-up event by the power-up detector. This measure ensured that other network devices are informed of the power-up event and can determine whether a concurrent power-up event at their location is the result of a user-intended switch-on or an unintended power failure.
According to a fourth option which can be combined with any of the first to third options, the control unit may be adapted to select a power failure mode if the output of the message detector indicates that a predetermined number of power-up messages has been received within a predetermined time period. The predetermined number can be selected based on the local environment of the network device to ensure that a reliable discrimination between an intentional switch-off and an unintentional power failure can be made.
According to a fifth option which can be combined with any of the first to fourth options, the control unit may be adapted to restore a previous state of a non-network function of the network device prior to the power-up event, when the power failure mode is selected. This measure ensures that an expected state of non-network function of the network device is restored in case of a power-up event after an unintentional power failure.
According to a sixth option which can be combined with any of the first to fifth options, the power-up message may be selected from a ZigBee link status massage, a ZigBee device announce message, a ZigBee inter-PAN broadcast or unicast message, a ZigBee broadcast message, a ZigBee multicast message, a ZigBee unicast message and a raw 802.15.4 message sent to all previously known neighbor devices. Thus, the proposed solution may easily be implemented in ZigBee networks based on available types of messages.
According to a seventh option which can be combined with any of the first to sixth options, the message detector may be adapted to distinguish between different sending network nodes by a source address or other identifier included in the power-up message. Thereby, reliability can be increased, since only such power-up messages are considered, that are received from different other networks nodes.
According to an eighth option which can be combined with any of the first to seventh options, the message detector may be adapted to ignore a power-up message with at least one of a signal quality or strength above a predetermined threshold, a transmitter identifier that indicates a network device locate between the same light switch as the network node, and an identifier that indicates the same light switch group as the network node. Thereby, reliability can be further increased, since only such power-up messages are considered, that are likely to be received from other networks nodes not connected to the same light switch.
According to a ninth option which can be combined with any of the first to eighth options, the control unit may be adapted to ignore a power-up message received from another network node based on a previous behavior of that other network node in comparison to the network node. Thereby, reliability can be further increased, since only such power-up messages are considered, that are likely to be received from other networks nodes not connected to the same light switch.
According to a tenth option which can be combined with any of the first to ninth options, the power-up message may comprise information about a type or role of device (e.g. luminaire device, sensor device, bridge device etc.) that has transmitted the power-up message. Thereby, reliability can be further increased, since only such power-up messages are considered, that are likely to be the result of the same cause of power outage.
According to an eleventh option which can be combined with any of the first to tenth options, the message detector may be adapted to detect a power failure report received by the network device. Thereby, reliability can be further increased, since other relevant types messages are considered, that indicate a power outage.
It is noted that the above apparatus may be implemented based on discrete hardware circuitries with discrete hardware components, integrated chips, or arrangements of chip modules, or based on signal processing devices or chips controlled by software routines or programs stored in memories, written on a computer readable media, or downloaded from a network, such as the Internet.
It shall be understood that the apparatus of claim 1, the network device of claim 11, the method of claim 12, and the computer program product of claim 13 may have similar and/or identical preferred embodiments, in particular, as defined in the dependent claims.
It shall be understood that a preferred embodiment of the invention can also be any combination of the dependent claims or above embodiments with the respective independent claim.
These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter.
In the following drawings:
Embodiments of the present invention are now described based on a wireless lighting network as an example of a wireless network and luminaire devices as an example of wirelessly controlled network devices.
Typically, energy is generated and transported to the home. In the home, there is a main fuse box, and electric equipment may be connected directly to the home mains net, but often, especially for bulbs, they are wired behind a mains (light) switch. This light switch is often located close to the entrance of a room, to make it easy for people walking in or out of the room to switch lights on and off.
The luminaire devices 20, 30 are equipped with a wireless communication interface allowing them to transmit and receive wireless messages for remote control and/or signaling purposes.
First luminaire devices 30 are wired directly to the main power supply 100, while second luminaire devices 20 are wired to the main power supply 100 via a light switch 10. This allows convenient switch-off of the light by the second luminaire devices 20, although doing that renders the wirelessly controllable second luminaire devices 20 uncontrollable from the lighting system. When the light switch 10 is switched back on, the second luminaire devices 20 are powered again. At that moment, the control unit (e.g. software) in the wirelessly controllable second luminaire devices 20 needs to decide what to do: either assume a user flipped the light switch 10 and therefore needs functional light or revert to the settings the wirelessly controllable second luminaire devices had before the power was cut. This may however be a low dimming level, a saturated color, or even off-state (standby). This is typically not what the user expects when flipping the light switch 10.
However, in other situations where the power is cut, for example a failure in the home's main fuse box, or a generic power outage caused by a problem in generating energy at the power plant or the transportation to the home, the expected behavior may differ. In such cases, it is more useful for the user if the wirelessly controllable luminaire devices 20 would go to the last state they had before the power outage.
According to various embodiments, a restart control function which may be called “User-Defined Start-Up” may be introduced, that lets the user choose what should happen after a power failure.
As an example, users can choose (per light, or may be aggregated per room or home) between:
Power fail mode is mainly intended for markets like India where the power grid is not so stable. But also, many users in the US and EU have complained that “the light does not remember its last state”.
However, the power fail mode raises the problem that users can no longer switch a light from a standby state to an on state anymore with the legacy wall switch 10.
This problem can however be overcome by having the wirelessly controllable luminaire devices, with a high level of accuracy, determine whether their power was toggled because of a mains power failure, or because of the user toggling the light switch 10.
According to various embodiments, this can be accomplished by letting the wirelessly controllable luminaire devices transmit a wireless power-up message upon power up. The wirelessly controllable luminaire devices may then also listen for this power-up message for a predetermined amount of time after power-up.
If a wirelessly controllable luminaire device receives such a power-up message within a pre-defined time after power-up (not being transmitted by itself), it knows that other wirelessly controllable luminaire devices were also powered up at the same time, and it assumes it was because of a mains power failure. The wirelessly controllable luminaire device could then e.g. go back to the previous state it was in.
Otherwise, If the wirelessly controllable luminaire device does not receive such a power-up message within this pre-defined time after power-up, it was the only wirelessly controllable luminaire device being powered up at that time, and it assumes it was because of a legacy power switch toggle by a user. The wirelessly controllable luminaire device could then e.g. switch to a default full brightness (e.g. default brightness at e.g. 2700K).
The network device of
According to
Furthermore, the network device comprises a power-up detector (PUD) 22 which detects a power-up after a loss of power supply to the network device (e.g. power-off by a user or due to a power failure).
It is noted that both power-up message detector 26 and power up detector 22 may be integrated in the power-up control unit 21, e.g., as dedicated subroutines of a power-up control program.
Based on information obtained from the power-up detector 22 and the power-up message detector 26 or the corresponding subroutines, the power-up control unit 21 controls a power-mode setting unit (PDMS) 24 to set a predetermined power-up mode in accordance with a ground of power loss determined from the information obtained from the power-up detector 22 and the power-up message detector or the corresponding subroutines.
Thereby, an adaptive restart mode after power-up can be automatically selected based on the circumstances of the power loss.
In step S300, the procedure is started in response to a detection of a power-up situation. Then, in step S301, a radio unit (e.g. the transceiver 28 of
Then, the procedure branches off into a transmission-related branch (steps S302 to S306) and a reception-related branch (steps S307 to S312) which might be processed concurrently or alternately.
In step S302, a transmit counter is set to zero and the procedure proceeds to step S303 where a first power-up message (e.g. “Just Started”) is broadcast through the network. Then, in step S304, the transmit counter is incremented by one and a predetermined or random delay period is introduced in step S305. Thereafter, in step S306, the procedure checks whether the value of the transmit counter is below a preset or random number of transmissions. If so, the procedure jumps back to step S303 and a second power-up message is broadcast with a subsequent incrementation of the transmit counter in step S304 and delay period in step S305. This loop of steps S303 to S306 is continued until the procedure determines in step S306 that the value of the transmit counter has reached the preset or random number of transmissions.
If the present number of transmissions of the power-up message have been broadcast, the transmission-related branch of the procedure ends.
Additionally, in the first step S307 of the reception-related branch, the procedure checks whether a power-up message (e.g. “Just Started”) has been received from another network device. If so, the procedure continues with step S308 and a receipt counter is incremented by one. Otherwise, if no power-up message has been received from another network device, the procedure jumps to step S309 and checks whether a predetermined start-up time has been reached. If not, the procedure jumps back to step S307 and checks again whether a power-up message has been received meanwhile and increments the receipt counter in the affirmative case.
Moreover, if the receipt counter is not zero, the procedure also checks whether the received message has been received from a new network device and only increments the receipt counter, if a power-up message has been received from another network device, not yet registered so far as having just started up. Thereby, it can be ensured that power-up messages received from different network nodes are counted only.
The loop S307 to S309 is continued until the predetermined start-up time period has been reached. Then, the procedure continues with step S310 and checks whether the receipt counter has reached a preset threshold number of power-up messages. If so, the procedure assumes that a power failure has happened and branches to step S312 where a power-failure start-up mode or behavior is applied. Otherwise, if the preset number of messages has not been reached within the start-up period, the procedure assumes that power has been switched off by a user and branches to step S311 where a legacy-switch start-up mode or behavior is applied.
It is noted that the delay period of step S305, the preset number of step S306, the predetermined start-up time of step S309, and/or the preset threshold number of step S310 could also be calculated based on at least one external factor (e.g. level of interference, received signal quality, total number of network devices or other suitable factors).
Thus, the procedure of
The wireless power-up message (e.g. “Just Started”) may be a new wireless message created for this purpose or an existing wireless message of the network system, that is re-purposed (e.g. an empty link status message or a device announce message sent by ZigBee devices upon start-up).
As another option, the wireless power-up message (e.g. “Just Started”) may be a raw 802.15.4 message or a ZigBee Inter-PAN (Personal Area Network) broadcast message. Although it is an Inter-PAN message, its scope can still be limited to the current PAN by setting the destination PAN identification (ID) to the current network's PAN ID instead of the more typical of setting it to “0xFFFF” (meaning all PANs). Thereby, the Inter-PAN message does not leave the PAN.
Zigbee Inter-PAN messages are not re-transmitted by other nodes while networked messages are re-transmitted by nodes that are in the same network (e.g. PAN).
Further options for the power-up message are a ZigBee Inter-PAN unicast message (sent to all previously known neighbors), a ZigBee broadcast message, a ZigBee multicast message, a ZigBee unicast message (sent to all previously known neighbors). The wireless power-up message (e.g. “Just Started”) may be transmitted once at a pre-defined (possibly randomized) time after start-up (i.e. preset number in step S306 of
As a further option, network devices that receive the wireless power-up message and know they were not recently power cycled, could send a response message to the sender of the power-up message, indicating that it was not a mains power failure.
In case more than one network device (e.g. wirelessly controllable luminaire device) are connected behind the same legacy light switch (e.g. as depicted in
As a still further option, wirelessly controllable network devices may ignore power-up messages with a signal strength (e.g. RSSI (Received Signal Strength Indication)) above a certain threshold, assuming these messages come from wirelessly controllable network devices that are close (and thus likely part of the same luminaire or light switch group).
As a still further options, wirelessly controllable network devices may detect that certain other wirelessly controllable network devices always power up at the same time as themselves (using the power-up message) and may use that information to ignore the power-up messages received from those.
In more refined embodiments, the wirelessly controlled network device could also enter into a learning mode, wherein it checks which devices report normally (e.g. when a device is in a group). In that case, the network device can determine that it is not an issue if e.g. four other lamps report power-up, but it might be an issue if more than four report power-up.
Alternatively, or additionally, wirelessly controllable network devices could report more information, not only that they just powered up, but also what type of device they belong to. E.g., it is not common that a sensor node reports power-up at the same time as a lighting node does. Additional information or optional fields of the power-up message could be an intermediate counter value of the received power-up messages from the reporting node and/or the switch group to which the reporting node belongs. Such additional information could help in determining the reason for a power failure. Alternatively, or additionally, a second phase could be implemented, where a network device (e.g. a bridge device which is typically not located behind a light switch) that detects a power outage reports this using a further broadcast message, in order to corroborate the finding for other network devices. This option could increase reliability because when this network device was not recently power-cycled, it could respond to the power-up messages by broadcasting a message (e.g. “not a power failure”) that indicates that no power failure has occurred. For all above cases, it is also relevant to consider the situation where there is a bridge device with multiple lamps in a mesh, or whether there is just a mesh of peer devices. In the first case, the threshold of the required number of received power-up messages may need to be suitably increased to cover all dependent network devices controlled by the bridge device.
The flowchart in
To summarize, methods and apparatuses have been described for automatic detection whether a wirelessly connected network device with a non-network role was powered on by using a legacy (wall) switch or after recovery of a power failure. Based on the result of detection, an expected behavior for end users is selected, so that the connected network device can behave accordingly.
While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive. The invention is not limited to the disclosed embodiments. The proposed restart control procedures can be applied to and possibly standardized in other types of multi-hop networks and with other types of messages and control fields. Moreover, the invention can be applied in any product that implements a wireless network (e.g. Zigbee or others). The present invention is equally applicable to network devices of any other wireless technology (e.g. BLE, Infrared (IR), near field communication (NFC), wireless local area communication (Wi-Fi), Zigbee PRO, Thread, Zwave, WirelessHART, CityTouch, IP500, other 802.15.4 networks, or also for 802.11 networked devices and any other mesh or tree-based technology).
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. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. The foregoing description details certain embodiments of the invention. It will be appreciated, however, that no matter how detailed the foregoing appears in the text, the invention may be practiced in many ways, and is therefore not limited to the embodiments disclosed. It should be noted that the use of particular terminology when describing certain features or aspects of the invention should not be taken to imply that the terminology is being re-defined herein to be restricted to include any specific characteristics of the features or aspects of the invention with which that terminology is associated.
A single unit or device may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.
The described operations like those indicated in
Number | Date | Country | Kind |
---|---|---|---|
19183531 | Jul 2019 | EP | regional |
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/EP2020/067281 | 6/22/2020 | WO |
Publishing Document | Publishing Date | Country | Kind |
---|---|---|---|
WO2021/001184 | 1/7/2021 | WO | A |
Number | Name | Date | Kind |
---|---|---|---|
5198985 | Kwon | Mar 1993 | A |
6904800 | Merwin | Jun 2005 | B2 |
6910638 | Fruhauf | Jun 2005 | B2 |
7501946 | Lanigan | Mar 2009 | B2 |
7567825 | Ueno | Jul 2009 | B2 |
7594609 | Kotlarsky | Sep 2009 | B2 |
7708205 | Kotlarsky | May 2010 | B2 |
8509790 | Christensen | Aug 2013 | B2 |
8649883 | Lu | Feb 2014 | B2 |
9264252 | Ebrom | Feb 2016 | B2 |
9594369 | Diab | Mar 2017 | B2 |
9820361 | Turvy, Jr. | Nov 2017 | B1 |
9883570 | Turvy, Jr. | Jan 2018 | B1 |
9949350 | Roquemore, III | Apr 2018 | B2 |
10009986 | Turvy, Jr. | Jun 2018 | B2 |
10085328 | Barna | Sep 2018 | B2 |
10219356 | Barna | Feb 2019 | B2 |
10594131 | Chen | Mar 2020 | B2 |
10747548 | Vier | Aug 2020 | B2 |
10789074 | Joshi | Sep 2020 | B2 |
10897790 | Velev | Jan 2021 | B2 |
11006510 | Krajnc | May 2021 | B2 |
11349298 | Chen | May 2022 | B2 |
11398924 | Barna | Jul 2022 | B2 |
11726184 | Ferreira | Aug 2023 | B2 |
11758624 | Dolan | Sep 2023 | B2 |
20040178278 | Fruhauf | Sep 2004 | A1 |
20060220847 | Lanigan | Oct 2006 | A1 |
20070181689 | Kotlarsky | Aug 2007 | A1 |
20070215706 | Kotlarsky | Sep 2007 | A1 |
20070240173 | McCoy | Oct 2007 | A1 |
20070264962 | Ueno | Nov 2007 | A1 |
20080006698 | Kotlarsky | Jan 2008 | A1 |
20080127325 | Ebrom | May 2008 | A1 |
20090027188 | Saban | Jan 2009 | A1 |
20090046707 | Smires | Feb 2009 | A1 |
20090103535 | McCoy | Apr 2009 | A1 |
20090132070 | Ebrom | May 2009 | A1 |
20110028141 | Yang | Feb 2011 | A1 |
20110066378 | Lerche | Mar 2011 | A1 |
20130028295 | Hui et al. | Jan 2013 | A1 |
20130138367 | Boivin et al. | May 2013 | A1 |
20130259147 | Wang | Oct 2013 | A1 |
20130261821 | Lu | Oct 2013 | A1 |
20130300569 | Lerche | Nov 2013 | A1 |
20150054413 | Chen | Feb 2015 | A1 |
20150256028 | Suman | Sep 2015 | A1 |
20160006264 | Alperin | Jan 2016 | A1 |
20160029457 | Sung | Jan 2016 | A1 |
20170170649 | Chen | Jun 2017 | A1 |
20170171950 | Barna | Jun 2017 | A1 |
20170173262 | Veltz | Jun 2017 | A1 |
20170331322 | Tuerk | Nov 2017 | A1 |
20170366020 | Brookshire | Dec 2017 | A1 |
20180027633 | Roquemore, III | Jan 2018 | A1 |
20180035519 | Turvy, Jr. | Feb 2018 | A1 |
20180103859 | Provenzano | Apr 2018 | A1 |
20180173666 | Srivastava | Jun 2018 | A1 |
20190243657 | Vier | Aug 2019 | A1 |
20190243660 | Joshi | Aug 2019 | A1 |
20190354377 | Tan | Nov 2019 | A1 |
20200008284 | Krajnc | Jan 2020 | A1 |
20200045767 | Velev | Feb 2020 | A1 |
20200284883 | Ferreira | Sep 2020 | A1 |
20200319324 | Au | Oct 2020 | A1 |
20210028619 | Chen | Jan 2021 | A1 |
20220070766 | Haque | Mar 2022 | A1 |
20230198602 | Zeineddine | Jun 2023 | A1 |
Number | Date | Country |
---|---|---|
3010291 | Apr 2016 | EP |
WO-2013030715 | Mar 2013 | WO |
2018036845 | Mar 2018 | WO |
Number | Date | Country | |
---|---|---|---|
20220361102 A1 | Nov 2022 | US |