Looking good - thank you again for all the work you have put into this @guessed.
Thank you, Guessed!
The problem is solved and it was in the following:
Our Implementation file (I_SamsungSoundBox.xml) has a different name than that declared in the D_SamsunSoundBox.xml file (currently listed as I_SQdev908265815.xml).
[quote=“z-waver.ru, post:23, topic:167682”]Thank you, Guessed!
The problem is solved and it was in the following:
Our Implementation file (I_SamsungSoundBox.xml) has a different name than that declared in the D_SamsunSoundBox.xml file (currently listed as I_SQdev908265815.xml).[/quote]
Thanks @z-wave.ru, good to hear it’s working for you. I’ve added this problem to the debugging doc in case others run into it.
I am trying to interface my LG Air Conditioner to Vera using the SQBlaster plugin. Mat from SquareConnect did a great job was able to isolate the codes for the AC and I have this working great in SQ Remote.
I followed the directions to install the SQBlaster plugin from the wiki. On UI 4, I do not get the text on the icon indicating it is UP, so I am not sure what I did wrong. The IR Blaster - Room device just shows a generic circle/apple looking icon but nothing else. I uploaded the files from the wiki as per the instructions and created the device, entered the IP address but no go.
I did the Xslt transformation of the xml file from the box.net backup, and created an LG air conditioner device from that, but when I create a scene to test it out, none of the commands show up as they are supposed to in the drop down menu. I entered the correct IP address (did not enter a mac address but don’t think I have to…) I am not sure if this would work if the sqblaster device is not configured correctly to begin with.
I attached my box.net backup file, the packageDevices.xml and the derived LG Air conditioner files. I using the shell tools online site to process the files. I looked at the debug log from my vera but there is no line with SQblaster anywhere. Any help would be appreciated!
Vera firmware version 1.1.1245, zwave 3.2
Addendum: I also had an incorrect reference to the implementation file in the descriptor file, but I fixed it. I deleted the SQblaster Plugin and recreated it and now the correct icon and the text with …up appears, so the first issue is fixed. The LG Airconditioner device is still not working though.
Interesting. For the normal AV Devices that SQRemote/SQBlaster use, they generate a “[tt]SQKeyCode[/tt]” attribute value in the [tt]devxxxxxxxx.xml[/tt] file for each IR Code.
These SQKeyCodes come from a pre-fab “table” of codes that SquareConnect maintain, where things like “Volume Up” are made consistent across all types of AV Devices.
My SQBlaster Transform files map these SQKeyCodes, and a handful of alternative [tt]command_name[/tt] attr values, to the corresponding MiOS AV Controls.
There are a few issues in the source [tt]devxxxxxx.xml[/tt] file, based upon the above:
a) None of the IR Codes in here have SQKeyCodes
Without [tt]SQKeyCode[/tt] values, the transform doesn’t map anything to the MiOS AV counterparts
Here are some examples that [minimally] should be setup in the [tt]devxxxxxxxx.xml[/tt] file:
The “Power Off” code needs to have a [tt]SQKeyCode[/tt] of 3, if it truly represents the Discrete-code for “Off”
The “Power On/Off” code needs to have a [tt]SQKeyCode[/tt] of 1
The “Off” code needs to have a [tt]SQKeyCode[/tt] of 3, if it represents power Off
b) You have multiple Power “off” codes, per the above.
As someone once said “There can be only one”, mostly since these “off” codes will map to a single MiOS “Off” code, and there can only be one of those.
c) There are a whole bunch of AirCond specific codes that have no counterparts in MiOS’s AV setup.
Things like “Temp Up”, “Temp Down”, “Deg C/F”, “Low”, “High”, etc, etc.
Since there’s no logical equivalent, there’s no automated way to map these. Of course they could be mapped to any of the AV Codes, just so they could be activated, but that would have to be done manually
d) There are a series of recording-specific codes
These are like:
[i]Set nn - Cool - F1[/i]
where nn is between 60 and 86
and they appear to be repeated. Since these are recording specific, there’s no mapping similar to item (c) above.
If you’re just trying to map On/Off functions, then fill in the SQKeyCodes (per the above) and re-run the transform. Mat/John should tweak what they generate for this (if possible) to put in the Key codes.
For a broader AirCond control there’s a gap, since MiOS has AV controls but not AirCond ones, so that would need to be added to MiOS itself.
Very good point. I will talk to John about creating a set of standard sqcodes for air conditioners, and make sure we adhere to them as we expand the number of units .
The lg was unusually straight forward to capture as we were able to get both discrete up/down as well as the more typical “complete state”. The complete state codes are the ir equivalent of scenes… A single command puts the air conditioner into a known state. However, even those could probably be mapped. I’ll talk to John about how we can do this.
Mat
Thanks for you reply!
I tried pruning down the xml files to the bare minimum, with just an OFF and a Power ON/Off command to see if I could get it working. There were some mistakes in the D_LGAirCond.xml file (typos) that I fixed and I tried to get this to work but no luck. I changed the SQKey codes as you suggested but the options for Off or Power On/off do not show up when I go under the Advanced tab in creating a scene. I tried the manual steps to reassign the IO to the device number of the blaster (60) as you described with the manual bug for a previous version of the vera firmware but that did not make any difference.
I think it is something stupid that I am just missing. Here are the new xml files.
Yes, they’re a little off from what my XSLT Transforms would generate. Generally, you’d have to edit the source [tt]devxxxxxxxx.xml[/tt] and add the [tt]SQKeyCode[/tt] information in and then regenerate the [tt]I_SQdevxxxxx.xml[/tt] and [tt]D_SQdevxxxxx.xml[/tt] files from that [edited] source file.
Unfortunately, adding these SQKeyCode’s directly into the generated I_ and D_ files won’t help since the horse has bolted already.
Anyhow, I’ve attached what it likely would have generated for both the I_ and D_ files “trimmed down” to just the [tt]TogglePower1::OnOff[/tt] and [tt]DiscretePower1::Off[/tt] codes that you had.
I haven’t tried these, but they should be functionally what I would have generated.
I tried these new xml files also but still there is some problem.
I deleted the old LG Airconditioner device, and SSH 'd into vera to manually delete any files related to LG Airconditioner (there were just the 2 old xml files).
When I set up the device again (LG Air Conditioner) there is no IR “Logo” like there is for the “IR-Blaster Room”. I don’t think this is being recognized as an IR device.
To create the device after I uploaded the new I_xxxx.xml and D_xxx.xml files under the Lua tab, I created the new device using these 2 xml files in the correct spaces. I hit create device, saved, then went into the device advanced tab and entered the correct ip address, and saved. That did not work when I set up a new scene (pull down in Advanced scene tab did not show commands).
I went back to the LG Air Conditioner device and under Advanced tab, variables I set up New service: urn:micasaverde-com:serviceId:HaDevice1, new variable: IODevice New value 60 (the device number for my “IR Blaster-Room”) but still the drop down does not contain the commands when I create a scene in the Advanced scenes tab.
Is there something I am doing wrong in the setup?
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.
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 [tt]devxxxxxx.xml[/tt] file, so they should not have generated into the [original] D_ and I_ files.
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.
Any Progress? I am in the process of building an house using mini splits.
@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?
What brand/model of mini-splits are you planning on using?
Mat
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)
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
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?
In theory, you’d add the [tt]BinarySwitch1[/tt] 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 [tt]luup.chdev[/tt] methods, but have the Parent (IR) device handle all of the events of the Child ([tt]1[/tt] in [tt]D_SQdev1401130560.xml[/tt])
eg. basic device creation example from the Weather code http://code.mios.com/trac/mios_weather/browser/trunk/I_GoogleWeather.xml#L264
eg. [tt]handleChildren[/tt] example from the RFXCOM code D_RFXCOM.xml – RFXcom Gateway
Then add [tt][/tt] blocks for the Switch events, this would look like the following, and be put into the IR device implementation file ([tt]I_SQdev1401130560.xml[/tt]):
eg. [tt][/tt] block for [tt]urn:upnp-org:serviceId:SwitchPower1[/tt] from the RFXCOM code I_RFXCOM.xml – RFXcom Gateway
Then implement if… then… else logic, along with [tt]luup.call_action(…)[/tt] to invoke the various handlers on the Parent to send the IR commands.
[tt]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[/tt]
That’s not all of it, but it’ll get you a good starting point to experiment with … 8)