SmartMi Fan 3 reports busy - fixable by NodeRED restart

[schaze]

Hi,

I have the same issue as reported at the end of issue #4 for the SmartMi Fan 3. More or less after 1 day (sometimes less) I received ¨busy" messages. Unfortunately rebooting the fan is not that easy as it has a battery attached. I had to unscrew the base and disconnect the standing bar to get it to power cycle. Afterwards I noticed that the fan responded very sluggishly, even when using the remote or the android app. This looked like it was flooded with messages. After a minute or so the fan reported busy again. So I actually restarted NodeRED. Afterwards the fan instantly responded again via all channels (remote, android app and via nodered). My flows are very basic (just an input from mqtt to miio-localdevices send node) and I am pretty sure there is no MQTT spamming going on, also I connected all nodes to debug nodes and could not see any unusual logs.

My suspicion is that miio-localdevices is getting a loop somewhere and starts flooding the fan which overloads it. I have now disabled polling for now, since this seems to be the only looping part in your code I can see.

Can I enable any debugging for the nodes to maybe check when it happens again?

Best regards, schaze

P.S. I created this new issue after I noticed I commented on a closed issue.

[stason325]

Hi, I answered there but I think it is good to repeat it here.

You need to modify your flow a bit to solve your problem because it is most likely not about miio-localdevices nodes. I think the nature of the problem is here:

My flows are very basic (just an input from mqtt to miio-localdevices send node) and I am pretty sure there is no MQTT spamming going on

Mqtt node sends its state on a periodic basis... every 15 or 30 seconds => every 15-30 seconds your flow execute command to the fan => you overpush your fan with requests => fan do not have enough time to execute them => and send back "busy" state.

What I propose: to prevent looping your flow, as I wrote in readme, use filter (rbe) node between Mqtt and miio-localdevices send node. Rbe-node will limit duplicate messages from mqtt and let go through only those with updated status.

As for my nodes there are no looping inside and auto-polling works pretty stable with interval from 5 secs.

Try rbe-nodes and write whether it helped. In my flows I always use them.

Regards

[schaze]

Hi Stanislav,

thanks for the fast reply! Periodic sending usually only happens for persisted messages via websockets for mqtt nodes. This is not the case here (also I am not using the nodered mqtt nodes but another implementation following a certain mqtt convention). I can say with 100% certainty that these nodes do not send periodic messages, I use them in other scenarios as well.

Also the debug node does not log any messages over time.

I agree your polling is just a self-recalling setTimeout loop - I dont see that ¨breaking" somehow... also the debug node attached to the Get Data node would create a lot of debug messages if it were going haywire....

What I do see however is that the GetData node is receiving updates every 30 or so seconds even though I disabled polling.

Could there maybe be an issue with the node-mihome library?

Best regards, schaze

[stason325]

Hello, Schaze

What I do see however is that the GetData node is receiving updates every 30 or so seconds even though I disabled polling.

Concerning that: starting from 0.5.0 I restructured a bit the logic of pushing requests to the device, now they are all executed async through config node. That gave me 2 useful things: first there should be no "call to device timeout" errors (tests on different devices show that it really works), second - I implemented quick auto-response from the device after each command has been executed (see number 4 here: https://github.com/stason325/node-red-contrib-miio-localdevices#get-node). So your debug updates are about this matter I suppose.

Could there maybe be an issue with the node-mihome library?

Frankly speaking i don't think it could somehow help, because node-mihome library is a simple tool that decodes mi binary protocol by creating ws, then sending handshake package to the device, then sending data package to the device with data that is configured in miio-localdevices nodes, then sending the response from the device.

I still think that issue here is either about NR flow (rbe-nodes could be the cure here) or about specific features of firmware of the device (maybe it is worth giving a slightly longer time lag between sending commands to the device so that the device can clear its cash from previous command).

Anyway, let's start with adding rbe-nodes before send command nodes and watch a bit whether it helps.

Regards, Stas

[stason325]

Here are some more ideas about your case.

Try to understand under what circumstances you get first "busy" warns. Maybe you're trying to execute conflicting commands: for example you are trying to adjust swing angle when swing-mode is off or something like that.

I think more precise observation could be useful here.

[schaze]

Hi Stas,

thanks for the explanations. I checked the code of node-miihome and I have to agree with all your statements it is all mostly straight forward protocol translation.

Besides the flows I showed in my screenshots there is really not much going on in terms of automation at the moment. It is mostly for control through alexa and manual control via a web UI. So the possiblity of some automation going into a loop is basically 0 as nothing is automated currently.

Now to analysis mode :) I had polling disabled for 3 days now, no problems since then any more. I will now enable polling again and see what happens.

Best regards, schaze

[stason325]

Hi there. 3 days without incidents - is a pretty good track record in terms of some chinese devices :) Let's continue observing and find out where it goes with polling turned on now.

Regards, Stas

[schaze]

Hi Stas,

so I just came home from work and the fan was not responding any more - also nodered restart did not help. All commands actually received a timeout message - not even a busy signal. I had to power cycle the thing. Now it works again. I will now disable polling again and give it a week. If it does not freezes up again I am fairly certain the polling is causing this. Maybe the fan has some memory leaking firmware that simply gives up after a certain amount of commands ... it is however a bit frustrating, I hope the thing will become more stable...

Regards, schaze

[stason325]

Hi Stas,

so I just came home from work and the fan was not responding any more - also nodered restart did not help. All commands actually received a timeout message - not even a busy signal.

I had to power cycle the thing. Now it works again. I will now disable polling again and give it a week. If it does not freezes up again I am fairly certain the polling is causing this. Maybe the fan has some memory leaking firmware that simply gives up after a certain amount of commands ... it is however a bit frustrating, I hope the thing will become more stable...

Regards,

schaze

Hello. According to your words it really looks like the device is going out of memory after certain number of commands and it does not have enough time to clear its memory. In your case it is mostly triggered by auto polling.

Maybe increasing polling interval could be useful here...Up to say 2-3-4 minutes. I would try it as well.

Regards, Stas

[stason325]

Hi, Schaze,

How is it going with your fan? Is your fan's case still staying as an issue for my nodes or you have already solved your problem with not responding fan?

Regards, Stas

[schaze]

Hi Stas,

since disabling polling again I had no issues any more for nearly 2 weeks. I think it is save to say the problems is somewhere on the fans side. Since I do not really need polling (as after every command a status update follows more or less) I am fine with keeping it off, or maybe setting it to 12 or 6hrs intervals. It would be interesting to check if there is any remote command that reboots the fans so I could powercycle it every night to keep it working fine - however I could not find any api spec that would enable this.

As far as this issue goes it should be closed - no issue with your nodes at all - they work very stable and reliably.

Best regards, Thomas

[schaze]

And thanks again for beeing very responsive and proactive btw :)

[stason325]

And thanks again for beeing very responsive and proactive btw :)

You're welcome. I glad if some support from me was helpful for you 😊

Regards, Stas