[BUG] THR316D mapping issue in native integration (CUBE 2.12.0) - Regression from Docker Add-on!

eWeLink CUBE
,
1

Hi eWeLink Team,

I am reporting a critical bug in the scene engine logic (CUBE OS) regarding the THR316D (Firmware 1.3.0) on the iHost (CUBE Version 2.12.0).

The issue appears after migrating from the deprecated “eWeLink Smart Home” Docker add-on to the new native device synchronization method (“Add eWeLink-linked Devices”). The new native method completely breaks the logic for TH devices by introducing incorrect capability mapping.

Here are the two critical bugs we are currently facing:

BUG 1: “OFF” state blocks temperature reading in conditions (UI Bug)
In the native scene creator, when trying to set up a complex condition (IF) for the THR316D:

  • If I set the relay state to ON, the system allows me to add a second condition from the same device (e.g., Temperature < 20°C).
  • If I set the relay state to OFF, the iHost UI incorrectly assumes the entire device is inactive/powered down and blocks/hides the ability to add a temperature condition.
    This is an absurd UI logic flaw. The most basic heating automation is: “IF the heater is OFF AND the temperature drops below X → TURN ON”. Currently, this is impossible to set up natively. In the old Docker add-on, this worked flawlessly.

BUG 2: Missing promised exception for TH devices (IF / THEN block)
It has been stated multiple times on this forum (e.g., by admin songal) that TH (Temperature & Humidity) devices would be an exception to the rule and could be used simultaneously as a trigger (IF) and an action (THEN) in the same scene.
Unfortunately, in the new native integration, this exception does not work. If I use the THR316D in the IF section (e.g., temperature drop), the device completely disappears from the list of available devices in the THEN section. Again – there was no such issue in the old Docker add-on because the relay and the sensor were treated independently.

Summary:
This is not a “Feature Request”. It is a clear regression and a bug in the CUBE OS code, which misinterprets multi-capability devices added via the new method. Users are being forced to abandon a perfectly working Docker add-on in favor of a native system that makes it impossible to build a basic thermostat.

Please forward this directly to the development team to fix the TH device mapping and UI logic in CUBE OS.

4

Hello @JMZ,

Thank you for your feedback. We sincerely apologize for any inconvenience this may have caused.
We have urgently identified the root cause of this issue and completed verification of the fix. This fix will be officially included in the upcoming 2.13.0 release in August.
To help resolve your current problem sooner, we are offering an early firmware version 2.12.1 with the fix already applied. Could you please provide the device ID of your iHost so that we can push this version to your device? Once the push is completed, we will update you in this thread and provide instructions on how to install the firmware package.
After the official 2.13.0 release, you will still be able to obtain the formal version through the regular update feature.
We appreciate your cooperation.

5

I sent DM with IDs

6

Hello @JMZ , thank you for your feedback. Version 2.12.1 has been pushed to your iHost device. You can check for the latest version and update it by following the instructions shown in the figure below.
As for the CUBE OS distribution, you will need to wait approximately two weeks; the 2.13.0 release will address the issue you are experiencing.

Additional notes:
Regarding BUG 1 you reported – after investigation, we found that devices synced via the old add‑on also do not support setting the temperature when the relay state is set to “OFF”. This feature will be available in the 2.13.0 release in August, and both the built‑in add‑on and the old add‑on will support it.
The targeted firmware package we are pushing to you now is intended to resolve BUG 2 in advance. Thank you for your understanding.

b429eddfb0768556555e329b3ecc8f92
b429eddfb0768556555e329b3ecc8f921768×899 74.6 KB

7

Hi Miao,

Thank you for the incredibly fast response and for pushing the 2.12.1 firmware to my iHost. I really appreciate the team taking this seriously.

I have tested the new version and here is my feedback:

1. BUG 2 is fixed!
I can confirm that I can now use the same TH device in both the IF (trigger) and THEN (action) sections within the same scene. This is a huge improvement, thank you!

2. BUG 1 is still partially bugged in 2.12.1.
When I set the TH device state to “OFF” in the IF section, I still cannot select “Temperature”. However, interestingly, the system does allow me to select “Humidity”. It seems the UI logic is specifically blocking the temperature parameter when the relay state is OFF, but forgot to block humidity.

I note your explanation that the complete fix for BUG 1, as well as the update for the CUBE OS (Proxmox VM), will be fully addressed in the upcoming 2.13.0 release in August. I will patiently wait for that official release to finalize my complex heating automation setup on my Proxmox server.

Thank you again for your excellent support and for listening to the community!

8

@Miao any progress regarding this topic?

9

Hello, @JMZ
Thanks for your thorough testing and feedback – it’s greatly appreciated.

Your observation of BUG1 in 2.12.1 is correct. This hotfix mainly targeted BUG2 (IF/THEN conflict), which is now fixed. For BUG1 (temperature blocked when relay is OFF), full support requires deeper scene engine changes, so we plan to include it in the August 2.13.0 release for both iHost and CUBE OS.

So, temperature still being unavailable in 2.12.1 is expected – it’s not a new bug. We’re on track, and full support (including temperature) will be available in 2.13.0 for both iHost and CUBE OS. Thank you for your understanding.

10

Hello, @Miao

Thank you for the transparent explanation! It makes perfect sense. I will patiently wait for the 2.13.0 release in August to get the full fix for BUG 1. I really appreciate your great support.

Since we are discussing CUBE OS, could I ask you to clarify one more critical behavior regarding the Automatic Backup feature? I would like to know if this is a BUG or an intended FEATURE.

Currently, the automatic backup seems to force itself to run at 4:00 AM every day, even if it is toggled to “Disabled” in the UI.
For example:

  • If I simply disable the automatic backup while it is set to “Daily”, it still runs at 4:00 AM.
  • If I schedule a backup for 2:00 PM, the system makes a backup at 2:00 PM, but also forces another one at 4:00 AM.

Why is this important?
When this forced 4:00 AM backup runs, under certain circumstances (though not always), CUBE OS simply loses its connection with Node-RED (or vice versa). As a result, Virtual Switches sometimes lose their connection to the CUBE OS API and require re-initialization.

For users running CUBE OS as a Virtual Machine (e.g., on Proxmox), we perform full VM-level backups, making the internal CUBE OS backup completely unnecessary.

Could you clarify if this 4:00 AM behavior is a bug? And will there be a clean, official option to completely disable internal backups for VM users in future releases?

Thanks again for your time and help!

PS. One more thing – A Feature Request for CUBE OS Cast:
Currently, I use Node-RED virtual switches to trigger manual scenes in CUBE OS just to have visual feedback on my Cast dashboard. I realized this would be a fantastic native feature for CUBE OS.

Could the team consider adding a native “Stateful Scene Switch” (Virtual Toggle)?
Here is how it would work:

  • Toggling the switch ON triggers one specific manual scene.
  • Toggling the switch OFF triggers another manual scene.
  • Most importantly, it retains its ON/OFF visual state on the Cast dashboard.

Currently, manual scenes on Cast are just stateless push-buttons. By looking at the screen, you cannot tell if a specific mode or scene is currently active. A native toggle switch would provide instant visual feedback for the users, completely eliminating the need for external workarounds like Node-RED just to see what is currently running.

11

Hello, @JMZ
Thank you for your detailed feedback. We have successfully reproduced the issue where the automatic backup forcibly runs at 4:00 AM, and we are currently investigating and working on a fix. We will keep you updated on any progress.

Regarding your feature request for a “Stateful Scene Switch” (Virtual Toggle) for CUBE OS Cast – we would like to ask whether you have already tried the following workaround, and whether it might meet your needs:
Create a virtual switch in the eWeLink app, sync it to iHost via the add‑on, configure the desired scenes, and then display the switch on the Cast panel.

Please let us know if this approach works for you.

12

Hello, @Miao

Thank you for the great news! I am very glad to hear that the 4:00 AM backup bug has been reproduced and a fix is in the works. This will be a huge relief for all VM/Proxmox users.

Regarding your suggestion to use virtual switches from the eWeLink app:
I am familiar with eWeLink virtual switches, and I also know there are quantity limits depending on the subscription plan.

However, the main problem is that they work via the cloud, not locally. The ultimate goal of using CUBE OS is to have everything running 100% locally, so the system works flawlessly even when there is no internet connection.

That is exactly why I currently use Node-RED to create local virtual switches. It keeps everything local and independent of the cloud.

But this raises the question: why not build this functionality directly into CUBE OS? Having a native, 100% local “Stateful Scene Switch” (Virtual Toggle) would eliminate the need for external add-ons or cloud dependencies just to get a proper, state-aware button on the Cast dashboard.

I hope the team will consider adding this native feature in the future! Thanks again for your excellent support.

13

Hello, @JMZ
Thank you for your detailed feedback.

Here is an update on the two items you raised:

  1. Regarding the issue where the automatic backup forcibly runs at 4:00 AM – we have confirmed that this will be fixed in the upcoming 2.13.0 release in August. After updating to this version, you can select “Disable” on the automatic backup configuration page. This will stop all automatic backup tasks, including the forced 4:00 AM backup you mentioned. When you later wish to use the automatic backup feature again, simply select “Enable”, and only your currently configured backup schedule will run – the forced 4:00 AM backup will no longer occur.

  2. Regarding your request for a native, fully local “Stateful Scene Switch” (Virtual Toggle) – we have recorded this request and will conduct an internal evaluation.

We sincerely appreciate your support and understanding.

14

Thank you.