I am not a expert in interpreting the frames but auto stop looks different. Your results confirm what I supsected. For up or down the binding first sends a stop and in the case of consecutive up/down commands it shows the position after the first command but for the actual first command it shows the target position 0/100, assumimg the UNDEF has gone away… Not that it matters much for me.
The actual command looks the same, both auto-stop and the stop issued by the binding is *2*0*51## (WHO=2 for automation, WHAT=0 for stop, WHERE=51 for the shutter with A=5/PL=1). The difference seems to be that the binding is issuing a *2*1000#0*51## before the stop, so the same message but with WHAT=1000#0. The WHO_2 specification lists this kind of message, e.g. in section 3.0.2.1, as part of an “Event Session”, but I lack the knowledge of OpenWebNet to really understand what that is about …
But in the case of my issue the binding reacts correctly if the auto-stop comes after the Shutter Run time, but incorrectly if it comes before that - that is why I thought it is probably more related to the internal status of the shutter in openHAB than with anything happening on the bus.
I have now logged an issue for this, describing the test case that leads to the issue, and two test cases that avoid the issue (either running a full down/up cycle or setting Shutter Run < auto-stop). For all three test cases log files on DEBUG level are included.
I also logged the topic of auto-calibration and its working as documentation issue:
My weather station setup and its integration with openHAB and the BTicino shutters is now complete and working as expected. I wrote about it again on my blog.
Hello, I’m still having the same exact problem (no updates for the heating valves state) with OpenHab 3.4.1. Is it still broken? I’ve read through the long thread and I thought that the thermo support is supposed to be working from 3.3 onwards. Am I missing something?
Hallo Dario, welcome to the community.
Thermo support has been added since few OH versions now, but there can be some bugs that we could correct with the gentle help from the community.
So if you @Wism and @m4rk can provide these detailed info all together:
thing and item configurations
hw modules involved (central unit model, valves controllers models)
and then the most important: the openHAB log at level DEBUG for openwebnet from when you restart OH up to when you are sure your heating valve should be updated to, for example, ON but it does not update
NOTE: if you have many items/things it is VERY useful to temporarly remove/comment all things that are not invovled in the test, to simplify log messages and to speed up the diagnosis
…we can try to help.
You can either provide info here or, much better, open up a new issue on GitHUb where you have all the instructions for adding an issue the right way.
NOTE if you already provided these information, then… sorry: replicate them and be patient!
It’s sometime complicated to follow all the threads with few intermitted volounterring hours one can dedicate to this project (this is by no means a professional customer support, and you are no customers)
String UtilityRoom_HeatingActuator_Str "Utility room heating str" <radiator> {channel="openwebnet:bus_thermo_zone:gateway:12:actuators"}
I did have to create a rule to convert the string to a number item for Grafana charting
when i send a timed-light command (eg from a touchscreen) the state will not be updated in sitemap. the item does not receive the ON command and also not the OFF command at the end of the timer.
the own command for exmaple is *#1*45#4#01*#2*0*5*0## for a timed light with 5 minutes.
i kindly want to ask if this is on the roadmap for a new version?
in fact light temporization commands are not supported by the binding.
However looking at the documentation your example looks like what is described at page 19 of WHO_1: it should be followed by an ON/OFF event with the new state. So maybe there are other messages involved?
→ it seems all settings work with the same commands, the only difference is the fixed timed light sends every second a new timed light and the timed light only sends one timed command.
but in all cases light items like switch or dimmer do not recieve ON / dimmerlevel and also do not change to OFF / 0 at the end of the time
in the shown examples, beside the countdown timed events, the only useful messages are these two:
Mon:*#1*45#4#01*4*140*1## → dimmerLevel100 status 40% Mon:*#1*45#4#01*4*100*1## → dimmerLevel100 status 0%
there is no other indications of ON/OFF commands or events being sent.
So either these are all dimmerLevel100 objects (for which there is already an issue request to support them) or other relevant messages are missing from your logs…
shutterRun is auto-calibrated according to the first stop received after a full run (it’s exaplained in the README): in this case it was calibrated to 61s because the auto-stop was received at 60s, close but not exact.
Setting corretly shutterRun is crucial.
→ here obviously the screen does not send a timer command but switches ON the light and at the end OFF again, so the items are updated correct with ON and OFF
Thanks, understood! But then it seems to me that the auto-calibration feature will always lead to a shutterRun setting that is slightly higher than the auto-stop of the actuator, which leads to problems down the road. Does it then even make sense to have/use the auto-calibration?
Not sure if I understand that. The binding has no way of knowing the actual runtime, or does it? So if the shutterRun is 61 seconds, and a stop is sent after 60 seconds, should the binding not just set the open state to something like 99%, believing the shutters run was stopped shortly before it reached its final position?
Or, if the shutterRun time is reached first and the state is put to 100%, and then the auto-stop is received shortly after that, couldn’t the binding safely assume that the shutters remain in their 100% position and leave the state at that?
shutterRun auto-calibration has indeed worked for some users, but of course there are some factors that can generate not perfect calibration, that is why the README suggest to fine tune it.
In your logs there is also a very strange stituation where sometimes the message received gets ignored:
2023-01-11 15:10:21.288 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *2*0*51##
2023-01-11 15:10:21.288 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownIdFromMessage(<*2*0*51##>) --> 2.51
2023-01-11 15:10:21.289 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownId=2.51 has NO DEVICE associated, ignoring it
while just few instants after the very same message (*2*0*51## = STOP) is handled correclty: if the STOP message gets ignored during calibration it can lead to imprecise setting of shutterRun. I do not know why you have this configuration, maybe removing and re-adding the same Thing can solve the problem.
The binding has no way to know actual runtime: it only knows the timing between a UP/DOWN commands and a STOP and the value of shutterRun and can compare them.
So if position=UNDEF and it sees a time=60s between UP and STOP, which is slightly less than shutterRun=61, it can calculate 99% steps of UP movement (it’s in fact writter in the logs), but it cannot determine if now the new position estimation is: 100%-99%=1% or is: 99%-99%=0%: since both are possible situations the current position estimation will remain UNDEF. The same happens after a reboot for every runtime observed which is less than shutterRun. That is why after a reboot you need to complete a full UP/DOWN run to be able estimate again the position, but only if shutterRun is configured correctly.
Hope this clears how shutterRun and position estimation work together.
Since there is no apparent bug in the binding I will close soon the relevant issue on GitHub.
If you wnat you can suggest some changes in the README to give suggestion about the auto-stop setting (note: it’s also important to be very concise in the README)
The missing part for me was that auto-calibration only works when the auto-stop of the actuator is set to actual runtime. Consequently, auto-calibration is only usable if you have those newer actuators where you actually can change the auto-stop time. On mine, the older ones without ID and not supporting advanced configuration via MyHome suite, it is fixed at 60 seconds, so auto-calibration will always lead to wrong results.
I will think of a suggestion for amending the documentation with this information and submit it.
Yes, thanks, I will have a closer look at that. But at the moment everything appears to work correctly, I’ll have to check the logs if these ignores are still there.
