The definitions are scattered inside the various S_*.xml files on your Vera unit. Probably the easiest way to see some of the more common ones are to look at the source code of a few AV Plugins on http://code.mios.com
The S_.xml define the ACTION names to use, but you have to glean the ServiceId’s from other files. It’s a bit painful (no real doc here either) so it’s sometimes easier to look at the working examples. The downside is that they don’t always exercise all of the potential ACTIONS from each of the S_.xml files, just the common ones.
My Vera got unstable, so I took a look at the logs and found two issues (among others) related with the Sonos plugin:
Every minute, the plugin logs several messages (log1.txt), but one of those has log level 1, so I guess it’s an error. However, It’s not explicit enough, so I don’t know what it means… Is there something wrong with my configuration ? Is it due to the temperature being reported in fareneight ?
Plugin #188 fails to load. After rebooting, UI5 shows “Loading plugin #188” for a minute. The log shows the associated error. According to http://forum.micasaverde.com/index.php/topic,9052.msg59279.html#msg59279 It doesn’t seem to be required at UI5, but the instructions for it’s removal refer to a hidden plugin, and my SQ Blaster plugin, as well as the 4 independent IR channel plugins (using S Blaster plus) are visible at the interface. Should I remove as explained under the refered link ?
@guessed, is the new changeset, published at May 24, already avaliable ?
The latest code samples the blaster every minute, to get Temperature readings from SQBlaster+ models. This is logged at log level 1, not for any valid reasoning other than I like it to stand out in the logs
You don’t mention the specifics of what your seeing wrong, so I can’t tell if it’s this, or something else.
#188 is a long standing issue wit the SQRemote Plugin that MCV didn’t automatically cleanup during UI5 upgrade. It’s benign and, in theory, can be cleaned up using a technique that @mcvflorin posted in one of the threads here. I’m waiting for them to automatically clean it up, as CTs shouldn’t have to do that upon product upgrade.
I can’t tell If the 0.32 build is in apps.mios.com, as the site is erroring with a full screen SQL syntax error (no testing?)
I suspect it is there, I just can’t check it right now.
I’ve made mods to the code to move messages into better buckets.
[tt]50 … SQBlaster: …[/tt] Startup, and the periodic updates go into level=50
[tt]35 … SQBlaster: … debug:[/tt] Debug now go into level=35
[tt]01 … SQBlaster: … error:[/tt] Errors go into an error level=1 (red)
The periodic processing now goes into level 50, the first bucket, so they won’t be red anymore, but they are still emitted.
Errors, like not being able to contact the SQBlaster are now errors, and will appear red in the log files.
When we have a reasonable set of changes to bundle, these will be put into apps.mios.com (etc) but for now they’re just untested in trunk.
New to this, but am I right in thinking that if you parsed the devxxx.xml file into D_xxx.xml, I_xxx.xml and S_xxx.xml, and linked them correctly inside, you would end up with a device that exposed services for all IR codes in the devxxx file (and no extras)?
If so, what would be the disadvantage against using the “standard” service interfaces?
[quote=“Weeves, post:87, topic:167682”]New to this, but am I right in thinking that if you parsed the devxxx.xml file into D_xxx.xml, I_xxx.xml and S_xxx.xml, and linked them correctly inside, you would end up with a device that exposed services for all IR codes in the devxxx file (and no extras)?
If so, what would be the disadvantage against using the “standard” service interfaces?[/quote]
More or less, except I don’t create the S_xxx.xml file, it would be pointless since Vera’s UI is really just for setup, not for use (in practice)
By implementing MCVs AV/IR services, control points can know what to expect when calling the device. Right now, SQRemote and the built in HTML/Image one are the only control points that do, but it means they can pickup and work with the Devices directly.
Like anything, you can always go custom, but then the control points won’t know how to call you. It be akin to everyone building their own ‘switch’ service, no one would be able to call it.
Hello all. I’ve been using the Vera for lighting, locks, alarm and HVAC for awhile now. Thanks to help from Guessed and his fantastic drivers, I’ve got a great platform.
My next project is integrating audio/visual. I’ve been looking at the SQ Blaster Plus, and I am pleased to see so much activity on this forum in regards to custom setups and troubleshooting.
My main question is the disturbing lack of Android support for the native apps. I note the presence of aftermarket apps made by other people… but is an apple handheld mission critical to use or install this device properly? Will I lose any functionality or whatnot if I don’t use the first party iOS apps? I’d rather not spend the many hours and the money to learn the system, if I’d be limited by OS support.
My second question is I can’t seem to find a database of compatible IR devices. I’m looking for a cheap media box that has XBMC support. I’m considering something like the G-Box Midnight MX2, or the Ouya if they ever get their act together. (And someone comes up with an IR dongle arrangement) Anyone know how the IR support is for some of the newer more exotic computers?
Can someone please point me towards the xls files that I’m supposed to run through the transform process with my xml files for the devices. When I try to follow the links it says they are private and I need to login. Thanks in advance.
