Node-RED control-device node throw an error

eWeLink CUBE
113

From what we tested, still works fine…
These devices are from smart-home, can you send us the log of smart-home add-on also?
So we can check the problem from the source.

114

Smart-home magazine
1-iHost
2cdb3a37-c162-439a-9d28-119fbbe96979.rar (6,8 МБ)
2-iHost
a2286e92-0f81-434a-b1f5-f3c4b7360a02.zip (6,7 МБ)

115

Two magazines above

116

Hi, aerograf.
The logs you gave have two network segments and iHost, the situation is as follows:

192.168.3 network segment, iHost device id 1001ec3340, there are three devices control more frequently

  1. device id 10018387ce, control 1666 times, failed 105 times
  2. device id 1001dd0dd1, control 4084 times, failed 32 times
  3. device id 10017799a4, control 1247 times, failed 1 time
  • Device 10018387ce AKA DurlR3’s control failure cause is located, we will optimize this control experience in the next version of smart-home add-on.
  • The control failures for the remaining two devices is within normal range, these failures are due to network or device itself.

192.168.2 network segment, iHost device id 1001ec32a6, there are three devices control more frequently

  1. device id 1001e3aef8, control 747 times, failure 4 times
  2. device id 100162f435, control 478 times, failure 243 times
  3. device id 10015f86cc, control 119 times, failure 21 times
  • Device 10015f86cc AKA DurlR3’s control failure are for the same reason as above.
  • Device 100162f435 control failures are quite frequent, we are still locating the cause and will update here later.
  • Device 10015f86cc control failure frequency is within the normal range, these failures are due to network or device itself.

Device id can be checked in eWeLink app’s device setting page.

1 Like
117

I will wait for a solution and expansion of functionality.
1001e3aef8 - Е5-3С-86
100162f435 - NSPanel
10015f86cc - DualR3
10018387ce -DualR3
1001dd0dd1 - FW - PSF-B04-GL (0485)
10017799a4 - PSF-X67

118

Hi, aerograf.

From what we have reproduced, the device id 100162f435 AKA NSPanel will fail or timeout due to frequent control (eg: control the device every few seconds).

For now, reduce the frequency of control is recommended.

We’ll optimize the control exprience of the device in the future firmware version.

119

I did this a long time ago, but I had to turn it off from the scripts in Node-Red altogether, because when physically switching, it turned out that several commands were sent, and the light began to blink.

120

Do you mean that after the control fails, physically switch the device will cause it to switch more than once?

121

Yes. And also on TX Ultimate, etc.

122

Got it.
We’ll look into that, too.

1 Like
123

The smart-home add-on and node-red-contrib-ewelink-cube package released a new version yesterday.
Please update the add-on and node-red package, see if the control fail problem fixed?

124

Hello.
Already updated. I’m testing.
There are errors with the dashboard. I will write in more detail later.
Thanks for the work!

125

Sure.
Waiting for your feedback!

1 Like
126

It didn’t get any better.
I’ll test it some more. I am attaching the magazine. The relays are the same…
1709919522674.tar.zip (4,4 МБ)

127

Hello.
I don’t know how related this is, but my observations showed the following:
(it’s related to Node-Red, WebCAST, IHost)
Data transmission from devices about the status, temperature/humidity readings, consumption readings from POW R3, SPM, POW Original, etc. for some reason is not transmitted correctly or is not transmitted at all. But once you open the eWeLink application, all data begins to be transmitted in a normal form and in a timely manner …
Just like when Node-Red is running. If you open the application, everything starts working normally, without delays and failures. Including the devices listed above (dual r3, TX Ultimate, etc.).
It feels like the devices go into hibernation and respond only when on/ off, and then reluctantly, and everything else gives out incomprehensibly …
This is clearly visible on the WebCAST… I noticed the SPM on the readings and began to check further.

128

First of all, from what we tested.
TX Ultimate control failure is due to device itself.
If you have another TX Ultimate, try control it via node-red to compare with the other.

So Besides TX Ultimate, the durl r3 control failure is fixed in smart-home add-on v2.1.0 and should not be the problem here.
It’s the control failure of durl r3 still persist?

And then the problem of device status upload delay.
By saying the eWeLink application, did you mean eWeLink app?
Further more, the situation is you open iHost Cast or Node-red, the status and data transmission is inaccurate and with delay. But with eWeLink app open, it works perfectly without any delay?

For further information, we still need your smart-home add-on and node-red log.
Sorry for the problem it caused.

129

Yes. When you open the eWeLink application on your smartphone, the devices begin to work.
And this is visible not only on iHost, but also on the web version of CAST.
I can’t imagine the logs from iHost yet. Forced to return to HA.
I’ll try to restore iHost and continue testing…

130

iHost is not available now, is this means you cannot assure the control failure problem is fixed or not?

Problem received.
We’ll pinpoint what’s wrong.
We suggest submit the problem in your eWeLink app feedback, too.

131

iHost has limited availability. And the problem that existed before has not gone away. The magazine posted earlier.

132

If iHost system log is available, then smart-home add-on log is too.
Please post it in here as well.