forked from TD22057/insteon-mqtt
-
Notifications
You must be signed in to change notification settings - Fork 0
/
scenes.yaml
159 lines (149 loc) · 5.54 KB
/
scenes.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
# Scenes Definition File
#
# Overview
# This file allows users to define scenes that should exist on their network.
# This enables the sync links functions to work. A user is not
# required to have a scenes file, but it can make the process of maintianing
# a complex network of links easier by enabling the user to specify links in
# a single location rather than individually adding links to each device by
# hand.
#
# Format
# The scenes are defined as a yaml file. You can find the specifications for
# a yaml file online.
#
# A note about comments. Anything on a line after a # is treated as a comment.
# These comments will remain unaltered with the exception of when import-scenes
# is run. Import-scenes will attempt to keep your comments, but this is not
# always possible. As such:
#
# !!It is best to backup your scenes file before running import-scenes!!
#
# Individual Scene Format
# Below are some examples of how a scene may be defined. Each scene is an item
# in a list. Each scene item contains a dictionary of the following keys:
# name (string)- [optional] If specified and the modem is defined as a
# controller, this name will be attached to the modem scene number.
# Otherwise this is ignored.
# responders (list) - Each list item defines a scene device that acts as a
# responder in this scene. (more on scene device definitions this below)
# controllers (list) - Each list item defines a scene device that acts as a
# controller in this scene. (more on scene device definitions this below)
#
# Scene Device Format
# A scene device can be defined in a number of ways:
# - As a string of the device address such as aa.bb.cc
# - As a string of the device name as specified in the config file
# - As a dict, where the key is the device name or address and the value is
# the group as an int
# - As a dict, where the key is the device name or address and the value is
# a dict containing additional device attributes including by default:
# group, data_1, data_2, data_3
# the value of each is an int of the byte value for that attribute.
# Additionally, specific devices may also include attributes such as:
# ramp_rate (float .1 - 540.0) - How quickly the light should turn
# on or off in seconds
# on_level (float 0.0 - 100.0) - The brightness level of on
# expressed as a percentage
# Any device attribute that is unspecified will be set to the default value
# the following are the current defaults:
# group = 1, on_level = 100, ramp_rate = .1
#
# Generally, controller links do not have any attributes with the exception of
# a group number for multigrouped devices (keypadlinc, remotes, modem).
#
# Modem Controller Entries (Modem Scenes or Virtual Scenes)
# Each modem scene needs to have its own unique group number from 2-253. You
# do not need to specify this group number. Simply specify the modem as a
# a controller, and the rest will be handled for you. A group number will be
# added for you automatically from the pool of unused numbers after the Scenes
# file is processed the first time. You can see these numbers by opening the
# scenes file after it has been processed. However, if you want to add
# a group number manually you can, but be warned if the group numbers collide
# bad things will happen.
#
# Again, YOU ARE STRONGLY DISCOURAGED from making entries that look like:
# - modem: 21
# - modem:
# group: 21
#
# Instead just do:
# - modem
#
# Join and Pair Links
# Links that are generated by the 'join' command (Modem:1->Device) or the 'pair'
# command (Device->Modem) will not and need not appear in the scenes file.
# These links are handled entirely by the 'pair' and 'join' commands and they
# will be ignored and have no effect if you try to define them in here.
#
# Examples
- name: Upstairs Light
responders:
- living room lamp:
on_level: 70.0
ramp_rate: 10
- living room keypad: 3
- living_room_sw1
controllers:
- living room keypad: 3
- living_room_sw1
- modem
- responders:
- porch light
- driveway light
controllers:
- motion porch
- name: outdoors
responders:
- porch light
- backyard light
- super new device:
data_1: 0xAB
data_2: 23
data_3: 0
controllers:
- modem
- responders:
- master fan:
group: 2
on_level: 30
controllers:
- master remote: 4
- responders:
- master fan
controllers:
- master remote
# IOLinc examples
# The following are some examples of scenes which could be used to setup an
# IOlinc. The details describe what commands sent to the scene would do.
# Latching
# On and off commands to the scene will turn the relay on and off
# Momentary_A
# Only on commands will turn the relay on.
# Momentary_B
# Either on or off will turn on the relay.
# Momentary_C
# On commands will turn the relay on if the sensor is also on.
# Off commands will turn the relay on if the sensor is also off.
# All other commands would be ignored
- name: 'iolinc_command'
controllers:
- modem
responders:
- iolinc
# Latching
# On and off commands to the scene will turn the relay on and off
# Momentary_A
# Only off commands will turn the relay on.
# Momentary_B
# Either on or off will turn on the relay.
# Momentary_C
# On commands will turn the relay on if the sensor is off.
# Off commands will turn the relay on if the sensor is on.
# All other commands would be ignored
- name: 'iolinc_command'
controllers:
- modem
responders:
- iolinc:
on_off: 0