rule "AmpVol"
when
Item setampvol changed
then
setampvol_Args.sendCommand(setampvol.state)
setampvol.sendCommand
logInfo("Amp","Sent")
end
log:
11:50:52.989 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'setampvol' received command 20
11:50:53.014 [INFO ] [arthome.event.ItemStatePredictedEvent] - setampvol predicted to become 20
11:50:53.027 [INFO ] [smarthome.event.ItemStateChangedEvent] - setampvol changed from 15 to 20
11:50:53.244 [ERROR] [untime.internal.engine.RuleEngineImpl] - Rule 'AmpVol': An error occurred during the script execution: index=1, size=1
11:50:53.243 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'setampvol_Args' received command 20
11:50:53.276 [INFO ] [arthome.event.ItemStatePredictedEvent] - setampvol_Args predicted to become 20
11:50:53.288 [INFO ] [smarthome.event.ItemStateChangedEvent] - setampvol_Args changed from 15 to 20
I don’t really understand what wrong, the script take a percentage as a variable, so the dimmer state should be a perfect match, but I can’t get it to launch.
The run channel of the exec binding Thing is used to start the execution, and also report running/not running.
So it’s suited to a go-nogo model - a Switch.
A Dimmer type Item happens to support on/off as well as percentage … but I would use a Switch type here. Remember, this run channel only represents script running / script not running. Switch setampvol {channel="exec:command:setampvol:run"}
I’d also disable autoupdate on this one, preventing autupdate changing (predicting) state in response to a command, and leaving exec binding to update with real run status. Switch setampvol {channel="exec:command:setampvol:run", autoupdate="false"}
Your target args Item is a string type, this would be “nicer” to command it setampvol_Args.sendCommand((setampvol.state).toString)
If you’re going to send a command, you have to say what command setampvol.sendCommand(ON)
Okay, I’ve just realised your rule trigger is also your run and presumably on your UI etc. We need to restructure here.
It’s not clear if the exec binding supports linking the output channel string directly to a number or dimmer type Item - let’s assume it doesn’t, and use a separate dimmer.
I think we can take advantage of exec’s autorun feature too, and not bother with the run trigger. I’m guessing you’ve no need to inspect the run channel to find if the script is running.
// put this one on sitemap as slider
Dimmer myVolume "volume control"
String getampvol {channel="exec:command:getampvol:output"}
String setampvol {channel="exec:command:setampvol:input"}
rules
rule "Amp control"
when
Item myVolume received command // not changed, to avoid looping
then
setampvol.sendCommand((receivedCommand.state).toString) // autoruns script
logInfo("Amp","Sent")
// if you might get ON/OFF to the dimmer
// you could code to deal with that
end
rule "Amp status"
when
Item getampvol changed // updates at intervals
then
// parse string to number
myVolume.postUpdate( Integer::parseInt(getampvol.state.toString) )
end
13:08:14.495 [ERROR] [untime.internal.engine.RuleEngineImpl] - Rule 'Amp control': 'state' is not a member of 'org.eclipse.smarthome.core.types.Command'; line 5, column 28, length 21
Also, yeah, there no support of On/Off via the slider needed, as the script do not handle that (And it would be quite complicated to implement properly anyway due to how well made CEC is …)
Once I added those line, I was able to see that there was a permission error, as shampvol is creating a temporary script, and that openhab didn’t have RW on /tmp
Changed the temp folder for /var/lib/openhab2/tmp and it started working