Luup Plugin: SQBlaster interface

[tbever]

Rather than admitting defeat, I was able to set up a work around.

I created a new room (LG Air Conditioner) and created 3 separate scenes, ie Power off, Power on/off and Set temp 74 Cool Fan1 (a preconfigured code that Mat captured from the remote).  I just set up the IR-Blaster-Room to send out a direct Pronto code to the A/C for each scene and that worked fine.  This will probably serve my needs until I can figure things out a little better.

[guessed]

Try these, the others had some sort of DOS characters in them, which I hadn't noticed when I edited them last time and these were breaking MiOS parsing somehow.  Not sure how they got in since they don't appear to be in the devxxxxxx.xml file, so they should not have generated into the [original] D_ and I_ files.

[tbever]

Excellent!  Thanks guessed! That did the trick.

I did have to create a variable to link the device to the IR-Blaster-room device using your other instructions, and after that everything worked like a champ!  I was busting my brains trying to figure out what I did wrong.  I was using microsoft visual studio 2005 Tools for applications to edit the xml files but I must have screwed it up somehow.

Tomorrow I will try to fill out the IRl commands a bit and see if I can get some of the longer states ie 74 Cool F1 working.

[tinkerdoctor]

Any Progress?  I am in the process of building an house using mini splits. 

[guessed]

@tinkerdoctor,
The stubs above will do the Off (Discrete), and On/Off (Toggle) for the specific model of AirCond that was being used (an LG). 

Technically the other commands of the AirCond could be generated, and manually "assigned" to various AV-based IR Controls, but there's no "standard" for IR commands at this time, so the tool has no-where to map them when it brings them over to Vera.

What are you specifically looking for in terms of control of your units?

[SquareConnectMat]

What brand/model of mini-splits are you planning on using?

Mat

[tinkerdoctor]

I have missed the reply.
At this stage I don’t know yet.  Cost and efficiency are the most important.  By the way the house is in Mexico.  I am considering either SQBlaster or an appliance module (with possible relay for 220V) for just on off (I ransack all local RS within 30miles)

[SquareConnectMat]

We have a dealer in Mexico who I know has successfully recorded most of the air conditioner brands available in Mexico. If you email me at mat @ squareconnect.com, I'll connect you...


Mat

[drag0n]

These instructions are great.
I've successfully created a device for my Air Conditioner, with 3 commands: POWER ON, POWER OFF and Power on cool.
See attached xml files.  I can now use vera scenes to control my Aircon through sq blaster.

I would like this device to be recognized as a standard switch, so that I can use dashboard and ivera to turn it ON/OFF without the need to use scenes.

Can anyone suggest what needs to be changed in the device definition in order for it to be treated like a binary light switch?

[guessed]

Can anyone suggest what needs to be changed in the device definition in order for it to be treated like a binary light switch?

In theory, you'd add the BinarySwitch1 ServiceId and you'd then put in a little Lua to "wire" the Light events to call the corresponding IR calls.

In practice, this is a little more complex because most Control points (and the Dashboard itself) won't cleanly recognize it as a switch if you do that.

One approach to this is to add Luup Startup Logic that creates a Child device, using the standard luup.chdev methods, but have the Parent (IR) device handle all of the events of the Child (<handleChildren>1</handleChildren> in D_SQdev1401130560.xml)

eg. basic device creation example from the Weather code http://code.mios.com/trac/mios_weather/browser/trunk/I_GoogleWeather.xml#L264
eg. handleChildren example from the RFXCOM code http://code.mios.com/trac/mios_rfxcom/browser/D_RFXCOM.xml#L18

Then add <action> blocks for the Switch events, this would look like the following, and be put into the IR device implementation file (I_SQdev1401130560.xml):

eg. <action> block for urn:upnp-org:serviceId:SwitchPower1 from the RFXCOM code http://code.mios.com/trac/mios_rfxcom/browser/I_RFXCOM.xml#L1149

Then implement if... then... else logic, along with luup.call_action(...) to invoke the various handlers on the Parent to send the IR commands.

if (lul_settings.newTargetValue == "1") then
    luup.call_action("urn:micasaverde-com:serviceId:DiscretePower1", "On", {}, PARENT_DEVICE)
else
    luup.call_action("urn:micasaverde-com:serviceId:DiscretePower1", "Off", {}, PARENT_DEVICE)
end


That's not all of it, but it'll get you a good starting point to experiment with ... 

[mcvflorin]

I commited (created tag) and published version 0.21 which includes an updated doc_url, with a link to the code.mios.com Trac page.

Edit: apps.mios.com plugin ownership given to guessed.

[guessed]

Thanks!

[guessed]

As part of preparing for the release of the SQBlaster Plus, I'm making modifications to the SQBlaster Plugin to handle it's new functionality.

Per the spec sheet published on http://squareconnect.com, the new Blaster will have 5 channels of IR....  one built in (like the original) in addition to 4 individually addressable discrete IR channels.

So far, I've modded my Plugin code to create these 4 extra IR channels, and expose them as extra Devices, with the following characteristics, but I'd like comments on what people are expecting:

a) You still have the original "Parent" device, and it'll show in all the MiOS IrTransmitter dropdowns
b) The new children all have the flags set to force the child devices into the same Room as the Parent blaster, they cannot be moved around
c) The children all have titles of IR Channel 1, ..., IR Channel 4 .. on the assumption that the Parent is IR Channel Main or whatever.
d) These children only appear if you have a SQBlaster Plus (to make it transparent to the 1st generation SQBlaster users)

I think this is all reasonable behavior except, I'm not sure if people think about it being IR Channel 1..4, or IR Channel 2..5, IR Aux Channel 1..4 (etc) since the "Parent" is really the first channel.

I'm leaning towards changing the child titles to IR Aux Channel 1..4, as these are user-changeable anyhow, and relaxing the restriction so these devices can be placed in any room.

Anyone have a strong feeling one way or another?

[SquareConnectJohn]

Just a note to say that channel 0 is also a true channel, in that if you select channel 1... you will get no IR out of the body of the blaster.. its not Main Channel + selected channel.. its channel 0, 1, 2, 3 OR 4.

You might want to relax the room constraint as there may be needs to cable through to different rooms.

John

[guessed]

Just a note to say that channel 0 is also a true channel, in that if you select channel 1... you will get no IR out of the body of the blaster.. its not Main Channel + selected channel.. its channel 0, 1, 2, 3 OR 4.

You might want to relax the room constraint as there may be needs to cable through to different rooms.

John

Hey John,
I'm not worried about the internal representation, as I have that sorted and I understand these channels are not linked in any way.  I'm trying to sort out appropriate labelling/nomenclature that makes sense for a typical user when they see these on the MiOS Dashboard.

Per the picture, a SQBlaster Plus user will get [independent] 5 devices on their Dashboard, and in the related MiOS Dropdown/Picklists.  The first one is effectively Channel "0", then the others represent channel's 1,2,3,4 (Internally, from a Blaster perspective)

I want to ensure that people get the correct idea that "Channel 1" isn't the built in one, since "Channel 0" is kinda a programming construct, more than a user one.  I'm leaning to using labels like IR AUX Channel 1..4 for the extra independent channels

I'll relax the room construct.