Tricky Smart Switch / Smart Bulb Group Scenario

šŸ“ Rule MachineĀ®
1

Sorry for the long post, but I fear that if Iā€™m not specific, any answers may not apply enoughā€¦

Soā€¦ I have Meross WiFi switches that I used with SmartThings. I canā€™t afford to replace them with Z* devices. I recently purchased Sengled RGBW bulbs. I have multiple bulbs in a lighting unit (ceiling fan, vanity light, etc.).

The bulbs do not always show the correct status under ā€œCurrent Statesā€. This is especially true if the wall switch is actuated. In this case the bulbs often show the state they were in before the switch was de-energized. The Meross switches use a community driver. The switches are polled every minute to determine their status.

I created lighting groups for each unit. I included the Meross switches as well. Using the lighting group actuator always refreshes the Meross switch status correctly. The main issue is that when the Meross switch is actuated, either manually, the device page, a tile, or the actuator (yes, still the deviceā€¦), the Sengled bulbs sometimes turn on, sometimes turn on and off again, and sometimes do not come on. Toggling the switch manually a few times get the bulbs on again, but the WAF factor there is sub-zeroā€¦ :cold_face:

I tried rule machine to query the Meross switch, and if itā€™s on, to turn on the lights. This works great if the switch is actuated with the tile or from the device page. If energized manually, it takes up to a minute (the driver polling period) to turn the lights on. No problem, I thought, I can refresh the switches every second, and should reduce the latency to a maximum of 1 second. That worked very well, until the C-8 came to a screeching halt due to the loggingā€¦

My next attempt was to create a variable for each lighting unit. (FanBulbsAreOnline for example) I used rule machine to do the following:

If the Meross switch is discovered to be on (there must be power) Then

FanBulbsAreOnline = TRUE

EndIf

If any of the bulbs are on (again there must be power) Then

FanBulbsAreOnline = TRUE

EndIf

(This can be flakey because the bulbs donā€™t always show the correct status)

If the Light Group actuator is on Then

FanBulbsAreOnline = TRUE

EndIf

If the Light Group actuator is off Then

FanBulbsAreOnline = FALSE

EndIf

If the Meross switch is discovered to be off Then FanBulbsAreOnline = False

EndIf

(This can take up to a minute as well, but isnā€™t an issue as FanBulbsAreOnline still equals TRUE, should it be turned right back on again)

But wait, I have to query the state of the variableā€¦ So then came the following rule that runs, you guessed it, every second

If FanBulbsAreOnline == TRUE

Turn on the group (remember, the biulbs donā€™t always show the correct state

Else

Turn off Group

EndIf

This over fills the logs as well.

All the debug logging is off. The rules have no logging checked.

I realize that having a switch in front of the smart bulb is not best practice, but thatā€™s how it is, and why have a smart home hub except for to solve these little issues with automationsā€¦

So, my question is, not what hardware needs to be replaced, but what is the best way to accomplish the task? I would like to simply not log the events unless I needed to troubleshoot. The simplest rule was my first try (query the Meross switch, and if itā€™s on, to turn on the lights)

Iā€™d appreciate any constructive help! Thank you!

2

Which driver are you using for the Sengled bulbs?

For posting code like text, you can use the "preformatted" option and it will display nicer.
image

The bulbs do not always show the correct status under ā€œCurrent Statesā€. This is especially true if the wall switch is actuated. In this case the bulbs often show the state they were in before the switch was de-energized. The Meross switches use a community driver. The switches are polled every minute to determine their status.

This is expected. The status inside of Hubitat is updated when the device sends an 'event' to tell it what the status is. When power is abruptly killed (from turning off the switch) then the bulb isn't able to send the event that it was turned off. The hub remains blissfully unaware of it's current state.

That worked very well, until the C-8 came to a screeching halt due to the loggingā€¦

The logs aren't the problem. What you don't see is the app code in the backend that's constantly having to do (presumably) API calls to the switch to try getting the current status. That's what brought the hub to it's knees.

3

I'm using the system's Sengled Element Color Plus driver.

4

I updated my last post with some more details.

All this to say, with IP switches, you're going to have a mediocre experience.
With IP switches AND smart bulbs, you're going to have a bad time.

There's not much to get around it. There will always be some level of delay measured in seconds before those two devices come into sync with each other.

SmartThings worked around local processing limitations (like doing a bajillion API calls a second) by offloading some of that processing to their cloud service. Hubitat doesn't take that approach, so you are limited by what the SoC can handle inside the hub.

You can try switching to the "Advanced Zigbee RGBW" driver. There's a preference for setting the state when the device loses and regains power. I just don't recall whether or not that actually works with those bulbs.

The last option I can think of is to continue down the path of polling the switches. You can modify your actions to say:

Trigger: Meross switch turns off
Repeat while (Meross switch is off) every 20 seconds
     Refresh (switch)
END-REP

You will definitely need to poll less frequently. How often you can poll will depend on a lot of factors, predominantly based on what other loads the hub has. You may dial one device into 15 seconds successfully, but when you add a second one at 15 seconds, the hub locks up again.

5

Polling 10 switches per second with an HTTP request can't possibly be that taxing on the hub...

I dug out the Sengled hub and paired a bulb with it. It was able to determine the state dependably 100% of the time regardless, but maybe it polls...

The issue here is that the driver polls only once per minute:
runEvery1Minute(refresh)
Is there an option to, perhaps
runEvery5Seconds(refresh)
Again, I can't imagine that the hub has so little CPU power to handle that...

Edit:

This is the refresh code:

def refresh() {
if (!settings.deviceIp || !settings.uuid || !settings.key) {
sendEvent(name: 'switch', value: 'offline', isStateChange: false)
log 'missing setting configuration'
return
}

try {
    def payloadData = getPayload()

    def postBody = [
        payload: [ ],
        header: [
            messageId: "${payloadData.get('MessageId')}",
            method: "GET",
            from: "http://${settings.deviceIp}/config",
            timestamp: payloadData.get('CurrentTime'),
            namespace: "Appliance.System.All",
            sign: "${payloadData.get('Sign')}",
            triggerSrc: "hubitat",
            payloadVersion: 1
        ]
    ]

    def params = [
        uri: "http://${settings.deviceIp}",
        path: "/config",
        contentType: "application/json",
        body: postBody,
        headers: [Connection: "keep-alive"]
    ]

    def callbackData = [:]
    callbackData.put("messageId", payloadData.get('MessageId'))
    asynchttpPost("refreshResponse", params, callbackData)
} catch (Exception e) {
    log.error "refresh hit exception '${e}'"
}

}

6

I'm installing the latest update, but I'll try that later. If that works, it solves the problem...

7

You've proven that it is or we wouldn't be talking :slight_smile:.

It's more than just hitting the API. The hub has to make the call and then process the response once it comes back. That could be a few lines or it might be a page of stuff (I don't know specifically for these devices). There's also the possibility that the driver needs some efficiencies. Either way, you're stuck where you are.

That's the normal poll frequency. With the snippet you posted, I presume that there is a "refresh" button on the device page. So, in Rule Machine:

image

8

TouchƩ. It shouldn't possibly be that taxing on the hub...

Changing the driver from "Sengled Element Color Plus" to "Advanced Zigbee RGBW" fixed the issue, so I guess someone needs to work on the Sengled driver. I'd volunteer to test...

Thank you for your help!

1 Like