Accessories

WIFI BUTTON - EXAMPLES

Below are examples of rules associated with WiFi buttons.

Assuming that a WiFi button has been programmed to send messages to our Avior device, this accessory is identified by its MAC address which is made up of 12 characters.

In the Avior device this accessory can be stored by specifying the MAC address in whole or only partially:

EXAMPLE 1

A remote accessory (WiFi button) stored as an active user sends the message corresponding to a single press of the button, activating output 1 for 5 seconds.

ACE MESSAGE FROM ACCESSORY

$S24(single ACCESSORY LAST TEXT ( single

$S24(Desk ACCESSORY LAST TEXT ( Desk

out1=1,5

trigger event is the receipt of a message from an active accessory.

The first condition to check is that the message received contains (also) the text single.

The second condition to check is that the message received contains (also) the text Desk which is the name assigned (and sent) by sensor.

The first action contains the command that turns output 1 on for 5 seconds.

EXAMPLE 2

Each message sent by accessories includes the battery charge level and the same information is automatically sent every 24 hours. It is possible to easily associate this battery level to a variable.

ACE MESSAGE FROM ACCESSORY

$S24

trigger event is the receipt of a message from any active accessory.

The first action contains the tag that represents the text of the last message received from accessory, if this is a valid command it will be executed. Since the button periodically sends the battery charge level <NAME>.batt=xx if we assign the name <NAME>.batt (where <NAME> is the name assigned to the WiFi button) to a variable, this command will save the received value in the variable.
Then the value will be saved in variables having the names of the various accessories:
a variable named Desk.batt will contain the status of Desk battery.
a variable named stairs.batt will contain the status of stairs battery.
a variable named HALL.batt will contain the status of HALL battery.

And now we can define a rule that will send a message when the battery is low and needs to be recharged. Assuming the Desk button battery value is assigned to variable 1.

V1 MEMORY VARIABLE 1

$V11{20 MEMORY VARIABLE 1 VALUE { 20

AT+SMS=+391234,"Desk Low battery"

trigger event is the change in value of variable 1.

The first condition to check is that the value falls below the threshold of 20%. We use the threshold operator { because we want this condition to occur only the first time (not every time) the variable is lower than the set value, as would happen using the comparison operator <.

The first action contains the command that sends an SMS message to the number +391234 with the text "Desk Low battery".

EXAMPLE 3

A remote accessory (WiFi button) stored as a user sends the message corresponding to long pressure of the button, if this accessory belongs to group ring a tone will be played on local speaker.

ACE MESSAGE FROM ACCESSORY

$S23=ring LAST ACCESSORY GROUP = ring

$S24(single ACCESSORY LAST TEXT ( long

AT#SPK=5

$S24

trigger event is the receipt of a message from an active accessory.

The first condition verifies that the message received from an accessory belonging to gorup ring.

The second condition to check is that the message received contains (also) the text long.

The first action contains the command that plays a tone on local speaker.

The second action updates the battery status as described in example 2, is always advisable to add this action which guarantees the updating of the battery status at each message sent by the remote button.

EXAMPLE 4

A remote accessory (WiFi button) NOT stored as a user sends the message corresponding to double button pressure to toggle the status of output 4.

ACU MESSAGE FROM UNKNOWN ACCESSORY

$S24(double ACCESSORY LAST TEXT ( double

out4=T

$S24

trigger event is the receipt of a message from an unknown accessory.

The first condition to check is that the message received contains (also) the text double.

The first action contains the command that toggles output 4.

The second action updates the battery status as described in example 2, is always advisable to add this action which guarantees the updating of the battery status at each message sent by the remote accessory.