Mac Home Automation

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
=====Info.json: Required Fields=====

Every plugin must have an info.json file in it’s folder. This describes the plugin and it’s environment, the custom Unit types it will use, control the interface that is provided for setup as well as contain the info necessary for Xtenison to build any custom interfaces you need for the plugin as a whole as well as any necessary for individual unit types.


=====Required Fields:=====

**The following keys and information are required for every plugin:**

**Note:** json dictionary keys are case sensitive and due to historical reasons they are not always completely consistent. XTension was originally developed on a case insensitive platform. So please review before you assume.


>**name** String - The name that will be used to show the plugin in the popup of available plugins and also to describe it in log messages or other displays as needed.
  “name”:”Jamie's Super Awesome Weather Control Plugin”,



>**tag** String - Every plugin must have a custom “tag” value. This is how the plugin will be referenced internally even if the name changes. This must be unique. Xtension reserves all strings starting with “xt.” you should create a short string that contains something that sets yours apart from others thaat might make a similar plugin. For example “zwave” is a bad tag for an interface, consider instead something like “james.zwave.lutron” or something more specific. Don’t get too flowery. There is no limit to the length of the tag, but it will be stored many times in the database potentially and used in indexing and other things.
  “tag”:”jamie.weather.vengence”,


>**APIVersion** Integer - The only valid choice here at the moment is **2**
  “APIVersion”:2,


>**vers** Integer - This is an integer version value. Consider it like a build number or something similar. This is independent from the human readable version number. It will be used by the plugin manager to check for updates and so forth. This number should only ever increase as you build new versions. It is not displayed to the user, only compared to the last one when checking for updates.
  “vers”:45,


>**readableVers** String - This is the version that will be shown to the user. It is not parsed and so can be any string that describes what the version is to your users. “1.0” is fine, but might also be “43.200.17b2,7” or if  you’re using Oracle style version numbers there may be 15 or 20 fields separated by periods...
  “readableVers”:”13.667.9823.12 alpha14”,


>**script** String - valid entries are “python3” which is probably what it’s always going to be. If you create a binary plugin that does not need to be run by the built in python interpreter then this should be set to “binary”. In the future there may be more possibilities such as “node” or “lua” or whatever else comes up.
  “script”:”python3”,



>**module** String - The name of the actual plugin script file to run with the python interperter. If you are running a binary plugin program use the “binaryName” field below.
  “module”:”weatherslam.py"


>**binaryName** String - If not using a python or other scripting system and running a binary application use this to give the name of the application inside the isf folder. You may specify either the module key or the binaryName key but it makes no sense to include both.
  “binaryName”:”weatherslam.app”,




>**desc** String - A more long winded description of the plugin. This is still added to the popup plugin selector menu so dont go too crazy.
  “desc”:”For controlling local weather and punishing your political enemies!"



NEXT: [[pluginapi:portpopup]]