Not sure if I interpret it correctly, but in both cases, the [20*51##] seems to be received twice and in each case one ends up with being ignored due to âNO DEVICE associatedâ, albeit once this is the first message and then the second.
The other message that is processed leads to different results in what seems to be the position calculation.
as you see at @m4rk myhome config, he set the actor to 2 min. standard this is always set to 60sec - so i suppose this could be the reason for your problem.
i set all shutter actors in myhomesuite 2 seconds longer as in oh - to prevent that actor stops before oh. at least for me the setting in mhs is not so important because if set for example to 60sec the actor always is on for 60 sec, even if the shutter was nearly open and works only for 10 sec.
It was a long time ago but I think I set all my blinds at 2min for the auto stop to avoid âissuesâ like you are seeing. 2min because that is longer than the max runtime of my longest blind and as far as I know it is a safety stop. The stop event seemed to be necessary to get the binding to update. I even add extra stops in scenarios for by wireless blinds.
After reboot I do notice âundefâ for the blinds initially. Usually it sorts itself out after a full run but to speed it up eg when testing, I sometimes issue a stop and then up or down. Then I get a current position update. You will notice that for open close the binding shows the target final position and moves towards it. If you stop, or issue open/close, then the binding updates with the current position but in the case of repeated open/close commands the current position is displayed and it doesnât now show the new target position. So, that is a little bit inconsistent behaviour to a single open/close command without a stop between. Maybe its deliberate?
I have rule for one blind that warns me that rule cannot run due âundefâ. I could easily add code to force a full cycle but as that blind cycles daily anyway I donât. Patience
Am I right that there is no option for a positional slider, like a dimmer slider, in sitemap? I never tried to make a workaround for that.
Hmmm, I guess I am stuck with the 60 seconds auto-stop, I have the old actuators without ID, so I can only use the virtual configuration, not the advanced configuration:
So the only thing I can tinker with are the settings in openHAB. But I do not really understand yet how all this works together.
There is the Shutter Run parameter in the Things, which I had initially on AUTO and then did a calibration run. The calibration then set the Shutter Run of all our shutters to about 61 seconds, which is much more than they actually take. So it may actually have reacted to that auto-stop from the actuators and not when the real run was completed?
But my understanding was that the Shutter Run should be set to the actual time each of the shutter takes to go down, so that the binding can calculate how far the shutters have been going down?
Anyway, Iâll try a shorter Shutter Run value, see how it goes and will report back here.
For now I have also added a script that is executed on openHAB-startup and brings the shutters down and up again to get them initialized. Just sending an DOWN and then immediately an UP again does not resolve the issue, I have to wait for the shutters to go really down. And when I bring them up, some of them usually stay stuck at 1 % opening, the second UP resolves that and really brings them to 0 %.
if i remember right this i also had then. but when thinking about it seems clear: the âautoâ only can recognize a stop command, can not see or measure if the shutter really stopped. so if you set âautoâ and your actor sends an stop after 60 sec - then i think the shutter-run will be set to 60.
because i also had trouble then i mesaured the time of each shutter with a stopwatch, attention, at least for me the shutters take longer to open than to close. so i noted the opening time and set this in things at âshutter-runâ then the only other important thing is to set the actor time longer, if yours is set fix to 60 it should be no problem when your shutters are all faster.
i now did a reboot of oh, then my shutters are also undef, then when sendcommand to close 25% i also receive an error
Command 25 cannot be executed: unknown position or shutterRun configuration params not/wrongly set ...
but when i send an up command (although the shutter is open and does not move at all) - just wait the time that i have set in things, then the item shows 0 as value what is correct and now i can send a percent-command that will be executed, the shutter runs to the desired position
i am not 100% sure if eventually one of my rules could influence that behaviour but i think this should also work for you. i think it is annoying always close the complete house and open again only to make shutters work. at the moment i dont restart often, but i was thinking about a function that starts at reboot and sends an open-command when daylight (i suppose most shutters are open) or sends a close command at night (when shutters are closed normally) - the swabian variant
I dont use the auto calibrate. I timed all my blinds and entered the run time in the binding config. As I have been here during the development phase I didnât trust the auto times at first. Anyway, the plan was to make 50% exactly 50% coverage as the blinds have some travel in their boxes before they start to cover the windows. A bit obessive, I know. However, the difference was slight only I notice and so I never played with the timings.
Regarding the auto stop >>> A work around might be issue another open/close/stop. That might restart the auto stop timer and in the case of a stop cancel it.
With the amount of playing around I do, sometimes late in the night, that would be a good way to annoy the rest of the house You could just let the rule decide. If its undef then initilise the blinds by running them up or down or maybe a simple stop command would be enough.
edit⊠Stop from site map isnât enough. It seems that the autostop is needed to be runout. Do the two stops, sitemap vs auto, look different on the BUS?
Oh, and I should correct myself. I donât have 2mins for all my blinds. It seems I started to put more realistic times for the configured autostop but not for all blinds. About 2 secs longer than shutter run.
As I have reboot button in my site map and currently bored ill in bed I did a test.
Immediately after reboot. UNDEF >>
stop does nothing to fix it
open or close sets the target value but it returns to undef if a stop is issued from site map
A few minutes after reboot. UNDEF >>
stop does nothing to fix it
open and close sets the target value and the position data remains after a stop this time
If dont do anything for a few minutes after reboot and then open or close I get the target position but after a stop I get UNDEF again.
If I send and open or close and then wait until after auto stop was sent then the position data stays.
As i can hear the actuator I can hear that it remains open even after the blind reached position. The blind motors have their own endpoint, non-bus, switches. After a manual stop hear the relay change.
Listening to the relay I think that open followed immediately by another open actually issues a stop and then an open as I hear the relay click twice for the second open. So for the binding its always a stop, position update, open.
Do the two stops look the same on the BUS? The binding seems to treat them differently. sitemap stop vs autostop
I can confirm open or close reset the auto stop timer. So, could be used to extend the autostop if needed
I wonder if using persistance and restore on startup would help. Have you tried?
Looks like you are seeing the same issue as I am, with the state going back to UNDEF.
I now measured and entered correct Shutter Run times, and for me this has solved the issue. The Shutter Run times are between 30 and 52 seconds, so all below the 60 seconds auto-stop from the actuator.
Now after reboot, it is sufficient to send a single UP command to the shutters, they will then set their state to 0 and it stays that way, not go back to UNDEF as before when the Shutter Runs were all set to ~ 60 seconds. Sending the UP command makes sense in our case, we donât use the shutters that often and they are up most of the time anyway.
I guess a STOP command wonât help here, because the binding still would not know the position of the shutters, while an UP puts them in a known state.
Thanks, I read that already but my misconception was I thought the calibration can measure actual runtime, when in fact it measures the time to the auto-stop sent by the actuator.
And it seems here the auto calibration is getting in the way of how the binding then works, because having the Shutter Run at that time seems to lead to the issue I am seeing, with the state of the shutter going back to UNDEF when the auto-stop is sent.
No, I have not gotten that far yet. I think it may help, but it is not a water-proof solution. Especially if openHAB would be shut off for an extended time, the shutter state could change, and then whatever is in the persistence database is not correct anyway. So getting the shutters in a known state is probably safer than relying on persistence.
I think this is the main exaplanation for the wrong behavior you experienced. Maybe I should add a note on the READE about this setting of the auto-stop
Yes, it seems so and noting it in the binding documentation for sure would be helpful.
In my mind two questions remain:
First, is this a systemic issue of the auto calibration? Will the auto calibration always lead to Shutter Run values that are slightly higher than the auto-stop of the actuator, which seems to lead to the issue I observed?
And second, why does the auto-stop sets the shutter back to UNDEF from an already known state, and only under some conditions and when the Shutter Run values are too long? It seems that also under those conditions the binding should not reset the state, or should it?
To summarize what I observed:
Test case leading to the issue:
Initial conditions:
Shutter is up
State is 0 Shutter Run is 61 seconds
Auto-stop of actuator is 60 seconds
Action: OH is rebooted
Result: state is UNDEF (OK)
Action: sending an UP command
Result: state changes to 0, but after the auto-stop of the actuator, state goes back to UNDEF. (NOT OK)
Action: sending a DOWN command, waiting 120 seconds, then sending an UP command
Result: state is 0 again and stays that way, auto-stop is not interfering anymore. (OK)
Test case:
Initial conditions:
Shutter is up
State is 0 Shutter Run is 48 seconds
Auto-stop of actuator is 60 seconds
Action: OH is rebooted
Result: state is UNDEF (OK)
Action: sending an UP command
Result: state changes to 0 and stays that way, auto-stop is not interfering (OK)
I was thinking about why the different binding reaction to autostop vs rule, sitemap stop. I assume the frames are the same.
I already pointed this out but got no comment. Could it be that autostop and possibly wall switch stop are sent on the bus and are only received by the binding. Whereas, rule and sitemap stops are sent via the binding. So the difference is the direction, the binding is either sending or receiving the stop commands and therefore reacts differently.
I gave it a try and to me the stop message from the actuator looks the same as those triggered by the openHAB binding. See the screenshot below. I would guess the difference that leads to the issue is more with the state the shutter is in in openHAB than anything happening on the bus.
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.
