For folks that are having LCD noise issues: the comment Elco made about missing a pull-up on an AVR pin causing LCD corruption got me inspired to dig a bit to see if there might be other pins that could be prone to noise.
Considering sensors most folks might never wire up, the first candidate was the Door sensor input on Digital IO4.
By default, the web gui has this sensor unassigned, so it's basically ignoring it. I scoped the AVR pin and it was sitting at "0" volts. Then I used the BrewPi configuration gui to assign the device to Door Sensor, leaving it set for inverted mode, and suddenly there was a pull-up on that net. Then I de-assigned the sensor, but the pull-up remained. It persisted until I reset the Uno.
This doesn't seem right to me. There should always be a pull-up assigned to that low-asserted input, whether its state is ever processed or not. Conversely, if the sensor is set for non-inverted mode, there should be a pull-down assigned.
So, an easy long shot to try: enable the Door sensor device (it'll be the last device listed in the Detected Devices list). It's hard-wired to digital IO4, and set for inverted mode (meaning a LOW indicates the door is open). Assign it a valid slot and set the Function to Chamber Door then hit Apply.
Because the pull-up that gets invoked will hold the input in the negated state you won't ever get any messages. But see if it makes any difference wrt boinking the LCD.
There are likely other pins to inspect. I'll try to get to all of them...
Cheers!
Considering sensors most folks might never wire up, the first candidate was the Door sensor input on Digital IO4.
By default, the web gui has this sensor unassigned, so it's basically ignoring it. I scoped the AVR pin and it was sitting at "0" volts. Then I used the BrewPi configuration gui to assign the device to Door Sensor, leaving it set for inverted mode, and suddenly there was a pull-up on that net. Then I de-assigned the sensor, but the pull-up remained. It persisted until I reset the Uno.
This doesn't seem right to me. There should always be a pull-up assigned to that low-asserted input, whether its state is ever processed or not. Conversely, if the sensor is set for non-inverted mode, there should be a pull-down assigned.
So, an easy long shot to try: enable the Door sensor device (it'll be the last device listed in the Detected Devices list). It's hard-wired to digital IO4, and set for inverted mode (meaning a LOW indicates the door is open). Assign it a valid slot and set the Function to Chamber Door then hit Apply.
Because the pull-up that gets invoked will hold the input in the negated state you won't ever get any messages. But see if it makes any difference wrt boinking the LCD.
There are likely other pins to inspect. I'll try to get to all of them...
Cheers!