Structures or Objects to group Items?

Setup, Configuration and Use Items & Sitemaps
15

I’ll do that. I spent a lot of time trying to find examples and make sense of jsr223. I started by converting all of my Minimote (zwave scene controller remote) DSL rules, and then jumped into my Mother of Mother of All Light Rules rule. :slight_smile: Surprisingly, I didn’t see any performance benefit from it (both ran ~20-30ms), and with the bug I ran into, I stopped converting to jsr223. I plan to put the code for my post into Github, so I’ll include both versions, but the jsr223 one doesn’t currently trigger (I had been testing by changing an item in Karaf). Another hurdle with understanding the info in the forum on jsr223, is separating the default ESH API and the modules and scripts from JSR223 Scripters. When I’m looking for something to do, I’ll start posting some jsr223 conversions in your DPs too. Who could create a new categpry in the forum for jsr223, and subcategories Jython, JS, Groovy, etc.?

I’ve actually done it a few ways, but currently it is just hard coded as a global. I would really like to move from using the hashmap to item metadata, but I haven’t yet gotten a response to that question. There’s a sample of the hashmap in that thread. I do file operations for TTS (I used pico2wave, but currently use flite), so it wouldn’t take much for me to pull it in from a file. I had actually thought of the possibility of doing this so that I could make a site to modify the values. I just haven’t had a need because changing values is rare and easy to do in the rule file.

The gist of it is to have gArea_Trigger and gArea_Action groups, and a single rule that will turn on/off lights, speakers etc. for the items in gArea_Action, depending on the state of its corresponding gArea_Trigger. I was able to remove over 500 lines from my rule files with this, and performance is the same to very slightly higher then previously. The tricky part is figuring out the group logic!

The rule is a little simpler, but I prefer the FileReader version because building the XML would be a headache.

import java.util.HashMap
import java.util.Properties
import java.io.FileInputStream

rule "Test"
when
    Item Virtual_Switch_1 received command
then
    var Properties prop = new Properties
    val String propFileName = "/opt/openhab2/conf/test/test.xml"
    prop.loadFromXML(new FileInputStream(propFileName))
    var HashMap<String,String> test = new HashMap<String,String>
    for (String key : prop.stringPropertyNames()) {
        val String value = prop.getProperty(key);
        test.put(key, value);
    }
    logDebug("Rules","Test: [{}]",test.toString)
end

Where test.xml contains…

<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
    <entry key="key1">value1</entry>
    <entry key="key2">value2</entry>
    <entry key="key3">value3</entry>
</properties>

That DP is confusing for me because i would use item.label for a friendly name. :stuck_out_tongue_winking_eye:

import java.util.List
import java.io.File
import java.io.BufferedReader
import java.io.FileReader
import java.util.HashMap

rule "Test"
when
    Item Virtual_Switch_1 received command
then
    logDebug("Rules","Test: Start")
    val String filePathString = "/opt/openhab2/conf/test/test.txt"
    val File filePath = new File(filePathString)
    if (filePath.exists) {
        var HashMap<String,String> test = new HashMap<String,String>
        var BufferedReader in = new BufferedReader(new FileReader(filePathString))
        var String line = ""
        while ((line = in.readLine) !== null) {
            val List<String> parts = line.split(",")
            test.put(parts.get(0), parts.get(1))
        }
        in.close
        logDebug("Rules","Test: [{}]",test.toString)
    }
    else {
        logDebug("Rules","Test: file does not exist!")
    }
    logDebug("Rules","Test: End")
end

Where test.txt contains…

key1,value1
key2,value2
key3,value3