Confirmed. I changed my public IP, and now we’re working again. Something in between is definitely blocking TCP connections from specific IPs, but allowing ICMP pings.
Nice to hear my theory about IP banning is correct! But why I wonder … mqtt query rate filter? why not all users of this integration? I just opened a tech support ticket, hopefully it gets escalted to engineering team right away
I also just opened a support ticket. My guess is that there’s a rate cap that triggers an IP ban. Perhaps some rapid-fire HA/MQTT restarts edged us over that threshold. Looking at my logs, it seems like this happened at some point between July 2 and August 18. We’ll see what FB support comes back with. Until then, if you can get a different WAN IP, that should clear it up. (I set a different WAN MAC manually, and power cycled my cable modem.)
1 Like
I still have zero issues with connectivity now with two Flameboss devices running too.
Ok I’ve been unbanned. They apologized, confirmed they welcome integrations like this and said “not sure why we banned you”.
1 Like
I’m getting similar disconnections. Sometimes I can catch the data if it is published while I’m connected.
s7 no longer works at all - unknown host
s4 allows me to connect.
Taking a slightly different track here, does anyone know how to get at the raw JSON feed that is served via the webserver on the fans? I’m nearly certain I’ve gotten to it before, but I can’t recall what series of ‘/foo/bar/blah’ I had to tack onto the landing page the unit serves when on the network and running.
I did a netstat against mine and it is only serving on port 80. I suppose I could get postman out and see what’s what but I’m already out of my wheelhouse and wanted to see if anyone else knew offhand.
If nothing else, it would serve as a potential way to avoid having to worry about getting throttled and keep everything local without reliance on a cloud service.
Is this for a local connection?
Regarding the bridging issues…
Because I’ve been having similar disconnection issues, I wrote an MQTT client of my own and connected it directly to the flameboss servers (i.e. No Home Assistant involved here) and I discovered that the connection is very stable. Even while the HomeAssistant MQTT bridge continues to connect and disconnect every few seconds.
So, that got me thinking…it must be something with the bridge behavior…and because my stand-alone client is not be disconnected…the issue is likely on my side.
Also, thinking a little more, I’m wondering how does HomeAssistant know when to connect and disconnect from the Flameboss servers. It likely doesn’t. Is it trying to maintain a persistent bridge that is connected all the time? Well that doesn’t make sense. It really only needs to be connected when there is an active cook in progress. So, how would HA know that?
Continuing from posts above by @spelton , it is possible that I too had been banned…but…
On a hunch, I tried setting my client id in my flameboss.conf file. (not previously set).
remote_client_id myRandomlyChosenId
and then I restarted MQTT.
Now the connection in HA is stable and I’m getting real time updates of my currently active cook with no connect/disconnect cycling. That leads me to believe that the ‘banning’ was by remote client id.
Honestly, if HA was trying to maintain a persistent bridge 24/7 (even when there is no active cook), I don’t blame Flameboss support for putting my old (default) remote client id on a banned list.
So that leaves my previous question/mystery unsolved. How to only have MQTT bridged to the Flameboss servers when there is an active cook in progress.
This link may be useful for someone: flameboss api
I am the inventor, founder, programmer, and designer of Flame Boss. We were not intentionally blocking these integrations but the broker bridging feature of HA apparently publishes to a topic that is not authorized on our broker, and that did cause IP bans. I’ve disabled that security feature so that should not be a problem going forward.
However, you might have another problem. Unless you implemented an http API request to determine which server your device is connected to, you have a 1/N chance of connecting to the correct server where N is the number of servers in the cloud. We used to operate a MQTT cluster that solved this problem, but that was not reliable enough. Also, any month except November you probably won’t have a problem because we don’t need more than one server. (In November we scale up for Thanksgiving.)
I hope that explains what you are observing.
I am thrilled to see DIYs using the open standard features of our product to do cool things with it; that’s why we made them that way. Let me know if there is anything I can do to help.
1 Like