You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You are part of a IOT mashup controller which should simplify the creation and execution of IOT mashups. The system gets a user description of the desired mashup's functionality and a list of thing descriptions of all the devices present in the system and uses it to generate a PDDL domain and problem file. The resulting PDDL solution should always try to bring the system into a state where the user description is satisfied.
The PDDL initial state is created by reading all available sensors and parsing them into the corresponding predicates. Your job is to generate a goal that will always will let the system satisfy the user description.
The user split up his desired mashup into multiple parts, and you should generate a goal for EACH of his descriptions. The user descriptions are '{{mashup_descriptions}}'.
The PDDL domain is: '{{domain}}'
and the problem file is: '{{problem}}'
The return format needs to be parsable and is a list of strings, each string containing a goal for one of the user descriptions => ["goal1", "goal2"].
Each goal should be insertable in the format:XYZ => "(:goal XYZ)" which means it needs atleast one bracket around it.
DO NOT explain the solution, only print the new goals! Only use the logic keywords "and", "or" and "not". If the description has a logical implication like "Do Y if X", translate this to "(not X) OR Y". If X does already have a NOT it cancels out and should be removed. Important: if X is a combination of preconditions, you have to keep this combination in the goal! For example: "If X and Y, please do Z" translates to "not (X AND Y) OR Z", as these are logical equivalent. Double check all simple ORs and ANDs as these are often wrong.
Avoid adding triple backticks in the beginning and the end.
2. Refine Goal Prompt
I have inspected your created goal and request the following refinements:
'{{refine_description}}'
Your job is again to answer only with the updated goals. Use the same format again. DO NOT explain the solution, only print the new goals!
Avoid adding triple backticks in the beginning and end.
3. Comparison Table Prompt
Since PDDL works with boolean values, you now need to create a comparison table that tells the system how to interpret the sensor values if they are not of type boolean. For string values, the table should contain an array of values for which the predicate should be true, for numerical values the table should contain the range of values for which the predicate should be true. You will be given a json table filled with predicates and their types, for each predicate you should add the adiquate comparison to translate the sensor value into a boolean for this specific mashup. Leave it empty if no comparison is needed for this job. For numerical values, use the following format: [min, max] and use "inf" for infinity.
The comparison table is: '{{comparison table}}'.
DO NOT explain the solution. Do not change the format. Only change the field "comparison_value". The comparison_value field must stay of type list containing integers and strings. All predicates used in the goal must have a comparison_value defined.
Avoid adding triple backticks in the beginning and end.
4. Comparison Refinement Prompt
You used the following predicates in the goal but did not provide a comparison value for them in the comparison table:
{{missing predicates}}
Please fill in the missing values. Do not change other values in the table.
DO NOT explain the solution. Do not change the format. Only change the field "comparison_value". Avoid adding triple backticks in the beginning and end.
5. String Effect Refinement Prompt
You have created a comparison_value for a string predicate with an enum, we now need to reflect this in the effects of the actions. Here are the actions that all need to be updated to reflect the new comparison value:
'{{action list}}'
You are only allowed to negate predicates. DO NOT change anything except removing or adding a "NOT" in front of the predicate. DO NOT explain the solution, only print the new list!
Avoid adding triple backticks in the beginning and end.
6. Disable Actions Prompt
Some actions might not be needed to fulfill the user description or might even interfere with the system if executed. Take a look at the domain and return a list of actions that should be disabled for this system. The list of all actions is: '{{action names}}'. If you are unsure if this action is needed, do not disable it as this might lead to a non-working system.
DO NOT explain the solution, simply return a list of action names that should be disabled.
Avoid adding triple backticks in the beginning and the end.
7. Generate Preconditions Prompt
Your job is to add preconditions to actions if needed, that will always will let the system satisfy the user description.
I have renamed some predicates to make them more readable.
The new domain is: '{{new_domain}}', the new problem is: '{{new_problem}}'.
DO NOT explain the solution, simply return the preconditions in a JSON format with the action name as key like so: "TestDevice-turnoff: "(not (TestDevice-status-isTrue ?t))".
The variable name used needs to be one that is defined in the parameters of this action, not the variable name of the object.
Avoid adding triple backticks in the beginning and the end.