Closed fkroepfl closed 6 months ago
As already mentioned, I am trying to operate two tilt devices, RED and BLUE, via TiltBridge.
Tilt BLUE has not been sending data to Grainfather via logging URL for nine hours, or irregularly, i.e. not at the specified interval, via MQTT to Home Assistant.
However, and this makes me wonder, Tilt BLUE sends data via Bluetooth at very short intervals, which can be received locally via other devices, eg Home Assistant via BT Interface.
In the meantime, I'm pretty stumped, although it now looks like TiltBridge is having problems proxying the data.
Or am I seeing this wrong?
Is the logging URL you are using HTTP or HTTPS?
Edit: Nevermind, shouldn't matter... hmm.
Unfortunately, Grainfather support is something that someone contributed to TiltBridge, and I don't have any personal experience with it or with the Grainfather platform. Reading through the code I don't see anything obvious that looks like it should be a problem, other than potentially interactions with other send targets. I have a few questions for you in order to help me try to diagnose what is going on:
- What other send targets are you using, if any? You mention MQTT - what is the send delay for that -- and are you using TiltBridge for MQTT?
I’m using just Grainfather and MQTT-Home Assistant (and the MQTT server on HA) as target, at least I modified just these entries. Push Frequency (s) is 300s.
In case of Grainfather, I created for safety reasons new logging URLs, but the behaviour is finally the same as with the former URLs.
Note:
- You mention something about TiltPi -- Are you currently running both TiltPi and TiltBridge?
I have both, but there is always just one powered up. I’m using TiltPi just to compare the results on Grainfather.
- Are you using a single TiltBridge for both the Blue and Red tilt, or multiple?
I’m using one TiltBridge and both Tilts (BLUE & RED) are recognised by this TiltBridge. As target, as mentioned above, I activated Grainfather & MQTT (Home Assistant).
- When you look at the "about" page for TiltBridge, what is the uptime that you see? Is the TiltBridge crashing?
at least I've never seen a crash, but for sure, I did some restarts after changing the settings.
Uptime: Days: 0, Hours: 19, Minutes: 10, Seconds: 12 Reset Reason: Reason: ESP_RST_SW, Description: Software reset via esp_restart Heap Information: Free Heap: 74296, Max: 45044, Frags: 40
FYI: This restart was definitely not triggered by me.
Uptime: Days: 0, Hours: 3, Minutes: 4, Seconds: 55 Reset Reason: Reason: ESP_RST_SW, Description: Software reset via esp_restart Heap Information: Free Heap: 72140, Max: 36852, Frags: 49
Yeah -- that one (with the reason "Software reset via esp_restart") is a timed reset that was added awhile back when there were issues with one of the libraries which could cause the device to progressively slow down. I've since removed that library, but admittedly forgot that reset was in there. Still though - it doesn't hurt to have it. ;)
Unfortunately, at the moment I'm at a loss. At the moment, the connections don't have any kind of logging attached to them to show the status. This is something that would be a good idea, though, so I'll try to get it added with the upcoming TiltBridge refresh. I'm tracking that feature request here.
We're travelling for the next few days, so I'm not sure if I'll be able to get something built to try to debug what is happening here, but in the mean time my recommendation would be to potentially temporarily disable the MQTT send on TiltBridge and see if that helps. It's possible that there is something weird going on with that target which is causing Grainfather not to work.
Unfortunately, at the moment I'm at a loss
I feel the same way 😉 .
I'm still trying to find out more by replacing components. I now have a new ESP32 board, without OLED display but with the same firmware, in use and only started with Tilt-BLUE. Interestingly, it has worked with Grainfather so far. After about 4 hours I also activated Tilt-RED. This has also worked in principle so far. Only one data point was lost - for whatever reason.
However, it is noticeable that the data series via MQTT are now very poor. A lot of values are missing.
What is not clear to me is whether it is the ESP32 module or the combination of data targets that influences or triggers the behavior.
@thorrak The attached result may give a hidden hint, because
Huh. Out of curiousity, if you set the Red tilt to sleep mode (rest it vertically) does the Blue tilt update properly?
I'm wondering if something may be going on with the rate limiting on Grainfather's side. If that fixes it, I can reach out to them to find out.
Huh. Out of curiousity, if you set the Red tilt to sleep mode (rest it vertically) does the Blue tilt update properly?
No, but if you start with blue alone after a reset, the values via TiltPi and TiltBridge are identical.
If red then also transmits, the data is swapped.
@thorrak A few more comments.
If the Tilt Red is active first, or the Red and Blue are operating at the same time, or the Tilt Blue is not transmitting alone and before the Tilt Red, the data sent via TiltBridge will not be interpreted correctly.
Either they are not updated or, as already documented, they are mixed up when Blue is activated first.
Hmm. I'm at a bit of a loss as to what could be happening here. The code looks correct, but clearly the outcome you're seeing is wrong which indicates that something obviously isn't working.
After reading through everything, even ignoring this issue I think there is an opportunity to clean things up. I went ahead and rebuilt this morning, and am going to spend this afternoon testing them to make sure they work (and don't leak memory all over the place). I'll try to get a "test" firmware built for you to try out later tonight assuming all goes well.
With that in mind, which firmware type do you use? OLED, TFT, or eSPI?
🤗
With that in mind, which firmware type do you use? OLED, TFT, or eSPI?
It's OLED Firmware on two different ESP Boards, one with display, one without.
Alrighty! The new beta firmware should now be available on BrewFlasher with the rewritten data sender: https://web.brewflasher.com/fw/25
The version is TiltBridge Beta - v1.2.2-beta1 - OLED
I've tested this with a single Tilt with Grainfather and can see that it updates, but unfortunately don't have more colors here at the moment to test with.
As always, please let me know if you have any issues/questions (or alternatively, if this solves the issue). Once you confirm that things are good (fingers crossed!) then I will merge the code into master and issue an official release.
@thorrak I have now installed the FW and will share my observations after a while.
It should be mentioned briefly that with the current FW version you have to wait a disproportionately long time for a response when calling up the settings page.
Unfortunately, I can't replicate the slow response time on my end. When I go to the settings page it fully loads within 2-3 seconds. It might be worth restarting the device at some point and seeing if this helps.
Unfortunately, I can't replicate the slow response time on my end. When I go to the settings page it fully loads within 2-3 seconds. It might be worth restarting the device at some point and seeing if this helps.
It was noticeable after the first boot after flashing. After a power reset, this behavior was no longer present.
It looks good for the first monitoring use. The values that come from the same tilt and are only forwarded via different paths are now identical.
Only Grainfather is now set up with 2 uncalibrated tilts.
The next step is to setup MQTT as target and finally the calibration.
If I notice anything else during operation, I'll let you know.
Many thanks for the bugfix. 🤗
Explanation of the labels:
@thorrak Since there have been no significant problems with reception on Grainfather with the last FW version, I will create a separate post for the MQTT problems.
Glad to hear that this solves the Grainfather sending issues. I'll tag this issue to close when that is merged.
Only Grainfather is now set up with 2 uncalibrated tilts.
What do you mean by this comment? Do you mean that you do not currently have the tilts calibrated within TiltBridge, or that the calibrated data isn't being used (only the raw data is being sent to Grainfather)?
FYI: The data series in direct comparison
What do you mean by this comment? Do you mean that you do not currently have the tilts calibrated within TiltBridge, or that the calibrated data isn't being used (only the raw data is being sent to Grainfather)?
I meant to say that I don't use the calibration feature in either TiltBridge or TiltPi so that I have the raw data consistently across both ways for comparison.
Correction of the posting, as data points are now visible on the Grainfather platform, albeit with gaps.
I have deleted the existing equipment on the Grainfather platform and set it up again. Now the system is behaving closer to what is expected.
Whether this was or is part of the reason, I cannot determine.
Basically, data points are displayed every 15 minutes, which corresponds to the transmission via TiltPi and can probably be seen as normal.
What remains now are data point failures over a period of one to two hours.
Question: Is there a way to check whether TiltBridge was able to transfer the data successfully?