Did it get completely funded by donations? (with all your work, I think it should be a freebee for you)
Yes - I think there were 6 donations that came in almost exactly at the cost of the smallest blind (approx 120 GBP if I remember correctly including P&P).
Hopefully once it arrives it won’t be too hard to get working.
Thanks.
3 Likes
Just a quick update on this - the blind arrived on Thursday and I’ve just done some initial pairing checks using my test console. It looks like it should not be too hard to get working and I’ll try and get that done this weekend.
For my future reference I’m dumping some output from my test console below.
Node Info Value
Application Version 34
Date Code 20190311
Generic Device Class 0
Generic Device Type 255
HW Version 1
Manufacturer Name IKEA of Sweden
Model Identifier FYRTUR block-out roller blind
Power Source 3
Product Code ByteArray [value=45 31 37 35 37 2D 31 34 30]
Product URL
SW Build ID 2.2.007
Stack Version 99
ZCL Version 3
Supported received commands for server cluster Window Covering (0102)
CommandId Command
0 WindowCoveringUpOpen
1 WindowCoveringDownClose
2 WindowCoveringStop
5 WindowCoveringGoToLiftPercentage
2 Likes
I’ve created a PR for this and will merge later this evening -:
I’m glad we went down the road of me getting one of these as working out some of the workings would have been a prolonged affair if we’d just used logs.
Let me know how this goes. I may still need to look at the percentage value again - I think this doesn’t report if the endstop isn’t set, so you will need to set the limts for this to work properly.
3 Likes
Great job! Just updated to snapshot binding and got it working (pairing was real pain though, took me like 20 attempts).
Just a few notes:
- Now it does not show battery level channel, i only see “Window Covering Lift (Rollershutter)” and “Battery Alarm (String)”
- Reporting percentage works perfectly
- UP, DOWN and STOP commands work, with small latency
- Setting specific percentage seems to be broken, for example setting it to 10 moves shutter to 25, 5 to 13, 8 to 20, sometimes it does nothing, 100 does nothing but 0 works
I also managed to pair the included remote (also the repeater but it has no clusters) and it showed battery channels and one dimmer channel, but pressing buttons on remote did nothing (nothing showed in events log), is it possible to get it working?
Never mind, the battery channels just appeared…
For me it paired first time.
It should - it certainly works fine with me. The battery voltage was reading strange, but that doesn’t seem to be the binding, but the percentage was ok.
There will always be a latency - the device is battery operated so it sleeps a lot and wakes up approximately once per second - this causes the latency.
I’ll fix that - I see the problem. For some reason ZigBee uses a different formula for this than the normal percentages.
I didn’t try the remote at all - just the blinds.
This should fix the percentage issue - I’ve not had the chance to test it, but it looks a simple fix.
When you paired, what did you do? Again, this is a slow device, so it will take some time to be discovered due to all the commands that need to be sent, and the slow responses. You should get an initial thing in the inbox, but it will then take some time to be given a name.
Or was the problem more basic than that, and it was just problematic to reset and include? I found holding the two buttons down for 5 seconds worked well every time I tried it (although admittedly that was only 3 or 4 times).
Yes, I think it was just me being impatient. First time it showed as unknown device and stayed that way after adding it. So I tried removing and resetting it and after that it stopped showing in inbox completelty. I paired it with the remote again and after few tries it worked.
What do you mean by this? So far I’ve not even put the batteries in the remote and I’ve not looked at how that integrates. I’ve read that the remote is somehow already linked with the blinds, but then this means it’s working outside of the ZigBee network in some way at least.
I probably need to have a better look at the remote and what it’s doing, but so far I’ve focussed on the blind itself.
After resetting the blinds got into some weird state where they stopped showing in inbox completely and no resetting helped. When pairing the light on them stayed solid white (it seems to be pulsing when it communicates with remote/hub) and I didn’t see any messages with its address in debug logs.
So I just reset them again, but this time paired them with the included remote (you need to pair the remote with that repeater first) just to make sure it still worked (it did). It was during this that the remote and the repeater started to show up in inbox (but the blinds did not). After that I just reset them again and it started to show up in inbox again.
Btw just tried the latest snapshot (2.5.6.202006062238) and setting the percentage seems to be working fine now.
1 Like
Ok, interesting. I didn’t see that here - resetting (holding down both buttons for 5 seconds) always seemed to work, but as I said, I only did it a few times.
Great - thanks for the feedback.
I have paired my blinds (deconz) multiple times on first attempt by press and hold both buttons for approximately 20 seconds. (Found the tip on a HA forum).
Ok, one more thing - I’ve just charged the battery and it reported 0%, after I send command to it, it changed to 50% (it showed 40% before which was suspiciously low since I charged it pretty recently after like 4 months).
I suspect this might be an error in the device. The binding assumes a value of 200 is 100%, but if the device is returning percentage, then it will be out by a factor of 2. I’m not sure there’s a lot I can do to fix that unfortunately or it will be wrong for other devices.
@chris
Just an obsvervation about the remote. (please bear with me, since I have no knowledge about programming nor zigbee comunication intrinsics - I am using layman terms…)
I’ve been using the phoscon/deconz solution for a bit over a week, just to try it out.
When paring the remote in phoscon, it creates a group to the remote. I can then add one or more blinds to that group and control it/them without any intervention from openhab. It is kind of neat, since it works similar to an association with Zwave, and I can control my blinds even if my “server” goes down for any reason.
The low level ZigBee libraries don’t currently support groups, however groups aren’t really the ZigBee equivalent of associations in ZWave. ZigBee uses a concept called binding and reporting and this is how the device informs other devices about things like button presses etc. Groups allow multicast addressing and groups can also be configured with reporting… Normally it’s possible to set multiple reports - the same as in ZWave where you can have multiple nodes in an association group. So, I doubt that groups are required here.
Anyway, I’ve not looked at all at the remote - I’ve not even put the battery in it as yet so I don’t know anything about it. My focus had been to get the blinds working - I had initially thought that the remote was somehow directly linked to the blinds (based on the manual). I’ll try and take a look at this in the near future.
Ok so since the 2.5.6 version is oficially released with fyrtur blinds support, I’ll mark this thread as resolved. Once again, thanks @chris for implementing this feature.
Just one last thing I’ve noticed after using it for some time - seems like the battery life of the blinds is way worse than when I controlled them with that included switch. I bought them at the end of january and didn’t charge until about mid may and they still worked, not sure how much battery was left. Right now they show about 10% battery left and I had trouble controlling them, seems like the battery is too low.
Battery life shouldn’t really be impacted - the binding sets up reports at a rate of every 15 minutes, but I wouldn’t really have expected that to make a lot of difference to battery life. You could reduce it if you like though.