I have a weather station, as well as wind, rain and sun switches setup. I use some BTicino contacts sensors, I also have my electric garage door integrated, again using contact sensors. If you want to discuss please use the general thread unless its binding specific.
Good morning,
I am back with a question about shutters and their state.
I am now using a non-semantic group hierarchy where I put all my shutters to send them commands. All the groups have member base type Rollershutter and AVG as aggregation function.
-
After I reboot openHAB, the state of all the shutters and groups is UNDEF, as expected.
-
If I then send an UP command to the top level group (the “house”), its state changes to “0”, also as expected.
-
However, the sub-groups stay at UNDEF, which I’d expect to be set to 0 as well.
-
Then also the top level group status changes back to UNDEF after 20-30 seconds. Looks like the aggregation function kicks in and overwrites the top level status again with the UNDEF in which the sub-groups still are.
Is this a bug? Shouldn’t the UP to the top-level group also set the state of all the sub-groups to 0?
In this state I also cannot send a percentage command to the shutters, it will give me the following error, which is probably because the state is still UNDEF:
2023-01-11 05:42:05.755 [INFO ] [.handler.OpenWebNetAutomationHandler] - Command 10 cannot be executed: unknown position or shutterRun configuration params not/wrongly set (thing=openwebnet:bus_automation:22eef285a7:51)
What is the best way to bring the shutters in a defined state after a reboot of openHAB?
The problem seems to occur also on the level of individual shutters. If after the reboot I execute the following code, the state will first go to 0, but then after 20-30 second go back to UNDEF. Shutter_OG_AO_Roller_Shutter is a Point representing an individual shutter.
var shutters = items.getItem( "Shutter_OG_AO_Roller_Shutter" );
shutters.sendCommand( "UP" );
shutters.postUpdate( "0" );
What could be the cause of the shutter state to change back to UNDEF after some time?
Groups are not directly handled by the binding but by the OH core.
But if the item value goes back to UNDEF after a while in the single shutter, than something is wrong either in the configuration or in the binding.
It would be useful to see the log ( DEBUG level) when you send the UP command after a reboot, and the thing+item configurations.
I can reproduce that, so the issue seems to really happen on item level.
If I set the log to debug, there are so many entries I do not really know what to send. Is there a way to limit the debug level to the OWN binding?
Here is my Thing:
UID: openwebnet:bus_automation:22eef285a7:51
label: Rollladen OG AO
thingTypeUID: openwebnet:bus_automation
configuration:
where: "51"
shutterRun: "61540"
bridgeUID: openwebnet:bus_gateway:22eef285a7
And here my Item:
You should set the DEBUG level just for then OpenWebNet binding.
See instructions here.
Then just copy-paste in a .txt file the log from when you sent the command to the single shutter (after a reboot), and attach the file here
Great, thanks, here is the file:
Shutter_UNDEF_Debug_Log.txt (18.8 KB)
I appended my code to add some log entries that show where the problem occurs, the log starts with:
*** ShutterTest: Sending UP ***
And ends when the state changes back to UNDEF:
*** ShutterTest: State now UNDEF ***
Here is the code I used:
console.info( "*** ShutterTest: Sending UP *** ")
var shutters = items.getItem( "Shutter_OG_AO_Roller_Shutter" );
shutters.sendCommand( "UP" );
shutters.postUpdate( "0" );
java.lang.Thread.sleep(5000);
while( shutters.state == 0 )
{
java.lang.Thread.sleep(1000);
console.info( "*** ShutterTest: State still 0 *** ")
}
console.info( "*** ShutterTest: State now " + shutters.state + " *** ")
What seems to happen before the state goes back to UNDEF is this:
2023-01-11 07:15:43.605 [INFO ] [nhab.automation.script.ui.1d9969a35d] - *** ShutterTest: State still 0 ***
2023-01-11 07:15:44.022 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*2*0*51##]
2023-01-11 07:15:44.022 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *2*0*51##
2023-01-11 07:15:44.023 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownIdFromMessage(<*2*0*51##>) --> 2.51
2023-01-11 07:15:44.023 [DEBUG] [.handler.OpenWebNetAutomationHandler] - handleMessage(<*2*0*51##>) for thing: openwebnet:bus_automation:22eef285a7:51
2023-01-11 07:15:44.023 [DEBUG] [.handler.OpenWebNetAutomationHandler] - updateAutomationState() - msg=<*2*0*51##> what=STOP
2023-01-11 07:15:44.023 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # current positionEstimation=-1 movedTime=60943
2023-01-11 07:15:44.023 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # movedSteps: 99 UP(-)
2023-01-11 07:15:44.024 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # movingState=0 positionEstimation=-1 - calibrating=-1 shutterRun=61540
2023-01-11 07:15:44.041 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*2*0*51##]
2023-01-11 07:15:44.042 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *2*0*51##
2023-01-11 07:15:44.042 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownIdFromMessage(<*2*0*51##>) --> 2.51
2023-01-11 07:15:44.043 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownId=2.51 has NO DEVICE associated, ignoring it
2023-01-11 07:15:44.606 [INFO ] [nhab.automation.script.ui.1d9969a35d] - *** ShutterTest: State still 0 ***
2023-01-11 07:15:44.607 [INFO ] [nhab.automation.script.ui.1d9969a35d] - *** ShutterTest: State now UNDEF ***
However, since there is another of my entries showing the state as 0 before it goes to UNDEF, I am not sure if the OWN log entries before that are really the cause or unrelated.
One more thing: what solves the issue is when I bring the shutters down first, wait for them to physically go down, and then bring them up. After that, the state does not change to UNDEF but stays at 0, or sometimes at 1, which I put down to calibration issues.
This would be the code for that:
var shutters = items.getItem( "Shutter_OG_AO_Roller_Shutter" );
shutters.sendCommand( "DOWN" );
java.lang.Thread.sleep(120000);
shutters.sendCommand( "UP" );
Sorry to butt in but if I rember correctly the actuator sends out a stop command after a fixed time set in the actuator config. Make sure that is a sensible time. Not sure if helps anway.
That is a very good point, that STOP message (20*51##) seems what I am seeing in the log just before the state of the Item goes back to UNDEF. It comes about 60 seconds after the original UP command sent from openHAB, which seems sensible. My actuator is an old one, I can only use virtual configuration and it does not have any configuration parameter for that time.
But the STOP message should not put the openHAB Item in an UNDEF state, or should it?
Edit: and it seems to do that only if the state was UNDEF before. If I bring the shutters completely down and then up again after the reboot, then after that the script works fine.
I have now compared the log entries for the OWN STOP messages that are being sent 60 seconds after I send the UP command.
Here is the previously posted log of when I do it directly after reboot of openHAB:
2023-01-11 07:15:44.022 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*2*0*51##]
2023-01-11 07:15:44.022 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *2*0*51##
2023-01-11 07:15:44.023 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownIdFromMessage(<*2*0*51##>) --> 2.51
2023-01-11 07:15:44.023 [DEBUG] [.handler.OpenWebNetAutomationHandler] - handleMessage(<*2*0*51##>) for thing: openwebnet:bus_automation:22eef285a7:51
2023-01-11 07:15:44.023 [DEBUG] [.handler.OpenWebNetAutomationHandler] - updateAutomationState() - msg=<*2*0*51##> what=STOP
2023-01-11 07:15:44.023 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # current positionEstimation=-1 movedTime=60943
2023-01-11 07:15:44.023 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # movedSteps: 99 UP(-)
2023-01-11 07:15:44.024 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # movingState=0 positionEstimation=-1 - calibrating=-1 shutterRun=61540
2023-01-11 07:15:44.041 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*2*0*51##]
2023-01-11 07:15:44.042 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *2*0*51##
2023-01-11 07:15:44.042 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownIdFromMessage(<*2*0*51##>) --> 2.51
2023-01-11 07:15:44.043 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownId=2.51 has NO DEVICE associated, ignoring it
And here if I run the same command again after bringing the shutters completely down and up again:
2023-01-11 15:10:21.287 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*2*0*51##]
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
2023-01-11 15:10:21.294 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*2*0*51##]
2023-01-11 15:10:21.294 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *2*0*51##
2023-01-11 15:10:21.295 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownIdFromMessage(<*2*0*51##>) --> 2.51
2023-01-11 15:10:21.295 [DEBUG] [.handler.OpenWebNetAutomationHandler] - handleMessage(<*2*0*51##>) for thing: openwebnet:bus_automation:22eef285a7:51
2023-01-11 15:10:21.296 [DEBUG] [.handler.OpenWebNetAutomationHandler] - updateAutomationState() - msg=<*2*0*51##> what=STOP
2023-01-11 15:10:21.296 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # current positionEstimation=0 movedTime=60965
2023-01-11 15:10:21.296 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # movedSteps: 99 UP(-)
2023-01-11 15:10:21.296 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # 0 - 99 = -99
2023-01-11 15:10:21.296 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # movingState=0 positionEstimation=0 - calibrating=-1 shutterRun=61540
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.
After reboot:
2023-01-11 07:15:44.023 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # current positionEstimation=-1 movedTime=60943
2023-01-11 07:15:44.023 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # movedSteps: 99 UP(-)
2023-01-11 07:15:44.024 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # movingState=0 positionEstimation=-1 - calibrating=-1 shutterRun=61540
After bringing the shutter completely down and up again:
2023-01-11 15:10:21.296 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # current positionEstimation=0 movedTime=60965
2023-01-11 15:10:21.296 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # movedSteps: 99 UP(-)
2023-01-11 15:10:21.296 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # 0 - 99 = -99
2023-01-11 15:10:21.296 [DEBUG] [.handler.OpenWebNetAutomationHandler] - # w:51 # movingState=0 positionEstimation=0 - calibrating=-1 shutterRun=61540
@massi, could this be the cause of the shutter going to UNDEF when issuing the command after reboot?
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.
so one example of me:
mhs:
and corresponding setting in things-file:
bus_automation Balkon_Ro "Balkon_Ro" @ "Rollladen" [ where="91#4#01", shutterRun="26000" ]
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.
correct, i also think a longer time set in the actor (mhs) is not a problem, but if shorter the binding gets confused.
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 %.
var shutters = items.getItem( "CC_House_Shutters" );
console.info( "Initialize shutters: sending DOWN ...")
shutters.sendCommand( "DOWN" );
console.info( "Initialize shutters: waiting 2 minutes ...")
java.lang.Thread.sleep(120000);
console.info( "Initialize shutters: sending UP ...")
shutters.sendCommand( "UP" );
console.info( "Initialize shutters: waiting 2 minutes ...")
java.lang.Thread.sleep(120000);
console.info( "Initialize shutters: sending UP ...")
shutters.sendCommand( "UP" );
console.info( "Initialize shutters: done!")
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.