search

WolfwithSword / Bambu-HomeAssistant-Flows

A collection of HomeAssistant Dashboards and NodeRed Flows with a configurator to connect a BambuLabs printer to HomeAssistant through MQTT - based off of my Gists
32 stars 3 forks source link

BambuLab Cloud MQTT Restrictions #10

Closed mkosmo closed 6 days ago

mkosmo commented 6 days ago

Filing an issue for awareness: Not sure if you saw this forum post, but I reckon the cloud MQTT connectivity may have had something to do with it.

Use of NodeRed/HA for Bambu cloud MQTT integration may result in service outages for users until they roll out their changes.

WolfwithSword commented 6 days ago

Thanks for the headsup, just gave my response to it all in both twitter and the forum post.

I don't think it's caused by my cloud connection logic specifically, but rather another group who probably took inspiration from it. Reason being, I cannot simulate it making multiple concurrent connections frequently at all to a local broker even when introducing multiple restarts and such.

At most, it will disconnect and reconnect cleanly once every 10 minutes if on cloud connection, because Bambu's cloud mqtt goes stale and keeps a connection alive with no data after 10-15 minutes. So my theory is another group of users connects every minute uncleanly, keeping old connections alive somehow, as a way to get "around" that issue in a destructive way.

Thankfully, the amount of users who use my cloud connection are very very minimal compared to those who use it with a lan connection (default).

In fact, since around December of last year when I added optional cookie tracking for counting number of downloads, the cloud login flow was only downloaded 54 times, of which at least 10 were probably me testing the download. Granted this only would count users who consented to it, but still.

Will keep this issue open until some more development from Bambu or if I find something in my flows.

WolfwithSword commented 6 days ago

Although I'm still suspect of it happening with my flow, I did identify a specific condition with the cloud flow that could, if the cloud was unstable during a reconnect attempt, it could accumulate reconnect loops in parallel, and this may grow over time.

This explains the reconnect and new client Id's they mentioned, but does not explain how the clients stayed connected, as they would have been disconnected by NodeRed.

Either way, I am pushing a 2.1.6 emergency update for the basic flow for this. It also includes hard-setting a client ID to make future stuff easier to identify.