Feature Request, Extend the protocol to manage the LCD Back Light of the Krake

[ForrestErickson]

Some times the LCD back light should be turned off but not always.
If off, the back light may be woken up when the user needs to read the display.

[TheBakedPotato]

The GPAP is a general purpose protocol. How would implementing functionality target to a specific device/client allow for making the protocol general? How do you envision something like this would be accomplished?

[ForrestErickson]

Regarding "How do you envision something like this would be accomplished?"
At some time in the past @nk25719 and @RobertLRead and I had discussed extention of the protocl where in addition to managing back light we would manage which sound files played and if sound files played once, N times or indefinatly.
It was never reduced to a single issue.

However in the Krake User/Opperator Manual found at:
https://docs.google.com/document/d/1qrhc7Yi6PFmagl4gnvSoc0T4vC_uqu-NLrmWMKFnwA0/edit?pli=1&tab=t.0#heading=h.wxbfbyr25edt
The Krake™ is also audio-file enabled

The Krake™ is also audio-file enabled. Files are stored on an SD card in the MP3 format. It can replay alarm conditions, such as a human voices speaking the words such as:
“The patient’s ventilator hose is disconnected.”
“The blood pressure monitor battery is nearly dead.”
“The back door is unlocked.”
“The back door is open.”
“The kiln temperature is too high.”
Of course, the Krake™ developer may record such messages in any human language. The Krake™ alarm messages do not depend on English, though our documentation is only in English at present. In this version, the LCD only displays text using the Roman alphabet.

Alarms are organized into the common form of five severity levels (plus a sixth of “no alarm”):
“0” – no alarm (no audio and LCD has text but is dark). Pressing any button or knob will briefly, 30 seconds, turn on the LCD backlight.
“1” – Informational,
“2” – Problem,
“3” – Warning,
“4” – Critical,
“5” – Panic.

Each alarm message may carry with it a text message of up to ??? characters organized as four rows of twenty characters.

In general the audio does not have to be associated with an alarm level. When an alarm is raised, the controller device will specify three pieces of information (optionally, some may be missing): 1) the alarm severity, 2) the text message, 3) the number of the sound file to play, if any. So the same sound file could be raised at severity 1, and then, later, perhaps if ignored for a long time, raised at severity level 2, and so on.

From this you can see that we began trying to specify the Krake in part in that document and another (I forget but something like a developers manual).
But we gradually and with out deliberate decision drifted into specifying feature only using GitHub Issues.

CC:
@nk25719
@RobertLRead

[ForrestErickson]

FYI here is the Developers Technical Manual
https://docs.google.com/document/d/150WA6Mb1_SFOBmFc9qBpT5b-MqXb7ejaZbKIxUqaDBY/edit?pli=1&tab=t.0#heading=h.qygltmza7ufl