I’m using the “invert percent” option for my FGRM222 and the actual percent value in the GUI is constantly changing although the rollershutters are not moving … it’s doing this for all six FGRM222 I have, below I concentrated on node 33 (item name=FibFGR222_Living_West_L):
events.log:
2017-06-18 22:03:54.816 [ItemStateChangedEvent ] - FibFGR222_Living_West_L changed from 82 to 83
2017-06-18 22:07:10.511 [ItemStateChangedEvent ] - FibFGR222_Living_West_L changed from 83 to 17
2017-06-18 22:37:10.187 [ItemStateChangedEvent ] - FibFGR222_Living_West_L changed from 17 to 83
2017-06-19 00:51:45.613 [ItemStateChangedEvent ] - FibFGR222_Living_West_L changed from 83 to 17
2017-06-19 01:31:48.493 [ItemStateChangedEvent ] - FibFGR222_Living_West_L changed from 17 to 83
2017-06-19 01:31:48.550 [ItemStateChangedEvent ] - FibFGR222_Living_West_L changed from 83 to 17
2017-06-19 02:51:50.625 [ItemStateChangedEvent ] - FibFGR222_Living_West_L changed from 17 to 83
2017-06-19 02:51:50.680 [ItemStateChangedEvent ] - FibFGR222_Living_West_L changed from 83 to 17
2017-06-19 07:37:21.814 [ItemStateChangedEvent ] - FibFGR222_Living_West_L changed from 17 to 83
2017-06-19 07:37:21.871 [ItemStateChangedEvent ] - FibFGR222_Living_West_L changed from 83 to 17
2017-06-19 08:07:10.433 [ItemStateChangedEvent ] - FibFGR222_Living_West_L changed from 17 to 83
2017-06-19 08:37:26.747 [ItemStateChangedEvent ] - FibFGR222_Living_West_L changed from 83 to 17
2017-06-19 08:45:20.161 [ItemCommandEvent ] - Item 'FibFGR222_Living_West_L' received command 0
2017-06-19 08:45:20.165 [ItemStateChangedEvent ] - FibFGR222_Living_West_L changed from 17 to 0
I grabbed the debug log from around 08:15 to 08:46 to catch the last events:
I have no idea if one of my rollershutter rules is causing this issue, but because the shutters are not physically moving I expect the percent value not to change.
rollershutter.rules (excerpt):
...
//shading positions
val Number ShadingLivingWest_L_Position = 70
val Number ShadingLivingWest_R_Position = 70
//closing positions
val Number ClosedLivingWest_L_Position = 70
val Number ClosedLivingWest_R_Position = 70
...
rule "move shutters living west to shading position = main execution"
when
Item Shading_Shutter_LivingWest_Autoshade received update
then
if (Shading_Shutter_LivingWest_Autoshade.state==ON && ShutterOverrideTimerLiving_West.state==OFF && ShutterAutoOpenCloseLiving_Lock.state==OFF) {
if (FibFGR222_Living_West_L.state != ShadingLivingWest_L_Position) {
Thread::sleep(20000)
FibFGR222_Living_West_L.sendCommand(ShadingLivingWest_L_Position)
}
if (FibFGR222_Living_West_R.state != ShadingLivingWest_R_Position) {
Thread::sleep(20000)
FibFGR222_Living_West_R.sendCommand(ShadingLivingWest_R_Position)
logInfo("SHUTTER", "shutter living west in shading position")
}
}
else if (Shading_Shutter_LivingWest_Autoshade.state==OFF && ShutterOverrideTimerLiving_West.state==OFF && ShutterAutoOpenCloseLiving_Lock.state==OFF && ShutterDelayTimerLiving_West.state==OFF) {
if (FibFGR222_Living_West_L.state > 3) {
Thread::sleep(20000)
FibFGR222_Living_West_L.sendCommand(0)
logInfo("SHUTTER", "shutter living west left in 0 position")
}
if (FibFGR222_Living_West_R.state > 3) {
Thread::sleep(20000)
FibFGR222_Living_West_R.sendCommand(0)
logInfo("SHUTTER", "shutter living west right in 0 position")
}
}
end
rule "shutter livingroom auto close west"
when
Channel 'astro:sun:shutterlivingroom:set#event' triggered END
then
if (AutoOpenClose_Shutter_Proxy.state==ON) {
ShutterAutoOpenCloseLiving_Lock.sendCommand(ON)
FibFGR222_Living_West_L.sendCommand(ClosedLivingWest_L_Position)
Thread::sleep(20000)
FibFGR222_Living_West_R.sendCommand(ClosedLivingWest_R_Position)
}
else if (AutoOpenClose_Shutter_Proxy.state==OFF) {
ShutterAutoOpenCloseLiving_Lock.sendCommand(OFF)
}
end
...
Apart from this the migration from the snapshot to the development branch was pretty straight forward, all devices were initialized quickly, even the battery devices and also including one new device did work well.
Got it. One is coming through the BASIC command class - this is not being inverted. The other is then coming through the MULTILEVEL command class, and this is being inverted…
Finally managed to try out new binding as well, but with rather limited success.
I did upgrade to the latest openhab 2.1 snapshot in combination with zwave binding 2.1.0.20170618203.
I am able to add my test fibaro FGRM-222 Rev.25.25 with no issue - adding in paper UI.
I am able to control the blinds just fine - again from paperUI BlindsControl (UP/STOP/DOWN) as well as Switch are working just fine.
But Lamella position slider/dimmer has no impact - it seems that no command is sent to FGRM-222.
In openhab.log I am getting loads of “[ERROR] [ome.core.thing.internal.ThingManager] - Exception occurred while calling handler: java.lang.NullPointerException java.util.concurrent.ExecutionException: java.lang.NullPointerException” whenever I am moving the lamella slider in paperUI
Attached in logs.zip.xml
bundle_list.txt
event.log
openhab.log with INFO
openhab_debug.log with DEBUG
I tried openHAB 2.1.0 Build #961 with the corresponding 2.1.0.SNAPSHOT Z-Wave Binding today, but there is no lamella channel on any of the two FGRM222.
This doesn’t have these changes for the FGRM222. The changes described here are only available in the development binding which needs to be manually installed.
Did you set the configuration parameter number 3 to value 1 (using Fibar command class) and parameter number 10 to value 2 (Venetian Blind Mode, with positioning). Just to make sure the setup is correct.
As mentioned before all other operations are working just fine - UP/STOP/DOWN (Blinds Control) as well as Switch to open/close.
Tried calibration no help.
When moving the slide for lamella control from e.g. 0 to 24 this is the result in openhab.log (DEBUG):
2017-06-21 12:50:30.994 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Command received zwave:device:3359c755:node2:blinds_lamella --> 24
2017-06-21 12:50:30.995 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occurred while calling handler: java.lang.NullPointerException
java.util.concurrent.ExecutionException: java.lang.NullPointerException
at org.eclipse.smarthome.core.common.SafeMethodCaller.executeDirectly(SafeMethodCaller.java:220)[98:org.eclipse.smarthome.core:0.9.0.201706191632]
at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous(SafeMethodCaller.java:189)[98:org.eclipse.smarthome.core:0.9.0.201706191632]
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:83)[98:org.eclipse.smarthome.core:0.9.0.201706191632]
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:67)[98:org.eclipse.smarthome.core:0.9.0.201706191632]
at org.eclipse.smarthome.core.thing.internal.ThingManager.receiveCommand(ThingManager.java:374)[105:org.eclipse.smarthome.core.thing:0.9.0.201706191632]
at org.eclipse.smarthome.core.items.events.AbstractItemEventSubscriber.receive(AbstractItemEventSubscriber.java:47)[98:org.eclipse.smarthome.core:0.9.0.201706191632]
at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:192)[98:org.eclipse.smarthome.core:0.9.0.201706191632]
at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:1)[98:org.eclipse.smarthome.core:0.9.0.201706191632]
at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:181)[98:org.eclipse.smarthome.core:0.9.0.201706191632]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_131]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_131]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_131]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_131]
Caused by: java.lang.NullPointerException
at org.openhab.binding.zwave.handler.ZWaveThingHandler.handleCommand(ZWaveThingHandler.java:968)[204:org.openhab.binding.zwave:2.1.0.201706182030]
at org.eclipse.smarthome.core.thing.internal.ThingManager$4.call(ThingManager.java:377)[105:org.eclipse.smarthome.core.thing:0.9.0.201706191632]
at org.eclipse.smarthome.core.thing.internal.ThingManager$4.call(ThingManager.java:1)[105:org.eclipse.smarthome.core.thing:0.9.0.201706191632]
at org.eclipse.smarthome.core.common.SafeMethodCaller.executeDirectly(SafeMethodCaller.java:218)[98:org.eclipse.smarthome.core:0.9.0.201706191632]
… 12 more
@chris
Uplift to build #961 and systemctl stop/start instead of systemctl restart of openhab did improve
the [ERROR] messages are gone.
In openhab log (DEBUG) I do see the following.
Still not able to confirm if lamella are actually moving since I am connect remotely. openhab_debug_build.log.xml (75.5 KB)