This shows you the differences between two versions of the page.
| Next revision | Previous revision Next revision Both sides next revision | ||
|
hekate:heart_howto [2009/08/14 15:10] gjn created, esimon ver imported |
hekate:heart_howto [2012/05/14 13:51] esimon |
||
|---|---|---|---|
| Line 11: | Line 11: | ||
| All of these modes can be run: | All of these modes can be run: | ||
| - | |||
| * from a given state, (//gox/3// predicate) | * from a given state, (//gox/3// predicate) | ||
| * with assumption that all //in// attributes have callbacks written that will be fired before inference process to collect all required data (//goxio/2// predicate) | * with assumption that all //in// attributes have callbacks written that will be fired before inference process to collect all required data (//goxio/2// predicate) | ||
| All information about the inference process, and states are displayed on the console. | All information about the inference process, and states are displayed on the console. | ||
| + | |||
| + | === Running Heart from a console === | ||
| + | To run heart from a Linus console run a bash script //heart// located in heart directory. The script can take 4 parameters: | ||
| + | - HML file to consult. Usage:<code>heart somefile.pl</code> After that, SWI-Prolog will be run, and file given as a parameter will be consulted. | ||
| + | - Tables to be fired. Usage:<code>heart somefile.pl [table1,table2,table3]</code>. After that swi prolog will consult somefile.pl file, and then fire table1, table2 and table3 in DDI mode. If there were callbacks written they also will be fired. | ||
| + | - Inference mode. Usage: <code> heart somefile.pl [table3] gdi</code> After that SWI-Prolog will consult somefile.pl file, and run GDI inference, treating table3 as a goal table. | ||
| + | - Initial state. Usage:<code>heart somefile.pl [table3] gdi state1</code> After that SWI-Prolog will run inference in GDI mode treating table3 as a goal table and taking attributes values from state1. | ||
| | | ||
| === Commands === | === Commands === | ||
| Line 119: | Line 125: | ||
| * **Port** - positive integer number that denotes a port on which the server will listen. | * **Port** - positive integer number that denotes a port on which the server will listen. | ||
| - | The protocol HOWTOis located in [[Protocol HOWTO]]. | + | The protocol HOWTO is located in [[Protocol HOWTO]]. |
| Line 127: | Line 133: | ||
| ==== Protocol commands ==== | ==== Protocol commands ==== | ||
| - | - **[hello,+client_name].** - welcome message that client sends to HeaRT in order to obtain information about version of the protocol implemented on the server, and functionality offered by the protocol.\\ As a result the client gets <code>[true,[heart,hello,1.0,5]]</code> | + | - **[hello, +client_name].** - welcome message that client sends to HeaRT in order to obtain information about version of the protocol implemented on the server, and functionality offered by the protocol.\\ As a result the client gets <code>[true,[heart,hello,1.0,5,[]]]</code> |
| - | - **[model, getlist].** - returns list of all models (with users' names that own them) that are store in HeaRT storage area.\\ As a result of the the client gets following answer <code>[true, [[username1,modelname1],[username1,modelname2], [username2, modelname3]]]</code> If there is no models in the storage area following answer is returned: <code>[true,[]]</code>. If there are errors during reading a model list, following message is returned: <code>[false,]</code>[false,'Error occured while reading a model list']</code> | + | - **[model, getlist].** - returns list of all models (with users' names that own them) that are store in HeaRT storage area.\\ As a result of the the client gets following answer <code>[true, [[modelname1,username1],[modelname2,username1], [ modelname3,username2]]]</code> If there is no models in the storage area following answer is returned: <code>[true,[]]</code>. If there are errors during reading a model list, following message is returned: <code>[false,]</code>[false,'Error occured while reading a model list']</code> |
| - | - **[model, get, +modelname, +username,].** - returns a model specified by modelname and username.\\ As a result client gets following answer: <code>[true,'MODEL']</code> where MODEL is the requested model.\\ If there is no requested model or user, follwing answer is sent: <code>[false,'Model or username does not exist.']</code> | + | - **[model, get, +format, +modelname, +username, +[+parts]].** - returns a model in the given format specified by modelname and username. The parts is a list defining which parts of model should be send in the responce. The following values are permitted: **[all]** - all parts, **[atrs]** all attributes, **[tpes]** - all types, **[tbls]** - all tables, **[clbs]** - all callbacks, **[atr,id]** - attribute with given id, **[tpe,id]** - type with given id, **[tbl,id]** - table with given id, **[clb,id]** - callback with given id. \\ In example, command:<code>[model, get, hml, +modelname, +username, [[atrs], [tpes], [tbl,t]]].</code>get the all the attributes and types and one table with id ''t'' in HML format. The Heart accepts only:<code>[model, get, hmr, +modelname, +username, [[all]]]</code>\\ As a result client gets following answer: <code>[true,'MODEL']</code> where MODEL is the requested model or part of it. \\ If there is no requested model or user, follwing answer is sent: <code>[false, 'Model or username does not exist.']</code> |
| - **[model,exists,+modelname, +username].** - checks if a given modelname that belongs to username is present in HeaRT storage area. If it is stored by the interpreter, following answer is sent to the client: <code>[true,true]</code> If there is no such file <code>[true,false]</code> is sent back. If there is an error during this procedure, following error message is sent to the client: <code>[false,'Error while checking file existence']</code> | - **[model,exists,+modelname, +username].** - checks if a given modelname that belongs to username is present in HeaRT storage area. If it is stored by the interpreter, following answer is sent to the client: <code>[true,true]</code> If there is no such file <code>[true,false]</code> is sent back. If there is an error during this procedure, following error message is sent to the client: <code>[false,'Error while checking file existence']</code> | ||
| - | - **[model,add, +modelname, +username, +'MODEL' ]**. - adds new model to HeaRT storage area, overriding any existing models of the sam ename.\\ If adding succeed, <code>[true]</code> is returned. In case of an error following error message is sent to the client:<code>[false,'Error while saving model.']</code> | + | - **[model, add, +format, +modelname, +username, +'CONTENT_OF_THE_MODEL_IN_SPECIFIED_FORMAT' ]**. - adds new model to the server storage area, overriding any existing models of the sam ename.\\ If adding succeed, <code>[true]</code> is returned. In case of an error following error message is sent to the client:<code>[false,'Error message.']</code> |
| - **[model,remove, +modelname, +username].** - removes a model specified by modelname and username. After successful deletion fo the model <code>[true]</code> is returned. In case of an error, following error message is sent back to the client<code>[false,'Error while deleting model.']</code> | - **[model,remove, +modelname, +username].** - removes a model specified by modelname and username. After successful deletion fo the model <code>[true]</code> is returned. In case of an error, following error message is sent back to the client<code>[false,'Error while deleting model.']</code> | ||
| - **[model,run, +modelname, +username, +{ddi | gdi | tdi | foi}, +tables, +{statename | statedef} ].** - runs inference process for the specified by specified model in one of the four modes, ddi, gdi, tdi or foi for given tables (schemas) - (see [[gox/3]] for details). State from which the inference should start can be either a name of the state that is located in HMR file, or a full definition of the state. The full definition of the state (statedef) should look as follows: <code>[[attribute_name1, value],[attribute_name2, value] ... ]</code> If the inference process succeed, the following answer is sent back to the client:<code>[true,system_state, system_trajectory]</code> The system_state is final state of the system defined as statedef. The system trajectory is a list of rules that were fired in the form of <code>[schema_name,rule_id,schema_name, rule_id, ...]</code> If there is an error during this procedure, the following error message will be sent back to the user: <code>[false,'Error occurred while running model']</code> | - **[model,run, +modelname, +username, +{ddi | gdi | tdi | foi}, +tables, +{statename | statedef} ].** - runs inference process for the specified by specified model in one of the four modes, ddi, gdi, tdi or foi for given tables (schemas) - (see [[gox/3]] for details). State from which the inference should start can be either a name of the state that is located in HMR file, or a full definition of the state. The full definition of the state (statedef) should look as follows: <code>[[attribute_name1, value],[attribute_name2, value] ... ]</code> If the inference process succeed, the following answer is sent back to the client:<code>[true,system_state, system_trajectory]</code> The system_state is final state of the system defined as statedef. The system trajectory is a list of rules that were fired in the form of <code>[schema_name,rule_id,schema_name, rule_id, ...]</code> If there is an error during this procedure, the following error message will be sent back to the user: <code>[false,'Error occurred while running model']</code> | ||
| Line 145: | Line 151: | ||
| ==== Protocol examples ==== | ==== Protocol examples ==== | ||
| - | - Adding a model <code> [model,add,'MyName','Username','xtype [ name: week_days, base: symbolic, ordered: yes, domain: [moday,tuesday], desc: \'This is only one definition\'].']. </code> | + | - Adding a model in hmr format <code> [model,add,hml,'MyName','Username','xtype [ name: week_days, base: symbolic, ordered: yes, domain: [moday,tuesday], desc: \'This is only one definition\'].']. </code> |
| - | - Getting a model <code> [model,get,'MyName','Username'].</code>As a result following message should be returned:<code>[true, [xtype[name:week_days, base:symbolic, ordered:yes, domain:[moday, tuesday], desc:'This is only one definition'].]]</code> | + | - Getting a whole model in hmr format <code> [model,get,hmr, 'MyName','Username', [[all]]].</code>As a result following message should be returned:<code>[true, [xtype[name:week_days, base:symbolic, ordered:yes, domain:[moday, tuesday], desc:'This is only one definition'].]]</code> |
| - | - Getting a list of all models stored by the server: <code> [model,getlist].</code> Folling answer can be returned:<code>[true, [[PHP, hqedmodel0], [PHP, temostat], [PHP, Termostat2], [PHP, therm-rt], [Username, MyName], [XTTd, Termostat1]]]</code> | + | - Getting all the atrributes and types in hml format <code>[model,get,hml, 'MyName','Username', [[atrs], [tpes]]]</code> |
| + | - Getting a two attribute with IDs ''att_1'', ''att_2'' and all the callbacks in the hmr format: <code>[model,get,hmr, 'MyName','Username', [[clbs], [atr, atr_1], [atr, atr_2]]]</code> | ||
| + | - Getting a list of all models stored by the server: <code> [model,getlist].</code> Folling answer can be returned:<code>[true, [[hqedmodel0, PHP], [temostat, PHP], [Termostat2, PHP], [therm-rt, PHP], [MyName, Username], [Termostat1, XTTd]]]</code> | ||
| - Deleting a model: <code> [model,remove, 'MyName','Username'].</code> | - Deleting a model: <code> [model,remove, 'MyName','Username'].</code> | ||
| - Running a model <code> [model,run,'temostat','PHP',ddi, [ms,dt], s1].</code>This command will run a Data-Driven inference from state //s1// on the model //temostat// belonging to PHP user. Following return message can be sent by the server:<code>[true, [[day, 3.0], [hour, 3.0], [month, [2.0]], [season, 3.0], [today, 1.0], [operation, 2.0], [thermostat_settings, 16.0]], [ms, 4, dt, 1, th, 3, os, 7]]</code> Instead of state name, clinet can send a full state definition over the protocol:<code> [model,run,'MyName','Username',ddi, [ms,dt,th,os], [ [day,monday], [hour,13], [month, january] ] ].</code> | - Running a model <code> [model,run,'temostat','PHP',ddi, [ms,dt], s1].</code>This command will run a Data-Driven inference from state //s1// on the model //temostat// belonging to PHP user. Following return message can be sent by the server:<code>[true, [[day, 3.0], [hour, 3.0], [month, [2.0]], [season, 3.0], [today, 1.0], [operation, 2.0], [thermostat_settings, 16.0]], [ms, 4, dt, 1, th, 3, os, 7]]</code> Instead of state name, clinet can send a full state definition over the protocol:<code> [model,run,'MyName','Username',ddi, [ms,dt,th,os], [ [day,monday], [hour,13], [month, january] ] ].</code> | ||
| Line 157: | Line 165: | ||
| === JHeroic === | === JHeroic === | ||
| - | Download JHeroic (version 1.0.1): {{:student:msc2009_xtteng:jheroic.zip|}} | + | Download JHeroic (version 1.0.1): {{jheroic.zip|}} |
| When you download file with JHeroic library there will be file called "make". Using it you can build jar archive and then you can add it to your project. If you would like to compile this library manualy you have to: | When you download file with JHeroic library there will be file called "make". Using it you can build jar archive and then you can add it to your project. If you would like to compile this library manualy you have to: | ||
| Line 183: | Line 191: | ||
| === YHeroic === | === YHeroic === | ||
| - | Download YHeroic (version 1.0.1): {{:student:msc2009_xtteng:yheroic.zip|}} | + | Download YHeroic (version 1.0.1): {{yheroic.zip|}} |
| After downloading YHeroic library you can compy YHeroic.py file to you Python project. To include this library to it you must import it | After downloading YHeroic library you can compy YHeroic.py file to you Python project. To include this library to it you must import it | ||
| Line 197: | Line 205: | ||
| </code> | </code> | ||
| - | An example of Python script using YHeroic you can download here: {{:student:msc2009_xtteng:main.zip|}} | + | An example of Python script using YHeroic you can download here: {{yheroic-main.zip|}} |
| === PHeroic === | === PHeroic === | ||
| - | Download PHeroic (version 1.0.1): {{:student:msc2009_xtteng:pheroic.zip|}} | + | Download PHeroic (version 1.0.1): {{pheroic.zip|}} |
| After download library you can copy it to your web page and include to other php script | After download library you can copy it to your web page and include to other php script | ||
| Line 224: | Line 232: | ||
| ===== Callbacks How To ===== | ===== Callbacks How To ===== | ||
| - | Download JHNormal interface: {{:student:msc2009_xtteng:jhnormal.zip|}} | + | Download {{:hekate:callbackslibrary.zip|}}. It is a NetBeans project that contains a set of default components for acquiring data from a user. The components are: |
| + | - silder \\ {{:hekate:cases:hekate_case_cardio:hekate_case_cardio-1-clb.png|}} | ||
| + | - combo box \\ {{:hekate:hekatecases:hekate_case_thermostat:hekate_case_thermostat-1-clb.png|}} | ||
| + | - list \\ {{:hekate:hekatecases:hekate_case_cardio:hekate_case_cardio-2-clb.png|}} | ||
| + | |||
| + | Code is organized in following packages: | ||
| + | * skeleteon | ||
| + | * DataFetcher.java - an abstract class that other callbcks classes have to extend | ||
| + | * RequestInterface.java - the controler | ||
| + | * Response.java | ||
| + | * callbacks | ||
| + | * input | ||
| + | * ComboBoxFetcher.java | ||
| + | * SliderFetcher.java | ||
| + | * TwoListsFetcher.java | ||
| + | * ComboGUI.java | ||
| + | * SliderGUI.java | ||
| + | * TwoListsGUI.java | ||
| + | |||
| + | To fire one of the following GUI callbacks from Prolog, you have to copy the catalog structure to the folder where your HMR file is located, and then add xcall definition in your HMR file:<code>xcall callback_name: [AttName] >>> (jpl_new('skeleton.RequestInterface',[],T), | ||
| + | jpl_call(T,request,['callbacks.input.CALLBAC_NAME',PARAMETERS],Answer), | ||
| + | atom_to_term(Answer,Answer2,_), | ||
| + | alsv_new_val(AttName,Answer2)).</code> | ||
| + | where | ||
| + | * CALLBACK_NAME - is either ComboBoxFetcher, SliderFetcher, TwoListFetcher | ||
| + | * PARAMETERS - is properly formated string with parameters. | ||
| + | |||
| + | ===Examples=== | ||
| + | - For SliderFetcher. Domain should be defined as Min to Max:<code> | ||
| + | xcall ask_numeric_GUI : [AttName] >>> (jpl_new('skeleton.RequestInterface',[],T), | ||
| + | alsv_domain(AttName,[Min to Max],numeric), | ||
| + | concat_atom(['[',AttName,',',Min,',',Max,']'],Parameters), | ||
| + | jpl_call(T,request,['callbacks.input.SliderFetcher',Parameters],Answer), | ||
| + | atom_to_term(Answer,Answer2,_), | ||
| + | alsv_new_val(AttName,Answer2)).</code> | ||
| + | - For ComboBoxFetcher and TwoListsFetcher. <code> | ||
| + | |||
| + | xcall ask_GUI : [AttName] >>> (jpl_new('skeleton.RequestInterface',[],T), | ||
| + | alsv_domain(AttName,Domain,_), | ||
| + | Params = [AttName|Domain], | ||
| + | term_to_atom(Params, AtomParams), | ||
| + | jpl_call(T,request,['callbacks.input.ComboBoxFetcher',AtomParams],Answer), | ||
| + | atom_to_term(Answer,Answer2,_), | ||
| + | alsv_new_val(AttName,Answer2)).</code> | ||
| + | | ||
| + | |||
| ===== Miscellaneous ===== | ===== Miscellaneous ===== | ||
