I have the following temperature profile running to test my setup, but it doesn’t appear to be working. Beer temp should be 19degC, but is currently 19.4degC.
Note the Ferment Process widget show no beer set point and neither does the Ferment Cool/Heat PID
The proportional values are not being calculated?
Brewblox diagnostic data & log:
https://termbin.com/oxiy
brewblox-logs.json (2 Bytes)
The PID is inactive because a dependency block is missing or invalid. If you check your Spark service page, one of the blocks above it will have a red dot indicating invalid configuration, or a grey dot meaning it’s disabled.
That looks like a bug - the profile should have output, but the setpoint doesn’t have input, even though it is claimed.
Does the Setpoint have a setting again when you disable and enable the profile?
Yep seems like a bug as the profile doesn’t calculate the proportional gain/error ( = Setting - Measured), but the input or setting is noted.
If I disable the profile to run on set point only, the set point is blank until I “check for problems” → “click to fix” then add the set point value.
When I re-enable the profile the set point becomes blank again.
If you create a new profile block with the same points, and disable the old one, does this correctly set the setpoint setting?
The setpoint setting is inactive by design when you disable a profile. It is activated again when you manually set the setting, either in the setpoint block itself, or using the temp control assistant.
Hi Bob. I have created another setpoint profile block but that did not work either. Where any of the log files I included in my original post of any use?
We did some digging and I think the following happened:
When the service started, the system time on your pi was incorrect. This incorrect time (Feb 4) was synced to the spark.
Later your pi probably corrected its time, but this was not synced as this only happens on connect.
Evidence in your log for this:
{
"id": "SystemInfo",
"nid": 2,
"type": "SysInfo",
"serviceId": "bbb_spark2",
"data": {
"deviceId": "21003d001447353236343033",
"version": "97191719",
"platform": "PLATFORM_PHOTON",
"protocolVersion": "98742fbf",
"releaseDate": "2023-01-27",
"protocolDate": "2023-01-10",
"uptime": {
"__bloxtype": "Quantity",
"unit": "second",
"value": 46033.685,
"readonly": true
},
"updatesPerSecond": 276.274,
"systemTime": "2023-02-04T12:05:32Z",
"timeZone": "NZST-12NZDT,M9.5.0,M4.1.0/3",
"displayBrightness": 255,
"ip": "0.0.0.0",
"tempUnit": "TEMP_CELSIUS"
}
},
System block has “2023-02-04T12:05:32Z” as time at the time the log was generated. This is GMT, but still far off.
The profile start time is "start": "2023-02-05T11:19:08Z", so the profile has yet to start as far as the spark knows, and that is why the setpoint is inactive.
The UI shows the position in the profile based on the browser time.
In the boot log:
[Mon Feb 6 02:17:03 2023] systemd[1]: System time before build time, advancing clock.
When systemd has no better fallback, it uses the time it was compiled.
systemd will also write the last known time to the sd card. If the SD card is dying and is in read only mode, this will have problems.
Some more info here:
https://forums.raspberrypi.com/viewtopic.php?t=307328
https://wiki.archlinux.org/title/systemd-timesyncd
Also in your log:
[Mon Feb 6 02:22:38 2023] Mem-Info:
[Mon Feb 6 02:22:38 2023] active_anon:14041 inactive_anon:76993 isolated_anon:90
active_file:66751 inactive_file:47685 isolated_file:0
unevictable:4 dirty:590 writeback:195
slab_reclaimable:5320 slab_unreclaimable:6590
mapped:73223 shmem:15986 pagetables:3274 bounce:0
kernel_misc_reclaimable:0
free:7308 free_pcp:8 free_cma:1260
[Mon Feb 6 02:22:38 2023] Node 0 active_anon:56164kB inactive_anon:307972kB active_file:267004kB inactive_file:190740kB unevictable:16kB isolated(anon):360kB isolated(file):0kB mapped:292892kB dirty:2360kB writeback:780kB shmem:63944kB writeback_tmp:0kB kernel_stack:5376kB pagetables:13096kB all_unreclaimable? no
[Mon Feb 6 02:22:38 2023] DMA free:29232kB min:20480kB low:24576kB high:28672kB reserved_highatomic:4096KB active_anon:56164kB inactive_anon:307972kB active_file:267004kB inactive_file:190740kB unevictable:16kB writepending:3140kB present:970752kB managed:944268kB mlocked:16kB bounce:0kB free_pcp:32kB local_pcp:32kB free_cma:5040kB
[Mon Feb 6 02:22:38 2023] lowmem_reserve[]: 0 0 0
[1:47 PM]
[Mon Feb 6 02:17:06 2023] systemd-journald[128]: File /var/log/journal/c7dbd1bc914f4485ba61e79f9b2fd5fe/system.journal corrupted or uncleanly shut down, renaming and replacing.
Never yank power to the pi without a proper shutdown first. This can cause sd card corruption.
If you set up WiFi on the Spark, it will get the time from sntp and it will receive time updates independent of the server.
Hi Elco, ahh l see, that makes sense.
I don’t usually shut down the rpi in this manner, but my system does include a “kill switch”. I use this to test that the spark controller keeps the setpoint if power is restored after an unexpected power cut. As you say, not ideal for the SD card though.
I prefer to keep the spark connected to the rpi via usb not wifi. If I stop the system (brewblox-ctl down) and re-flash the firmware, should that now sync the correct time to the spark?
Or if I also set up wifi on the spark with --discovery=all, will the time be updated even though connection hierarchy is usb discovery first?
Thanks for your help on this.
You can force to use usb with --discovery=usb, but still set up wifi for sntp.
Flashing the firmware is completely unrelated to the time sync. Time sync happens every time the service connects. A docker container restart causes a resync.
Shutting down with ‘sudo shutdown -h now’ should still be a valid test without potential corruption on the pi.
Ok, I’ll look into setting up wifi.
“Time sync happens every time the service connects. A docker container restart causes a resync.”
During my own investigations to get the profile setpoint enabled I have either stopped and restarted the service using the comands brewblox-ctl down → brewblox-ctl up or brewblox-ctl restart. Should this have resynced the time on the spark?
The controller accepts time updates from the service only if not previously set. We wanted to avoid repeated back-and-forth time changes if the service and NTP disagree, and NTP is the primary mechanism.
Needless to say, we’re looking at how to handle cases like this. It at the least involves notifying the user when controller and server significantly disagree about the time.
We should probably change that to ‘if not recently set by sntp’ if possible.