Need Suggestion for Z-Wave Fan Level

Setup, Configuration and Use Items & Sitemaps
, ,
1

I use GE In-Wall Smart Fans Switches. They’re similar to Dimmers where they have levels 0-100. When the switch is level 1-33, the switch will output the low voltage to the fan, 34-66, medium voltage and 67-100 high voltage.

I’m using Selection in Sitemap and Panel with the options OFF=0, LOW=10, MED=50, HIGH=100. This works great until someone uses the physical switch to change the Fan speed. When that happens the switch level can end up at any dim level within the LOW, MED and HIGH levels. When that happens, the BasicUI and Panel may no longer display LOW, MEDIUM or HIGH because the Dim level may no longer be 10, 50 or 100.

I setup a fans.map where 0=OFF, 1-33=LOW, 34-66=MED, 67-100=HIGH. This works great when using a Slider, but not with Selection.

The other option I tried was a rule that would set the switch to 10, 50 or 100 when the fan changes to something other than 10, 50, 100. The problem is, OH doesn’t always know when the switch level was changed.

I’m wondering what other approaches there are or better yet, if this could be defined at the binding level.

Thanks, Glenn

2

Explain further. If OH doesn’t know that the switch changed then there is nothing you can do at all. OH can only work with what information it has.

With zwave it polls every so often so eventually it will detect and update the Item when it polls the device and discovers that the Item state doesn’t match the switch state. And then your Rule will run to reset the levels. But if you need the sitemap to immediately to reflect the physical switch, the physical switch must report when it is physically manipulated. There isn’t anything we can do from the OH side to force it.

The one thing you can check is to see if the Thing has any association groups. If it does make sure it (or one of them) is set to “controller” which will cause the switch to report state changes back to the controller.

3

Hi @rlkoshak, thank you for the suggestion.

The devices report back when they go from On to Off and Off to On from the wall switch but not when the dim level changes. There are no group associations.

I’m fine with the device not reporting back immediately so you suggestion a on the polling should be fine. Can you tell me what trigger I would used to detect when the item state doesn’t match the switch state?

Thanks!

4

That is all handled in the binding. You can write a Rule that triggers on changed and then postUpdate to the adjusted value if it isn’t one of the four accepted values.

5

Hi @rlkoshak, I set the polling on a couple of the fans to 10 minutes to test and sure enough the following code runs and ensures the fan is set to 10, 50 or 100.

rule "Set Ceiling Fan Levels"
when
    Member of Fans changed 
then
    logInfo("RuleExamples", "The item " + triggeringItem.name + " changed state from " + previousState + " to " + triggeringItem.state)
    if ((triggeringItem.state != 0) && (triggeringItem.state != 10) && (triggeringItem.state != 50) && (triggeringItem.state != 100)) { 
        if ((triggeringItem.state > 0) && (triggeringItem.state < 34)) { 
            Fans.members.filter[d|d.name == triggeringItem.name].forEach[d|d.sendCommand(10)]
        } else if ((triggeringItem.state > 33) && (triggeringItem.state < 67)) {
            Fans.members.filter[d|d.name == triggeringItem.name].forEach[d|d.sendCommand(50)]
        } else if (triggeringItem.state > 66) {
            Fans.members.filter[d|d.name == triggeringItem.name].forEach[d|d.sendCommand(100)]
        }
    }
end

Any suggestions you have for optimizing the code would be very welcome :slight_smile:

Couple other questions if you don’t mind. The default polling period for all my z-wave devices (about 65) is 1 Day.

  • Would setting them all to 1 hour create any issues?
  • Is there a way to globally make the change so I don’t have to go through each one by one?

FYI, I’m using text file to configure Items but Things are configured in the UI.

Thanks Again

6

It might be a little clearer to use a switch statement.

This results in a rule along the lines of:

    logInfo("RuleExamples", "The item " + triggeringItem.name + " changed state from  " + previousState + " to " + triggeringItem.state)

    val currState = triggeringItem.state as Number

    var newState = 0
    switch(currState) {
        case 0,
        case 10,
        case 50,
        case 100: return; // nothing to do
        case currState > 0 && currState < 34: newState = 10
        case currState >=34 && currState < 67: newState = 50
        case currState >=67: newState = 100
    }

    triggeringItem.postUpdate(newState)

Notice a few changes, I use >= so there are no skipped numbers. I use postUpdate because presumably you don’t want to actually change the speed of the fan (maybe you do in which case continue to use sendCommand). Why are you filtering then looping through members of Fans when you already have the Item you need to postUpdate/sendCommand to in triggeringItem?

I can’t answer that but that many devices probably generates a lot of traffic. I’d be prepared to dial that back if you run into problems.

I doubt it. Once you change the parameter the binding must send that new value to the device. I doubt you can do that by just editing the JSONDB, though it might be possible.

1 Like