eWeLink scenes triggered by temperature or light intensity

Ideas & Suggestion
1

Dear all,

I’m using a ZBBridge Ultra and am trying to create simple scenes in eWeLink that are triggered by a temperature threshold being exceeded (Zigbee SONOFF SNZB-02P) or by a decrease in outdoor light levels (Zigbee SONOFF SNZB-03PR2). I want to create an automation that, for example, closes the blinds when the temperature is exceeded or when outdoor light levels decrease, or turns on a light when outdoor light levels decrease—and vice versa.

  • The problem is that if I set the event trigger in the eWeLink app for the SONOFF SNZB-02P to, for example, temperature > 26°C, or for the SONOFF SNZB-03PR2 to illuminance < 150, the scene does not trigger just once when the threshold is exceeded, but triggers repeatedly as long as the condition is met—and very frequently at that (for the SONOFF SNZB-02P at intervals of approximately 3–10 minutes, and for the SONOFF SNZB-03PR2 at intervals of 5–30 seconds).

  • This behavior makes it very difficult to create any meaningful automation with these triggers, because the scene keeps repeating. For example, the relay in a roller shutter switch is constantly cycling, and it is impossible to open the shutter manually because the scene repeatedly closes it, and so on.

  • While it is possible to work around this behavior by disabling the scene after it starts and then enabling another scene that will later re-enable it, this is completely unnecessarily complicated. Furthermore, this type of scene—which enables or disables other scenes—apparently requires a cloud connection (unlike other scenes, which are marked as “local” in the eWeLink app).

  • I don’t think this behavior makes sense. For example, if I create a scene triggered by a switch (on/off), the scene doesn’t repeat continuously as long as the switch is on; instead, it runs only when the switch’s state changes. This allows me to continue controlling the device that was turned on or off by the scene. I would expect exactly this behavior from scenes triggered by an analog parameter as well.

I am therefore reaching out to the eWeLink team to ask if they could consider changing the behavior of these scenes with analog parameters (e.g., for the SONOFF SNZB-02P and SNZB-03PR2), and likely others as well, so that the scene is triggered only once when the condition is met.

Thank you in advance

2

I agree that continuously retriggering a scene while an analog condition remains true is not very useful, especially for actions such as closing blinds or switching a relay.

However, I believe the expected behavior should actually be slightly different from what you are proposing. A threshold trigger should ideally fire when the value crosses the threshold, rather than every time the sensor reports a value that still satisfies the condition.

For example, with temperature > 26°C, the scene should trigger when the temperature rises from 26°C or below to above 26°C, and then remain inactive while the temperature stays above 26°C. It should become eligible to trigger again only after the temperature falls back to 26°C or below and subsequently crosses the threshold again.

This is also consistent with how threshold triggers have been described by eWeLink in the past. So if your scenes are currently being retriggered every few minutes/seconds while the condition remains true, I would consider that a bug rather than an intentional behavior.

Hopefully the eWeLink team can clarify whether this is the intended behavior for these particular Zigbee sensors, or whether something is causing every sensor report to be treated as a new trigger.

I had similar issues when I was still using eWeLink for my automations. In fact, limitations like this were one of the reasons I eventually moved my automations to Home Assistant. I kept the same Sonoff sensors, so this wasn’t a matter of replacing the hardware, only the way it was used.

One of the advantages of HA in this kind of situation is that you have much more control over the trigger logic. You can explicitly distinguish between a state/threshold crossing and a condition that simply remains true, add hysteresis or delays where appropriate, and decide exactly when an automation should be allowed to run again. This makes automations such as temperature- or illuminance-based blind control much easier to implement reliably.