Luup Plugin: SQBlaster interface

I’ve uploaded 2x XSLT files to code.mios.com that can be used (with a freestanding XSLT Tool) to “transform” an XML Device file, from SQRemote’s backup, into the requisite [tt]I_xxx.xml[/tt] and [tt]D_xxx.xml[/tt] files for MiOS to talk directly to the Puck.

They’re prototypes right now, and currently untested.
[url=http://code.mios.com/trac/mios_sqblaster/browser/trunk/xslt/SQBlaster_I.xsl]http://code.mios.com/trac/mios_sqblaster/browser/trunk/xslt/SQBlaster_I.xsl[/url]
[url=http://code.mios.com/trac/mios_sqblaster/browser/trunk/xslt/SQBlaster_D.xsl]http://code.mios.com/trac/mios_sqblaster/browser/trunk/xslt/SQBlaster_D.xsl[/url]

If you feed the SQBlaster device files ([tt]xxxxxxxxx.xml[/tt]) through an XSLT processor with [tt]SQBlaster_I.xsl[/tt], it’ll emit the [tt]I_xxx.xml[/tt] file for the Mios Device Implementation file.

If you feed this new Implementation file ([tt]I_xxx.xml[/tt]) through an XSLT processor with [tt]SQBlaster_D.xsl[/tt], it’ll emit the [tt]D_xxx.xml[/tt] file for the MiOS Device Descriptor file.

Again, it’s not been tested yet, and the IR “mapping” isn’t complete just yet, but it’s a start. If anyone has good Javascript skills the XML/XSLT Processing could be done “in browser” to avoid the extra step of having the command line XSLT Processor :wink:

Any idea if the below would work for the translation?

Or is it too basic in that the output format can’t be specified?
I just ran it with one of the two code sets I have in my backup (not sure which one is which to be honest) but for the most part the output for an implementation xml seemed very close to what I’d expect.

Out of interest, what are you using on the Mac to transform?

Yes, that URL works just fine. I use fairly minimal spec XSLT, so I imagine there are a few of those around. There’s one on the W3C site, but it only takes URL’s as input (not pasted text) so this one is better.

On the Mac, I’m trialing a very expensive Development tool that’s specifically targetted at XML/XSLT and Debugging. It’s not something the average person would likely buy if it’s only going to be used for this purpose.

[quote=“guessed, post:1, topic:167682”]I’ve uploaded 2x XSLT files to code.mios.com that can be used (with a freestanding XSLT Tool) to “transform” an XML Device file, from SQRemote’s backup, into the requisite [tt]I_xxx.xml[/tt] and [tt]D_xxx.xml[/tt] files for MiOS to talk directly to the Puck.

They’re prototypes right now, and currently untested.
http://code.mios.com/trac/mios_sqblaster/browser/trunk/SQBlaster_I.xsl
http://code.mios.com/trac/mios_sqblaster/browser/trunk/SQBlaster_D.xsl

If you feed the SQBlaster device files ([tt]xxxxxxxxx.xml[/tt]) through an XSLT processor with [tt]SQBlaster_I.xsl[/tt], it’ll emit the [tt]I_xxx.xml[/tt] file for the Mios Device Implementation file.

If you feed this new Implementation file ([tt]I_xxx.xml[/tt]) through an XSLT processor with [tt]SQBlaster_D.xsl[/tt], it’ll emit the [tt]D_xxx.xml[/tt] file for the MiOS Device Descriptor file.

Again, it’s not been tested yet, and the IR “mapping” isn’t complete just yet, but it’s a start. If anyone has good Javascript skills the XML/XSLT Processing could be done “in browser” to avoid the extra step of having the command line XSLT Processor ;)[/quote]
I pushed newer versions of these XSLT files over the weekend, with the following improvements:

a) Broader mapping of SQRemote “codes” to MiOS IR-Device Actions
b) Use [tt]SQKeyCode[/tt] as the Primary “mapping” vehicle instead of the Text-based Description (which varies too much across devices)
c) Generate correct output for UEI-based SQBlaster codes, as these weren’t handled correctly

If you try it, let me know feedback/comments. Folk should be able to use the URL that @strangely posted to generate starter [tt]I_xxxx.xml[/tt] and [tt]D_xxxx.xml[/tt] files if they don’t otherwise have a tool to kickoff the transform.

Many thanks to @SquareConnectJohn for a prelim of the SQBlaster API doco. It made is easier to expand the mappings and gave me a clearer understanding of the SQBlaster XML Device file elements/structure (etc).

Hi, guessed,
I am very interested in your plugin for Sqblaster in vera. But I don’t have any experience with programing in vera. Can you provide an example for me?
I attached a saved configuration file download from box.net. I have tested this configuration in SQ Remote on Ipad and confirmed it’s working.
Would you please transfer this file to a plugin that can be used in vera?
I have already installed the plugin from: SQBlaster
I am hoping that once I install your newly developed plugin, I can create a scene in vera to “Turn on” my TV at 7am in the morning?
Thank you very much.

Sorry for the delay, turns out that the hosted site I’ve been using to do this XSLT transformation has been down all day (it’s the one @strangely lists above).

Anyhow, it encouraged me to write a pure-Lua version of it so, longer term, I won’t need to use anything other than Vera to execute the Conversion process.

The [converted] IR Device Plugin files for the Zenith are (attached) and are in addition to the SQBlaster IR Transmitter Plugin files you probably already have loaded and setup.

I’ve modified the Wiki instructions to show both what the SQBlaster plugin does, as well as the requirement to generate the IR Device files

Unfortunately I’m running a version of the Beta (1.1.1183) that doesn’t let me associate the Zenith with my SQBlaster, but you shouldn’t have that problem unless you’ve moved to the Beta.

If you have, let me know, as it’s still possible to fix, just takes a little longer to describe the work-around.

I’ve attached some screenshots showing the Setup Process (etc), these are all out of sequence, but I’m sure you’ll work it out.

… and the most important one, the “Install” setup I used to get the Zenith TV device created, after uploading the generated/derived [tt]D_SQdevxxxx.xml[/tt] and I[tt]_SQdevxxxx.xml[/tt] files.

This screenshot is of the Advanced Scenes Tab, showing the pull down for IR Actions that can be executed against the Zenith TV.

Hi, guessed,
Thank you for your work. I have successfully setup the IR Transmitter and the Zenith TV device in Vera. Now I CAN see all commands in advance tab when creating new scenes. So I assume it should work.
Unfortunately, it didn’t. Maybe it is because of my firmware version? Currently I am running at 1.1.1186.
Do I need to reset the firmware to an older version?

[quote=“shuyu2k, post:8, topic:167682”]Hi, guessed,
Thank you for your work. I have successfully setup the IR Transmitter and the Zenith TV device in Vera. Now I CAN see all commands in advance tab when creating new scenes. So I assume it should work.
Unfortunately, it didn’t. Maybe it is because of my firmware version? Currently I am running at 1.1.1186.
Do I need to reset the firmware to an older version?[/quote]
Yeap, you’re on a Beta release.

A problem was intro’d into the Beta’s where the normal UI “mechanism” for associating an IR Device, with the IR Transmitter that it should use, it missing. They’ve since added it back, but we don’t yet have access to that version.

It’s normally a Drop-down menu, present in the Device’s editing dialog that lets you do this, and the drop down shows “all” the IR Transmitter devices you have installed into your system.

If you’re on a Beta release, as you are, then this association needs to be setup manually before the “Device” can start sending stuff (since, in any system, there might be more than one IR Transmitter device, like I have)

Anyhow, here are the manual steps you need to perform to work-around the Beta bug:

a) Find the “Device #” of the IR Transmitter device in your system
In the example screenshot (UI4_1.png) mine shows as “90” in the Device dialog. In the examples below, I’ll use the value “90”, but you should change this to the value from your system.

b) Open the Device Dialog for your IR Device in your system (the ZenithTV in your case) and create a Variable called “IODevice”.
The specifics of the Variable are as follows:

[i]New service:[/i] [tt]urn:micasaverde-com:serviceId:HaDevice1[/tt] [i]New variable:[/i] [tt]IODevice[/tt] [i]New value:[/i] [tt]90[/tt]

These values are case-sensitive, and should be entered exactly as above, then click the (Add >) Button

c) Click (Save)

d) Validate the values in the Dialog.
If you go back into your Zenith TV dialog, after Vera restarts completely, you should see something like the attached screenshot (UI4_3.png)

At this point the IR Device (Zenith TV) should be setup to send it’s codes via your IR Transmitter (SQBlaster Plugin)

again, this work-around shouldn’t be needed going forward.

I successfully installed the IR Blaster plugin onto my MIOS system.

I took my device file from my backup of my SQ Remote and used the I_XSL file against it and used the D_XSL file against the resulting file as instructed.

I upload the two xml files to my MIOS system.

I tried to create a device but things just aren’t working at this point.

I’ve attached both my device and implementation files.

I would appreciate any help.

Thanks.

guessed, it worked! Thank you very much!

You’re welcome. Looking forward to making it all easier for folks, esp once I productionize the Pure-Lua version I’ve got going.

[quote=“IamLegend, post:10, topic:167682”]I tried to create a device but things just aren’t working at this point.

I’ve attached both my device and implementation files.

I would appreciate any help.

Thanks.[/quote]
If you’re on 1.1.1183 it’s not going to work at all, since all IR is broken at the MiOS Level
If you’re on 1.1.1186 it should work, but you need to manually Associate the IR Device (Samsung TV) with the IR Transmitter (SQBlaster Plugin)
If you’re on another MiOS Version, please let me know.

Can you elaborate on this:

I tried to create a device but things just aren't working at this point.

Specifically:

a) Did the IR Device creation, in MiOS, Work?
b) Do you get any Startup errors for any of your Devices?
c) Did you attach your Samsung IR Device to the SQBlaster IR Transmitter Device?
d) Does the IR Transmitter (SQBlaster) Device show as “Up” in it’s Dashboard presentation like this image shows:
http://code.mios.com/trac/mios_sqblaster/attachment/wiki/WikiStart/SQBlasterDevice-UI4.png
e) Can you see the IR Device in the Scene Advanced mode (like the pictures above)?

If all of the above are working, then please outline the specifics of the problem being experienced. Feel free to also PM me with the location where I can download your [tt]LuaUPnP.log[/tt] file so I can see what’s really going on.

Looking at the generated D_SamsungTV.xml, it looks like my XSLT isn’t gen’ing it quite correctly. That shouldn’t stop actual IR commands from working, but may cause other problems. Please attach the original devxxxxxxxxx.xml that was used to build this file as I need to see why the XSLT didn’t transform it correctly from the original content.

Basically it appears to be missing the Service Description block.

guessed,

I got it all working. I had to edit the xsl file because it was looking for a ‘.’ in the device string but it needed to look for ‘:’ instead.

Anyway, thanks for your xsl files and directions.

[quote=“IamLegend, post:14, topic:167682”]guessed,

I got it all working. I had to edit the xsl file because it was looking for a ‘.’ in the device string but it needed to look for ‘:’ instead.

Anyway, thanks for your xsl files and directions.[/quote]
Sorry about that. Looks like I checked in 1/2 of the fix prior (did the [tt]SQBlaster_I.xsl[/tt] before but didn’t check in the [tt]SQBlaster_D.xsl[/tt]).

In the process, I noticed that the [tt]SQBlaster_D.xsl[/tt] was missing the [tt]TogglePower[/tt] implementation, so I went ahead and added that in. If [tt]TogglePower[/tt] “[tt]OnOff[/tt]” is important to you you’ll want to regenerate your [tt]D_Samsung.xml[/tt] using the newer [tt]SQBlaster_D.xsl[/tt].

btw, my plan here is to migrate this all over from [external] XSLT processing to my pure-Lua implementation. I already have the pure-Lua version “converting” [tt]devxxxxxxxx.xml[/tt] files directly to the counterpart [tt]I_SQdevxxxxxx.xml[/tt] and [tt]D_SQdevxxxxxxx.xml[/tt] files, processing that I do directly on Vera.

…with the correct usage of “:” instead of “.” :slight_smile:

This code will evolve into a “Parent Device” that’ll periodically wake up, and look for [tt]devxxxxxx.xml[/tt] files that have been uploaded to Vera, and convert them over to the Vera-specific file formats (then delete the Vera-local [tt]devxxxxx.xml[/tt])

That’ll make the conversion process automatic. You’d install the existing D_SQBlaster Plugin, and some additional Plugin files that I’m creating, and then simply “upload” the devxxxxxxxx.xml files from SQRemote’s box.net backup, and the Plugin will auto-convert them.

The step after that involves reading “looking for” and then reading, the SQRemote’s config file so I know what SQBlasters you have, and what IR Devices should be attached to which SQBlaster, and then create all the Devices (as children) and perform all of the IODevice associations necessary to make it “just work”.

That should avoid most of the above manual steps, but people will be able to do them if they want to.

At that point, the only thing I’d need to know, that I don’t otherwise know from the SQRemote config data (from it’s box.net backup) is the IP Addresses of the Puck’s themselves (as MiOS doesn’t include Avahi, the lib needed to implement Bonjour reliably)

Anyhow, the goal is to learn from, and then eliminate, the bulk of the problems identified above… It might take a while :wink:

Anyhow, figured an update might be appropriate, since I’ve been posting only “trickle” changes here.

[quote=“guessed, post:15, topic:167682”][quote=“IamLegend, post:14, topic:167682”]guessed,

I got it all working. I had to edit the xsl file because it was looking for a ‘.’ in the device string but it needed to look for ‘:’ instead.

Anyway, thanks for your xsl files and directions.[/quote]
Sorry about that. Looks like I checked in 1/2 of the fix prior (did the [tt]SQBlaster_I.xsl[/tt] before but didn’t check in the [tt]SQBlaster_D.xsl[/tt]).

In the process, I noticed that the [tt]SQBlaster_D.xsl[/tt] was missing the [tt]TogglePower[/tt] implementation, so I went ahead and added that in. If [tt]TogglePower[/tt] “[tt]OnOff[/tt]” is important to you you’ll want to regenerate your [tt]D_Samsung.xml[/tt] using the newer [tt]SQBlaster_D.xsl[/tt].[/quote]

Thankfully I’m a developer and already modified the xsl file to get the TogglePower working :slight_smile:

Hi guessed!

I have a problem regarding how to get work my IR device with SQ Remote via scene in Vera. I posted ticket to John and Mat (squareconnect.com) but they point me to you.

I tried to do all steps you wrote in this topic but with no success.
My Vera runs on 1.1.1236

Any advise is appreciated.

Boris

Hey Boris,
I’ll need details as I cannot read the SQConnect’s Ticketing system.

Please bundle together:
a) Your [tt]devxxxxxxxx.xml[/tt] files from Box.net backup
b) Your [tt]PackageDevices.xml[/tt] from your Box.net backup
c) A detailed description of what you’ve done so far.
d) Your derived [tt]D_Xxxxxxx.xml[/tt] and [tt]I_xxxxxxx.xml[/tt] files using the XSLT process that’s been outlined.

I do have a Pure Lua implementation that will do all the [XSLT] conversions for you, but it hit a runtime bug in MiOS that’s prohibiting me from deploying it to folks. It’s a pity, as that codebase will do it all after you upload (a) and (b) above to Vera, and do a restart (it converts all the [tt]devxxxxx.xml[/tt] files, instantiates them as IR devices, instantiates all your Puck’s, and wires them all together). The only thing you’d do is upload your source ([tt]devxxxxxx.xml[/tt]) files, and apply IP addresses to the Puck, and everything else is done for you…

If you’re technical, send me a PM and I’ll send you instructions to that version since you can use it to do the conversion steps also, avoiding the XSLT, even if you don’t use it for Runtime.

I’ve updated the SQBlaster instructions with a section on “debugging”, which is here:

http://code.mios.com/trac/mios_sqblaster/wiki/Debugging-UI4

It’s only at start at the moment, but it contains some of the common log output corresponding to “successful” and “failed” IR Cases in the MiOS Log files when working with IR Devices.