the blinds are raised, but lowered again for a split second.
2017-09-02 13:43:07.177 [ItemCommandEvent ] - Item 'ZWaveNode10FGRM222RollerShutter_BlindsControl' received command UP
2017-09-02 13:43:07.179 [ItemStateChangedEvent ] - ZWaveNode10FGRM222RollerShutter_BlindsControl changed from 100.0 to 0
2017-09-02 13:43:08.397 [ItemStateChangedEvent ] - ZWaveNode10FGRM222RollerShutter_SensorPower changed from NULL to 109.6
2017-09-02 13:44:07.563 [ItemStateChangedEvent ] - ZWaveNode10FGRM222RollerShutter_SensorPower changed from 109.6 to 0
2017-09-02 13:44:08.585 [ItemStateChangedEvent ] - ZWaveNode10FGRM222RollerShutter_SensorPower changed from 0 to 106.3
2017-09-02 13:44:10.290 [ItemStateChangedEvent ] - ZWaveNode10FGRM222RollerShutter_SensorPower changed from 106.3 to 0
From completion: variable BlindsUp is defined:
var BlindsUp = "UP"
var BlindsDown = "DOWN"
Calibration of the FGR-222 did not improve the situation.
Raising the blind from Paper UI does have the same effect.
2017-09-02 14:10:41.627 [ItemCommandEvent ] - Item 'ZWaveNode11FGRM222RollerShutter_BlindsControl' received command UP
2017-09-02 14:10:42.821 [ItemStateChangedEvent ] - ZWaveNode11FGRM222RollerShutter_SensorPower changed from 0 to 111.1
2017-09-02 14:11:41.898 [ItemStateChangedEvent ] - ZWaveNode11FGRM222RollerShutter_SensorPower changed from 111.1 to 0
2017-09-02 14:11:42.917 [ItemStateChangedEvent ] - ZWaveNode11FGRM222RollerShutter_SensorPower changed from 0 to 107.9
2017-09-02 14:11:44.350 [ItemStateChangedEvent ] - ZWaveNode11FGRM222RollerShutter_SensorPower changed from 107.9 to 0
Using the manual switches allows raising the blind completely.
I am observing the same behaviour on all FGR-222 I am using and all are version 25.25
The configuration of one FGR-222 is attached
Same here. Whatās ultimately your hw, binding version and item config.
Check (and try changing) parameters 3 (you likely donāt have a OH to understand Fibaro commands) and 13 (read it up in the Fibaro manual if you donāt know what it does).
Answering your questions one by one: OH version: openHAB 2.1.0 release build with Z-Wave Dev build 2.1.0.201708201145 for lamella positioning support items: All Zwave things and items were defined in Paper-UI Did it ever work: yes, Changes: no SW upgrades, did initial install after 2.1.0 was released, HW changes added more FGR-222 and refined the rules controlling the blinds. Blinds type: All blinds are venetian blinds and I am not refering to tilt angle. Calibration: Yes, via switch connected to S2 and via HABadmin
All blinds are configured identical parameter #3: āBlind Positioning with FIBAR Commandā and #13: ādefault - controller+switchlimitā and all blinds behaving the same.
Find the logs with ālog:set debug org.openhab.binding.zwaveā here.
Since raising the blind via Paper UI as the same effect the UP command below was triggered via Paper-UI.
Also important there is no impact of the tilt angle in which the lamellas where positioned before UP command was issued. openhab2_debug.log.xml (31.1 KB)
To demonstrate the difference between UP command and physical switch:
with UP command: !
With physical switch: blind_raised_with_switch|320x240
and how are the items defined, whatās the channel name ?
Did you try using blinds_control and/or blinds_shutters channel ?
and what exactly was your change that did break it ?
First and foremost, the simple answer to your question of this thread is:
The ālower the blinds a bitā is standard behavior to return to the lamella tilt angle that was set before the blinds started moving.
Your log is only showing a single Fibar message which likely is the state report, the others are āpowerā reports and as such I believe them to be unrelated to positioning.
The message also keeps complaining about the unknown Fibar command class, but Iām not sure about the interpretation, you need to ask @chris for help here.
Either way, a single message is unlikely to be the origin of TWO consecutive state change events.
Are you sure your log is comprehensive ?
Did you try other settings of #13 ? Iām using ālike 1 + with STOP control frameā.
Possibly an additional message is generated when your blinds hit the limit.
Iāve not seen the message you refer, but if this is the Fibaro specific command, then itās not supported in the current master version - only in the development version.
I am using Blinds Control e.g.
zwave:device:99f8ebf5:node6:blinds_control
and Lamella position e.g.
zwave:device:99f8ebf5:node6:blinds_lamella
to control the venetian blinds.
I am not able to determine when it stopped working - we had loads of sunshine and the blinds were not raised for quiet some time. Now with summer ending I found outā¦
I might have encounter the same issue a couple of month back when testing with the first (and only fgr222) and might fixed it with reseting the device.
Testing was done on 2.1 snapshots and zwave dev build back then.
With all blinds now equipped with fgr222 and a couple additional zwave devices I would really like to avoid going back to square one
Iām not sure why the proprietary command class wouldnāt be recognised. The only thing I can think of is that it was somehow missed during the device interrogation phase. You could try to reinitialise it (use advanced mode in HABmin and select āreinitialise deviceā in the top right menu of the thing).
Instead of stopping in fully closed position the blind is raised and the lamallas are in extreme position - pointing upwards.
Check mesurement reportsā¦
BUT: after calibration the DOWN command is fine again.
DOWN lowers the blinds with lamellas fully closed
and UP is back to before.
I donāt think this sounds like itās a binding issue. It sounds more like an issue with getting the device to work, so I hope someone else will be able to help you with thatā¦
These messages are just not processed at the moment. Only commanding is supported.
So the question remains, why does FGR-222 lower the blinds again after they have been fully raised.
I might consider reseting one FGR-222 and re-add to zwave as new device.
I already answered: because thatās standard behavior. After positioning (incl. UP,DOWN), FGRMs re-adjust lamellas to the angle that they were set to before the positioning command was received.
It must be done like that because thereās just one single motor to do both mechanically, raise/lower and lamella tilt.
If down/up are reversed, you need to set the āinvert controlā switch on the channel (well, or reverse the electrical wiring).
Found a workaround to limit the impact of the standard behaviour: Tilting the lamellas to horizontal position before raising.
With this tilt angle the blinds are almost fully closed.
!
