Vera + Puck would = :) mbairhead

[mbairhead]

So is their any word on who (if anyone) is working on getting Vera and the Puck together? If so, how's it coming?

[SquareConnectMat]

MiCasaVerde are working on this.... I can not speak for them on when this will be available

Mat

[mbairhead]

Wow...ask and ye shall receive. Thanks guessed, I'll try this out later today.

[strangely]

d) The code hasn't been tested in a while, and @strangely reports a few kinks in using it lately...  I'd love to hear more details
e) The code hasn't been updated to the latest SQBlaster API's, and uses a legacy throwback API that might be causing (d)

Haven't really looked into this but despite the blaster being able to receive the Vera commands pronto codes (I can see in the syslog), only very rarely does one register on the two devices I'm trying to blast to. If I get some time I'll perhaps try to capture what it sends with the old USB-UIRT on my PC.

@mbairhead, it'll be interesting to see your mileage with it?
Also if you had another device already like a USB-UIRT or a GC100 etc then you can just re-assign the IODevice number that the Puck represents (obviously have to add it first) to your old plugin in the IODevice field and save.

[fall-line]

Apologies if I am being dense, but I think I need a little help to utilize this plugin. I installed it as instructed, which went well. I then added a couple of devices that were actually found just fine in the internal database, such as my Denon Receiver (which uses D_DENONAVR889.xml.lzo) and my Sharp Aquos TV (D_Aquos.xml.lzo). When adding the devices I was able to send Test codes to them via the Test buttons next to the actions, and control worked just fine. However, now that I have gone ahead and added them, I see the new devices (called _TV and _Receiver) showing up in my devices list, but am unsure how to actually control them.

The reading I've done referring to the use of manually programmed pronto codes seems to not apply to me since both of these devices were already defined, correct? I would have thought that the actions which I was able to test during the device setup, would then be available under the device once added, and could therefore be added to scenes, etc.

Thanks again!

[guessed]

Ok, so you have two Plugin files (D_DENONAVR889.xml and D_Acquos.xml) that have been "auto" built for you by Vera, based upon it's IR Database. 

In turn, Vera has used these Plugin files to build Vera Devices, specifically _TV and _Receiver.  These Device stubs are meant to represent the physical "TV" and "Receiver".  The "_" is just there to remind you to rename them, and place them into Rooms that make sense.

It's this Physical Device that has a setting to "know" which IR Device it needs to use.  If you have the Puck, and the SQBlaster Plugin, then you'd set the TV and Receiver devices to use the SQBlaster as the "IR" Transmitter.

Now you have the Device stubs in Vera, and you've let Vera know to use the SQBlaster for their IR Control, you can use "Advanced" Scenes (the Advanced Tab) to perform IR Actions against those devices.

The primary use-case for doing all this "dance" is to do things like "Power Off" from Vera, as a part of a larger "Goodnight" type scene where various devices around the house are shutdown.  Obviously, the Advanced Scenes in MiOS lets you do any of the IR actions that the specific Plugin exposes ("ChannelUp", "ChannelDown", "VolumeUp", etc, etc) but it's far more likely that you'd do that directly between SQRemote and SQBlaster. 

That said, you could use it to turn on TV's (etc) whilst you're on vacation, to make the house look more lived in.


and yes, there's a reason that it's being more tightly integrated... to avoid all these discrete setup steps

[fall-line]

Got it - thank you @guessed!

The bit I was missing was going back and setting the recently created devies to be controlled via the IR transmitter, and then adding the control via the Advanced tab in my scenes. The use case you suggest is exactly what I want to do (well, that and a Power on and set input for an audio scene) so this should do nicely. I've looked at the process again and it makes sense to me now. I'll give it a test when I get home.

Thank you again for your help, and the work that you've put into this.

[guessed]

You're welcome.  That was the easiest of Plugins to write, since it really just proxy's over to SQBlaster....  The real work was done in the Puck development.

The "more integrated" one is looking to use mDNS to find the Puck, the same way that SQRemote does.  That alone will be a ton of value (I played for a while to make an mDNS-compatible Lua Library, and it was tough going)

[woodsby]

Thanks so much @guessed... I needed this for remote control outside of my wifi network.

And, using snippets of your code, I created a Logitech PS3 adapter device that has discrete power codes that first ping the PS3 to check power status before turning it on/off.  Since the Playstation button is part of both the on and off sequences, if the PS3 is off and you hit "power off" using the sqblaster directly from sqremote, it turns the PS3 back on... finally, I have solved this problem.

[guessed]

@woodsby, now that's a creative usage of the IR "plugins".  Hadn't considered that one.  I have my Logitech Revue now, so it'll be interesting to see how it can be controlled in these setups as well.

[woodsby]

I am going to do the same for my TV to avoid the 14 second delay before setting the input if the TV is already on.  I was going to bug Mat again for the API, but your plugin gave me all I need.

I wonder if there is a way to make use of the repeat and delay functionality in your plugin.  I'd rather the community work on this than MCV, quite honestly - to avoid distracting them from their priorities.

[guessed]

I wonder if there is a way to make use of the repeat and delay functionality in your plugin.

I'm not 100% on what you're looking for here.  In the current MiOS API's, there's very little scope to handle real IR - the stuff where you get to pressDown, hold, and Release - with corresponding auto-repeat based upon the cycle used.

Are you looking to extend this somehow?

The SQBlaster supports that notion, but I have to dumb it down for the MiOS IR routines.  Hopefully this is something they fix more systematically with their more integrated model.

[woodsby]

I noticed in your code, you have repeat=0 in the sqblaster http call. So if I want to run a scene to control a device that needs to have a button press repeat twice (using sqblaster's repeat functionality to simulate a button hold), do you think there is a way to do this with the sqblaster plugin?  Also, for delays I had to use os.execute(sleep 2) between IR codes. This of course, doesn't allow fractions of seconds. I am wondering if this is something that can also be handled by the sqblaster plugin. What I envision is being able to create macros in the scene advanced tab, rather than hardcoded into the av device plugin. But, I haven't seen the API for the blaster yet, so I don't know.

[fall-line]

I too had to do quite a bit of fiddling with delays and repeats to get a couple of simple IR commands working, but am happy to report that it is working.

I'm happy to be able to shut off my AV gear as a part of my All Off/Good Night scenes from Vera now, as well as being able to turn on and set the correct input on my AV Receiver as a part of my scenes that utilize my poor man's (iTunes based) whole house audio config. As @guessed as mentioned, more advanced control than these uses will likely be much easier once the official SQ Blaster plugin is available.

Thanks again for the help!

[guessed]

Can you lads publish examples of the specific tweaks you're doing?  I want to see them, concretely.

I don't want to exec(sleep) as that would be bad (blocking call), but can achieve it in more elegant manners as required.

It's likely to do what you're looking for that a few API calls will need to be added, then you'd have to do "odd" things in the scene to call these API's to set-or-reset delays prior to making the associated IR callout.


... mostly because these aren't "parameters" within the existing MiOS IR Framework.  Having examples might help us to help-them, to "evolve" these API's tho...