Cynical Behaviors #

Cynical Behaviors is a collection of Indigo plugin devices that represent virtual devices and behaviors. Think of its devices as things that happen to other devices in Indigo.

These devices are meant to simplify commonly encountered home control situations. I use every one of these in my house (which is of course why they are here). They are also designed to be easily integrated into more complex workflows.

Cynical Behaviors is a bit of a grab-bag. Some of its device types are related by function, but others have really nothing to do with each other, besides all of them being behaviors of some sort or another. Pick and choose which ones you find useful and ignore the rest.

Overview #

• To coordinate multiple sensors and switches to synthesize an indication of activity or presence, create a Presence device for each situation.
• To coordinate multiple sensors and switches to control one load, create a Switch Control device for each load.
• To manage a conventional U.S.-style garage door, install a switch relay and door sensor device, then create a Garage Door device with them.
• To link INSTEON KeypadLinc buttons to devices or variables in Indigo, create one suitable INSTEON Button device for each button.
• To supervise INSTEON Leak Sensor devices, create one Leak Watch device and then create triggers based on its states.
• To find and report devices with low batteries, create one Battery Watch device and then create triggers based on its state.
• To create a virtual device that turns a relay into a dimmer, create a Interval Dimmer device.
• To make a relay device blink, create a Blinking Relay device.

About INSTEON Button Devices #

The INSTEON KeypadLinc devices are incredibly useful for controlling multiple things from one spot but they have some limitations. Indigo can only directly link them to other INSTEON devices. For all other cases, you need to separately program button presses to cause actions, and track states to update button lights accordingly. If you have many KeypadLinc devices, this gets very tedious very quickly. Also, the INSTEON commands to toggle KeypadLinc button lights tend to be a bit temperamental.

The INSTEON Button family of devices each establishes a bidirectional connection between a single KeypadLinc button and some Indigo state. If you press the button, the associated thing toggles according to the state of the button light - if the light is on, the thing turns off, and vice versa. If the thing changes, the button light will change to represent this new state. The supported “things” are the on/off state of any Indigo device (not just INSTEON ones), the state of a FanLinc fan controller, or the true/false state of an Indigo variable.

Buttons are identified using standard INSTEON numbering using numbers between one and eight. The main load button(s) cannot be linked to another device, though the main load of a KeypadLinc can be used as the linked-to device. In other words, only secondary buttons (#3-6 on 6-button devices, #2-8 on 8-button ones) are eligible as the “linked button”. The plugin will only let you choose eligible buttons.

You can associate multiple KeypadLinc buttons with the same thing, and they will effectively act together - pressing any one of them will change the thing, and that will in turn change all the other buttons’ lights to match.

Note: The button control devices in Cynical Behaviors can use buttons on any INSTEON device that has controllable LEDs. It just so happens that this applies only KeypadLinc devices as far as Indigo is concerned.

Reporting Device Lists #

Cynical Behaviors has several devices that report lists of devices as state variables. These states are strings that by default contain comma-separated lists of device names with additional information in parentheses - for example:

Garage motion (0%), Living room motion (17%)

If no devices are in the list, the string is empty. These strings are designed to be easily included in emails or text messages, spoken to the user, or such. For reading aloud it helps to change the separator string to " and “.

If you want to process these device lists from Python or AppleScript actions, you can check the Report Device IDs option of the reporting device. This turns the device-list states into simple lists of (only) device ID numbers, which are easier to process (though harder to pronounce).

Devices #

Switch Control Device #

This device manages the on/off state of one subject Indigo device. The subject is often a light, but it could be anything that can be switched on or off - a relay controlling a heater, a fan, etc. The subject device is normally off. It turns on when any of a number of chosen trigger devices report activity, and then a count-down timer controls when the subject is automatically switched back off. Yes, in its simplest form this can just turn a light back off after a delay.

Configuration Settings #

The Duration is, of course, how long the Controlled Device remains on while all Sensor devices remain quiet. If you don’t want the subject device to turn off automatically, simply put a large number there.

If you select an Indigo variable in Only If Not , the device will do nothing unless the variable is false. This odd choice accommodates the predefined isDaylight variable, which lets you suppress light activity unless it’s dark. Define your own variables to filter device activity according to your needs. If this setting is empty, the device is always active.

You can specify two kinds of trigger devices. Sensor devices turn on the subject device and reset the timeout any time they trigger, regardless of circumstances (unless inhibited by Only If Not). Perimeter devices only do this if the subject load is currently off and is actually transitioning from off to on. Put devices into the perimeter list if they are sensors you are likely to trip on your way out - typically a door sensor on an exit door of an area. This keeps them from prolonging the duration even while you leave the area. In particular, use perimeter devices for door sensors.

Turning the subject device on explicitly (by its own switch, or by remote action) will always turn the load on, and will always be treated as a trigger event for (re)setting the timeout. This will happen even if the Only If Not variable would normally suppress the timer.

Immediately after the subject device is turned off, sensors are ignored for the following Perimeter Cycle Time. This allows you to turn off a light and then leave, accounting for the time it takes you to leave the sensor area (as well as any sensor latency). After the Perimeter Cycle Time expires, the device rearms and responds again to sensors. Turning the subject device on directly will still work, of course. If you don’t want this behavior, just set this time to zero.

Presence Device #

This device works exactly like a Switch Control device, except that instead of acting on a controlled relay (switch) device, it is one. In other words, it simply switches itself on and off. This has no inherent effect on your Indigo world, but it can be used to create an indication of presence in an area based on recent activity there. You can then use the resulting device to make your world a bit brighter:

• Use the device’s transition to off state to trigger time-out behaviors.
• Combine multiple sensor inputs into a synthetic “recently seen” indication.
• Use the on state in conditions on triggers, or anywhere else where Indigo allows you to gainfully employ a device state.
• Use explicit Trigger Device Control actions to further enhance things, e.g. from triggers or schedules.

Note that you can explicitly turn a Presence device on or off. This acts exactly as if you’d switched the target device of a Switch Control device, because that’s what it is.

Garage Door Device #

Your typical garage door is operated with a single push-button that variously triggers opening, closing, or stopping of your door. It is pretty easy to wire a (low voltage) relay into this circuit. However, that doesn’t tell you whether your door is open or closed. For that, you typically add a door sensor device that can tell whether the door is fully closed. Now you have two devices (one relay, one sensor), which you have to program using arcane Indigo logic.

You can buy various home control kits that combine a relay and a door sensor in this way, or assemble your own. Garage Door does not care, as long as you follow these simple rules:

• The relay device must be wired into the door control button so it “presses” the button when it is active.
• The door sensor must report off when the garage door is fully closed, and on otherwise.

A Garage Door device combines these two devices into a virtual device that acts fairly well like a normal relay switch. It is off when the door is closed, on if it’s not. It responds to standard on commands by opening the garage door, and to off commands by closing it. It won’t get confused by the toggle logic of the garage door controller. It also contains behaviors that deal with the inevitable accidents of garage door life: the door reversing when dirt gets into the light beam; someone pushing the remote while the door is moving; and teenagers.

Configuration Settings #

A single sensor cannot reliably tell Indigo all possible states your typical garage door can be in - it will only indicate whether the door is closed or not, where not might mean open or opening or closing or even stopped in the middle. Garage Door makes some educated guesses to provide as reliable a door simulation as possible, but it needs some information from you.

The Operating Duration indicates how many seconds it takes your garage door to go from closed to fully open (or vice versa). Measure this time with a clock, and round it up slightly. It is important that this time is not too short. You can make it bigger than necessary, though that will make the door operate more sluggishly in some situations.

Large garage doors vibrate while they move, which can cause the Open Sensor to repeatedly change rapidly. This can confuse Garage Door and repeatedly set off any Indigo triggers you have applied to it.Garage Door waits for Sensor Delay seconds before reacting to a change in the Open Sensor to mitigate this problem. If your door vibrates more violently, you may need to increase this value. Otherwise just leave it alone.

Garage Door assumes that to trigger opening or closing the door, it should “hold down” the Toggle Button device for a short time. The Button Duration setting indicates how long. Most garage door controllers will work fine with the default value, but you may need to adjust it depending on how yours works.

Device States #

In addition to a standard on/off state, Garage Door has a state named state that indicates what it thinks is going on with its door:

The transition from opening to open is made by a timer based on the Operating Duration setting - this is why it’s important that you get that right. When an attempt to close the door does not trigger the Open Sensor during the Operating Duration, Garage Door will press the button again; this deals with stopped-in-the-middle situations as well as stray remote commands. If repeated attempts to close the door fail, the state changes to error and no further action will be taken.

If you command a Garage Door to open while it’s closing, it will ignore you. On the other hand, if you command it to close while it is busy opening, the close command will be remembered and executed after the door has stopped moving. (Recall that pressing the button while the door is moving usually stops it.) This intentional asymmetry reflects the fact that when in doubt, people tend to want their garage doors to be safely closed.

If an obstacle triggers the door controller’s safety features, the door will repeatedly reopen and Garage Door’s state will end up as error. (A kid with a garage remote can have a similar effect.) If you require reliable unattended door closing (say, in a good-night script), you need to trigger on the error state and do something to alert you to the problem.

INSTEON Button Device Control Device #

This device links an INSTEON KeypadLinc button to any Indigo device that can be switched on and off. That includes relay and dimmer devices of any kind - INSTEON or otherwise, even those defined by other plugins. The link goes both ways - when the device is on, the button is lit and pressing it turns the device off. Conversely, if it’s off, the button is unlit and pressing it turns it on. If the device changes state for any reason, the button light will be adjusted to reflect the new situation.

Configuration Settings #

The Button Device is the KeypadLinc whose button we want to link. Once it is selected, the Button menu will show the available buttons. (This will depend on what kind of KeypadLinc this is.) Finally, the Target Device is the Indigo device whose on/off state you want to connect to the selected button.

Despite its name, INSTEON is not instantaneous. In particular, updates to LED state may take a little while. If your INSTEON network is idle, that’s only half a second; but if there is a lot going on, it may take a few seconds. Be patient; the plugin is working as fast as it can.

INSTEON Button Variable Control Device #

This device links an INSTEON KeypadLinc button to a boolean Indigo variable (it typically contains true or false). The link goes both ways - if you press the button, the variable toggles. If the variable changes, the button state changes to match.

Configuration Settings #

The fundamental idea is that the variable represents some house state, and you add Indigo triggers to respond to changes of that state, rather than establishing direct triggers on the button’s state. This indirection through a variable approach has some major advantages. Try it!

INSTEON Button Fan Control Device #

This device links an INSTEON KeypadLinc button to a fan device - that peculiar kind of Indigo device that has an on/off state and three speed settings. It works very much like an INSTEON Button Device Control device in that the button is linked to the fan’s on/off state. You may choose what fan speed (low/medium/high) should be selected when the button turns the fan on. In addition, a different fan speed can be selected when the button is double-tapped.

Configuration Settings #

Fan speeds are low, medium, or high. It is customary to pick a higher speed for a double-tap, but you can select any speed for either gesture.

Tapping a lit button will turn the associated fan off regardless of its current speed.

Battery Watch Device #

This device automatically watches all Indigo devices that have meaningful battery indications. Those whose battery value is below a threshold are collected as the value of the low state.

Configuration Settings #

Specify the Threshold below which battery devices are reported.

There is usually no point in changing the check interval. Battery-powered devices report their battery status infrequently and when they feel like it, and checking more often does not usually improve things.

There is no need to specify battery devices; Battery Watch automatically applies to all battery-reporting devices in your Indigo database.

Device States #

Leak Watch Device #

This device automatically supervises all INSTEON Leak Sensor devices in your Indigo database. In addition to reporting any wet devices, it also identifies any that have missed their heartbeat for too long. All leak sensors are managed by a single device.

Configuration Settings #

Leak Sensor devices wake up once each day to transmit a heartbeat signal to indicate that they are alive. Those signals can occasionally be lost. The Heartbeat Tolerance setting indicates how many consecutive heartbeats a Leak Sensor device may miss before being included in the overdue list. Overdue devices are either low on battery, or are in a location where their radios cannot reach a nearby INSTEON device. In the latter case, installing a dual-band device nearby may help.

There is no need to select any devices; Leak Watch automatically applies to all Leak Sensor devices in your Indigo database.

Device States #

The wet list is updated immediately whenever a sensor reports water (or the absence thereof, if you press its button while it is dry). The overdue state is updated every few hours.

Inactivity Watch Device #

This device watches a set of devices you choose, and reports any that have not changed state (as indicated by their last changed value) for longer than a configurable threshold.

Having a last changed time long ago is not necessarily a sign of a problem. For example, a door sensor may simply watch a door that hasn’t been moved for a week. On the other hand, if you expect regular state changes, then a lack thereof may be an indication of a weak battery or other problems worth investigating. That is why this device lets you explicitly select which devices it should monitor. If you select a device whose last changed date indicates that it has never been changed, it is automatically ignored (never reported).

Configuration Settings #

Interval Dimmer Device #

Some devices are relays - they can only turn on or off. There may be situations where you want to approximate a dimmer device by cunningly turning a relay on and off. Interval Dimmer is a dimmer device that does this job - when it is at 100%, the underlying relay is always on, at 0% it is always off, at 50% it is on half of the time, and so on. The actual duration may vary, but the fraction of on-time is roughly what the dimmer device requests.

One useful application is an electric heater that can only turn on or off. If you set an Interval Dimmer to 70%, the heater will be on for 70% of the time (and off for the rest), achieving approximately 70% of maximum heating output.

Configuration Settings #

Many relays are mechanical devices that are rated for a limited number of lifetime operations. You can tell by the clacking sound they make when they switch. Interval Dimmer enforces a minimum duty cycle to help protect you against wearing out such a relay. If your relay is electronic, you can set that to a small value (1) to make operation smoother.

Blinking Relay Device #

This device makes an electronic relay device blink. You simply specify the on-time and off-time in seconds, and the relay will blink with this cadence while the device is on. This is primarily intended for festive lighting, but could be used for warning lights or alert claxons.

Configuration Settings #

Note that the on-time and off-time can be specified as a plugin formula , and thus you can vary them dynamically as you see fit.

Keep in mind that this device should only be applied to electronic relays. Operating a mechanical relay at short intervals for a long time will eventually wear it out.

Actions #

Trigger Device Control Action #

This action lets you explicitly trigger a Switch Control device, exactly as if a normally configured sensor had registered activity. This allows you to add arbitrary conditions that turn a controlled device on or keep it on. To support devices that are not sensor devices (in the Indigo sense), create an Indigo trigger on whatever condition should constitute activity and then put this action into the trigger’s action group.

Configuration Settings #

Update Now Action #

This action tells a Battery Watch or Activity Watch device to perform its periodic checks immediately and update its device state accordingly.

Update LEDs Action #

The various KeypadLinc button controllers can generate quite a bit of INSTEON traffic. If you execute large scenes, large numbers of INSTEON device may change state in a short time, and the button controllers add more activity to update the button LEDs to match these new states. If you have many KeypadLincs and many devices, this may briefly overload your INSTEON network and some of the button-LED update commands may get lost, despite the best efforts of Indigo and this plugin.

Configuration Settings #

This action has two related uses. If you leave the duration property off or set it to zero, all KeypadLinc control devices immediately check their state and issue new commands to update their LED lights if necessary. This is spread out over time to avoid overloading the INSTEON network. You can use this action once to correct a glitch, or on a schedule during times when your house is bored.

If you give a duration that is greater than zero, then this action immediately suspends all LED update activity for this many seconds, and then tells all the LED lights to update to their new state. Execute this action right before you execute large scenes with much update activity, and specify slightly more seconds than the scene usually takes to finish (including any cleanup activity). This effectively postpones the LED updates to after the scene completes, avoiding additional congestion of your INSTEON network.

Notes #

Release Notes #

Notable releases: