I see.
I guess the binding populates that with “discovered” data from TV.
Yup, those Item options are not directly accessible from DSL rules.
You could re-jig your idea to use HTTP Action to grab the target Items JSON, then use a JSONPATH transform to recover the text you want, all in a DSL rule.
Alternatively, there may be a way to get direct access to Item option properties via new rule engine, let’s consult @5iver on that?
from core.log import logging, LOG_PREFIX#, log_traceback
LOG = logging.getLogger("{}.TEST_3".format(LOG_PREFIX))
# get a list of all state description options for an Item
LOG.warn("stateDescription.options: '{}'".format(itemRegistry.getItem("Lock_EntranceFront").stateDescription.options))
# get the state description option that matches the current state of an Item
LOG.warn("stateDescription.options that match current state: '{}'".format([option for option in itemRegistry.getItem("Lock_EntranceFront").stateDescription.options if option.value == items["Lock_EntranceFront"].toString()][0]))
# get the label of the state description option that matches the current state of an Item
LOG.warn("label: '{}'".format([option for option in itemRegistry.getItem("Lock_EntranceFront").stateDescription.options if option.value == items["Lock_EntranceFront"].toString()][0].label))
That was the problem. After some googleing I found that passing pipe to exec is not working so I made a script: #!/bin/bash
curl -s ‘http://209.0.0.0:8080/rest/items/LG_TV0_Channel’ | jq ‘.stateDescription.options | select(.value=="’$1’") | .label’
The rule now becomes:
rule “Get Channel from rest/items”
when Item WebOS_state received update
then
logInfo(“test”, "WebOS_state received: " + WebOS_state.state.toString)
val myText = "/etc/openhab2/scripts/webOs_channel.sh " + “"” + WebOS_state.state.toString + “"”
val newValue = executeCommandLine(myText, 6000)
logInfo(“test”, "command = " + myText)
logInfo(“test”, "exec = " + newValue)
WebOS_label.postUpdate( newValue )
end
jq is notorious for problem with quote and parsing from one liners like this without a full shell. jq solves this by allowing you to define your arguments and variables before wrapping them in your query.
some examples here
you can look up the --arg and --argjson functions of jq. I’ve battled this myself in the past.
I begin to wonder if you can get hold of this info directly in DSL.
I don’t have a suitable Item to try it out on, with real stateDescription options … but try this and see what you get
var sd = LG_TV0_Channel.getStateDescription
logInfo("test", "object {}", sd)
logInfo("test", "options list {}", sd.getOptions)
I thought you were asking for an NGRE example . Here is how you could get an option using the rules DSL…
rule "Test DSL rule"
when
System started
then
logWarn("Rules", "Test: Start")
var current_label
val state_description_options = Lock_EntranceFront.stateDescription.options
state_description_options.forEach[option|
if (option.value == Lock_EntranceFront.state.toString()) {
current_label = option.label
}
]
logWarn("Rules", "current_label: '{}'", current_label)
logWarn("Rules", "Test: End")
end
Though I would still recommend using a shell script like you have done already. As mentioned, getting the quotes right and all the escaping becomes challenging. But I wanted to mention that it is possible to run commands in a shell so you can get pipes and redirects and such.
NOTE: There is no reason to sudo -u openhab, it’ll already be running as user openhab.
rule "Test DSL rule"
when
System started
then
logWarn("Rules", "Test: Start")
var current_label
val state_description_options = WebOS.stateDescription.options
state_description_options.forEach[option|
if (option.value == WebOS_state.state.toString()) {
current_label = option.label
}
]
logWarn("Rules", "current_label: '{}'", current_label)
logWarn("Rules", "Test: End")
end
where WebOS is like this, but with a lot more value/ label lines
That’s a bit curious; in a logInfo() curly braces get replaced with the object following. Importantly, the curly braces do not themselves appear in the output.
Looks like that doesn’t work with logWarn.
Let’s spell it out
logInfo(“test”, "result " + current_label.toString)