Edge release 2019/07/10

**Trig** · July 11, 2019, 3:08am

Hi,

Have updated and found that my previously “disabled” fridge is now cooling despite the set points showing as disabled ?

05%20PM

**Elco** · July 11, 2019, 7:07am

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.

**Trig** · July 11, 2019, 7:32am

brewblox-errors.json (1.8 KB)

**Trig** · July 11, 2019, 7:49am

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 53%20PM

Does any of that help?

**Trig** · July 11, 2019, 8:50am

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.

**Elco** · July 11, 2019, 10:26am

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.

**Elco** · July 11, 2019, 4:26pm

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.

**adiefender** · July 11, 2019, 8:45pm

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

**Trig** · July 11, 2019, 9:07pm

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.

**Bob_Steers** · July 11, 2019, 9:10pm

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).

**Bob_Steers** · July 11, 2019, 9:14pm

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.

**Trig** · July 11, 2019, 9:16pm

brewblox-errors.json (29 Bytes)

**Bob_Steers** · July 11, 2019, 9:17pm

The blocks please, not the errors =) top right corner spark page, under “actions”.

**Trig** · July 11, 2019, 9:19pm

Sorry, there s no actions on the spark page it is all blank.

**Bob_Steers** · July 11, 2019, 9:22pm

Could you please go to PI_ADDRESS/spark-one/api/doc, and under “Objects” run the command to get all objects?

**Trig** · July 11, 2019, 9:30pm

You are leading the blind here Bob, is that what you are after?

**Bob_Steers** · July 11, 2019, 9:33pm

Yes. That’s it.

Could you please copy the response body into a file?

**Trig** · July 11, 2019, 9:41pm

Object request.txt (19.7 KB)

**Bob_Steers** · July 11, 2019, 10:05pm

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

**Trig** · July 11, 2019, 10:39pm

Thanks Bob, do I re-run the update?

Ok all back to “normal”
Cheers!