Hi there,
is anyone already using the new Fibaro Roller Shutter 3 in his openhab z-wave network? My first one I send back as defect, because it was not able to perform the calibration. Including was easy after installing a snapshot binding from 2.5 for zwave.
I saw some other comments about this kind of issue, but nobody posted “is now fixed”.
Regards Jan
Platform information:
Release = Raspbian GNU/Linux 9 (stretch)
Kernel = Linux 4.14.98-v7+
Platform = Raspberry Pi 3 Model B Plus Rev 1.3
z-wave controller Razberry2
openHAB 2.4.0-1 (Release Build)
255 x Active x 80 x 2.5.0.201902081421 x ZWave Binding
I like to ask the same question, I’m going crazy with this FGR-223 Roller Shutter 3.
Is there anyone out there who can confirm that these Roller Shutter controller are working?
I’m willing to find my own mistakes but at the moment it seems that I have no chance.
I have 4 of them, with OpenHAB 2.5m1 and the latest Zwave binding, it works. Only the calibration doesn’t work as it suppose to do. But I think this is related to my blind. They have an electronic stop and they calibrate themselves. On the other hand according to the fibaro site, it should work.
So up down and stop works perfect, only position not (yet).
ok, thank you.
So, it seems it makes sense to play around a bit more.
One more question please. I think you did calibration manually by filling point 156 and 157 (movement time), right?
And if you send sendCommand(50) to the blinds_control channel, this works?
No I didn’t fill the parameters 156, 157. I don’t use the positioning, only UP and DOWN. I’ve read somewhere that you can play with the parameters 155 and 154.
I included one FGR.223 yesterday to test. The device was added with no rollershutter channel, just an switch_dimmer channel. Is this correct? How can you then stop an up or down movement?
Sorry, if I am asking a stupid question, but I am a beginner
HI. my friend with home center 2 update my 4 rollershutter 3 to firmware 5.1.
the problem with momentary switch it’s ok now, no problem, but with the absolute position there are some problem. if i press the phisical switch in the wall openhab don’t update the status, no way.
i ve try to change so many option but nothing…
it 's possible to see the traffic between the rolleshutter and the openhab? i think that it’s a different way to send the command from the fibaro.
seems so strange that rollershutter 2 it’s perfect no problem and the new have this issues…
Fibaro Germany, it’s company intuitech, ask me to buy update service in there online shop. I told them that my knowledge is that updates are free, they told me that I have to contact fibaro Poland for this.
So, I bought the update service and send the devices to intuitech. After a few days they ask me for additional 5.99 for sending the devices back to me.
I accepted and the devices are back in my office. But to late to test, I already started my summer holidays.
i ve made other tests and if i use the dimmer instead of blind control in channel section the status when i press the phisical switch it’s update.
the problem with the incorrect value when i set the percentage remain, if i set 50 and the blind is at 0 after 3 second update the actual position (e.g 15) the blind arrive at 50 but status remain at 15.
the strange thing is that if i press stop the status of position is update
Thank you @horstermann for the advice. Make sure to use the “Preisvorschlag” option to save some money (but I really think Fibaro should cover their flaw anyway). I made an overall price so no further cost were claimed and the handling went pretty smooth.
Day 1: proposed a price, got positive response the same day
Day 2: sent the package to them
Day 3: package arrived
Day 5: updated devices shipped back
Day 6: arrived at my home
(only considering working days)
Tested the devices, V5.1 running. So now I need to wait for 2.5M2 to get the blinds_control channels as I am hesitating to update to snapshot versions.
As far as I understand (and saw in my configuration) the 2.5M1 database only supports switch_dimmer. @davideesse: you may want to see this post proposing to use blinds_control1 channel.
thank you for the advice.
i ve the 2.5.0 snapshot.jar binding zwawe and i don’t have blind control 1… i ve only blind control.
i ve to update openhab or just the binding? where i can find it?
The device database is part of the z wave binding. So no need to update OpenHAB.
Which exact snapshot build do you have? Typically it has a 4 digit number or you may find a time stamp.
With the Karaf command bundle:list you should be able to identify it.
However I can’t tell how the channels are called in your version as I am running the “old” milestone release and have switch_dimmer, switch_dimmer1 and switch_dimmer2.
Which channels are offered to you in the thing configuration in PaperUI or HABmin?
I have problems to get FGR-223 Roller Shutter 3 running
The Log show the following message:
2019-06-15 20:48:15.723 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 19: Device discovery could not resolve to a thingType! 010F:0303:1000::5.1
2019-06-15 20:48:15.736 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘zwave:device:88190bb8:node19’ to inbox.
BasicUI show the following Thing:
Thing details in BasicUI:
Z-Wave Node 019 (010F:0303:1000:5.1)
Unknown Device
This device has not been fully discovered by the binding. There are a few possible reasons for this -:
The device is not in the database. If the device attributes show that this device has a valid manufacturer ID, device ID and type, then this is likely the case (eg. you see a label like " Z-Wave node 1 (0082:6015:020D::2.0) "). Even if the device appears to be in the database, some manufacturers use multiple sets of references for different regions or versions, and your device references may not be in the database. In either case, the database must be updated and you should raise an issue to get this addressed.
The device initialisation is not complete. Once the device is included into the network, the binding must interrogate it to find out what type of device it is. One part of this process is to get the manufacturer information required to identify the device, and until this is done, the device will remain unknown. For mains powered devices, this will occur quickly, however for battery devices the device must be woken up a number of times to allow the discovery phase to complete. This must be performed with the device close to the controller.
I run openHAB 2.4.0-1 (Release Build) on Raspberry Pi 3 Model B (latest stable version)
I have upgraded all installed software packages and applied the latest improvements
There are some good news about your issue.
First of all, your device is in the current database, second you have the better firmware version 5.1.
The bad news is, the device wasn’t available in 2.4 releases, so a later version is needed.
You need to at least update the Z-Wave binding by copying the .jar-file in the openhab2-addons directory. The latest snapshot can be found here.
Don’t forget to confirm you’re running the correct binding version, e.g. by using bundle:list in karaf console.
