Dimmer target levels in ZWave?

@chris I have a bunch of Cooper dimmers which on my Vera setup I could set target levels for the dimmers without turning them on. I haven’t been able to find anything similar when I migrated them to OH2. Is this simply a mater of configuring the Zwave database for those devices or is this not possible currently?

Thanks.

I’m not sure how this is done - I guess it’s probably device specific so I think you need to provide a bit more information about what the device is and how you did this on Vera.

I have a Leviton dimmer I still run on the Vera which are very similar to the Coopers.

Is this done by the Load Level Target property as opposed to the Load Level Status which actually adjusts the light?

I don’t know what this is…

There is an option in the multi-level-swich class to restore the last level when the device is turned on - this is available in recent OH2 and also OH1. This is a feature of the SET_LEVEL command. I’m not aware of a “Load Level Target” command and it’s not documented in the ZWave standard -:

The Start level change command has the ability to set a target level, but as I read it, it will start to move to that level immediately - I don’t see any way to set a target level but not change the current level, which is what I understand you are asking for…

Can you point me at the device that does this so I can take a look at the manual.

Sorry, I was actually replying to rgerrans. I’m assuming he was doing this via Luup commands in Vera as I’m not aware of any way to do it via a scene or directly.

Not sure if it will help at all, but these are all the items created via the MiOS generator and binding for my dimmer which, as I said, is very similar the the Cooper ones.

/* Device - Foyer Lantern */
Number   FoyerLanternId "ID [%d]" (GDevices) {mios="unit:vera,device:199/id"}
String   FoyerLanternDeviceStatus "Foyer Lantern Device Status [MAP(miosDeviceStatusUI.map):%s]" (GDevices) {mios="unit:vera,device:199/status"}
String   FoyerLanternIgnoreConfigFails "Foyer Lantern FIXME IgnoreConfigFails [%s]" (GDevices,GRoom2) {mios="unit:vera,device:199/service/HaDevice1/IgnoreConfigFails"}
Number   FoyerLanternConfigured "Foyer Lantern Configured [%d]" (GDevices,GRoom2) {mios="unit:vera,device:199/service/HaDevice1/Configured"}
String   FoyerLanternModeSetting "Foyer Lantern Mode Setting [%s]" (GDevices,GRoom2) {mios="unit:vera,device:199/service/HaDevice1/ModeSetting"}
DateTime FoyerLanternLastUpdate "Foyer Lantern Last Update [%1$ta, %1$tm/%1$te %1$tR]" <calendar> (GDevices,GRoom2) {mios="unit:vera,device:199/service/HaDevice1/LastUpdate"}
DateTime FoyerLanternFirstConfigured "Foyer Lantern First Configured [%1$ta, %1$tm/%1$te %1$tR]" <calendar> (GDevices,GRoom2) {mios="unit:vera,device:199/service/HaDevice1/FirstConfigured"}
Dimmer   FoyerLanternLoadLevelTarget "Foyer Lantern Load Level Target [%d %%]" (GDevices,GRoom2) {mios="unit:vera,device:199/service/Dimming1/LoadLevelTarget"}
Dimmer   FoyerLanternLoadLevelStatus "Foyer Lantern Load Level Status [%d %%]" (GDevices,GRoom2) {mios="unit:vera,device:199/service/Dimming1/LoadLevelStatus"}
Switch   FoyerLanternStatus "Foyer Lantern Status" (GDevices,GRoom2) {mios="unit:vera,device:199/service/SwitchPower1/Status"}
String   FoyerLanternslHail "Foyer Lantern FIXME sl_Hail [%s]" (GDevices,GRoom2) {mios="unit:vera,device:199/service/HaDevice1/sl_Hail"}
String   FoyerLanternPollRatings "Foyer Lantern FIXME PollRatings [%s]" (GDevices,GRoom2) {mios="unit:vera,device:199/service/HaDevice1/PollRatings"}
DateTime FoyerLanternLastPollSuccess "Foyer Lantern Last Poll Success [%1$ta, %1$tm/%1$te %1$tR]" <calendar> (GDevices,GRoom2) {mios="unit:vera,device:199/service/ZWaveNetwork1/LastPollSuccess"}
Number   FoyerLanternConsecutivePollFails "Foyer Lantern Consecutive Poll Fails [%d]" (GDevices,GRoom2) {mios="unit:vera,device:199/service/ZWaveNetwork1/ConsecutivePollFails"}
Number   FoyerLanternCommFailure "Foyer Lantern Comms Failure [%d]" (GDevices,GRoom2) {mios="unit:vera,device:199/service/HaDevice1/CommFailure"}
DateTime FoyerLanternCommFailureTime "Foyer Lantern Comm Failure Time [%1$ta, %1$tm/%1$te %1$tR]" <calendar> (GDevices,GRoom2) {mios="unit:vera,device:199/service/HaDevice1/CommFailureTime"}
String   FoyerLanternCommFailureAlarm "Foyer Lantern FIXME CommFailureAlarm [%s]" (GDevices,GRoom2) {mios="unit:vera,device:199/service/HaDevice1/CommFailureAlarm"}

FoyerLanternLoadLevelStatus actually controls the dimmer. I was wondering if FoyerLanternLoadLevelTarget (or his equivalent) was what he was using to set the level but not activate the light.

My Leviton dimmer is a VRI10-1LX if memory serves me right. The instruction and data specification sheets can be found here:
http://www.leviton.com/OA_HTML/ProductDetail.jsp?partnumber=VRI10-1LX&section=44140

@RHINESEL In the Vera you can get to the additional variables through the Advanced Option vs. having to do direct Luup programming (which I’ve always had mixed results in and hence why I moving over to OH)

@chris In the Vera the variable is defined as “SetLoadLevelTarget” (consistent with the Mios mapping Matthew and I are both seeing from the Mios binding). What it does is overrides the last dim level with a new level so that when the dimmer comes back on at the “restore to last” it comes up at that target level. I guess the million dollar question is if this is a device feature (i.e. if I set it while the device is off, will the notification level on the dimmer adjust while it is off) or is it a backend process where they are intercepting the “on” command to the dimmer and sending the new target level.

I will try to test tonight to see if I can verify that they are directly communicating this to the device in real time, but I’m heading out of town tomorrow so might not be able to test until late next week.

If you set the last level, and then turn the switch on at the physical switch, does it respect the new level, or another (older) level?

I don’t remember, that’s what I was saying that I need to test that when I’m back home to see so we’d know if it’s actually on the device or a backend work around.

Here is the spec sheet for the Cooper dimmer I’m using - http://www.cooperindustries.com/content/dam/public/wiringdevices/products/documents/spec_sheets2/AspireRFSmartDimmerSpecSheet.pdf

What is “Basic Set Value” (Parameter 4)?

I’m not sure, but often this sort of parameter is the value that the device sends to other devices when you click on it. So, if you had an association between two devices, then you can configure the value that it sends…

Or… it might be something else - try it and see :wink:

Thanks. I’ll try to do the physical test tonight to verify if I can preset the levels with the device off (which is what I’m trying to achieve so I can set lower levels at night on my bathroom dimmers w/o having to set them after they are turned on).

I’ll still do a physical test, but it looks like a similar discussion was going on over at SmartThings a year ago - https://community.smartthings.com/t/set-dimmer-value-without-changing-light-state/10926/7 where they also thought that the feature should be available on Leviton and Coopers but didn’t see how to set it.

Are there any files on the Vera that I could pull that would show how they are communicating with the dimmers?

It’s been far too long since I used my Vera - maybe someone else has an idea…

Looks like there is no likely difference between SetLoadLevelStatus and SetLoadLevelTarget. I realized I could setup a remote scene on my Vera and monitor if the light came on or not and sure enough using the SetLoadLevelTarget on the Vera turned on the light at the dimmer level. I also realized that while the Mios Binding exposes a SetLoadLevelStatus there is no equivalent in the advanced options on the Vera. So it looks like both of these are the same command.

Oh well, guess plan b of adjusting the dim level after it’s turned on manually. Hopefully the delay won’t be too bad.

Sorry for sending us down a rabbit hole.

So, what is your use case? Maybe someone can help you with a rule to accomplish what you want.

Are you trying at a certain time to have the level set to a specified level so that next time the person manually turns on the switch it will come on at the predefined level?

@RHINESEL Thanks. The rule isn’t the issue it’s how it gets implemented. I’m trying to set target dimmer levels based on time of day (100% during sunlight hours, 60% until ~midnight and 25% until dawn). In an ideal world, when the dimmers are turned on manually they’d go right to those levels.

My Plan B is to trigger the rule when the dimmer is turned on and then change the dim level. The question is going to be how long will the delay be. I use Coopers for the most part so they are supposed to send status changes to the controller vs. having to wait to be pulled so hopefully they will go change pretty quickly. I do have a few other micro dimmers behind switches where I didn’t want the blue LED’s showing so we’ll see how they play…

SetLoadLevelStatus doesn’t exist as a UPnP Action (AKAICT). I ran http://veraIP:3480/data_request?id=invoke to peruse the tree of UPnP Actions that are exposed (my Vera is on UI5)

For the UPnP _State variable_s, LoadLevelTarget represents the requested value, from the user, and LoadLevelStatus is the currently reported value, from the device.

In theory, they’re supposed to become the same, with a time-lag between the phases (requested-state, execution on the device, and new-state back to Vera)

In practice, they often get out of whack, esp when activated at the Switch (I have Leviton VR line)

For UPnP Actions, MiOS only exposes the SetLoadLevelTarget call. The generator will expose both as UPnP State Variables (above), but it only exposes/uses the SetLoadLevelTarget action. Any changes to the UPnP State Variable LoadLevelStatus are internal to MiOS (typically when the device reports back to Vera)

You mention that you see it making these SetLoadLevelStatus calls, can you elaborate a little? The MiOS Binding should never do that.

Anyhow…
The bit that’s missing is the internal settings (Device Options/Add Configuration setting in Vera). The Leviton (and Cooper) devices likely have an internal variable to set the default-level to use when someone presses the physical Dimmer button.

It’d be the logical equivalent of the “Program Mode A-3” Setting that’s available for Leviton:

http://www.leviton.com/OA_HTML/ibcGetAttachment.jsp?cItemId=MXB2B25lX67a1PUQEBH9VA&label=IBE&appName=IBE&minisite=10251

With that, you’d be able to set the default-level. All other MiOS actions would result in the light coming on whilst the SetLoadLevelTarget is executed (and you’d have to quickly follow with a SetTarget to turn them off)

@guessed Mark - Thanks for taking the time to dig in and explain this a technical level that is much above my pay grade.

As far as the Mios Binding, when I ran the generator scripts and got similar results for my dimmers as Matthew (I’m traveling this week so don’t have access to the files) but from his pull above:

Dimmer   FoyerLanternLoadLevelTarget "Foyer Lantern Load Level Target [%d %%]" (GDevices,GRoom2) {mios="unit:vera,device:199/service/Dimming1/LoadLevelTarget"}
Dimmer   FoyerLanternLoadLevelStatus "Foyer Lantern Load Level Status [%d %%]" (GDevices,GRoom2) {mios="unit:vera,device:199/service/Dimming1/LoadLevelStatus"}
Switch   FoyerLanternStatus "Foyer Lantern Status" (GDevices,GRoom2) {mios="unit:vera,device:199/service/SwitchPower1/Status"}

I configured my initial switches using the LoadLevelStatus since I was seeing it presented in both the Switch and Dimmer items being generated from the transformation script and it was consistent with the Mios Binding GitHub wiki page: https://github.com/openhab/openhab/wiki/MiOS-Binding#a-dimmer-volume-control-speed-controlled-fan

Then I made the incorrect jump to assuming that the LoadLevelTarget would change the target value in the switch w/o turning it on. But based on digging into my Vera I realized there was no LoadLevelStatus presented for a dimmer, just the LoadLevelTarget which caused the device to immediately turn on and go to that dimmer level,

Hopefully that all makes sense.

Thanks.

For that one, bound to Dimming1/LoadLevelTarget, I should generate it differently. In this case, it should be closer to:

Number   FoyerLanternLoadLevelTarget "Foyer Lantern Load Level Target [%d %%]" (GDevices,GRoom2) {mios="unit:vera,device:199/service/Dimming1/LoadLevelTarget"}

This would make it closer to matching the Generation I do for the SwitchPower1/Target state variable from MiOS.

As it stands, using the Dimmer control against the FoyerLanternLoadLevelTarget probably does nothing to control the physical Dimmer.

For the Item generator, I bind the Value Item in openHAB to the Control (Dimmer, etc). When you interact with the Control in an openHAB UI, it’s sending Commands to the MiOS Binding code. Behind the scenes, I’m translating these openHAB Commands into the required UPnP Action call for MiOS.

There’s an internal mapping in the MiOS Binding that makes this work, behind the scenes, without most needing to know how it works.

But only for certain well known/common cases.

To give you a better idea, here’s a walked example (end-to-end) for Dimmers. In this case, you’re bound to a Dimming1/LoadLevelStatus value from MiOS, then any interaction with the UI Control will cause:

  • a) openHAB Commands are transformed by the MiOS Binding into Dimming1/SetLoadLevelTarget(…) calls to MiOS/Vera.
  • b) MiOS/Vera sets the value of Dimming1/LoadLevelTarget and sends a request to the physical Device
  • c) the physical Device changes it’s value and notifies MiOS/Vera.
  • d) MiOS/Vera changes the value of Dimming1/LoadLevelStatus
  • e) The MiOS Binding sees this change in value and sets it into openHAB to whatever Items are bound to it’s Dimming1/LoadLevelStatus value.

@guessed Thanks for the clarification
I won’t get to experiment until this weekend but will come back with any additional questions.