For the record, now that I know the issue, I can work around it. And I was DEFINITELY not asking you to donate your time to fix MY specific problem.
It might be worth looking at my rule a little. I am only calling get temp (which returns the alarm values as well) 99% of the time. Every 15 minutes, I do a full refresh (3 queries) and delay the next regular temp check for a minute.
Something similar in the main app could be to have separate polling rates for each of the queries and enable/disable each query from the main refresh command as options?
For the main app, I wouldn't go shorter than 30 seconds. Although for monitoring a grill, you definitely want <1 minute. Temps can jump 20 degrees or more in a minute. That is a gripe I have with Fireboard though. That rate limit is totally unreasonable - it pushes to their phone app and web page MUCH more frequently than that. I wonder if they would let us set up something to push from the device (like Ecowitt has)
While I am here, what are the return values for the sensor alarms?
Boolean True/False? (I see "none" in the logs) They might useful in reducing the other rules I have for my cooks
I made the alarm(s) strings because they are meant to tell the user what the potential issue is. So, on individual child devices you get:
Alarm = "Temperature is below minimum." and/or "Temperature is above maximum." It is capable of stating below and above, and will put an " & " between the two, although I would only expect this if someone does something REALLY weird with their min/max alert values, but since those are outside my control I had to account for it.
On the parent device you get:
Alarms = "CH${ Channel } temperature is below minimum." and/or "CH${ Channel } temperature is above maximum." It can build up for any of the channels because you could have many alarms showing.
I also found a typo in the alarm message when typing this up plus I put in a preference to disable drive logging (since most people will not have a drive, it is disabled by default) which will cut out one of the queries in a normal refresh. Update will be posted right after this.
Fixed typo in Alarm and Alarms messages stating "minumum" when it should have been "minimum". Oops.
Added a Preference to the parent device that disables Drive logging by default (for new installs) from the refresh (as set by Refresh Rate or manual polling). This removes one of the queries (of the 3) performed each refresh. If you have a Drive unit, you can easily enable the Preference. It will continue to run if the Preference is null (if you do not Save Preferences since it has been added).
Weird. 405 means that it is the wrong type of request to the server (like it was trying to do a GET when it should have been a PUT or such). Per the Fireboard API (just checked to see if they had changed it), only the Authorization Token request is a POST and everything else is a GET... which is exactly what the driver is doing.
So, maybe they are having some issues on their side at the moment? I guess we should wait and see if they resolve it or if it keeps happening.
Something must have been going on with their server. It came back, and had lost the names for my probes (renamed them back to the generic channel 1 and channel 2 - on the Fireboard Android app as well) This happened in the middle of a cook.
Yep, sorry for the false alarm. Apparently, I just happened to catch a cloud glitch real time. Yet another reason why local is better. Really weird that it lost my saved names for the probes (but did not for the temperature unit itself)
Whe I replaced the unit about a year ago. It was reporting the correct names at the beginning of the cook and has been since I changed them initially. They reverted to the default channel 1/2 in the middle of the cook. They changed in the cloud account - not just on HE. I changed them back in the Fireboard (THEIR) app. The next time it reported in HE, it was corrected.
