Zwave Feature Needed : polling a zwave device from a rule

Done. https://github.com/openhab/openhab2-addons/issues/682

@chris, Are you aware of the RefreshType.REFRESH command, which is meant to allow exactly such a behavior? It might not be technically feasible to implement on all devices, but where it is possible, the bindings should support it.

Hi Kai,
Nope - was not aware of that. I’ve just done a quick scan and found some stuff on it in another binding so can certainly look at this.

Thanks
Chris

The RefreshType.REFRESH command is implemented in the OH2 binding (from the next snapshot) if anyone wants to try it.

Coming into this way late, but is the bottom line that RefreshType.REFRESH essentially force a poll from a rule? (If so, that’s great, as I’m running into a similar issue here!)

Yes. Sending this command will perform an immediate poll of the channel (as with any poll, it’s low priority, but if the network is running well it should only be a matter of tens of milliseconds).

Chris

1 Like

Is there an example rule of this?

I believe you just send a command to the required channel, with the value set to RefreshType.REFRESH. I’m not sure where this is documented though…

1 Like

I was wondering the same. I tried this last night and it just threw an error on me. Here’s what I was doing:

sendCommand(Dimmer_Kitchen, RefreshType.REFRESH)

What was the error? Was it an exception from ZWave, or an error in the rule?

13:13:36.362 [ERROR] [org.quartz.core.JobRunShell         ] - Job DEFAULT.2016-03-06T13:13:36.333-05:00: Proxy for org.eclipse.xtext.xbase.lib.Procedures$Procedure0: [ | {
  logInfo(<XStringLiteralImpl>,<XBinaryOperationImplCustom>)
  var command
  sendCommand(<XFeatureCallImplCustom>,<XFeatureCallImplCustom>)
  logInfo(<XStringLiteralImpl>,<XBinaryOperationImplCustom>)
} ] threw an unhandled Exception: 
java.lang.RuntimeException: The name 'REFRESH' cannot be resolved to an item or type.
	at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.invokeFeature(ScriptInterpreter.java:110)[114:org.eclipse.smarthome.model.script:0.8.0.201603021108]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:900)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:863)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:222)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:202)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:825)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:262)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:202)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:445)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:226)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:202)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.evaluate(XbaseInterpreter.java:188)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.ClosureInvocationHandler.doInvoke(ClosureInvocationHandler.java:46)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.AbstractClosureInvocationHandler.invoke(AbstractClosureInvocationHandler.java:28)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at com.sun.proxy.$Proxy117.apply(Unknown Source)[:]
	at org.eclipse.smarthome.model.script.internal.actions.TimerExecutionJob.execute(TimerExecutionJob.java:38)[114:org.eclipse.smarthome.model.script:0.8.0.201603021108]
	at org.quartz.core.JobRunShell.run(JobRunShell.java:202)[94:org.eclipse.smarthome.core.scheduler:0.8.0.201603021108]
	at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573)[94:org.eclipse.smarthome.core.scheduler:0.8.0.201603021108]
13:13:36.372 [ERROR] [org.quartz.core.ErrorLogger         ] - Job (DEFAULT.2016-03-06T13:13:36.333-05:00: Proxy for org.eclipse.xtext.xbase.lib.Procedures$Procedure0: [ | {
  logInfo(<XStringLiteralImpl>,<XBinaryOperationImplCustom>)
  var command
  sendCommand(<XFeatureCallImplCustom>,<XFeatureCallImplCustom>)
  logInfo(<XStringLiteralImpl>,<XBinaryOperationImplCustom>)
} ] threw an exception.
org.quartz.SchedulerException: Job threw an unhandled exception. [See nested exception: java.lang.RuntimeException: The name 'REFRESH' cannot be resolved to an item or type.]
	at org.quartz.core.JobRunShell.run(JobRunShell.java:213)[94:org.eclipse.smarthome.core.scheduler:0.8.0.201603021108]
	at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573)[94:org.eclipse.smarthome.core.scheduler:0.8.0.201603021108]
Caused by: java.lang.RuntimeException: The name 'REFRESH' cannot be resolved to an item or type.
	at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.invokeFeature(ScriptInterpreter.java:110)[114:org.eclipse.smarthome.model.script:0.8.0.201603021108]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:900)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:863)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:222)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:202)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:825)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:262)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:202)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:445)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:226)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:202)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.evaluate(XbaseInterpreter.java:188)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.ClosureInvocationHandler.doInvoke(ClosureInvocationHandler.java:46)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at org.eclipse.xtext.xbase.interpreter.impl.AbstractClosureInvocationHandler.invoke(AbstractClosureInvocationHandler.java:28)[128:org.eclipse.xtext.xbase:2.6.2.v201407030533]
	at com.sun.proxy.$Proxy117.apply(Unknown Source)[:]
	at org.eclipse.smarthome.model.script.internal.actions.TimerExecutionJob.execute(TimerExecutionJob.java:38)[114:org.eclipse.smarthome.model.script:0.8.0.201603021108]
	at org.quartz.core.JobRunShell.run(JobRunShell.java:202)[94:org.eclipse.smarthome.core.scheduler:0.8.0.201603021108]
	... 1 more

Well I didn’t get an exception, but I didn’t get a result, either.

Threw it in the middle of another simple rule I had handy. Both devices (BEDROOM_LAMP and BEDROOM_TV) are simple zwave smart switches.

rule "Bedroom lamp on scene"
when
	// only process on a switch on state
	Item BEDROOM_SCENE_LAMP_ON received update ON
then
	{
		logInfo("openhab","Bedroom lamp on scene activated.")		
		sendCommand("BEDROOM_LAMP","ON")

		logInfo("openhab","Sending REFRESH to bedroom tv")
		sendCommand("BEDROOM_TV","REFRESH")
		logInfo("openhab","Sending RefreshType.REFRESH to bedroom tv")
		sendCommand("BEDROOM_TV","RefreshType.REFRESH")


		BedroomLampOnTimer = createTimer(now.plusSeconds(1)) 
			[|
				logInfo("openhab","(Turning off bedroom lamp on switch)")
				sendCommand("BEDROOM_SCENE_LAMP_ON","OFF")
			]
	}	
end

Doesn’t generate an unhandled exception, just says that I’m whippin’ nulls…

2016-03-06 15:36:25.764 [INFO ] [g.openhab.model.script.openhab] - Bedroom lamp on scene activated.
2016-03-06 15:36:25.854 [INFO ] [g.openhab.model.script.openhab] - Sending REFRESH to bedroom tv
2016-03-06 15:36:25.896 [WARN ] [.c.i.events.EventPublisherImpl] - given command is NULL, couldn't send command to 'BEDROOM_TV'
2016-03-06 15:36:25.933 [INFO ] [g.openhab.model.script.openhab] - Sending RefreshType.REFRESH to bedroom tv
2016-03-06 15:36:25.975 [WARN ] [.c.i.events.EventPublisherImpl] - given command is NULL, couldn't send command to 'BEDROOM_TV'
2016-03-06 15:36:27.094 [INFO ] [g.openhab.model.script.openhab] - (Turning off bedroom lamp on switch)

From what I can tell, it shouldn’t be a string.

How about something like

var refresh as RefreshType
sendCommand("BEDROOM_TV", refresh.REFRESH)

It’s a complete guess, but the type needs to be RefreshType I think, so enforcing the type might help.

OH Designer really doesn’t like that. var refresh as RefreshType says it can’t derive what type refresh is. (“whazzat? dunno.”) Might be a case of not including the right libraries. Right now I’m including:

import org.openhab.core.library.types.*
import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*

Yeah, if I wasn’t such a dingus I would have noticed you specifically called out OH2. I’m running OH1. Disregard me! :wink:

Just to note, I was having a problem with dimmers that didn’t have association groups messing up sliders. This fixes the problem, I have to items right now with this problem, assigned a rule with refresh to one of them, which fixes it, other one still showing symptoms. So without doubt this has fixed the problem here:

Good work Chris!

@chris here’s what I get now:

21:47:13.726 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Command received with no implementation (RefreshType).

To get it to this point I had to import the RefreshType at the top of my rule file.

Excellent - it seems you were successful… Unfortunately, I wasn’t…

I’ll make an update to the binding tonight to try and resolve this issue, but it looks like you’re close…

Hmmm. Ok I jumped the gun, my bad!
So I’m getting a crap load of errors on this, which I presume actually interrupts whatever it is that’s causing my problems, making me think it’s fixed! YEY.

I’ll update to the newest when it’s available and test again.

Any better luck with the most recent binding?