Difference between revisions of "Internal Sandbox"

From GrandCare Systems
Jump to navigation Jump to search
m (Reverted edits by Mark (talk) to last revision by Kristin)
Line 3: Line 3:
[[Ashley Test|Ashley Test]]
[[Ashley Test|Ashley Test]]
[[Adding Users|Adding Users]]
[[Adding Users|Adding Users]]
Battery-operated devices are a special challenge within a Z Wave network, because they are mostly in a sleeping state for current savings reasons and cannot be reached from a controller in this state.[[Main Page]]
Battery-operated devices are a special challenge within a Z Wave network, because they are mostly in a sleeping state for current savings reasons and cannot be reached from a controller in this state.
 
Battery operated device know two states:


'''Battery operated device know two states:
'''
* They are awake and can communicate with other devices of the network
* They are awake and can communicate with other devices of the network



Revision as of 19:53, 4 February 2014

Battery operated devices

Ashley Test Adding Users Battery-operated devices are a special challenge within a Z Wave network, because they are mostly in a sleeping state for current savings reasons and cannot be reached from a controller in this state.

Battery operated device know two states:

  • They are awake and can communicate with other devices of the network
  • They are sleeping and do not communicate at all. For other controllers they may appear as non existing to damaged

In order to allow communication with battery operated devices a mains powered and therefore always active static controller needs to maintain a waiting queue, where all commands are stored which are to be sent to a sleeping device. When the battery operated device wakes up it will inform this controller and “empty the mailbox”.

At the moment a battery operated device wakes up it sends a so-called WAEKUP_NOTIFICATION to the controller and stays awake. The WAKEUP_NOTIFICATION indicates to the controller that the battery device is now listening to commands. If all commands are sent the controller will send a final command “NO_MORE_INFO” to indicate to the battery device that it can’t go back to sleeping mode. If the battery operated device does not receive a “NO_MORE_INFO” if will go back to sleeping mode after a defined time.

http://www.zwaveeurope.com/images/man_en/z48.png

Figure 4.8: Sleeping and wakeup

The operation of battery-operated devices requires at least one static and mains powered controller in the network to store commands for sleeping battery devices. If a local action on a battery operated device is performed such as pressing a button the battery device is usually woken up immediately to issue a command according to this action. Each battery device needs to have a defined local action for wake up such as pressing a certain button.

http://www.zwaveeurope.com/images/man_en/z49.png

Figure 4.9: Example of a wakeup time dialog

Most battery-operated devices will have an internal timer, which wakes up the device regularly to check for queued commands. This maximal sleeping time can be configured. A typical sleeping interval is between 30 seconds and days and can usually be configured on a user interface of the controller. Any change of the wakeup time will, like any other command sent to the battery device, become effective after the next wakeup.

Certain devices will limit the wakeup interval to a maximum and minimum value. Unfortunately it is not defined how the device shall react if a forbidden interval value is configured.

Therefore the wakeup command class was extended to allow manufacturers to announce a minimum and maximal wakeup time during configuration. If these new command classes are used a misconfiguration is impossible. Nevertheless its worth to refer to the manufacturers manual for further information.

To allow an initial configuration of a device after inclusion every battery device shall stay awake for a defined time, which may vary between 20 seconds and some minutes.

Table 4.1 summarized again the different states of a battery operated device and the conditions to change the status,

Situation Awake Sleeping
Inclusion Right after inclusion Turns into sleeping mode after a couple of minutes without any further user action.
Regularly Wakes up after a defined interval and sends a notification to static controller. Typical Wakeup intervals are between minutes and hours and can be configured by the user within certain boundaries Controller can turn back the battery-operated device by sending a command. Otherwise the battery device turns back into sleeping mode after a defined time (usually a minute)
Local operation of the device Wakes up on every local operation and communicates status if needed (e.g. button pressed) Immediately after finishing action

Table 4.1: Conditions to change state for battery operated devices

This wakeup/sleep behaviour may cause a couple of failures or unclear conditions.

Typical Failure during Inclusion into a Network

It’s a common approach to include multiple devices one after each other. However it can happen that a battery powered device may be sleeping already when the controller wants to include it. The controller will not “see” the device and may conclude that the device does not exist or is dead. The battery-operated device will usually wake up after a defined time interval but this may happen after multiple hours or days.

Therefore its recommended to configure the battery-operated device right after inclusion or make manually wakeup the device later on for configuration. In case of manually wakeup it may happen that the device goes back into sleeping mode right after wakeup if no further information is available from the static controller.

It’s possible that a battery-operated device wakes up but does not know where so send the wakeup information to. This happens if the device was not configured after inclusion to know the Node ID of the static controller who holds his command waiting queue. Therefore it’s highly recommended to configure a battery operated device right after inclusion and to have the static controller included first. Only then the static controller is able to configure the battery-operated device correctly.

Certain devices will stay awake after first power up only and go right into sleep state after first inclusion. This is not longer accepted by the standard but older model may behave like this. If the device is powered up using the batteries and is included into the network much later it may result again in an error since the battery device will not stay awake long enough after inclusion to allow correct configuration.

Therefore it is recommended to follow the following guideline when including battery devices into a Z-Wave network:

  1. Include every battery-operated device right after inserting the batteries the first time. Make sure to configure a reasonable wakeup time before the device goes into sleeping state for the first time.
  2. In case there is further configuration work to do configure a low wakeup time first but make sure that you configure a longer battery saving wakeup time when all configuration is finished.
  3. Do not batch include and configure afterwards and don’t loose any time after inclusion to configure the device.
  4. A reasonable wakeup time is a trade-off between two goals:
    1. A very long wakeup interval will save battery capacity but may create problems in case of network reorganization. The static controller may not hear anything from the battery device during the reorganization and then threat the device as not functioning.
    2. A very short wakeup time helps the controller to keep track of the device but costs battery lifetime.
  5. The wakeup interval must be configured between the allowed boundaries. Refer to the manual of the manufacturer has set any boundaries.

Maximization of battery life time

The battery lifetime is the critical measure of battery-operated devices. Therefore some estimates should be given and taken into account.

  • A typical Alkaline-Microcell (AAA) has an energy capacity of approx. 1000 mAh. A typical battery-operated sensor has 2 such batteries.
  • A Z-Wave module of the class 300 consumes 2.5 myA in the hibernation state and 21 mA in the wakeup mode. During transmission of packets about 36 mA are required. Table 4.2 shows the current need of the single chip generations in their respective working conditions.
  • Additional battery power can be used for the devices functionality such as operating an infrared sensor or moving a thermostat valve. This power consumption varies from device to device and is usually only a fraction of the power used for the electronics. For the following estimate this portion of the power usage should be neglected
Chip Generation Hibernation (A) Transmitting (mA) Listening (mA)
100 31 25 21
200 (since 2005) 2.5 36 21
300 (since 2007) 2.5 36 21
400 (since 2009) 1 23 21

Table 4.2 Power consumptions of different chip generations

If a sensor is in the active reception mode constantly, his battery is empty after 1000 mAh / 21 mA = 47 hours = 2 days!

It is therefore mandatory to move a battery-operated device into the sleeping state. The maximum battery lifetime in the permanent sleeping state for the accepted configuration is 1000 mAh / 0.0025 mA = 400,000 hours = 16.666 days = 45 years. In this time even alkaline batteries will have become empty by self-unloading.

If a battery device is not turned back into sleeping mode right after wake up and exchange of queued commands from the mailbox the device will stay in listening mode for about one minute A transmitting time of 1% of the reception time is assumed corresponding with the regulation of the Z-Wave radio standard. The programmed wakeup interval determines, how long the battery will last.

Wakeup interval Battery life time
120 Seconds 4 days
1800 Seconds = 30 Minutes (typical) 118 days
24 hours 2439 days

Table 4.3: Battery Lifetime as function of wakeup time

A battery lifetime of 118 days (under disregard of all local operations like blinking of a LED, moving of a motor etc.) is still unacceptable. Hence, it is necessary to operate a static controller in the network to manage battery-operated devices and shorten the wakeup time.

If a static controller is programmed in a way that he will send every device back into sleep mode right after wakeup and cleaning the mailbox the battery live time is extended dramatically.

Assuming typical wakeup intervals and assuming that 50 % of the wakeup time is used for transmitting signals from the battery operated device to the controller with a total communication time of 50ms. Table 4.4 shows the resulting battery lifetime.

Wakeup interval Battery lifetime
120 seconds 59 days
1800 seconds = 30 minutes (typical) 850 days
24 hours 12400 days

Table 4.4: battery lifetime depends on wakeup interval

These numbers are only valid under the assumption that no additional power is used for the functionality of the battery-operated device, e.g. turning a valve of a heat of measuring some environmental data. Assuming a factor of 50 % of the total power consumption for these functions the resulting battery lifetime is in the neighbourhood of 1 year that confirms values given on vendor data sheets for typical battery operated devices.

However to reach these value the presence of static controller is mandatory managing the battery operated devices. In a network with only portable controllers the lifetime of battery powered devices will be shortened. The values of table 4.3 should apply in this case.

These estimate are only applicable for battery operated slave devices. Portable controllers, which are battery-operated devices as well, will always sleep unless pressing a button wakes them up. Hence, the battery life time of these device totally depends on the self discharging effect of batteries and the usage pattern and will typically reach 2…3 years.