Replacement firmware for iSpindel (GravityMon)

[mper]

If of any interest:
I use a tp-link EAP110-Outdoor AP.
High-power amplifier and good antennas.
The ESP32-s2 mini has never had problems connecting through the SS fermenter inside a fridge. Typically -60dBm.
The AP stands around half a meter from the fridge.
And the s2's battery seems to stay on 4.09V forever - well, at least 3-4 weeks

Really good, can you check what the average runtime is? Just curious how fast it is on connecting..

 

[larsh]

Really good, can you check what the average runtime is? Just curious how fast it is on connecting..

Average runtime: 3s
Interval: 900s
Estimated runtime: 8weeks 2days

 

[mper]

Average runtime: 3s
Interval: 900s
Estimated runtime: 8weeks 2days

Thats really good, probably as fast as it can go

 

[larsh]

Thats really good, probably as fast as it can go

Oh, forgot to mention, if Service Integrations affects Average Runtime: My SI's are only local.
* MQTT to Home Assistant
* BrewPi Remix

 

[DuncB]

10 months WiFi sending every half an hour seems pretty good for one of my ispindels in a dessert wine in secondary.

 

[neomod]

Hello,

I hope I’m in the right section to ask some questions about the “GravityMon” firmware.

I’m currently experimenting with it on an ESP32 C3 Mini version 2.1.0 assembled on a standard iSpindle PCB (“The Jeffrey”) only for testing, as I understand this board requires some further tweaks to work correctly (decoupling capacitor, an additional resistor for the voltage divider, etc) and I’m planning to build a custom PCB.

Anyway, I flashed the C3 Mini straight from VSCode (since the BrewFlasher app, both WEB and DESKTOP) only caused issues with this board, mostly failed attempts with board stuck on reset loop. Upon realizing that this led me to use the bleeding edge alpha version of GravityMon, I tried downgrading to the latest stable (v. 1.3.0) using the “firmware update” functionality.

The firmware load is successful, and the device boots up, but I am seeing some inconsistencies and I’m not sure if it’s my fault for not understanding the documentation (which is amazingly written, so I’m pretty sure I’m the n00b in that case) or if I have an issue with the components.

After completing the initial configuration (wifi connection details, gyro calibration, formula input) I’m facing the “status” page where everything seems to be working fine: angle, temperature and battery values are being reported and the gravity value is being calculated.

Although it seems the device never enters “monitoring” mode: I left it untouched for a while (>4h) and I noticed it never disconnected from the WiFi and the configuration page was still accessible.

I checked the logs (from the web interface) and I noticed this:

CALC: Validation failed on angle 32.62, deviation too large 3.6075 SG, formula order 2 CALC: Validation failed on angle 24.41, deviation too large 3.7407 SG, formula order 2 CALC: Validation failed on angle 32.62, deviation too large 3.6075 SG, formula order 2 CALC: Validation failed on angle 24.41, deviation too large 3.7407 SG, formula order 2 CALC: Validation failed on angle 32.62, deviation too large 3.6075 SG, formula order 2 CALC: Validation failed on angle 24.41, deviation too large 3.7407 SG, formula order 2 CALC: Validation failed on angle 32.62, deviation too large 3.6075 SG, formula order 2 CALC: Validation failed on angle 24.41, deviation too large 3.7407 SG, formula order 2 CALC: Validation failed on angle 32.62, deviation too large 3.6013 SG, formula order 2 CALC: Validation failed on angle 24.41, deviation too large 3.7342 SG, formula order 2 CALC: Validation failed on angle 32.62, deviation too large 3.5772 SG, formula order 2 CALC: Validation failed on angle 24.41, deviation too large 3.6786 SG, formula order 2 CALC: Validation failed on angle 32.62, deviation too large 3.4838 SG, formula order 2 CALC: Validation failed on angle 24.41, deviation too large 3.5811 SG, formula order 2 CALC: Validation failed on angle 32.62, deviation too large 3.1134 SG, formula order 2 CALC: Validation failed on angle 24.41, deviation too large 3.3608 SG, formula order 2 CALC: Validation failed on angle 32.62, deviation too large 3.1103 SG, formula order 2 CALC: Validation failed on angle 24.41, deviation too large 3.3541 SG, formula order 2 GYRO: No valid calibration values, please calibrate the device. CFG : Configuration file does not exist


The “CFG: Configuration file does not exist” error seems a bit strange: I did everything as described, and the values shown on the main page suggest that the device is working correctly. I went and repeated the whole configuration (even after a factory reset) thinking that maybe I made some mistakes during initial data input, but the error persisted.

The “GYRO” error really throws me into a bit of confusion: calibration of the gyroscopic module completes successfully, and the device reports that a proper configuration has been saved. (and I’m sure the module works: I’ve tested it separately on a D1 MINI with the dedicated sketch from the library).

So, I went on and inspected the serial output while doing another calibration:

252 I: SDBG: Serial logging started at 115200. 260 I: Main: Started setup for 1f3198. 260 I: Build options: 1.3.0 (..b68835) LOGLEVEL 4 261 I: HELP: Chip=ESP32C3, Rev=4, Feat=0x0012 263 I: CFG : Filesystem mounted. 272 I: WIFI: Current reset counter 0. 284 I: HELP: Last reset cause 'unknown reset reason' (21) 299 I: CFG : Size of configuration file=1195 bytes. 318 I: CFG : Configuration file /gravitymon.json loaded. 335 I: CFG : Size of configuration file=304 bytes. 341 I: CFG : Configuration file /hardware.json loaded. 1236 I: Main: Battery 4.29 V, Gyro=89.05, Run-mode=1. 1273 I: WIFI: Connecting to wifi (0) using stored settings iNeo. .... 1779 I: WIFI: Connected to wifi iNeo ip=192.168.0.46. 1779 I: WIFI: Using mDNS name gravitymon1f3198. 1815 I: TSEN: Found 1 temperature sensor(s). Using 9 bit 1816 I: Main: Activating web server. [ 1816][E][WiFiGeneric.cpp:1438] hostByName(): DNS Failed for [ 1817][W][HTTPClient.cpp:1469] returnError(): error(-1): connection refused 1818 E: WIFI: OTA error checking version.json, response=-1 1816 I: Main: Activating web server. [ 1816][E][WiFiGeneric.cpp:1438] hostByName(): DNS Failed for [ 1817][W][HTTPClient.cpp:1469] returnError(): error(-1): connection refused 1818 E: WIFI: OTA error checking version.json, response=-1 1819 I: WEB : Configuring web server. 1840 I: WEB : File=error.log, 1691 bytes 1846 I: WEB : File=error2.log, 4038 bytes 1852 I: WEB : File=gravitymon.json, 1195 bytes 1858 I: WEB : File=hardware.json, 304 bytes 1863 I: WEB : File=reset.dat, 1 bytes 1863 I: WEB : Setting up handlers for web server. [ 1883][E][vfs_api.cpp:104] open(): /littlefs/runtime.log does not exist, no permits for creation 1885 I: WEB : Web server started. 1886 I: Main: Setup completed. 5143 I: WEB : webServer callback for /api/formula(get). 37833 I: WEB : webServer callback for /api/config(get). [ 37962][E][vfs_api.cpp:104] open(): /littlefs/runtime.log does not exist, no permits for creation 38989 I: WEB : webServer callback for /api/config/advanced(get). 47989 I: WEB : webServer callback for /api/calibrate. >......>......-1464.00000, 63.00000, 1416.00000, 162.00000, 75.00000, -8.00000


Indeed the gyro calibration is producing the expected results. But then I noticed this line: [vfs_api.cpp:104] open(): /littlefs/runtime.log does not exist, no permits for creation

Apparently, it’s just a log file that can’t be found and I’m not sure if this impacts the intended behaviour of the device; is this error to be considered “normal” and thus ignored?

Regarding the polynomial formula: I’m using the one I calculated for the same device (except while using a D1 Mini on board) using the standard “sugar wash” method, and I’m pretty confident in the results. I used the same formula while configuring the C3 Mini and yet it seems to be failing to calculate a 2nd (and further) degree formula from the data provided.

I also tried to populate the table for the Formula Creation inside the web interface, but the results were the same; reading documentation I tried to increase the “Formula Max Deviation” value in an attempt to force the issue (I know that results are inaccurate this way, I didn’t mean to use in production) but the error persisted.

While looking at the “Formula Calculation” table, another doubt entered my mind: am I reading those values correctly? The use of “comma” instead of “dot” throws me a bit off, so it’s probably just my “metric brain” being confused and this has nothing to do with it…but, for example, reading a value in “Specific Gravity” for pure water I would read it as “one thousand” (written 1000 or 1.000) and not like “one point zero zero” or “one comma zero zero” (written 1,000). So I was wondering…compiling the table with a value of “1,0700” corresponds to “1070” (one thousand and seventy) or not? If so it may explain why I’m having trouble getting a valid formula.

(although It won’t explain why the error persists even if I’m using the 3rd Degree polynomial calculated before with the iSpindle Calculator)

Attached there are also a few screenshots from the web interface, hoping they might prove useful in finding my mistakes.

Thank you for your time reading this, and If I posted in the wrong section please beg my pardon: if you’ll let me know I’ll immediately remove the post and move it to the appropriate section/discussion.

 

[mper]

Hello,

I hope I’m in the right section to ask some questions about the “GravityMon” firmware.

I’m currently experimenting with it on an ESP32 C3 Mini version 2.1.0 assembled on a standard iSpindle PCB (“The Jeffrey”) only for testing, as I understand this board requires some further tweaks to work correctly (decoupling capacitor, an additional resistor for the voltage divider, etc) and I’m planning to build a custom PCB.

Anyway, I flashed the C3 Mini straight from VSCode (since the BrewFlasher app, both WEB and DESKTOP) only caused issues with this board, mostly failed attempts with board stuck on reset loop. Upon realizing that this led me to use the bleeding edge alpha version of GravityMon, I tried downgrading to the latest stable (v. 1.3.0) using the “firmware update” functionality.

The firmware load is successful, and the device boots up, but I am seeing some inconsistencies and I’m not sure if it’s my fault for not understanding the documentation (which is amazingly written, so I’m pretty sure I’m the n00b in that case) or if I have an issue with the components.

After completing the initial configuration (wifi connection details, gyro calibration, formula input) I’m facing the “status” page where everything seems to be working fine: angle, temperature and battery values are being reported and the gravity value is being calculated.

Although it seems the device never enters “monitoring” mode: I left it untouched for a while (>4h) and I noticed it never disconnected from the WiFi and the configuration page was still accessible.

there are a few options that can cause this.
1. battery voltage over the 4.15v limit is seen as charging and the sleep is disabled. Check th voltage factor och change the limit under advanced settings.
2. sleep disabled on the status page

update: on the status page the voltage is 4.29 so it will go to sleep after it has dropped below 4,15

I checked the logs (from the web interface) and I noticed this:

CALC: Validation failed on angle 32.62, deviation too large 3.6075 SG, formula order 2 CALC: Validation failed on angle 24.41, deviation too large 3.7407 SG, formula order 2 CALC: Validation failed on angle 32.62, deviation too large 3.6075 SG, formula order 2 CALC: Validation failed on angle 24.41, deviation too large 3.7407 SG, formula order 2 CALC: Validation failed on angle 32.62, deviation too large 3.6075 SG, formula order 2 CALC: Validation failed on angle 24.41, deviation too large 3.7407 SG, formula order 2 CALC: Validation failed on angle 32.62, deviation too large 3.6075 SG, formula order 2 CALC: Validation failed on angle 24.41, deviation too large 3.7407 SG, formula order 2 CALC: Validation failed on angle 32.62, deviation too large 3.6013 SG, formula order 2 CALC: Validation failed on angle 24.41, deviation too large 3.7342 SG, formula order 2 CALC: Validation failed on angle 32.62, deviation too large 3.5772 SG, formula order 2 CALC: Validation failed on angle 24.41, deviation too large 3.6786 SG, formula order 2 CALC: Validation failed on angle 32.62, deviation too large 3.4838 SG, formula order 2 CALC: Validation failed on angle 24.41, deviation too large 3.5811 SG, formula order 2 CALC: Validation failed on angle 32.62, deviation too large 3.1134 SG, formula order 2 CALC: Validation failed on angle 24.41, deviation too large 3.3608 SG, formula order 2 CALC: Validation failed on angle 32.62, deviation too large 3.1103 SG, formula order 2 CALC: Validation failed on angle 24.41, deviation too large 3.3541 SG, formula order 2 GYRO: No valid calibration values, please calibrate the device. [/QUOTE] validation errors are normal when trying to create a formula. it tries a number of variants and discard those that is to far off from the input. If you get a formula back in the calibration screen you are good. [QUOTE="neomod, post: 10314852, member: 342729"] CFG : Configuration file does not exist

if you havent changed the advanced settings this is normal, that file is only created if there are changes to that section, that is stored in a separate file.

The “CFG: Configuration file does not exist” error seems a bit strange: I did everything as described, and the values shown on the main page suggest that the device is working correctly. I went and repeated the whole configuration (even after a factory reset) thinking that maybe I made some mistakes during initial data input, but the error persisted.

The “GYRO” error really throws me into a bit of confusion: calibration of the gyroscopic module completes successfully, and the device reports that a proper configuration has been saved. (and I’m sure the module works: I’ve tested it separately on a D1 MINI with the dedicated sketch from the library).

if the gyro calibration is successful you should see the values on the config section. If they are zero then the there is no calibration. This could be a bug or failure to write the config file.

So, I went on and inspected the serial output while doing another calibration:

252 I: SDBG: Serial logging started at 115200. 260 I: Main: Started setup for 1f3198. 260 I: Build options: 1.3.0 (..b68835) LOGLEVEL 4 261 I: HELP: Chip=ESP32C3, Rev=4, Feat=0x0012 263 I: CFG : Filesystem mounted. 272 I: WIFI: Current reset counter 0. 284 I: HELP: Last reset cause 'unknown reset reason' (21) 299 I: CFG : Size of configuration file=1195 bytes. 318 I: CFG : Configuration file /gravitymon.json loaded. 335 I: CFG : Size of configuration file=304 bytes. 341 I: CFG : Configuration file /hardware.json loaded. 1236 I: Main: Battery 4.29 V, Gyro=89.05, Run-mode=1. 1273 I: WIFI: Connecting to wifi (0) using stored settings iNeo. .... 1779 I: WIFI: Connected to wifi iNeo ip=192.168.0.46. 1779 I: WIFI: Using mDNS name gravitymon1f3198. 1815 I: TSEN: Found 1 temperature sensor(s). Using 9 bit 1816 I: Main: Activating web server. [ 1816][E][WiFiGeneric.cpp:1438] hostByName(): DNS Failed for [ 1817][W][HTTPClient.cpp:1469] returnError(): error(-1): connection refused 1818 E: WIFI: OTA error checking version.json, response=-1 1816 I: Main: Activating web server. [ 1816][E][WiFiGeneric.cpp:1438] hostByName(): DNS Failed for [ 1817][W][HTTPClient.cpp:1469] returnError(): error(-1): connection refused 1818 E: WIFI: OTA error checking version.json, response=-1 1819 I: WEB : Configuring web server. 1840 I: WEB : File=error.log, 1691 bytes 1846 I: WEB : File=error2.log, 4038 bytes 1852 I: WEB : File=gravitymon.json, 1195 bytes 1858 I: WEB : File=hardware.json, 304 bytes 1863 I: WEB : File=reset.dat, 1 bytes 1863 I: WEB : Setting up handlers for web server. [ 1883][E][vfs_api.cpp:104] open(): /littlefs/runtime.log does not exist, no permits for creation 1885 I: WEB : Web server started. 1886 I: Main: Setup completed. 5143 I: WEB : webServer callback for /api/formula(get). 37833 I: WEB : webServer callback for /api/config(get). [ 37962][E][vfs_api.cpp:104] open(): /littlefs/runtime.log does not exist, no permits for creation 38989 I: WEB : webServer callback for /api/config/advanced(get). 47989 I: WEB : webServer callback for /api/calibrate. >......>......-1464.00000, 63.00000, 1416.00000, 162.00000, 75.00000, -8.00000


Indeed the gyro calibration is producing the expected results. But then I noticed this line: [vfs_api.cpp:104] open(): /littlefs/runtime.log does not exist, no permits for creation

this is an error from esp idf and its annoying. This is shown when trying to open a file for read that does not exist. In your case since you have not had it in gravity mode.

Apparently, it’s just a log file that can’t be found and I’m not sure if this impacts the intended behaviour of the device; is this error to be considered “normal” and thus ignored?

Regarding the polynomial formula: I’m using the one I calculated for the same device (except while using a D1 Mini on board) using the standard “sugar wash” method, and I’m pretty confident in the results. I used the same formula while configuring the C3 Mini and yet it seems to be failing to calculate a 2nd (and further) degree formula from the data provided.

could you share the datapoints? the testcases i have produce the same results on all boards.

update: the formula looks good in the screenshot, no deviations

I also tried to populate the table for the Formula Creation inside the web interface, but the results were the same; reading documentation I tried to increase the “Formula Max Deviation” value in an attempt to force the issue (I know that results are inaccurate this way, I didn’t mean to use in production) but the error persisted.

While looking at the “Formula Calculation” table, another doubt entered my mind: am I reading those values correctly? The use of “comma” instead of “dot” throws me a bit off, so it’s probably just my “metric brain” being confused and this has nothing to do with it…but, for example, reading a value in “Specific Gravity” for pure water I would read it as “one thousand” (written 1000 or 1.000) and not like “one point zero zero” or “one comma zero zero” (written 1,000). So I was wondering…compiling the table with a value of “1,0700” corresponds to “1070” (one thousand and seventy) or not? If so it may explain why I’m having trouble getting a valid

the separator is different in us and europe but the meaning is the same. 1,070 and 1.070 is the same

(although It won’t explain why the error persists even if I’m using the 3rd Degree polynomial calculated before with the iSpindle Calculator)

Attached there are also a few screenshots from the web interface, hoping they might prove useful in finding my mistakes.

Thank you for your time reading this, and If I posted in the wrong section please beg my pardon: if you’ll let me know I’ll immediately remove the post and move it to the appropriate section/discussion.

 

[kdw2pd]

I'm trying to flash a pair of Lolin C3 Mini V2.1s with GravityMon 1.3. When I attempt to run it in BrewFlasher, the program output makes it look like it flashed successfully. However, when I open up the serial monitor, I get the following repeating rapidly:

Saved PC:0x403d0f62
SPIWP:0xee
mode: DIO, clock div:1 [added a space after the :, modeIO does look hilarious though]
load:0x3fcd6100,len:0x438
load:0x403ce000,len:0x90c
load:0x403d0000,len:0x2358
entry 0x403ce000
ESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021
rst:0x3 (RTC_SW_SYS_RST),boot:0xd (SPI_FAST_FLASH_BOOT)

Due to lack of familiarity with the interface, I didn't have any success flashing the 1.4 dev version via VSCode/PlatformIO. Any other suggestions for how to get the C3 Minis cooperating with GravityMon?

 

[mper]

I'm trying to flash a pair of Lolin C3 Mini V2.1s with GravityMon 1.3. When I attempt to run it in BrewFlasher, the program output makes it look like it flashed successfully. However, when I open up the serial monitor, I get the following repeating rapidly:

Saved PC:0x403d0f62
SPIWP:0xee
mode: DIO, clock div:1 [added a space after the :, modeIO does look hilarious though]
load:0x3fcd6100,len:0x438
load:0x403ce000,len:0x90c
load:0x403d0000,len:0x2358
entry 0x403ce000
ESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021
rst:0x3 (RTC_SW_SYS_RST),boot:0xd (SPI_FAST_FLASH_BOOT)

Due to lack of familiarity with the interface, I didn't have any success flashing the 1.4 dev version via VSCode/PlatformIO. Any other suggestions for how to get the C3 Minis cooperating with GravityMon?

Well this is most likley a flashing problem, which version of brewflasher did you use? Could you try the brewflasher version attached to the gravitymon release?

the usbc chips can be tricky to get into flash mode but if you hook up a serial monitor it will show waiting for upload when its ready to be flashed. I have noticed that it can be a little difficult to flash chips for the first time.

hold down both boot and en then release the en and a second later he boot button. That should force the chip into flash mode

 

[kdw2pd]

Well this is most likley a flashing problem, which version of brewflasher did you use? Could you try the brewflasher version attached to the gravitymon release?

Can you point me to which version of BrewFlasher I should be using? I was initially trying on 1.5.2, but using the newest version from the BrewFlasher GitHub (1.7), I was having the same results. I didn't see a GravityMon-related version of BrewFlasher on gravitymon.com or on the GitHub site, if it's there somewhere I missed it.

I'm pretty sure I got it into flash mode. I was doing what you suggested, it did the 1200bps touch, and ended with "firmware successfully flashed."

 

[mper]

Can you point me to which version of BrewFlasher I should be using? I was initially trying on 1.5.2, but using the newest version from the BrewFlasher GitHub (1.7), I was having the same results. I didn't see a GravityMon-related version of BrewFlasher on gravitymon.com or on the GitHub site, if it's there somewhere I missed it.

I'm pretty sure I got it into flash mode. I was doing what you suggested, it did the 1200bps touch, and ended with "firmware successfully flashed."

Its here, Release v1.2.0 esp32 release · mp-se/gravitymon. This one ive tested with.

Please try flashing the 1.2 version and see if there is any difference

 

[kdw2pd]

Please try flashing the 1.2 version and see if there is any difference

It was a no-go with 1.2, in both BrewFlasher 1.5.2 and 1.7, getting the same error message.

However, I tried the Tasmota ESP Flasher for ESP8266/ESP32 (Releases · Jason2866/ESP_Flasher) with your C3 1.4 frimware, and it flashed and booted the GravityMon AP right up for both boards I tried. So I'd suggest people give that a shot for flashing C3s if you hit the same roadblocks I did, and don't want to learn how to use PlatformIO or Arduino IDE.

 

[mper]

It was a no-go with 1.2, in both BrewFlasher 1.5.2 and 1.7, getting the same error message.

However, I tried the Tasmota ESP Flasher for ESP8266/ESP32 (Releases · Jason2866/ESP_Flasher) with your C3 1.4 frimware, and it flashed and booted the GravityMon AP right up for both boards I tried. So I'd suggest people give that a shot for flashing C3s if you hit the same roadblocks I did, and don't want to learn how to use PlatformIO or Arduino IDE.

Great, i will take a look on that when im back home and sort this out with thorrak so we can fix it.

 

[mper]

It was a no-go with 1.2, in both BrewFlasher 1.5.2 and 1.7, getting the same error message.

However, I tried the Tasmota ESP Flasher for ESP8266/ESP32 (Releases · Jason2866/ESP_Flasher) with your C3 1.4 frimware, and it flashed and booted the GravityMon AP right up for both boards I tried. So I'd suggest people give that a shot for flashing C3s if you hit the same roadblocks I did, and don't want to learn how to use PlatformIO or Arduino IDE.

I can confirm that there is an issue with the bootloader for the C3 board in brewflasher. I have asked Thorrak to replace the faulty file so flashing will work.

 

[mper]

It was a no-go with 1.2, in both BrewFlasher 1.5.2 and 1.7, getting the same error message.

However, I tried the Tasmota ESP Flasher for ESP8266/ESP32 (Releases · Jason2866/ESP_Flasher) with your C3 1.4 frimware, and it flashed and booted the GravityMon AP right up for both boards I tried. So I'd suggest people give that a shot for flashing C3s if you hit the same roadblocks I did, and don't want to learn how to use PlatformIO or Arduino IDE.

Brewflasher is now working with the C3 board. It was the bootloader that was faulty and is now updated. Big thanks to @Thorrak for fixing this quickly. I have tested flashing the v1.3 version.

 

[kdw2pd]

Brewflasher is now working with the C3 board. It was the bootloader that was faulty and is now updated. Big thanks to @Thorrak for fixing this quickly. I have tested flashing the v1.3 version.

Great, a huge thank you to you and @Thorrak for all your hard work! Is there a spot I can snag the updated version at?

 

[Thorrak]

Great, a huge thank you to you and @Thorrak for all your hard work! Is there a spot I can snag the updated version at?

The existing version of BrewFlasher should work, assuming you close & relaunch it. Otherwise, you can always get the latest version of BrewFlasher here.

 

[kdw2pd]

The existing version of BrewFlasher should work, assuming you close & relaunch it. Otherwise, you can always get the latest version of BrewFlasher here.

Ah, thanks! I'd interpreted what @mper said as reflecting something that needed to be updated in the BrewFlasher software, not the GravityMon firmware. My bad.

 

[kdw2pd]

Deleted, solved the issue. It was a hardware problem. Carry on folks, I'll stop clogging up this thread.

 

[Thorrak]

Ah, thanks! I'd interpreted what @mper said as reflecting something that needed to be updated in the BrewFlasher software, not the GravityMon firmware. My bad.

It was - but it was something that gets updated on the server in this case so a restart it takes care of it. Glad you got GravityMon working - brew on!

 

[DuncB]

Deleted, solved the issue. It was a hardware problem. Carry on folks, I'll stop clogging up this thread.

Your router / relay, ispindel build issue?

 

[kdw2pd]

Your router / relay, ispindel build issue?

I was having an issue building the C3 iSpindels where the battery would charge and the charging LED would light up red, but the ESP32 wouldn't run on battery power. So "solved the issue" was optimistic, at least ID'd it. 99% sure it's an issue with the charging module, but I'm far from an electronics wizard. Frustrating, as I built some ESP8266-based iSpindels using the same chips and PCBs, and they all work fine, so not sure what I did wrong with this one.

I have some more TP40565's coming on the slow boat, hopefully by next week. Assuming that fixes the issue, I'll test out the iSpindel Tilt emulation --> TiltBridge and report back if it works.

 

[neomod]

there are a few options that can cause this.
1. battery voltage over the 4.15v limit is seen as charging and the sleep is disabled. Check th voltage factor och change the limit under advanced settings.
2. sleep disabled on the status page

update: on the status page the voltage is 4.29 so it will go to sleep after it has dropped below 4,15

if you havent changed the advanced settings this is normal, that file is only created if there are changes to that section, that is stored in a separate file.

if the gyro calibration is successful you should see the values on the config section. If they are zero then the there is no calibration. This could be a bug or failure to write the config file.

this is an error from esp idf and its annoying. This is shown when trying to open a file for read that does not exist. In your case since you have not had it in gravity mode.

could you share the datapoints? the testcases i have produce the same results on all boards.

update: the formula looks good in the screenshot, no deviations

the separator is different in us and europe but the meaning is the same. 1,070 and 1.070 is the same

I do apologise for the late response, I am really sorry: I've been completely absorbed by work and couldn't find 5 minutes to get back at this project.

Thank you so much for the detailed response: it helped resolving all the issues.

The battery voltage issue was probably the biggest issue: I didn't know about the threshold level, and I had done some tests with DC power instead of battery...sigh, I'm an idiot for not realizing it sooner.

Using a battery now - or simply tweaking the voltage conversion factor - I am seeing a constant flow of data to the Influx bucket: I'll leave it for another 10/12 hours with a longer delay just to be sure.

As for the calibration, I tested a few different settings (mostly to speed out test phase) and I flashed a "zeroing sketch" before flashing the firmware again: I am not seeing that error anymore (after changing the advanced settings section).

I have attached my latest calculation with datapoints and resulting graph. I double checked the measurements, but I was on short time so I did only a 9 point reference.

And as for the separator..thanks a lot. It was a stupid thing to ask, but beeing late at night testing and having all sorts of doubts it was something I started wondering. Thank you for clarifying.

 

[neomod]

I was having an issue building the C3 iSpindels where the battery would charge and the charging LED would light up red, but the ESP32 wouldn't run on battery power.

I am familiar with this issue: I have seen two major failure-points in "cheap" TP40565 modules available online.
In most of the cases where I had a failure, it was due to the fact that the second trace for the output was physically missing from the PCB, effectly not routing the power from the battery.
In some other cases - very few and all from the same seller which I have avoided since then - the modules had an incorrect layout: one of the resistors (R0) and one of the coupling capacitors used had a value beyond the recommended specs.

 

[kdw2pd]

I am familiar with this issue: I have seen two major failure-points in "cheap" TP40565 modules available online.
In most of the cases where I had a failure, it was due to the fact that the second trace for the output was physically missing from the PCB, effectly not routing the power from the battery.
In some other cases - very few and all from the same seller which I have avoided since then - the modules had an incorrect layout: one of the resistors (R0) and one of the coupling capacitors used had a value beyond the recommended specs.

Huh, I wasn't aware of this. I know there'd been issues with cheap gyroscope knockoffs and D1 Minis.

I haven't had any issues with the MPU6500s or the V3 D1 Minis that I ordered from AliExpress in the past, so I'm getting charger modules from the same seller this time (https://www.aliexpress.com/store/1100537934). Hoping that since the gyroscopes have been good where I've gotten crap ones elsewhere, the chargers will be as well.

I've looked at my soldering and the iSpindel schema, and I feel like they should work, so fingers crossed replacing the charging module does it.

 

[mper]

1.4 beta 2

https://github.com/mp-se/gravitymon/releases/tag/v1.4.0-beta2
Available in brewflasher as usual.

Biggest changes are support for S3 mini and move to async webserver to speed up web interface.

 

[kdw2pd]

Finally got an iSpindel with an ESP32 C3 V2.1 up and running. After selecting 'red' for the Bluetooth tilt color and 30 seconds for an interval (to speed up testing), I was was able to pick up the iSpindel on both the Tilt app and via TiltBridge in Fermentrack. So cool that it works!

And a huge thanks to @neomod: I replaced a couple of TP4056s with replacements from an AliExpress shop that appears to sell okay parts, and the issue with iSpindels not running on battery disappeared.

 

[mper]

Finally got an iSpindel with an ESP32 C3 V2.1 up and running. After selecting 'red' for the Bluetooth tilt color and 30 seconds for an interval (to speed up testing), I was was able to pick up the iSpindel on both the Tilt app and via TiltBridge in Fermentrack. So cool that it works!

And a huge thanks to @neomod: I replaced a couple of TP4056s with an AliExpress shop that appears to sell okay parts, and the issue with iSpindels not running on battery disappeared.

Good to hear you sorted out the hardware issues. In the 1.4 version there will be some more options for sending data over bluetooth and I'm working on a PR for tiltbridge to support some of those options. The focus has been to send more accurate data and also increase what can be sent.

 

[MaltyMcMaltMalt]

Hi.

Have been using Gravitymon successfully with Ubidots for many brews, but having just recently moved over to BrewFather, i'd like to get it working in BrewFather. I'm having no luck. Nothing is reported in BrewFather

I have 900sec update interval, V1.3.0. I can test push successfully. I have [SG] in my device name. and my temp set to DegC. All other settings are below (my BrewFather i.d is fabricated for security!). Thoughts on the problem appreciated..

 

[mper]

Hi.

Have been using Gravitymon successfully with Ubidots for many brews, but having just recently moved over to BrewFather, i'd like to get it working in BrewFather. I'm having no luck. Nothing is reported in BrewFather

I have 900sec update interval, V1.3.0. I can test push successfully. I have [SG] in my device name. and my temp set to DegC. All other settings are below (my BrewFather i.d is fabricated for security!). Thoughts on the problem appreciated..
View attachment 838877

View attachment 838878

View attachment 838879
View attachment 838880

View attachment 838881

Do you get any error message when sending the data in the test function or anything in the error log?

 

[MaltyMcMaltMalt]

Do you get any error message when sending the data in the test function or anything in the error log?

Hi, thanks for replying.

The manual test push to "target 'http-1' " completes successfully.

Below are the last 6 logs. I let the Ispindel 'try' and upload to BF for 2hrs on a 900 second interval, and there were no additional logs created, so the below seem to be historic..

PUSH: HTTP post failed response=-1 http1
PUSH: HTTP post failed response=-1 http1
WIFI: Failed to connect to wifi 4
WIFI: Failed to connect to wifi 4
PUSH: HTTP post failed response=-1 http1
WIFI: Failed to connect to wifi 4

I am on the Premium albeit trial 30-day subscription package with BF and I am beginning to think this is a non-advertised limitation of the 30-day premium trial - I have emailed BF

 

[mper]

Hi, thanks for replying.

The manual test push to "target 'http-1' " completes successfully.

Below are the last 6 logs. I let the Ispindel 'try' and upload to BF for 2hrs on a 900 second interval, and there were no additional logs created, so the below seem to be historic..

PUSH: HTTP post failed response=-1 http1
PUSH: HTTP post failed response=-1 http1
WIFI: Failed to connect to wifi 4
WIFI: Failed to connect to wifi 4
PUSH: HTTP post failed response=-1 http1
WIFI: Failed to connect to wifi 4

I am on the Premium albeit trial 30-day subscription package with BF and I am beginning to think this is a non-advertised limitation of the 30-day premium trial - I have emailed BF

-1 means connection refused, so something would be blocking the communication path. Wifi error 4 means connection failed so it might be that you dont have any internet/wifi connection or something is blocking the path to brewfather.

 

[MaltyMcMaltMalt]

Thanks - as there are no timestamps, how do we know when these occurred? Could they not be weeks old, and the connection to BF is making its way through fine?

By way of example the same (identical) logs were present at approx 14:00 and 16:00 and Gravitymon had been running constantly for the two hours in-between

cheers and thanks

 

[MaltyMcMaltMalt]

OK an, update. BF have confirmed for me that there have been requests from my Ispindel but the "body of the request was either invalid or contained no data".

I am using the std, 'Ispindel (POST)' push template; any reason why this would not work? When I select the BF template and hit save, leave and then come back to the template page, it seems to have defaulted back to the ISpindel template and ignored my selection. Is this part of the problem?

Running out of ideas!!

 

[mper]

Thanks - as there are no timestamps, how do we know when these occurred? Could they not be weeks old, and the connection to BF is making its way through fine?

By way of example the same (identical) logs were present at approx 14:00 and 16:00 and Gravitymon had been running constantly for the two hours in-between

cheers and thanks

true, there are no timestamps since nyp sync takes to long you need to know what errors are old. Dont remember if i added a clear log function

 

[mper]

OK an, update. BF have confirmed for me that there have been requests from my Ispindel but the "body of the request was either invalid or contained no data".

I am using the std, 'Ispindel (POST)' push template; any reason why this would not work? When I select the BF template and hit save, leave and then come back to the template page, it seems to have defaulted back to the ISpindel template and ignored my selection. Is this part of the problem?

Running out of ideas!!

Well that narrows it down, can you press the test button on the format template to see the result?

It will default back if the posted data is empty so can you check the console output in the browser? Its under development tools

 

[MaltyMcMaltMalt]

Success!

No real idea why or how, but changed over to HTTP 2 (HTTP 1 left blank) and then selected the 'GravityMon (POST)' push template and we seem to be in business...

It seems as thought there is some sort of bug somewhere with the template in, possibly HTTP 1 not being saved or used correctly.

@mper - DM me if you want further info on this and we can exchange emails. It might have to wait as tomorrow my Ispindel will be floating in a hefe for 2 weeks!

thank you

 

[mper]

Success!

No real idea why or how, but changed over to HTTP 2 (HTTP 1 left blank) and then selected the 'GravityMon (POST)' push template and we seem to be in business...

It seems as thought there is some sort of bug somewhere with the template in, possibly HTTP 1 not being saved or used correctly.

@mper - DM me if you want further info on this and we can exchange emails. It might have to wait as tomorrow my Ispindel will be floating in a hefe for 2 weeks!

thank you

I don't think there is a bug, might be something wrong with the filesystem on the device. If so then a fresh install with full erase should fix the problem. You can do a backup of the settings before that so you don't need to change everything again.

You can always DM me here in the forum.

 

[MaltyMcMaltMalt]

Thanks. When 1.4.0 is released ill push that through as a fresh install as its working for now.

Great software BTW.

 

[mper]

Thanks. When 1.4.0 is released ill push that through as a fresh install as its working for now.

Great software BTW.

Thanks for the kind words. I will release the 1.4 in the next few weeks as soon as i have completed my current fermentation and added a PR to tiltbridge for the new bluetooth formats. I usually do a full fermentation cycle before I release it.