Not sure how you can come up with that narrative. I have zero issues and run (3) flameboss’s on my HA. No issues. Are you sure you know how to setup your flame boss for cloud connectivity and not just local connectivity?
Yep it’s worked in the past with cloud. Let me call em and see what they say … will post what happens.
I’m seeing the same behavior here. Works on mobile data or via VPN using other devices, but not on the cable modem IP that HA uses. Can ping myflameboss.com, but don’t get a response on HTTPS or MQTT. Any word on them throttling/banning IPs?
I haven’t called them yet. It may be that @PrayerfulDrop’s MQTT instance is pinging them less frequently than ours is and so he hasn’t been banned yet. Or my theory could be totally wrong…
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.
3 Likes
@rc-flameboss Hey man! This is great to hear! I appreciate how forthcoming and supportive you are of us tinkerers!
@PrayerfulDrop Are you familiar with using this local and not via the cloud? I show that my device has a broker, and I can use MQTT explorer and mosquitto_sub to get data, but I am a newbie at MQTT in general and don’t understand how to get the flameboss.conf file configured correctly to connect to the flameboss. I am so close to just having this connect locally…
Yes you can access the flame boss locally. The only downfall of that is you lose access to the Flameboss app as the flameboss only connects locally or cloud. Hence why I chose cloud connectivity to be able to use automations with HA but still manage the Flameboss with the app from anywhere.
1 Like
Thank you. I just figured this out 
Here is a local flameboss.conf file for anyone interested. The username and password settings below are arbitrary (for me at least) but required. I have my BGE/Flameboss controller’s local settings set to open.
address localIPHere:1883
topic flameboss/controllerIdHere/send/open in 1 homeassistant/sensor/
topic flameboss/controllerIdHere/send/data in 1 homeassistant/sensor/
bridge_attempt_unsubscribe false
bridge_protocol_version mqttv31
cleansession true
keepalive_interval 60
try_private false
username homeassistant
password homeassistant
Firstly, love to see your participation here. This is a great example for all the other IoT vendors out there :-).
On a less good note, I’ve experienced the IP blocking over the past year or so, and am still having issues today. I have two WAN connections, and can reliably fix the issue by rerouting the traffic out the unblocked IP, but that’s a serious pain and degrades spouse approval factor of the FB greatly. In my case, I’m not getting MQTT alone blocked, but also regular browser HTTPS and app connectivity to myflameboss.com. I understand the need for defensive measures against DoS, but it’s not at all obvious how I’m triggering that. Can you give some definitive guidance for us to keep things working and avoid abusing your infrastructure?
Good questions. At this moment I am blocked too! Weird, because @rc-flameboss said “I’ve disabled that security feature so that should not be a problem going forward.”.
I have also found myself blocked today. Not just MQTT, but all traffic. Switching to a different WAN connection fixed it.
I’m sure we’re generating some traffic that is triggering the defensive measure, but have no idea what that is or how to fix it. Would love to hear from @rc-flameboss about how to avoid this.