[openWebNet/BTicino] openHAB3

After giving this some more thought, I am still not yet sure if we have completely covered this issue and if the 60 seconds fixed auto-stop is really the issue.

What I understand so far:

  • Neither the binding nor the actuator know about the actual runtime of the shutters, so we can actually ignore this factor.

  • Consequently the only thing that matters for the binding behavior is the correlation between the shutterRun parameter of the binding and the auto-stop configuration of the actuator.

  • The auto calibration sets the shutterRun to the time when the auto-stop is received. So when using auto-calibration these two parameters will always be very close.

  • It seems that receiving the auto-stop within the shutterRun time leads to issues. Also other users here in the thread have observed that they had to set the auto-stop time higher than the shutterRun for everything to behave correctly.

  • Since when using auto-calibration these two parameters are close, the issues may occur inconsistently due to racing conditions in the processing.

Given these points, I am not sure if the auto calibration feature is not fundamentally flawed?

If binding is not influenced by the actual runtime and the issue is in the correlation between shutterRun and auto-stop, then setting the auto-stop correctly to actual runtime will not help. Auto-calibration will still then lead to shutterRun values close to auto-stop, which in turn leads to issues.

What helps is not using auto-calibration at all, setting shutterRun to the actual runtime and auto-stop to a higher value, using it as the safety stop feature it is probably intended to be.

What do you guys think?

I dont use the auto calibration. I timed each blind and entered that.

actually the logic is this:

  1. for a system to work correctly, auto-stop should have been properly configured on the actuator by the installer to the time needed for each shutter to complete a full run (let’s call it ACTUAL_RUNTIME). This can be achieved via MyHome_Suite software (virtual configuration) or via jumpers (physical configuration, on older modules) with 5s steps. NOTE: many systems may work correctly even with a wrongly set auto-stop because shutter motors stop themselves in any case when the end run is reached, to prevent the motors from burning themselves out.
    So for example if a shutter has ACTUAL_RUNTIME = 43s, an installer should set auto-stop via jumpers to 45s.
  2. when the actuator is stopped or reaches the auto-stop time, a STOP openwebnet messages is sent as event on the BUS
  3. when you do auto-calibration from OH, the time from UP to STOP openwebnet messages is calculated and shutterRun parameter is set slightly less (0.5s if I recall correctly). In our example it should be shutterRun=44.5s

So if auto-stop is set correclty in the BTicino actuator, also auto-calibration in the binding should work correctly.

Another option is to have auto-stop set much higher (example 120s) and shutterRun set manually to 45s (by using a stopwatch).
Users are not forced to use auto-calibration, it’s just an option that works if the BTicino system was configured correctly.

The only condition when the binding does not work correctly is when shutterRun is set higher than the auto-stop (and this was explained already in the README)

I think the original issue in your setup was that for some reason the first STOP message was ignored during calibration, and this lead to a shutterRun setting slightly higher than the auto-stop time.
I think that your suggestion to improve documentation should guide future users to check their auto-stop setting on the actuators.

Hi Massimo, thanks for the explanation!

It seems our F411/2 actuators do not have that option, neither via jumpers nor in the virtual configuration in the My Home Suite.

OK, I have to try if I can reproduce this. If you are saying the first message might have been ignored, what would be the second STOP message?

I was looking to this datasheet where in 2.2 they explain the Timed stop
Maybe there are different versions…

Yes, if you set log level to DEBUG (both for binding and openwebnet4j lib, as per instructions), remove the shutter Thing+Item (better also disable all other Things that are not relevant), move with physical control the shutter to 50%, then add again the shutter Thing/Item and then perform a new autocalibration, then send me the log… i can give a look.
For now I have no idea why 2 STOP messages would arrive and why only the second one was considered.

Yes, it seems that has been improved in newer revisions of the F411/2. However, when looking at the older documentation I now realize that there is such an option as well. But it supports only five options, which do not really allow any accurate setting of the actual runtime: Default (1 minute), M=1 (2 minutes), M=2 (5 minutes), M=3 (10 minutes) or M=4 (no limit). This is also reflected in the virtual configuration in the My Home Suite:

Screenshot - 25_01_2023 , 20_49_50

OK, I’ll run some tests in the next couple of days and report back. :slight_smile:

OK, I did the test now, here are the results.

I started out with setting shutterRun=AUTO for the existing thing and redo the calibration, then leave the shutter position at 50%, remove the existing Thing, create a new one and run the test again. It seems that re-creating the Thing did not change anything. In both cases, there are many of the “ownId=2.51 has NO DEVICE associated, ignoring it” messages in the logs and the shutterRun gets set to ~61.5 seconds.

The steps in detail, with the openHAB logs and also the output from the OWN client:

  1. Set log level to DEBUG

  2. Set shutterRun for existing Thing (“openwebnet:bus_automation:22eef285a7:51”) with WHERE=51 from 48,000 to AUTO

  3. Sent command 50 to existing Point “Shutter_OG_AO_Roller_Shutter”

  4. Result: shutterRun set to 61,542
    Shutter Test - 1_Old_Thing_Calibration OH Logs.log (46.5 KB)

  5. Leave shutter position where they were, at ~ 50 %

  6. Remove old Thing

  7. Created new Thing (“openwebnet:bus_automation:22eef285a7:0773814f8d”) with gateway MyHomeServer1, WHERE=51 and shutterRun=AUTO

  8. Created new Point “AO_Test_Roller_Shutter”

  9. Sent command 50 to Point

  10. Result: shutterRun set to 61,551
    Shutter Test - 3_New_Thing_Calibration OH Logs.log (41.8 KB)

  • in the logs every receveid message is duplicated!!! maybe you have 2 openwebnet bridges configured?? perhaps one via WebUI and one via text files? Only one bridge has probalby associated the shutter Thing with where=51 so messages from that bridge are processed, while for the other bridge they get ignored since no device with where=51 has been associated.
    It’s not a good idea to configure 2 different bridge Things for the same BTicino bus system
  • since we understood that your shutter has a default auto-stop configured at 60s (M=0 option) then in this case the shutterRun get set much higher that actual run (48s). Sorry but in your case auto-calibration cannot be used. I will add more hints/alert about the auto-stop setting in the README

if you confirm the double bridge configuration, I think we can close this case

Yes, you are right, I have both the MyHOMEServer1 and the MH202 added as Things, however all the other Things are associated with the MyHOMEServer1 only.

But this only explains the ignored messages, but none of the other issues, or does it? I have now removed the MH202, but auto calibration still sets the shutterRun at ~ 61,5 seconds.

I still think that there is more at play here. From what I understand, the only problem from the shutterRun not equaling the actual runtime is that if the shutter run is stopped in between, the calculation of percentage would be wrong. It seems all other issues do not come from the shutterRun not equaling actual runtime but from shutterRun being higher than the actuator’s auto-stop.

However, even if I could set my auto-stop to 48 seconds, the auto-calibration would probably still set shutterRun to something like 49,5 seconds, and still all those issues stemming from a shutterRun that is higher than the actuator’s auto-stop would occur, wouldn’t they?

You mentioned before that the auto-calibration sets the shutterRun at -0,5 seconds from the measured time between the command and the received STOP. Maybe that -0,5 seconds is not sufficient on some systems, because processing takes longer than that?