Shutter control: "DOWN_BUT_TILT"

1

Hi all,
my shutter automation project grows and grows (Position estimator for shutters - #31 by konehead)

But now I have again a problem which I can not solve on my own:

In the afternoon, when the sun is shining into the “west windows”, I want to close the shutters and then tilt them up, so it is not complete dark.

This rule is triggered according to the Azimuth, and execution works fine of I only use WestShutters.sendCommand(“DOWN”) (where WestShutters is a fictive rollers shutter item, which forwards the received command to the individual shutters, like LivingRoomShutter, KitchenShutter, etc.)

If I execute WestShutters.sendCommand(“DOWN_BUT_TILT”) it does not work, and according to the log the DOWN_BUT_TILT command is either not sent or not received (no entry / error etc. Pops up in the log of :9001 ).

If I try to send KitchenShutter.sendCommand(“DOWN_BUT_TILT”) directly from my sitemap it works as expected, so my rule to manage DOWN_BUT_TILT seems to work fine.

My explanation for this is, that DOWN_BUT_TILT is not a known command for RollerShutter items, and therefore is filtered on low-level side, and therefore neglected instead of forwarded.

Is there a way to extend the allowed commands to 0-100,UP,STOP,DOWN and my new DOWN_BUT_TILT, or how would you suggest to manage this issue?

Thanks in advance,
Edizius

2

Nope.
What Items are actually involved here? Normally there’d be separate channels/Items for up/down and for tilt.

3

Actually the “group item” rule…

rule "move West shutters"
   when
      Item WestShutters received command
   then
{
    gRollershutterWestitems.members.forEach[ shutter |
            shutter.sendCommand(receivedCommand)
    	]
}

and then the “single shutter item” rule which controlls the specific “UP- and DOWN relais”

rule "ShutterItem received command"
   when
      Member of gRollershutters received command
   then
   {
...
switch(receivedCommand.toString)  
     {
        case "up",
        case "UP": 
        {
            ...
        }
        case "TILT_UP",
        case "DOWN_BUT_TILT" :
       { 
...
}

All shutter items are “Rollershutter” and the “UP- and DOWN relais” are normal Switch elements.

Maybe it would be enough to replace the group Rollershutter items with Text items?

4

No idea. Still scratching my head over what Item types are actually involved.

But there are subtleties about sending commands to Group type Items.

First, let’s be clear what usually happens.
You send a command to a Group, the command gets distributed to each member Item.
The command may or may not be suitable for any given member Item, it’s no good sending STOP to a Switch type Item, but that’s not the Groups problem.

Groups may or may not have subtypes, e.g. Group:Rollershutter.
If you do have a subtype, you are limited to commands suitable for that type.
Example, Group:Rollershutter command STOP good, command DOWN_BUT_TILT bad; it’s not an allowed command for a Rollershutter.

If there’s no subtype, it gets a little weird.

You can send what you like to a no-type Group from the UI, it just gets ignored Well, actually it throws a WARN message in the openhab.log. No surprise really, with no type there is no list of acceptable commands. I think what happens is that everything comes from the UI as strings, so is usually looked up for matches to “STOP” or “ON” or whatever.

However -
You can do a sendCommand from a rule to a no-type Group and it acts differently. If you send a defined system command type like
myGroup.sendCommand(STOP)
it sneaks under the look-up radar, and will generate a command event visible in the events.log. That’s good enough to trigger rules and so on.
That’s weird, because it also throws a WARN in openhab.log about not being accepted, and sure enough the command does not get passed to any member Items.

Bottom line;
If you want a Group to distribute commands, give it a subtype.
If you do have a subtype, send only suitable commands.

If you want to use non-standard commands like DOWN_BUT_TILT then you will have to use String types somewhere.

5

Hi rossko.

All my groups are groups with undefined type, and only the shUtters are RollerShutter types

I think you are right (somehow) as I tried to minimalize a testrule to

rule "test all down / sunset" 
when
  Item TestButton3 changed to ON
then
{
  LivingRoomShutter.sendCommand("TILT_UP")
}
end

And it happens… Nothing…

Funny thing, if I add something in below, to check if the executions fine, like

rule "test all down / sunset" 
when
  Item TestButton3 changed to ON
then
{
  LivingRoomShutter.sendCommand("TILT_UP")
TestButton3.sendCommand(OFF)
}
end

(or also use “DOWN_BUT_TILT”) I get the log output

[WARN ] [b.core.model.script.actions.BusEvent] - Cannot convert 'TILT_UP' to a command type which item 'LivingRoomShutter' accepts: [PercentType, UpDownType, StopMoveType, RefreshType].

But…
If I have a string item “ShutterSelection”, which contains the shutter name (e.g. “LivingRoomShutter”),
And a Rollershutter item “ShutterAction” containing, which receives via
Switch item=ShutterSelectionAction mappings=[UP="up", TILT_UP="tilt up", STOP="X", TILT_DOWN= "tilt dw", DOWN="dw", DOWN_BUT_TILT="dw tilted"]

the string “TILT_UP”, and execute following rule

//========================
rule "move selected Shutters"
//========================
 when
 Item ShutterAction received command
then
   if ( ShutterAction === null ) return;
   val ShutterItem = gRollershutters.members.findFirst[ shutter | shutter.name == ShutterSelection.state.toString ]
	    ShutterItem.sendCommand(receivedCommand)
	
    ShutterSelection.postUpdate(NULL)
end

It just executes fine.

Although LivingRoomShutter still is a RollerShutter item.

Anyhow, if there is no possibility to allow more commands for a RollerShutter item, I think I have to go with strings, althoug I have to remodel everything, because I also need the actual position [0-100], so just replace the items with string items is not enough unfortunately…

6

Don’t forget you can uncouple Item state from command by disabling autoupdate on individual Items. (That’s pretty meaningless for Groups though, where the state can only be derived from member Item states anyway.)
I don’t suppose states of string “75%” or whatever are very helpful?

Your underlying problem appears be trying to model a type of equipment that can’t be modelled in a single openHAB Item. You can’t hold both position and tilt status in one Item. You can’t command up/down and tilt in one Item.
So you’re probably compelled to use a couple of Items on the ‘device’ side, and associate them together.
And maybe a third “dummy” Item simulating a combined Item. That one you can send weird commands to, that do nothing of themselves, but a rule can decode to a command sequence for real devices. The dummy can also get its state updated to reflect one or other real devices, or if you wish some combination -“75% down, tilted”

Note, no Group so far. You don’t have to use Groups to create an association of a handful of Items.

7

Hi, yes I think you are right.

But, still, what I do not get is, why the RollerShutter Item accepts a random String provided with “Selection” from a sitemap, while it does not accept the same string sent via .sendCommand…

Meaning all is working es expected, as long I controll the shutter via Selection, but I am not able to simulate a “button press onto the selection” via a rule, which seems rather strange for me.

I am aware that with your design pattern I could set up all from the scratch again, but this would mean a lot of work, so I think if there is no easier solution, I think I will live with the remedy that only numbers 0-100 and UP, STOP, DOWN works to be set via a rule, and that TILT and DOWN_BUT_TILT can only set manually via sitemap

8

What Item? What type is it? What sendCommand? Show your events.log, and openhab.log.
There’s such a jumble of stuff going on here it is hard to isolate what you mean.

Note that every command sent from UI arrives in the form of a string, and must then be parsed against a list of known commands for any given type.
That’s not the same as
mySwitch.sendcommand(ON)
where there is no string and the command type is predetermined as an OnOffType object.
mySwitch.sendCommand("ON")
Works more like the UI, the string payload is parsed into something suitable.

9

Hi,
As said the Item is a string

String ShutterAction "Select Action" <blinds> {alexa="ModeController.mode" [supportedModes="up=up tilt_up=tilt up, stop=stop, tilt_down= tilt down, down=down"]}

And is controlled inside the sitemap via

Switch item=ShutterAction mappings=[UP="up", TILT_UP="tilt up", STOP="X", TILT_DOWN= "tilt dw", DOWN="dw", DOWN_BUT_TILT="dw tilted"]

Log result is

2021-05-28 19:18:29.229 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ShutterAction' received command DOWN_BUT_TILT
2021-05-28 19:18:29.234 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ShutterAction' changed from NULL to DOWN_BUT_TILT
2021-05-28 19:18:29.249 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'LivingroomShutters' received command DOWN_BUT_TILT
2021-05-28 19:18:29.256 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ShutterAction' changed from DOWN_BUT_TILT to NULL
....
2021-05-28 19:18:31.770 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LivingroomShutters' changed from 95.85405400 to 100.0
....
2021-05-28 19:18:33.525 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LivingroomShutters' changed from 100.0 to 98.54594600

So rule executed fine…

In comparison when I execute the test rule

rule "test all down / sunset" 
when
  Item TestButton3 changed to ON
then
{


	//LivingroomShutters.sendCommand("TILT_UP")
	
	val mycmd = myTestCmd.state.toString
  LivingroomShutters.sendCommand(mycmd)
  
  TestButton3.sendCommand(OFF)
}
end

The log output is

2021-05-28 19:25:47.939 [WARN ] [b.core.model.script.actions.BusEvent] - Cannot convert 'TILT_UP' to a command type which item 'LivingroomShutters' accepts: [PercentType, UpDownType, StopMoveType, RefreshType].
==> /var/log/openhab/events.log <==
2021-05-28 19:25:47.923 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'TestButton3' received command ON
2021-05-28 19:25:47.930 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TestButton3' changed from OFF to ON
2021-05-28 19:25:47.943 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'TestButton3' received command OFF
2021-05-28 19:25:47.947 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TestButton3' changed from ON to OFF

And nothing is triggered

10

If the received command is forwarded, and not send directly it seems to work as well…

I created a String item “myTestCmd” to which I can send the command instead of the LivingRoomShutter directly as follows

rule "test button 2" 
when
  Item TestButton2 changed to ON
then
{
//myTestCmd.postUpdate("TILT_UP")
myTestCmd.sendCommand("TILT_UP")
TestButton2.sendCommand(OFF)
}
end

rule "forward command to shutter " 
when
  Item myTestCmd  received command
then
{

  LivingRoomShutter.sendCommand(receivedCommand)
}
end

I think I will do it in such a way

11

Okay, that’s a String type Item.

And you send it a selection of different string commands, that’s fine; send any string you like.

This rule has nothing to do with the Item ShutterAction we’ve just been looking at, so that was all irrelevant it seems.

What is the type of LivingroomShutters? From the way it complains, I guess it is a Rollershutter type.

What are you sending this LivingroomShutters? The log tells us ‘TILT_UP’ and that is rejected. No surprise there, string ‘TILT_UP’ is not an acceptable command for a Rollershutter type Item.

So what’s your earlier log about? What’s the connection between that ShutterAction and this LivingroomShutters?
Is ShutterAction not actually a String type Item, but a Group:String type?
So … you’ve found a way to abuse the Group command-distribute-to-members feature to evade the “suitable command” police?

It’ would be really dumb to rely on this, it’s likely to stop working at any time if a developer improves the internal validation.

This looks like another exploit/abuse, I guess because the receivedCommand implicit variable is some kind of command object and not a simple string. It’s a clever find, and just as likely to disappear tomorrow.

Why not do all this with conventional, supported coding techniques?

12

Hi,
yes, it seems as I have by fault sneeked below the check all the time, and I agree that it is not best practice to use “bugs” to reach the goal as they will / might be solved at some time.
But, I think I can also solve the issue when this solution does not work anymore, as the effort is the same, resp. maybe at that point the ShutterItems allow some additional commands, so the effort is maybe even less if I wait till this solution does not work anore

I try to answer your questions:

What is the type of LivingroomShutters? From the way it complains, I guess it is a Rollershutter type.

Yes, exactly.

What are you sending this LivingroomShutters? The log tells us ‘TILT_UP’ and that is rejected. No surprise there, string ‘TILT_UP’ is not an acceptable command for a Rollershutter type Item.

Yes, is either UP, STOP, DOWN, TILT_UP, TILT_DOWN, DOWN_BIT_TILT, or a numeric value 0-100, where 0 is equivalent to UP, and 100 to DOWN.

So what’s your earlier log about? What’s the connection between that ShutterAction and this LivingroomShutters?

As my sitemap exploded with all the shutters, I decided to create a drop-down menu for all the shutter names (=ShutterSelection), and a selector for what should be done with the selected shutter (=ShutterAction). This is then sent to the shutteritem

Is ShutterAction not actually a String type Item, but a Group:String type?

No, is defined in the items as " String ShutterAction"

So … you’ve found a way to abuse the Group command-distribute-to-members feature to evade the “suitable command” police?

Yes, I think so

Why not do all this with conventional, supported coding techniques?

Actually I started with the normal RollerShutter item as I liked to have the shutter position + the possibility to move up/ down with percent, as well as with UP and DOWN commands. So why invent the wheel again if there is already a appropriate solution exactly for my use case? Therefore, I first implemented the observer, to update all the positions as soon as a switch of a relay of any shutter is detected, and then extended it to control the relays via the RollerShutter item.
I simply extended the commands not thinking about that I abuse them. So project grow, and now I am at a point where I do not want to throw everything away and start from the scratch again, especially as I am now at the point where it works rather fine (for the moment).
So, I have a working observer and can control several shutters in groups via sitemap or via rules. So in theorning shutters move up, if sun is shining into my living room in the afternoon, and a certain W/M2 threshold is exceeded, then shutters move down and tilt up, and in the evening all are closing (I hope, but let’s see tomorrow).

13

Created now for every shutter item a string item named “[shutter name]_command”, put them in the gCommands group, and added this to the trigger of my rule for manage TILT, DOWN, etc.
In this rule I remove inside the itemname the _command it there is any and search the item with this name.

So now I call instead of LivingRoomShutter.sendCommand("DOWN_BUT_TILT")
the command
LivingRoomShutter_command.sendCommand("DOWN_BUT_TILT")
inside my rules.

This works now so far and is “future proof”.
Thanks for the support

1 Like
14

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.