Events (previously called Sequences) are a quick way to do something with multiple steps with time delays between. It is essentially the LightwaveRF equivalent of a macro.
Timers can be used for similar purposes, but they lack the precision of an Event as they only run on a specific minute. Events can have delays set between them to seconds, rather than minutes. An Event can also have 10 steps and it is possible to store 32 Events (i.e. a maximum of 320 steps if all Events were used. By comparison, a timer can only execute a single step and there are 32 timer slots which can be used.
An example is ‘Make cup of Tea’. This is something that would have the same steps every time you need to make a cup of tea.
Step 1: Kettle On
Wait 3 minutes (to allow the kettle to boil)
Step 2: Kitchen Lights 100%
Wait 4 minutes (to allow you to add teabags, milk, sugar, hot water, find your favourite biscuits…)
Step 3: Kitchen All Off
Example command structure:
!FeP”Demo”=!R1D1F1,00:00:15,!R1D1F0,00:00:03
Store event “Demo” which turns Room1 Device1 On, waits 15 seconds, then turns Room1 Device1 Off
!FeP”<EventName>”=<Command1>,<Delay1>,<Command2>,<Delay2>
Where:
| !FeP | Store an event |
| EventName | Events name. Must be unique |
| Command1 | First step of the event. Must be a valid command |
| Delay1 | Time delay after first step in HH:MM:SS |
| Command2 | Second step of the event |
| Delay2 | Time delay after second step. Even though the second step is the last step, there should be a time delay after |
Note
Events stored via the first party apps utilise the ID of the Event from the server, and not the Events name. The ID is prefixed with “E”. For example, an Event could be stored in the Link asE12345. There is no way using the local comms to identify the name of this Event, however.
| Command | Operator | Example |
|---|---|---|
| Store event | !FeP | !FeP”Hello”=!R1FmP3,00:00:15,!R3Fa,00:00:03 (Store event ID Hello which will do Room1 Mood3, wait 15secs, Room3 All Off) |
| Start event | !FqP | !FqP”Hello”|Start Event|Hello (Start event with the ID Hello and display Start Sequence (row 1) and Hello (row 2) on the WiFiLink screen) |
| Cancel running event | !FcP | !FcP"Sample Event" | Cancel Event|Sample Event (Cancel event with the ID “Sample Sequence” if it is running and display Cancel Sequence (row 1) and Sample Sequence (row 2) on the WiFiLink screen) |
| Delete event | !FxP | !FxP"Sample Sequence"|Deleting Sequence (Deletes event with the ID “Sample Sequence” and display Deleting Sequence on the WiFiLink screen) |
| Cancel ALL events and timers | !FcP | !FcP"*" *indicates all timers/events |
| Delete ALL events and timers | !FxP | !FxP"*" *indicates all timers/events |
Note
- Time delays will be a minimum of 3 seconds. If set to 0, 1 or 2 seconds then the time delay will still revert to 3 seconds when it is actually ran.
- Note that Moods and All Off commands can be used as actions in events.
- You cannot have an event trigger another event as an action.
- The event name must only contain alphanumeric characters.
- Events and timers use the same memory and so should not have the same name.
- The maximum string length of an event command is 256 characters. A maximum of 10 action/time pairings can be in one event.
- The event name cannot be more than 16 characters.
- The WiFiLink can store 32 events in its memory.
In recent versions of the Lightwave Link and WiFiLink (2.92 onwards) there have been the introduction of JSON packets in response to almost all commands. When the Link receives the commands above, it will send an OK response initially (described in Example Interactions) and then a second packet containing information on what it has done with the Event.
It is also possible for the Link to be interrogated for details on the Events it has stored in its memory.
The format for adding, editing and deleting Events is:
*!{
"trans":36387,
"mac":"03:45:67",
"time":1420070400,
"pkt":"event",
"fn":"create",
"name":"E1234567890",
"mod":1462462829
}where:
| Name | Value(s) | Description |
|---|---|---|
| trans | 1-4294967295 | Transaction number of the JSON packet. Increments every transaction |
| mac | XX:XX:XX | Last 6 octets of Links MAC Address |
| time | 1420070400 | Timestamp of the transaction in a local UNIX time (i.e if Link is set to UTC+2, this time will be UNIX + (3600*2) |
| pkt | event | This JSON packet output relates to Events |
| fn | create | An Event has been created |
| edit | An Event has been edited | |
| delete | An event has been deleted | |
| name | E1234567890 | The ID of the stored Event |
| mod | 1420070400 | The last time the Event was modified in a local UNIX time (i.e if Link is set to UTC+2, this time will be UNIX + (3600*2) |
Additionally, it is also possible to obtain the current situation of Events in the Link to understand how many are currently stored, and what the IDs of them are. It is not possible to retrieve the actual Event contents, however.
The Events are stored in an internal table of 32 Events, and you can interrogate which rows in the table have been used by sending the command @E. The Link will then respond with:
*!{
"trans":36409,
"mac":"03:36:48",
"time":1462466637,
"pkt":"event",
"fn":"summary",
"stat0":7,
"stat1":0,
"stat2":0,
"stat3":0
}where the first four values are the same, and the following are:
| Name | Value(s) | Description |
|---|---|---|
| fn | summary | This packet is a summary of the Event details |
| stat0 | 255 | Convert this to binary to find out which slots are in use for slots 1-8 |
| stat1 | 255 | Convert this to binary to find out which slots are in use for slots 9-16 |
| stat2 | 255 | Convert this to binary to find out which slots are in use for slots 17-24 |
| stat3 | 255 | Convert this to binary to find out which slots are in use for slots 25-32 |
To identify which slots are used, you will need to turn the value in statX to a binary format, with the least significant bit (LSB) being the value at the right.
Examples:
stat0 - 00000001 would indicate that the only event slot in use between 1-8 would be in slot 1.
stat0 - 00000011 would indicate that the event slots in use between 1-8 are in slots 1 & 2.
stat0 - 00000100 would indicate that the only event slot in use between 1-8 would be in slot 3.
stat1 - 00000001 would indicate that the only event slot in use between 9-16 would be in slot 9.
stat2 - 00000011 would indicate that the event slots in use between 17-24 are in slots 17 & 18.
stat3 - 10000001 would indicate that the event slots in use between 25-32 are in slots 25 & 32.
For example, if the value is 21, then this converts to binary of 00010101, In the case of this, the slots in use are 1, 3 and 5.
With this information, it is then possible to check the information of the Events in each slot by sending @?E_ where _ is the number of slot you’d like to check. @?E1, @?E2, @?E3…@?E32, for example. The Link will then respond with:
*!{
"trans":36415,
"mac":"03:36:48",
"time":1462466672,
"pkt":"event",
"fn":"read",
"slot": 20,
"name":"E84050",
"steps":2,
"mod":1462361540
}where:
| Name | Value(s) | Description |
|---|---|---|
| trans | 1-4294967295 | Transaction number of the JSON packet. Increments every transaction |
| mac | XX:XX:XX | Last 6 octets of Links MAC Address |
| time | 1420070400 | Timestamp of the transaction in a local UNIX time (i.e if Link is set to UTC+2, this time will be UNIX + (3600*2) |
| pkt | event | This JSON packet output relates to Events |
| fn | read | The Event is being read |
| slot | 1-32 | The event slot that is being used in the Links memory |
| name | E123456 | The ID of the Event. Will be unique to the Link |
| steps | 1-10 | The number of individual steps in the Event |
| mod | 1420070400 | The last time the Event was modified. The client may have a record of the Event, but it may have been modified on the Link via another client more recently |
If you check a slot which has no Event stored in it using @?E_, then the Link will then respond with:
123,ERR,5,"Slot is empty"for example:
Last updated 16/12/16