2 issues with iSpindel based device

[gabeweisz-oldacct]

I'm having 2 issues and am trying to figure out how to debug them.

• When I try to turn the iSpindel on in configuration mode, the blue light stays on solidly for 2-3 minutes before starting to blink (at which point I can use it in configuration mode)
• When in configuration mode, I can send data to BrewFather just fine using "test push" - and data is visible in BrewFather - but when I tip the iSpindel up to go into floating mode, nothing ever gets logged. I have the logging interval set as 900 seconds.

How should I debug this? The only things I see in the error log on the configuration page are from before I calibrated the device. Voltage shows up as 3.96-3.97V, but I think this is off because the (built-in) charger thinks the device is fully charged.

My log URL is http://log.brewfather.net/ispindel?id=[_my actual id is here_]

[gabeweisz-oldacct]

Logging seems to work OK when I turned off "Temperature adjust gravity" and set the logging interval to 1 minute, trying a larger interval with temperature adjust gravity turned off

[gabeweisz-oldacct]

Also seems OK at 5 minutes with "temperature adjust gravity" off, trying 15

15 seems OK with "temperature address gravity" off.

Any reason why this setting might cause issues? I am using the regular temperature sensor, not the one on the gyro.

[mp-se]

I normally dont use temp correction myself so i will need to test that part to see if its broken or could cause an issue. Based on your first post i would belive it was an issue with the resistor for sleep mode, but since you got it to work with the temp correction of there is probably something else. You dont get any errors in the error log?

On the topic of debugging, i would recommend to do short intervals and attach a serial console to see the output. Its not recommended to have the battery attached when doing that since you might overload the battery. In order for the device to go into sleep mode you need to adjust the threashold value (default 4.15) to a value above your charge level. This will force it to only check the angle when checking mode.

[gabeweisz-oldacct]

There were no errors in the log, from what I can tell the device just didn't turn on. And it's been working perfectly since I turned the temperature correction off.

Unfortunately, I can't easily get to the serial console because the D1 mini I have has the USB port stuck against the main board, but I'll see if I can get to the serial console another way

[mp-se]

I will test it tomorrow, im doing some battery life testing at the momemt.

[gabeweisz-oldacct]

Thanks, I have a workaround in turning off the temp correction setting, so it is not urgent for me.

[gabeweisz-oldacct]

Maybe the device was turning on, but the reading wasn't getting sent to BrewFather for some reason, and I was just missing the blue light.

It looks like the temperature corrected gravity is calculated whether or not the box is checked (https://github.com/mp-se/gravitymon/blob/v1.1.1/src/main.cpp#:~:text=float%20corrGravitySG%20%3D,myAdvancedConfig.getDefaultCalibrationTemp())%3B) and the box just determines whether or not this value is used. Could it be that gravityTemperatureCorrectionC was returning some totally crazy value (maybe because myAdvancedConfig.getDefaultCalibrationTemp() returned something unreasonable), and that caused either converting the value to a JSON value to fail or it caused BrewFather to just drop the request?

[mp-se]

I cant repeate the issue, it works with 30s 5m and 15m for me.

The temp correction is always calcuated and the checkbox only makes the software use that value in the payload. Normally its added to a separate tag called "corr-gravity".

All the advanced values have default values and it should work without changes. If those change it might cause issues if they are "invalid".

Keep in mind that brewfather will only accept values every 15m, if you send more often they will be ignored.

[mp-se]

I missed answering the first question. IT's likely that the device goes into wifi mode due to it detects a double reset (you can check if there is a WIFI hotspot created when that happends). If the light is solid, just do a reset again and it should start normally.

On the second point I'm not sure what is causing the issue you describe. I assumed you used the esp8266 and v1.1.1 (or v1.1.0), is that correct ?

[gabeweisz-oldacct]

Thanks for the answer to the first question - that does explain what I was seeing. For the second one, I am monitoring a fermentation with this device right now (it is working perfectly so far after 3 days), but when this batch is done I'll do some more testing with it and see if I can find a way to connect to the serial console.

…

On Thu, Nov 17, 2022 at 4:27 AM Magnus ***@***.***> wrote: I missed answering the first question. IT's likely that the device goes into wifi mode due to it detects a double reset. If the light is solid, just do a reset again and it should start normally. On the second point I'm not sure what is causing the issue you describe. I assumed you used the esp8266 and v1.1.1 (or v1.1.0), is that correct ? — Reply to this email directly, view it on GitHub <#119 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKS4X66YRLITYXJ2DN3IDLWIX3AHANCNFSM6AAAAAASAC5QVU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mp-se]

Its strange behaviour since its always doing the temp correction calculation. If the value is corrupt it could crash but then there should be an entry in error log. Typically the sleep problem is related to hardware and the diode/resistor that triggers the wakeup. I dont see any reason that the temp correction option should have any impact to this.

I have a similar issue with the serial connector so on the esp32 boards i have been moving the serial console to the rx/tx pins and that works well. You only need an usb to ttl converter.

This is a new option in the v1.2 version.