Multiple Sqblasters and only one Vera3 Controller

Apps & Remote Access Unmaintained
#1

Hi all !

to work with 2 or more sqblaster in a home with only one vera3, must I install 1 sqblaster plugin for each one sqblaster ?

I am asking this because I know to run sqblaster plugin with success I need inform the ip address of sqblaster in plugin settings.

thanks for help.

#2

Yes, it supports multiple SQBlaster/SQBlaster+ devices on a single Vera.

It’s one Plugin (codebase), multiple Devices hanging off that codebase (one per IP Address).

If the unit is a SQBlaster+ you’ll get 4 more “child” devices for each of these parent devices. Each child will representing an Alt Channels (1…4), for discrete control of it’s extra channels.

I run 2x SQBlaster units at home on a Vera3 (recently moved from my Vera2).

#3

ok guessed, but excuse me I do not understand…

I have to install 1 plugin for each device sqblaster+ ? actually I have one and I have 1 parent and 4 childs… with 2 I will have 2 parents and 8 childs ? and with 3, 3 parents and 12 childs…

thanks for clear this…

my doubt starts about the ip address what I need put to vera3 find sqblaster… and I have only one field for this.

#4

In MiOS, the term “Plugin” refers to the code that implements the logic behind a “Device”. Each of these Devices has configuration attributes (like a name/title, an IP Address and so on in order to handle Device-specific configuration). Part of the confusion is that when you install a Plugin (code), it automatically creates the first Device (instance)… users can go on and create more if they need them.

So you install the plugin once, and then [effectively] create one-or-more Devices off of it. In the case of the SQBlaster plugin, you’d create one Device per physical piece of SQBlaster hardware, and each of those devices would need to be told the IP Address that the physical Hardware is running on.

… the same for SQBlaster+ models, except that the SQBlaster plugin automatically detects that you’re using a SQBlaster+ model, and it goes a step further by creating a set of “child” devices (Alt1…Alt4 + temperature)… so a bunch more “stuff” appears on the Dashboard, but these don’t need any additional configuration (although you might tailor their Titles or something)

#5

When I tested IR with Vera the one thing I did was modify the I/R output names to align with something more descriptive.
Of course the subordinate child I/R devices were created as invisible devices and thus a simple process I used was:

Confirm Device # for Parent IR Device
http://Vera_IP/port_3480/data_request?id=user_data&output_format=xml
In result set search for id_parent="XXX”

E.g. Example of GC100 device I/R output details
<device id=“300” name=“GC100 I/R Port” device_type=“urn:schemas-micasaverde-com:device:IrTransmitter:1” room=“0” id_parent=“294” disabled=“0"device_file=“D_IrTransmitter1.xml” impl_file=”" manufacturer=“” model=“” altid=“6” ip=“” mac=“” time_created=“1348035340” category_num=“10” subcategory_num="1"embedded=“1” invisible=“1” local_udn="uuid: " commProv=“ir”>

Using Luup to run an update from APPS > Develop Apps > Test Luup Code (Lua)
The GC100 has six I/R ports and thus I set all port to ensure their name is more descriptive. E.g.

luup.attr_set(“name”,“GC100 I/R Port1”,300)
luup.attr_set(“name”,“GC100 I/R Port2”,301)
luup.attr_set(“name”,“GC100 I/R Port3”,302)
luup.attr_set(“name”,“GC100 I/R Port4”,303)
luup.attr_set(“name”,“GC100 I/R Port5”,304)
luup.attr_set(“name”,“GC100 I/R Port6”,306)