Openhab version 3
Aeotec Dual Wallmote 01 ZW129 Dual Wallmote
Added the wallmote thing correctly and it’s online.
That really depends on your system and your usage parameters.
Under the most basic setup, the buttons on the wallmote will change the Scene number channel. The result will be in the form of “#.#” The ones place will be the number of the button 1 or 2, or 1 - 4 depending on whether you’ve got the two or four panel version. The decimal place is 0 for short press, 1 for long press, and 2 while press is being held down. The depreciated channels are to replicate the association groups if you wanted to set up direct links for different scene arrangements.
I prefer to have mine just toggle various other things around the house (e.g. using both long and short presses, the wallmote 4 in my upstairs hallway can toggle 8 different first floor lights). I have a generic rule for most of my remote controls which reads an associated metadata namespace to determine which other item to toggle based on the scene number.
Whether you include this in your semantic model is a personal preference. I do (for an obscure reason), but there is not a lot of benefit to with my toggling item setup. It might be of more benefit if you use the scene numbers as more traditional scene settings.
Many thanks JustinG
I am making use of the semantic model too and the goal is to toggle various things around the house as well.
Any chance you can show what the configuration on the UI looks like for the scenenumber channel associated with the wallmote (if any) and the generic rule you mention? (you have 1 rule for all the wallmotes?)
In my system, any item linked to remote’s scene or control channel and is supposed to toggles other items has a ToggleControl metadata namespace that associates other item names with keys that match the possible scene output values. That looks something like this:
value: map
config:
"1.0": Switch_KitchenLight_OnOff
"1.1": Switch_LivingRoomLight_OnOff
"2.0": Switch_BreakfastLight_OnOff
"2.1": Outlet_LivingRoomLamp_OnOff
"3.0": Switch_DiningRoomLight_OnOff
"3.1": Switch_FrontHallLight_OnOff
"4.0": Switch_MudRoomLight_OnOff
"4.1": Switch_PantryLight_OnOff
Every item is also a member of the same remote group, gRemotes and I have a single rule which activates whenever a member of that group updates (<- note: not changes, but updates):
The script in that rule takes advantage of the javascript helper libraries to read the metadata from the item that updated and toggles the associated item:
var event;
var logger = Java.type('org.slf4j.LoggerFactory').getLogger('org.openhab.rule.' + ctx.ruleUID);
load('/openhab/conf/automation/lib/javascript/core/metadata.js');
/*Find item to toggle based on trigger item's ToggleControl metadata*/
var toggleItemName = get_key_value(event.itemName,'ToggleControl',event.itemState.toString());
logger.info(['Remote: ',event.itemName,', Control Value: ',event.itemState,', Item to control: ',toggleItemName ? toggleItemName : 'No Target Item Found'].join(''));
/*If toggleItemName is not NULL then toggle Item state*/
if (toggleItemName) {
events.sendCommand(toggleItemName,ir.get(toggleItemName).state==ON ? 'OFF' : 'ON');
}
This way, whenever I add a new remote, I don’t need to change or add any rules, I just make sure the remote is a member of gRemotes and then setup the metadata with the items I want to link it to.
Awesome! Many thanks.
I was able to create one rule for now for 1 remote as below and it’s working 
The script is built-in the rule:
triggers: - id: "1" configuration: itemName: AeotecDualWallmote01ZW129DualWallmote_SceneNumber state: "1.0" type: core.ItemStateUpdateTrigger conditions: [] actions: - inputs: {} id: "2" configuration: type: application/vnd.openhab.dsl.rule script: | if (LV1SW1ZWaveNode006ZW175SmartSwitch7_Switch.state == OFF) { LV1SW1ZWaveNode006ZW175SmartSwitch7_Switch.sendCommand(ON) } else { LV1SW1ZWaveNode006ZW175SmartSwitch7_Switch.sendCommand(OFF) } type: script.ScriptAction
@JustinG just wondering, do you have any experience with rules based from sensors eg aeotec trisensors - trying to add up one trisensor and configuring so that when motion is detected it turns on a light for 15 minutes and then off, if within this 15 minutes another motion is detected, the 15 minutes start over again - could you show me if you have anything similar setup (am reading from other posts about the expire binding to achieve this)
Thanks
Depending on what is controlling the light you can off-load some or all of this from OH and let the devices handle it themselves.
The trisensor has a parameter that determine how long it maintains a motion event (i.e., how long after it detects motion that there has to be no motion before it turns the motion alarm back off) If you want no other conditions at all then just setting this value it the way to go, because then you don’t have to worry about the timing function at all in your rule,. At that point your rule will just have set the light state based on changes in the alarm item. (I have this set up for a few rooms that require no flexibility and have z-wave sensor but wifi light devices)
You don’t even need the rule part if the light controller is also z-wave because most z-wave devices have a feature called association groups. You can also see these in the list of details about the sensor in the thing page. In the case of your trisensor, association group 2 is the motion alarm group.
Any other z-wave item you add to this association group will get a direct On/Off signal from the sensor when it changes its state. Even though you are setting that parameter via OH that link is part of the z-wave network and works independently of OH. So, even if your OH system goes offline for some reason motion control will still work for that light. (I have this setup in a few rooms that require no flexibility and have z-wave sensors and z-wave light controllers).
If you want more variable control over the connection between sensor and light then the expire setting is probably what you’re looking for at the moment. In OH3 it is no longer a separate binding, the function is baked right in. For any item, you click on the add metadata link and choose expire timer. Then you would set up something like this:
You will still need to set up a rule that sends the ON command to the item whenever the motion alarm triggers. What this will do is every time the light get the turn on command it will start the countdown timer from 15 minutes. If there is new motion which causes the motion alarm to update the light’s state to ON again then the countdown timer will reset. If no further updates cause the countdown to reset then at the end of 15 minutes the expire timer will send the OFF command to the light.
The one possible problem with this is that the expire timer cannot distinguish between the source of the ON command that starts the timer. If you manually turn on the light the same expire timer will start up and the light will turn off again after 15 minutes even if maybe you didn’t desire it. If you know you always want the light to turn off after 15 minutes no matter how it is turned on then this is the way to go.
Lastly, you can do all of this with rules, but this gets much more complicated and you will have to familiarize yourself with the creation and operation of timers in rules and how to get those timers to persist between different iterations of a rule. Something like this is what I do for most of my living spaces where there’s a chance that someone is in the room without significant motion for a long duration because I can use metadata to distinguish between items that have been turned on automatically and thus should be turned off automatically and items that have been turned on manually and should remain under manual control. Furthermore, I can alter the both the ON and OFF responses based on the time of day.
Awesome @JustinG thank you will definitely try this.
For this part above, when you say metadata, what do you use in the rules to see whether the light has been turned automatically vs. manually? Is there any parameter in the metadata from the rule that controlled the item or on the item itself?
Is the flow like this:
Trisensor detects motion
Rule 1 detects the trisensor event → Turns on Item A
Rule 2 (time based) detects item A has been triggered automatically for X minutes (is this obtained from item A or do we make Rule 1 write this somethere?)
Rule 2 turns off item A
There is no standard metadata for this. I use a custom metadata namespace that I’ve named ControlEvent.
Motion sensor rule:
ON and controlled device OFF then controlled device ON and controlled device ControlEvent metadata value set to MotionOFF and controlled device ControlEvent meatadata equals Motion then controlled device OFFGeneral lighting rule:
OFF then ControlEvent metadata set to NoneHey JustinG,
Under the most basic setup, the buttons on the wallmote will change the Scene number channel. The result will be in the form of “#.#” The ones place will be the number of the button 1 or 2, or 1 - 4 depending on whether you’ve got the two or four panel version. The decimal place is 0 for short press, 1 for long press, and 2 while press is being held down. The depreciated channels are to replicate the association groups if you wanted to set up direct links for different scene arrangements.
I always only get the number channel without any decimal place. Any idea what is wrong?
openHAB 3.2.0.M1
Don’t necessarily trust what you see in that item page. The default widget will display the number state modified by any state description metadata that item may have and the z wave channel in this case applies a default state description that trims off the decimal.
Look at the logs when the item changes. Or look at the actual item state using the API explorer. There you should see that the actual state does have the decimal even if the display state does not.
hi @JustinG,
ah you’re right. I also tried to show the sate in basicUI but also didn’t get decimal point.
with [%1.f] it shows up.
Looks like this was a change in OH3 as i’m pretty shure that it worked with deciaml point in OH2 without using value casting.
Thanks!
