Premise GC100 Relay used to control a $10 ABSelector

[etc6849]

I'm working on making a simple speaker switcher that uses a 12V AC to DC transformer and a double pole double throw relay from radioshack. The GC100 relay connections on the back are contacts that open or close. Wiring these contacts in series with the 12VDC source and the DPDT relay coil will allow me to have a cheap speaker switcher or a cheap AB Selector to switch whatever I want upto 10 amps and 125 VDC (more than adequate for speakers).

I'm moving next week to a bigger place and will solder it up then, but for now I'm working on the Premise control for such a device. I've attached a simple example and would like feedback on it. Since I wanted to make custom buttons for the automation browser, I bound an action toggle button to a boolean property. Since I was using a toggle property, I had to come up with a way to bind a toggle property to an object that uses the digitalOutputEx class.

This is why I don't follow the normal convention in bold mentioned in the weeder technologies post and wanted an opinion on this (thanks goes to 123 for the handy info):

"In Premise, the existing DigitalInput class is used to model a real-world digital input. A collection of DigitalInput objects would represent a group of digital inputs. Premise's framework contains a slew of useful classes including DigitalOutput, Button, TemperatureSensor, HumiditySensor, Dimmer, Power, etc. A proper driver is composed of these core classes. If your Premise Home contains a Relay, Pump, or Fountain object, you can bind it to a driver that contains a DigitalOutput object. You can't bind it to a driver with a boolean value or an array of boolean values."

For the AB switcher module I do bind a boolean property (in effect through the property change script) to the digitalOutputEx of the GC100-12 (in this case called Relay3.Relay1). Any thoughts? Module is attached in a zip file with instructions.

If this looks like an ok way to do things, I'll post it in the downloads section.

 

[123]

...For the AB switcher module I do bind a boolean property (in effect through the property change script) to the digitalOutputEx of the GC100-12 (in this case called Relay3.Relay1). Any thoughts? ..

My point about not binding to a boolean value concerned the original Weeder driver. You most certainly can bind to booleans provided they are bindable properties of a proper class. A "proper class" ought to inherit from existing classes in Premise's library.

For example, may I suggest you consider having GenericSpeakerSwitcher_Base inherit from the DigitalOutput class. It will allow any Home object that inherits from DigitalOutput to bind to GenericSpeakerSwitcher. For example, "RelayDevice" could bind to GenericSpeakerSwitcher.

Instead of "ABSelect", the Boolean property will be DigitalOutput's "State". "OnChangeState" will replace "OnChangeABSelect". OnChangeABSelect's code currently looks like this:

If this.ABSelect = True Then
	this.BoundObject.Value = True
Else
	this.BoundObject.Value = False
End If

which can be reduced to one line and placed in "OnChangeState":

this.BoundObject.Value = sysevent.newval

Having GenericSpeakerSwitcher_Base inherit from DigitalOutput means that a custom Home-level class, such as GenericSpeakerSwitcher_Home, is not mandatory. However, it is required if you wish to give it a custom user-interface as you've done with GenericSpeakerSwitcher_Home.

In your installation instructions, as a courtesy, be sure to mention that the XDO will also add a new Selector to Plugins. If someone wishes to remove the GenericSpeakerSwithcer module, they simply delete it but are unaware that there's a leftover in Modules/Plugins/Selectors/GenericSpeakerSwitcher.