I run HA in a docker container and this took a while to get up and running. For anyone in that situation:
include_dir /mosquitto at the end of mosquito.confaddress myflameboss.com:1883
/mosquitto (can’t be in the same directory as mosquitto.conf)/mosquitto and /mosquitto/config in your docker-composeVery detailed. Great Post! I accomplished the same by using NodeRed.
Have you ever seen the Flameboss MQTT host change? My config originally used s7, it shows s8 now but still works using the s7 endpoint. Kinda weird…
Yeah this is why the “solution” I made really needs to be made into an integration. That is one of my goals to accomplish this year. That way the integration can query the end-point every so often and update accordingly when Flameboss changes your device’s connection point.
Since the beginning of June my integration stopped and I have the following message:
The mqtt platform for the sensor integration does not support platform setup.
Please remove it from your configuration and restart Home Assistant to fix this issue.
Any thoughts?
Need to change your configuration.yaml file to be similar to this:
mqtt:
sensor:
- state_topic: "homeassistant/sensor/flameboss/#####/send/open"
name: "Pit Temp"
unit_of_measurement: "°F"
device_class: "temperature"
force_update: true
value_template: "{{(float(value_json.temps[0]) * (9/50) +32) | round(0)}}"
- state_topic: "homeassistant/sensor/flameboss/#####/send/open"
name: "Probe Temp"
unit_of_measurement: "°F"
device_class: "temperature"
force_update: true
value_template: "{{(float(value_json.temps[1]) * (9/50) +32) | round(0)}}"
- state_topic: "homeassistant/sensor/flameboss/######/send/open"
name: "Pit Desired Temp"
unit_of_measurement: "°F"
device_class: "temperature"
force_update: true
value_template: "{{(float(value_json.set_temp) * (9/50) +32) | round(0)}}"
icon: mdi:thermometer
- state_topic: "homeassistant/sensor/flameboss/######/send/open"
name: "Fan Speed"
unit_of_measurement: "%"
force_update: true
value_template: "{{(float(value_json.blower)/100) | round(0)}}"
I’m pretty sure they are IP banning folks that are using this integration. I can’t get in from my phone app from home network unless I use my mobile data IP address. Maybe someone got tired of all the MQTT requests? I’ll give them a call I guess. Anyone with similar experience?
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.)
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”.
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.
