HitLights LED Lighting Strip

[macrho]

I picked up the following from amazon:

http://www.amazon.com/gp/product/B005QDO8YU/ref=oh_details_o01_s00_i00?ie=UTF8&psc=1

It's a pretty cool device for $39, colors and intensity are fairly easily controlled through the IR remote that comes with the device.

I decided to read in some of the IR codes using SQRemote HD app on my iPad, saved the configuration to box.net and then grabbed the corresponding xml file: dev3470926278.xml

I then used the new XSL files found here: http://forum.micasaverde.com/index.php/topic,5734.0.html

and created my

D_SQdev3470926278.xml and I_SQdev3470926278.xml

files

I then created a device called HitLights using the above 2 generated files

and finally added the IODevice variable:

   New service:    urn:micasaverde-com:serviceId:HaDevice1
    New variable:   IODevice
    New value:    90

In the generated D_SQdev..xml file, I see only one service, TogglePower. I assume others aren't listed as I have non-standard names for the action, hence no map?

Anyway, when I go to a scene and try to add the HitLights device to it, it is grayed out hence I can't event select togglepower

What have I done wrong?

[a-lurker]

Had a very quick look - the file D_SQdev3470926278.xml  does not have an opening "device" tag. Also the deviceType should probably be "urn:schemas-micasaverde-com:device:IrDevice:1" In the  I_SQdev3470926278.xml file all the serviceId(s) are the same - they should be different. As I understand it, the codes in the IR tags should be Pronto Codes. The codes in the file appear to be something else.

You may also be interested in this:

http://forum.micasaverde.com/index.php/topic,13418.msg99897.html#msg99897

and this:

http://forum.micasaverde.com/index.php/topic,12857.0.html

[macrho]

I've made changes to my device and implementation files but am still having no luck

I believe I have pronto hex codes now.
I have a global cache IRL and simply read the power button toggle in, which looks right?

0000 006D 0000 0022 0155 00AA 0015 0014 0015 0014 0015 0014 0015 0014 0015 0014 0015 0014 0015 0014 0015 0014 0016 003F 0016 003F 0016 003F 0016 003F 0016 003F 0016 003F 0016 003F 0016 003F 0015 0014 0015 0014 0015 0014 0015 0014 0015 0014 0015 0014 0016 003F 0015 0014 0016 003F 0016 003F 0016 003F 0016 003F 0016 003F 0016 003F 0015 0014 0016 003F 0015 0ED8


Other suggestions?

[a-lurker]

The xml files look pretty OK and the pronto codes look like pronto codes now. When you say it doesn't work. Can you make a device using these xml files? Have you associated the device created with the blaster device? If all OK so far; does the IR LED emit any IR light? Any errors in the log file?

In file I_SQdev3470926278.xml there is a stray backslash after the tag </action> and you specified the xml files as using UTF8 encoding but I wouldn't have thought that either of these would cause any problems - especially the latter.

[macrho]

I removed the stray backslash and created the device again
I assume I associate the device with the SQ Blaster Plus by adding a new variable under the Advanced tab:

New service: urn:schemas-micasaverde-com:device:IrDevice:1
New Variable: IODevice
New value: 61

61 is the device # for my SQ Blaster Plus

I then restarted the vera3 twice, by pressing reload and went to automation tab and tried to add my new device to a scene. The device shows up but with a red circle with a 45 degree line through it

[a-lurker]

The device created by D_SQdev3470926278.xml and I_SQdev3470926278.xml files (and after a few Vera Engine Restarts) should contain a pull down list of all the IR ports that Vera knows about. In your case, you should see on the list the SQ Blaster in the "Settings" tab of the device that contain the Pronto Codes.

However the method you have used (ie manually adding the variable ID of the blaster) should work - I've not tried this approach. At this stage I should say I'm not familiar with SQ Blasters but the interfacing should be pretty much the same for all IR devices.

On the device having a red circle and cross through it:  You have provided sufficient files for Vera to know about the IR device codes but not sufficient for the User Interface to display anything useful about your device/plugin. That information is held in the D_xxxxx.json and J_xxxxx.xml files, which are optional. Ie not all plugins make use of a user interface.

All the plugin files are discussed here:  http://wiki.micasaverde.com/index.php/Plugin_Creation_Tutorial

However in the LUUP test area: UI5 --> APPS --> Develop Apps --> Test Luup code (Lua), you can test/run this code: where you replace 41 with the ID of your device/plugin that contains the IR code(s). You can look in the log to see what's happening.

local RGB_LED_ID = 41
local ON_OFF_LED_SID = "urn:micasaverde-com:serviceId:TogglePower1"
luup.call_action(ON_OFF_LED_SID, "OnOff", {}, RGB_LED_ID)
return true

If this works, you can then place it in the LUUP section of a scene. It that all works, you can go on to create your own UI for your device, by adding in the optional D_xxxxx.json and J_xxxxx.xml files.

[guessed]

Had a very quick look - the file D_SQdev3470926278.xml  does not have an opening "device" tag. Also the deviceType should probably be "urn:schemas-micasaverde-com:device:IrDevice:1" In the  I_SQdev3470926278.xml file all the serviceId(s) are the same - they should be different. As I understand it, the codes in the IR tags should be Pronto Codes. The codes in the file appear to be something else.

The original I_ file had SQBlaster "Learned" codes.  As long as these were going to be played back over a SQBlaster, it would have been fine to use.

Technically, the <ir>...</ir> blocks just get "sent" to the IR Transmitter device associated with the IR Device.  It's up to that IR Transmitter to interpret those characters into something meaningful.

In this case, the Lxxxxx prefixed IR Blocks were just the learned codes for OnOff (etc)

[a-lurker]

Thanks @guessed - Can you explain further - how is this invoked and parsed? Just an arbitrary string where you decide the encoding, separators, etc? Do the IR tags just wrap around something like this?

Code: [Select]

<run>
    sendProntoCode(lul_settings.ProntoCode)
</run>

I have previously made a NEC to ProntoCode plugin:

http://forum.micasaverde.com/index.php/topic,13418.msg99897.html#msg99897

I thought I could modify it to just act as code translator?

I'll add any additional info to the Wiki when I get a moment. I hope my other advice has been correct so far?

[guessed]

In the IR stuff, there are always two players, the IR Device, containing one or more <ir> declarations, and the IR Transmitter, containing the SendProntoCode action that's responsible for delivering content to the physical Blaster device.

The IR Device gets associated with the IR Transmitter by the metadata field (referenced earlier)

Now whether this is done via codegen, or whether it's just a function of the engine, that's not clear.  You used to be able to view the source of a plugin's codegen, but that functionality was broken in MiOS some time ago, so you can't use that trick anymore.

Either way, the [string] contents of the <ir> block, from an IR Device file, is delivered "as is" to the SendProntoCode action of the associated IR Transmitter Device.
In most cases, like the GC100, the Kira and the SQBlaster Plugins this information is, in turn, passed simply on to the physical IR Blaster for interpretation.

[macrho]

I finally was able to get the Infrared Transmitter variables to show up under Settings on my HitLights device

I did something incredibly stupid:

In my D_ file I had this line:

      <deviceType>urn:schemas-micasaverde-com:device:IrDevice:1"</deviceType>

Do you see it? The trailing " after 1 and before the closing deviceType tag, doh!

So, I changed it to:

      <deviceType>urn:schemas-micasaverde-com:device:IrDevice:1</deviceType>

associated my SQ Blaster Plus via IODevice and voila

I'm still having a problem though: When I change to one of my automation scenes, the HitLights device does not show any actions, it's the same greyed out circle with a 45 degree line through it

[guessed]

Go into the Advanced pane in the Scene editor, and you'll be able to add stuff there. 

The generic scene editor is, well, very generic and not particularly capable.  I find that a lot of automation needs to be completed in the Advanced pane.

[macrho]

Go into the Advanced pane in the Scene editor, and you'll be able to add stuff there. 

The generic scene editor is, well, very generic and not particularly capable.  I find that a lot of automation needs to be completed in the Advanced pane.

Thank you, it's now visible - will test it a bit later and build up all the actions it can perform.