Hi,
Have updated and found that my previously “disabled” fridge is now cooling despite the set points showing as disabled ?
Hmm that’s not good. Can you export your blocks?
When a PID goes inactive it sets it’s output to zero only once to allow you to set the pwm manually later. Settings for the PWM block were stored when it was last configured, not when the PID changed the setting.
I suspect that on reboot the pwm was created after the inactive PID and included a setting.
I’ll try to reproduce it.
Can you confirm this theory by:
- confirming that the PWM setting is constant since the reboot
- setting it to zero and confirming that it stays at zero, also after a reboot
A possible fix is perhaps to split manual and PID applied setting of the pwm and only store a manually applied setting. I’ll have to think if this is also possible in other places.
All seems to be as it should now, I noticed the cooling after the update this morning, it was previously disabled as it is currently empty, I reapplied the “disable” but had to leave it until later in the day. I noticed it had been cooling to a previously set 11degs, albeit the set point was inactive. It stopped when I disabled the Cool PWM. I have just recycled the settings enable fridge constant and then disable and it seems to work. Have also rebooted and remains at zero.
Whilst in the disabled state I have applied a manual 18% duty to the heat PWM and it has started to heat despite the set point being disabled, I now can’t change it manually.
13%20PM|656x404
Does any of that help?
In addition it now won’t respond to the disable command and is still continuing to heat as if to follow the set point. Similar to the issue I first reported.
So to cut a long story short, it seems that a value entered manually into a PWM overrides the disabled set point.
Yes, that is by design.
When you disable the setpoint or PID, you can set the pwm manually.
I have been able to reproduce the issue.
The problem is that the order the blocks are recreated at boot is different than the order in which the settings were applied.
If you disable a setpoint or PID after manually setting the pwm, the PID sets the pwm to zero.
If at restart the PID is loaded first, it has no pwm to disable. The pwm is created with its last manually applied settings, which is enabled.
Because the inactive PID does not continuously set the pwm to zero, it stays at the manual setting.
It’s a hard problem that I have to think about for a bit.
After discussing this with Bob for about the entire afternoon, we found a fix that is simple enough and seems to work well.
We’ll release this as a hotfix tonight.
Since I have to specify in a file that I have 2 spark v2 with the addresses, why this late in the game do I still need to disconnect 1 to then update the second one? Why aren’t you reading said file and then running the firmware update on all specified addresses?
NOTE: Using RPi v3 with 2 Spark v2 connected via USB cable
Hi,
Sorry guys but I seem to have a issue after this hotfix.
I have lost the controller block list it is just blank
One setup has lost the PID displays and when they are selected the screen just dims.
The other when a PID graphic is selected it opens the PID but it cannot be edited with the screen going dim.
The third seems to be working as before on fridge constant.
I did capture an error message the first time I selected a PID graphic on Fridge 2, doesn’t display it any more the screen dims and hangs.
I have rebooted both the RPi and the brewpi and rerun the update.
To spare you the detailed technical explanation: streamlined firmware updates are in development right now.
Behavior will be to update firmware of the currently connected Spark(s) while everything is running. We haven’t turned it on yet in the UI because we have some issues with updates over USB (it already works nicely over Wifi).
I think this may be an issue with old deprecated objects. Could you please export your blocks? (spark service page, actions). If it is what I think that error message is saying, you may be able to resolve it manually before we release a fix tomorrow.
The blocks please, not the errors =) top right corner spark page, under “actions”.
Sorry, there s no actions on the spark page it is all blank.
Could you please go to PI_ADDRESS/spark-one/api/doc, and under “Objects” run the command to get all objects?
Yes. That’s it.
Could you please copy the response body into a file?
Thanks for the upload! It seems pretty clear where the problem comes from, but this will require some software changes. For now I’ll just roll back the hotfix.
Edit: it should be done in a few minutes. https://dev.azure.com/brewblox/brewblox/_build/results?buildId=1090
Thanks Bob, do I re-run the update?
Ok all back to “normal”
Cheers!