Fibaro Roller Shutter 3

[tormm]

1) Give a description of the problem
I have a Fibaro Roller Shutter 3, which is controlling a sunscreen. I have created a simple piston to set it down halfway if there is sun in the morning. But it seems to lower the screen to different hights, even if there is just one setting. (Set level to 40%). Yesterday I would say it closed to approx 60% and today only 33%, all with the same setting

I have also seen that the actual closing level of this screen is different in the new and the old ST apps.(So 40% in the new app is not the same as 40% in the old app).

2) What is the expected behaviour?
I would at least expect the sunscreen to close to the same level every day.
Do I need to use another kind of command than SetLevel?

''3) What is happening/not happening?
I

**4) Post a Green Snapshot of the piston![image|45x37]

5) Attach logs after turning logging level to Full

+0ms	╔Received event [My home].test = 1587537344545 with a delay of 0ms
+95ms	║RunTime Analysis CS > 20ms > PS > 55ms > PE > 20ms > CE
+97ms	║Runtime (37702 bytes) successfully initialized in 55ms (v0.3.110.20191009) (96ms)
+99ms	║╔Execution stage started
+113ms	║║Comparison (time) 30944649 is_between (time) 25200000 … (time) 37800000 = true (8ms)
+115ms	║║Time restriction check passed
+117ms	║║Condition #2 evaluated true (13ms)
+120ms	║║Cancelling statement #2’s schedules…
+125ms	║║Requesting time schedule wake up at Wed, Apr 22 2020 @ 10:30:00 AM CEST
+130ms	║║Condition group #1 evaluated true (state did not change) (26ms)
+139ms	║║Comparison (integer) 10000 is_greater_than_or_equal_to (integer) 7500 = true (2ms)
+140ms	║║Condition #4 evaluated true (8ms)
+142ms	║║Condition group #3 evaluated true (state did not change) (9ms)
+144ms	║║Cancelling statement #7’s schedules…
+651ms	║║Executed physical command [KokkenFibaro Roller Shutter 3].setLevel([40]) (500ms)
+652ms	║║Executed [KokkenFibaro Roller Shutter 3].setLevel (502ms)
+671ms	║╚Execution stage complete. (573ms)
+674ms	║Setting up scheduled job for Wed, Apr 22 2020 @ 10:30:00 AM CEST (in 6854.781s)
+684ms	╚Event processed successfully (683ms)

[Alwas]

In the first IF, I would try…
If weather illuminace changes to greater than…
AND
time is between…
THEN…

[tormm]

Thanks,

It seesm I can only check if the Illumination “Changed” not “Changed to” at this ST Weatherstation Tile…

[Alwas]

You could use $twcweather instead, I’m sure they have illuminance.
This piston runs every 47 minutes, if the wind is too strong it closes a sunscreen, hack it, do what you want. They’ll be example pistons for what you’re wanting, sure someone has done it before.

@WCmore knows about weather

[WCmore]

@Alwas, I have not been able to find “illumination” in $twcweather…
These are the closest built-in datasets, with sample data shown on the right:

$twcweather.conditions.cloudCeiling           ||  null, 100, 2100, 8500`
$twcweather.conditions.cloudCoverPhrase       ||  "Clear", "Partly Cloudy", "Mostly Cloudy", "Cloudy"
$twcweather.conditions.uvIndex                ||  1, 8, 12
$twcweather.conditions.visibility             ||  16.09
$twcweather.forecast.daypart[0].cloudCover    ||  14, 79, 100
$twcweather.forecast.daypart[0].precipChance  ||  0, 20, 100, 90

---

Alternatively, you can use the AccuWeather plugin for SmartThings, which can use “Cloud Coverage”, shown as a percentage.

---

Unfortunately @tormm, none of these will have any impact on the blinds not opening up the same amount each time… To get to the bottom of this, I would likely do all of my testing with only a single block of code.

Once your blinds are responding uniformly, then you can worry about the rest of your piston’s logic.

[WCmore]

I forget the way Fibaro handles it, but most SmartBlinds are not aware of what percentage the blinds are actually open. (it is simply a motor told to start and stop)

For example, if SmartBlindsX knows that it takes about ten seconds to fully open the blinds, then 40% is about 4 seconds from the closed state… or 6 seconds from the open state. This also means that if there is network chatter (or “lag”) at the time, there may be a slight delay before the “stop” command comes thru. (and of course, in this example, a 1 second delay means it would be about 10% off)

---

Edit:

This “shift” can be magnified even more if, (for example) your blinds start from a position that is not fully opened or closed. (IE: going from 20% to 40%) This is because each event can be off a second or so (10% per second, in my example above), so it may be compounded if not starting from 0 or 100.

[Paul1964]

I vaguely remember looking at the fibaro a few years ago when I was looking at automating the garage door. I seem to remember it had different operating modes, if it does, maybe one of these may work better for you, assuming you can set it with the DH you’re using.

[Alwas]

OK, set level is the issue, I saw a similar post in the ST forum. I have a few of these Fibaro Roller Shutter 3’s and they are super reliable in their level reporting. It depends a lot on the motor you’re using, and which device type handler you’re using. Was the motor a new install and you just calibrated the Fibaro Roller Shutter 3?
Ideally you would calibrate the motor first, to its max and min levels, then introduce the Fibaro Roller Shutter 3, which calibrates off those min max set values, and the level reporting should be 100 per cent reliable.

[WCmore]

It depends a lot on … which device type handler you’re using

I’ve been thinking a lot about this lately… (please bear with my ramblings)

I would love it if all companies followed these simple guidelines for SmartHome devices:

• All instant commands (turn on/off, set temp, etc) should be able to run directly from 3rd party apps (IE: webCoRE, web request, etc)
• All time-consuming tasks (fades, motor run for 6.4 sec, etc) can be initiated with a single command from webCoRE. (thereby turning control over to either the handler, or an internal chip onboard the device, to complete the duration)

I think this is the future…

A device that is Smart on its own, and yet (the crucial step!), is also allowing of external apps to fully control it. So many companies do not believe this philosophy, and it is really hurtful to the “integral nature” of the SmartHome community.

---

In case there are any developers / inventors reading this, let me emphasize:

• The more devices that can talk to your device, the more useful it will become.
  (if all devices can talk to it, you have hit the jackpot!)
• The more closed (or proprietary) system you create, the more estranged it will become.
  (perhaps door locks being the exception here)

[WCmore]

Sorry to jump tracks a little bit…

… We now return to your regularly scheduled programming …

[tormm]

Thanks. These are screens from “Kjells MArkiser” in Norway. I ordered them with only the simple motors, and they are controlled by the Fibaro Shutter 3. The only info I find about the motor, is a tag that says “IQ Motor” on the cable. They were calibrated as they were installed/connected (A process where they were run up and down a couple of times). It does not seem to be an isse when I adjust the level in the app. works correctly every time then. But I have noticed that for example 40% in the old and the new app are not the same.

I am using a DH called FGR-223 * Based on the FGR-222 handler by Julien Bachman.