I was just wondering as I’ve been looking at various AI tools if anyone has tried to create their own OH scripts using an AI tool like OpenAI Codex in say Javascript?
tl;dr: I’ve yet to see ChatGPT or Bard produce working OH rules code. I’ve not messed with Codex but am not hopeful. These LLM AIs are trained on what ever’s out there on the Internet. The bulk of rules code for OH on the Internet are on this forum. And the bulk of those are examples of code that people need help with (i.e. not working).
Add to that that openHAB is niche much of the JavaScript it generates is going to be generic JavaScript or Node.js JavaScript which isn’t necessarily compatible with OH.
Finally, most of these LLM systems are trained on data downloaded from the Internet a couple of years ago. That’s ages in openHAB time and much of that code isn’t compatible with current openHAB.
1 Like
Now when I did my search nothing came up but then I didn’t use ChatGPT in the search - thanks @rlkoshak
I would say the same is true for quite a lot of examples stackoverflow. Non the less it’s actually fun to use for example ChatGPT to develop a shell script by describing requirements and iteratively improving the result by giving feedback. I would assume that something similar should be possible with openHAB scripts in DSL/Jython/JavaScript/YouNameIt 
Disclaimer: You should be able to understand the resulting code and only run it if you are sure about every single line in the script. Similar to textual answers ChatGPT & Co are great at delivering result that only seem valid.
1 Like
Valid point - might be less bad with GPT 4 because of the newer training data
In my experiments, you basically have to be an expert in rules code (language of your choice) to get past the first step. In the end I found it much easier to just go write it than to fix all the many things wrong. Often the stuff that is wrong is pretty subtle or assumes things that are common in the language of choice but which are not possible in OH rules (e.g. build a bunch of code that hinges around await in JavaScript which isn’t supported in OH rules).
For example (ChatGPT):
Prompt:
Create an openHAB rule in JavaScript that is triggered when the Item IsCloudy changes to ON and sends an ON command to the Item WeatherLights, but only if it’s between 8 am and 10 pm.
Response:
var ScriptExecution = Java.type('org.openhab.core.model.script.actions.ScriptExecution');
rule "Cloudy Weather Lights"
when
Item IsCloudy changed to ON
then
var currentTime = now.toLocalTime();
var start = new java.time.LocalTime(8, 0, 0); // 8 am
var end = new java.time.LocalTime(22, 0, 0); // 10 pm
if (currentTime.isAfter(start) && currentTime.isBefore(end)) {
ScriptExecution.createTimer(now.plusMillis(100), [ |
WeatherLights.sendCommand(ON)
])
}
end
Problems with the response:
- The fist line is a Nashorn JS style import which would be needed if this were in fact JS, but…
- That’s Rules DSL, not JavaScript
- The semicolons are superfluous; not necessarily a problem
java.time.LocalTimedoesn’t have constructors, it has the static methodofused to create a new LocalTime- The timer is pointless here
What it gets right: (this is one of the most “correct” rules I’ve seen it produce, maybe it’s getting better)
- The structure of the rule works for Rules DSL.
- Except for the minor problems with the constructor, the time test works out.
A “correct” Rules DSL would look like:
rule "Cloudy Weather Lights"
when
Item IsCloudy changed to ON
then
var currentTime = now.toLocalTime();
var start = LocalTime.of(8, 0, 0); // 8 am
var end = LocalTime.of(22, 0, 0); // 10 pm
if (currentTime.isAfter(start) && currentTime.isBefore(end)) {
WeatherLights.sendCommand(ON)
}
end
But we asked for JavaScript which would be radically different. If we assume GraalVM JS Scripting it would look something like:
rules.JSRule({
name: "Cloudy Weather Lights",
description: "Turn on the lights when cloudy between 8am and 10pm",
triggers: [triggers.ItemStateChangeEvent('IsCloudy', 'OFF', 'ON')],
execute: (event) => {
if(time.toZDT().isBetween(time.toZDT('8:00 AM'), time.toZDT('10:00 PM'))) {
items.WeatherLights.sendCommand('ON');
}
},
tags: ["Lights"],
id: "CloudyWeatherLights"
});
or using the rules builder
rules.when().item('IsCloud').changed().toOn().then(event => {
it(time.toZDT().isBetween(time.toZDT('8:00 AM'), time.toZDT('10:00 PM')) {
items.WeatherLights.sendCommand('ON');
}
}).build('Cloudy Weather Lights', 'Turn on the lights when cloudy between 8am and 10pm');
or if it were a UI rule
configuration: {}
triggers:
- id: "1"
configuration:
itemName: vIsCloudy
state: ON
type: core.ItemStateChangeTrigger
conditions:
- id: "1"
configuration:
startTime: 08:00
endTime: 22:00
type: core.TimeOfDayCondition
actions:
- inputs: {}
id: "4"
configuration:
type: application/javascript;version=ECMAScript-2021
script: >-
it(time.toZDT().isBetween(time.toZDT('8:00 AM'), time.toZDT('10:00 PM')) {
items.WeatherLights.sendCommand('ON');
}
type: script.ScriptAction
Edit: When I corrected it and told it that isn’t JavaScript but Rules DSL, it apologized and generated this:
var logger = Java.type('org.slf4j.LoggerFactory').getLogger('org.openhab.rule.' + ctx.ruleUID);
var ScriptExecution = Java.type('org.openhab.core.model.script.actions.ScriptExecution');
var ZonedDateTime = Java.type('java.time.ZonedDateTime');
rule("Cloudy Weather Lights")
when
Item("IsCloudy") changed to ON
then
var currentTime = ZonedDateTime.now().toLocalTime();
var start = LocalTime.of(8, 0, 0); // 8 am
var end = LocalTime.of(22, 0, 0); // 10 pm
if (currentTime.isAfter(start) && currentTime.isBefore(end)) {
ScriptExecution.createTimer(ZonedDateTime.now().plusMillis(100), function() {
events.sendCommand("WeatherLights", "ON");
logger.info("Cloudy Weather Lights turned ON");
});
}
end
Still Rules DSL, now with more pointless Nashorn style JS imports.
1 Like
Ok, that’s much worse than expected 
Did you use GPT 3/3.5 or GPT 4? I did not test 4 myself but was told that the coding support was one of the big improvements between 3 and 4
(And yes, as far as I know GPT 4 is currently only available when you are a paying customer. For GPT 3/3.5 there are at least some workarounds to test it for free - for example the AI Chat in Wavelength)
It’s 3.5. I’m not sure how to test it with 4. I would hope that it would be better but I’m still skeptical. The big problem I see is that looking at the forum the model is going to see a ton of rules. But even still I’d guess about 80% of them will be Rules DSL with the rest of the languages having less than a few percent each. And there’s very little to tell the model “this rule is Rules DSL, that one is Nashorn JS, that one is GraalVM JS” and so on. So as soon as you give it the term “openHAB”, it’s going to generate Rules DSL just because of the statistics if nothing else.
Given what happened above though, if you want Rules DSL ChatGPT might be not half bad. Though you still have to know your stuff to recognize that it got the constructor wrong on LocalTime and the Timer is pointless.
1 Like
Agreed
As far as I’m aware the only way to use GPT 4 is, to subcribe for a paid GPT subscription And no, I did not do that (yet).
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.