[GH-ISSUE #101] Feature request: Openepaper JSON Template Language #1707

New Issue

sascha_hemi · 2026-03-20T20:05:08+01:00

sascha_hemi commented

2026-03-20 20:05:08 +01:00

Originally created by @steinwedel on GitHub (Aug 9, 2023).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/101

Goals:
All displays generated with the AP are no longer hard-coded in the program code, but stored in templates. This allows for easier customization of the templates.

Templates can be loaded via URL or stored locally.

For this purpose, there should be a new directory named "templates" under the root directory. Within this directory, there are subdirectories named "system," "system_mod," and "user."
/templates/system
/templates/system_mod
/templates/system/user

Users should not modify the /templates/system directory, as it may be overwritten during updates. To modify a system template, place it in the /templates/system_mod directory. When executing a system template, the interpreter first looks in the /templates/system_mod folder, and then in the /templates/system folder. All other templates are stored in /templates/user.

For fonts, I would also suggest a modified structure:
/fonts/system
/fonts/user
This has the advantage that users do not need to touch the fonts in the /fonts/system folder.

Additionally, there should be a directory named /data.

The JSON template file should have a new structure.

Colors are no longer encoded with 01,2. Since OLEDs can also be supported, the RGB color space is used. Colors should be represented using hex #FF0000. For better readability, constants like White, Red, Yellow, and Black should be defined.
A version should be included so that the interpreter can check if this version is supported:
{
"version": 1,
"vars": [],
"content": []
}
Content
Since various displays are intended to be supported by a template, the content must be specified for each supported display (similar to current system templates):
"content": [
{ "tag": "typ1", "display": [] },
{ "tag": "typ2", "display": [] }
]
Display in Content
Display follows the existing JSON template structure in principle. Some modernizations are to be considered. First, the syntax for fonts should be adjusted. For TTF fonts, a leading slash must be included. For bitmap fonts, it should not. This is illogical. Additionally, colors should be defined as mentioned above. Individual values can be passed as fixed arguments or as variables.
Example:
{"text": [5, 0, "%temperature °C", "fonts/bahnschrift20", 2]}
The content of the variables is defined in the vars section (see above). All existing hardcoded features should be included in the template language, including barcode128 and QR code.
Vars
The vars section is also of particular interest. Variables can be hardcoded in the template or loaded from another file or the internet. Special functions can also be introduced to generate variables all at once, e.g., for weather data.
- Hardcoded:
  {"var": "city", "content": "Berlin"},
  {"var": "temperature", "content": 10.5}
- From JSON file:
  {"var": "text", "filetype": "json", "url": "file:/data/mydata.json", "item": "[3][caption]"}
- From text file/URL (entire content):
  {"var": "text", "filetype": "text", "url": "file:/data/mydata.txt"}
- From text file (line):
  {"var": "text", "filetype": "text", "url": "http://test.de:/data/mydata.txt", "line": 3}
- Possibly from CSV file:
  {"var": "text", "filetype": "csv", "divider": ",", "url": "http://test.de:/data/mydata.txt", "line": 3, "item": 2}

For system templates, it might make sense to specify whether values can be entered and saved via the web interface. For example, for weather forecasts, the location:
{"var": "city", "input": "city", "label": "City"}
Localization for the respective language would need to be added (how?).

In future versions, it would likely be useful to include simple calculations, e.g., display_with-40, etc.

Originally created by @steinwedel on GitHub (Aug 9, 2023). Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/101 Goals: All displays generated with the AP are no longer hard-coded in the program code, but stored in templates. This allows for easier customization of the templates. Templates can be loaded via URL or stored locally. For this purpose, there should be a new directory named "templates" under the root directory. Within this directory, there are subdirectories named "system," "system_mod," and "user." /templates/system /templates/system_mod /templates/system/user Users should not modify the /templates/system directory, as it may be overwritten during updates. To modify a system template, place it in the /templates/system_mod directory. When executing a system template, the interpreter first looks in the /templates/system_mod folder, and then in the /templates/system folder. All other templates are stored in /templates/user. For fonts, I would also suggest a modified structure: /fonts/system /fonts/user This has the advantage that users do not need to touch the fonts in the /fonts/system folder. Additionally, there should be a directory named /data. The JSON template file should have a new structure. 1. Colors are no longer encoded with 01,2. Since OLEDs can also be supported, the RGB color space is used. Colors should be represented using hex #FF0000. For better readability, constants like White, Red, Yellow, and Black should be defined. 2. A version should be included so that the interpreter can check if this version is supported: { "version": 1, "vars": [], "content": [] } 3. Content Since various displays are intended to be supported by a template, the content must be specified for each supported display (similar to current system templates): "content": [ { "tag": "typ1", "display": [] }, { "tag": "typ2", "display": [] } ] 4. Display in Content Display follows the existing JSON template structure in principle. Some modernizations are to be considered. First, the syntax for fonts should be adjusted. For TTF fonts, a leading slash must be included. For bitmap fonts, it should not. This is illogical. Additionally, colors should be defined as mentioned above. Individual values can be passed as fixed arguments or as variables. Example: {"text": [5, 0, "%temperature °C", "fonts/bahnschrift20", 2]} The content of the variables is defined in the vars section (see above). All existing hardcoded features should be included in the template language, including barcode128 and QR code. 5. Vars The vars section is also of particular interest. Variables can be hardcoded in the template or loaded from another file or the internet. Special functions can also be introduced to generate variables all at once, e.g., for weather data. - Hardcoded: {"var": "city", "content": "Berlin"}, {"var": "temperature", "content": 10.5} - From JSON file: {"var": "text", "filetype": "json", "url": "file:/data/mydata.json", "item": "[3][caption]"} - From text file/URL (entire content): {"var": "text", "filetype": "text", "url": "file:/data/mydata.txt"} - From text file (line): {"var": "text", "filetype": "text", "url": "http://test.de:/data/mydata.txt", "line": 3} - Possibly from CSV file: {"var": "text", "filetype": "csv", "divider": ",", "url": "http://test.de:/data/mydata.txt", "line": 3, "item": 2} For system templates, it might make sense to specify whether values can be entered and saved via the web interface. For example, for weather forecasts, the location: {"var": "city", "input": "city", "label": "City"} Localization for the respective language would need to be added (how?). In future versions, it would likely be useful to include simple calculations, e.g., display_with-40, etc.

sascha_hemi added the enhancement ap fw labels 2026-03-20 20:05:08 +01:00

sascha_hemi closed this issue

2026-03-20 20:05:08 +01:00

sascha_hemi commented

2026-03-20 20:05:09 +01:00

@nlimper commented on GitHub (Aug 10, 2023):

Thanks for the extensive suggestions. A lot of those definitely make sense. But remember we're using a $2.5 microcomputer here, and we're kind of limited mainly by flash (program) size.
I will implement some of these items at some point. In the meantime, we do take pull requests, so if you created something yourself, you're very welcome to share it.
I leave this one open, and if any improvements are made, I will add it here.

@nlimper commented on GitHub (Aug 10, 2023): Thanks for the extensive suggestions. A lot of those definitely make sense. But remember we're using a $2.5 microcomputer here, and we're kind of limited mainly by flash (program) size. I will implement some of these items at some point. In the meantime, we do take pull requests, so if you created something yourself, you're very welcome to share it. I leave this one open, and if any improvements are made, I will add it here.

sascha_hemi commented

2026-03-20 20:05:09 +01:00

@nlimper commented on GitHub (Aug 11, 2023):

I have implemented some of these now:

Colors can now be 0,1, 2, but also "black", "white", "red" or "#ff0000"
Font parameter cleaned up. You can not use "fontname.vlw" (/fonts/ folder is assumed), or "/myfolder/blah.ttf", etc. The old values like "font/fontname" also still work.
Variables are implemented, at least the start of it. You can use {variablename} within text content of the json template, and set a single variable using a POST to /set_var using field key=variablename and val=myCoolValue, or set multiple variables using a POST to /set_vars with field 'json' and value { "temperature": 28.5, "door": "open", "testkey": "MyCoolValue" }. All tags that are using one of the changed variables, gets then reloaded. To be able to redraw, the json template is now always kept, so not deleted anymore, independant if the json template was pushed or pulled.

@nlimper commented on GitHub (Aug 11, 2023): I have implemented some of these now: - Colors can now be 0,1, 2, but also "black", "white", "red" or "#ff0000" - Font parameter cleaned up. You can not use "fontname.vlw" (/fonts/ folder is assumed), or "/myfolder/blah.ttf", etc. The old values like "font/fontname" also still work. - Variables are implemented, at least the start of it. You can use {variablename} within text content of the json template, and set a single variable using a POST to /set_var using field key=variablename and val=myCoolValue, or set multiple variables using a POST to /set_vars with field 'json' and value `{ "temperature": 28.5, "door": "open", "testkey": "MyCoolValue" }`. All tags that are using one of the changed variables, gets then reloaded. To be able to redraw, the json template is now always kept, so not deleted anymore, independant if the json template was pushed or pulled.

sascha_hemi commented

2026-03-20 20:05:09 +01:00

@steinwedel commented on GitHub (Aug 13, 2023):

OpenEPaper scribe = OEPscribe

Here, there are many ideas. Nic, hopefully you won't get a headache ;-)

First, an example in the old and new designs:
Old:

[
	{"text":[5,0,"Pantry","fonts/bahnschrift20",2]},
	{"text":[5,25,"Jam","fonts/calibrib30",1]},
	{"text":[5,55,"- Strawberry","fonts/calibrib30",1]},
	{"text":[5,90,"2022","fonts/bahnschrift20",1]},
	{"text":[248,110,"028","fonts/bahnschrift20",2]}
]

New:

{ "language": "OEPscribe", "version":1, "displays": 
	[
		{ "type":"${ST-GR2900}", 
			[
				{"cmd": "write", "value": "Pantry", "pos": {"x": 5, "y": 5}, "font":"/fonts/bahnschrift20", "color":"${red}"},
				{"cmd": "write", "value": "\nJam", "font": "/fonts/calibrib30", "color":"${black}"},
				{"cmd": "write", "value": "\n- Strawberries"},
				{"cmd": "write", "value": "\n2022", "font": "/fonts/bahnschrift20"},
				{"cmd": "write", "value": "028", "pos":{"x": 248, "y": 110}, "color":"${red}"},
			]
		},
	]
}

Why the departure from the previous "print" commands? From my perspective, they aren't very intuitive and difficult to expand. An example is adding support for TTF fonts. One has to remember the exact command structure, which varies between bitmap fonts and TTFs. Furthermore, there's no cursor, so when adding new text, the precise position must be specified. This is eliminated here. An example of extensibility is adding a "drawBox" command with a "fillPattern" option. If this is added later, existing scripts might need adjustment. In this new syntax, this option is certainly optional. Other options like fill color don't need to be at specific positions within the command. The second code is also simpler for variable substitution, as it allows substitution not only of text but all values. Disadvantage: the code is slightly longer. Given that the new syntax supports multiple tags within a template, the break in command syntax is acceptable, as templates would need adjustment anyway. Versioning also makes sense; if someone publishes a template, its compatibility with the firmware can be checked upon use. Otherwise, an error message appears with a precise description, guiding the user to update the firmware if necessary.

Commands:

varSet(varname, value)
varReadRaw(varname, url)
varReadArray(url)
varReadWeatherCur(location)
varDisplayConfig(varname,label,type)

write(value, size, color, align, fonturl, fontsize)

lineTo(pos, posTo, color)
drawBox(pos, posTo, Color)
drawImage(url, pos)
drawQrCode(pos, val)
drawBarCode128(pos, value)

//drawCircle (likely obsolete)
//drawTriangle (likely obsolete)
drawWeatherForecastChart(location, pos)
drawPrecipitationForecastChart(location, pos)

clearScreen()
showErrorDisplay()

varSet(varname, value)

This command assigns a value (value) to a variable name (varname) in the variable array. If the value doesn't exist yet, it's created.

varReadRaw(varname, url)

This command is similar to varSet, but the variable's value comes from a URL instead of the script.

varReadArray(url)

This command is like varReadRaw but reads an array of values instead of a single value. The format is:

[
	["name1", "value1"],
	["name2", "value2"],
	…
]

varReadWeatherCur(varname, location)

This command stores the following values in the variable: Temperature, Windspeed, Winddirection, Weathercode:
{"temperature": 13, "windspeed": 1.41, "winddirection":225, "weathercode": 3}

*** varDisplayConfig(varname, label, type)
This command enables system scripts to query and store parameters on the config webpage (.json).

*** write(value, size, color, align, fonturl, fontsize)
Except for value, all parameters are optional. Using write({"value":"This is text"}) prints text at the current cursor position in the current font/size/color/alignment. Additional parameters are cached. The initial cursor position is TopMargin/LeftMargin. "\n" performs a line break.

lineTo(pos, posTo, color)

drawBox(pos, posTo, Color)

drawImage(url, pos)

drawQrCode(pos, val)

drawBarCode128(pos, value)

//drawCircle //possibly unnecessary

This function is likely redundant, saving memory. Most TTF fonts include a bold dot.

//drawTriangle //likely obsolete

This function is likely redundant, saving memory. Most TTF fonts include appropriate characters.

drawWeatherForecastChart(location, pos)

Fun function. It might be worth asking users if they actually use it before incorporating it or using a #define to comment it out.

drawPrecipitationForecastChart(location, pos)

Fun function. It might be worth asking users if they actually use it before incorporating it or using a #define to comment it out. This function partially works in Germany (e.g., Hannover).

clearScreen()

This command makes sense if, after script execution has started, everything needs to be discarded. This command might only be useful when displaying error messages. Perhaps this behaviour of error handling is default. Then this command is unnessary.

showErrorDisplay()

This command intentionally displays the error page for testing functionality. It shouldn't appear in regular scripts; it's only relevant for development.

Parameters

varname

Name of the runtime variable

value

Value of the parameter

url

Supported URL protocols:

http://
https://
file://
If no protocol is given, the file:// protocol is used

fontUrl

Similar to file://, but specific to the file:// protocol

size

Font size; ignored for bitmap fonts

color

RGB Value: #ff0000; color variables for better reading, e.g., ${red}

align

Allowed values: left, right, center

pos

Position to start the command. Optional. If omitted, uses current cursor position (curPos). Structure: {"x": value, "y": value}. If x or y is omitted, the corresponding value from curPos is used. After operation, new position is stored in curPos.

posTo

Mandatory. Position for drawing (line, box, etc.); similar to pos

label

Assigns a name for displaying a value on the config page. Mandatory.

type

Different display types identified by a unique type. Display type is identified by an ordinal number. For each display type, a variable exists for readability, e.g., 1 corresponds to "ST-GR2900". This value is mandatory.

location

{"city": "Berlin", "lat": "52.1", "lon": "9.5"}
If lat and lon are set, city is optional. If omitted, city is used to potentially display the location name. If lat and/or lon are missing, they are derived from the location name. Optional if missing, derived from global data.

Before executing OEPscribe, system variables, global variables, and tag-specific variables are loaded into an array; all variables are stored under /vars. Global variables are saved in "global.json," tag-specific variables under the tag's MAC address. Existing variables can be overwritten.
System variables (immutable):

Location (City)
LeftMargin: 5
TopMargin: 5
RightMargin: 5
BottomMargin: 5
SystemFont: "something.ttf"
SystemFontSize: 20
"red": "#ff0000"
"black": "#000000"
"white": "#ffffff"
"yellow": "#ffff00"
defaultErrorScreen -> Possible design see **Error
date -> Current date
time -> Current time hh:mm
OEPscribeVersion: 1

Global variables:
Loaded from (current/global.json); system variables can be overridden here

Template Initialization Variables:

templateName (set automatically)
errorNo: "0" (set automatically; changed in case of errors)
errorName: "No Error" (set automatically; changed in case of errors)
errorDesc: "There is currently no error" (set automatically; changed in case of errors)
errorLineNo: -1 (set automatically; changed in case of errors)
errorLineText: "—" (set automatically; changed in case of errors)

Tag Variables:
Derived from file ...

TagType, e.g., 1
TagName, e.g., "ST-GR2900"
TagMac, e.g., "0000023C58973B14"
TagAlias, e.g., "My Tag"
TagWidth, e.g., 296
TagHeight, e.g., 128

Runtime Variables:
Set by the script

curPos: on start of template: {"x": "${LeftMargin}", "y": "${TopMargin}"}
curFont: on start of template: "${SystemFont}"
curFontSize: on start of template: "${SystemFontSize}"
curColor: on start of template: "${black}"

Variables are loaded into the variable array in the order of variable types during template or tag section loading. Existing variables can be overwritten, but sources like global.json are not overwritten.

Error

In case of an error

If an error occurs, the message from "Display":"Error" in the script is displayed. If "Display":"Error" is missing, the display is taken from defaultErrorDisplay:

	{"type": "error", "content":
		[
			{"cmd": "clearScreen"},
			{"cmd": "write", "text": "Error ", "font": "/fonts/bahnschrift20", "color": "${red}"},
			{"cmd": "write", "text": "in ${templateName}\n", "color": "${black}"},
			{"cmd": "write", "text": "in ${errorNo}: ${errorName}\n"},
			{"cmd": "write", "text": "in ${errorLineNo}: ${errorLineText}\n"},
			{"cmd": "write", "text": "in ${errorDesc}\n"}
		]
	}

Error codes:

1: OEPscribe not found
2: Script requires higher OEPscribe version (required: ${OEPscribeVersionExpected}, installed: ${OEPscribeVersion})
3: No display type definition in OEPscribe
4: Unknown OEPscribe command
5: Necessary parameter missing
20: URL ${url} could not be opened
200: Unknown city (geoLocation)

After loading, variable values containing variables themselves are checked and replaced. Multiple iterations are possible with limited interactions; when no more variables are found, the process stops.

When opening the template, the init section is executed first. It can be used for weather data initialization, for instance, saving work.
Next, the script tries to find a section for the corresponding tag. If not found or if an error occurs, an error section is sought. The error section can be used to communicate errors, such as the template not being available for the display or an error during script execution.

There's a default error screen, so it doesn't need to be included in templates.

Undefined yet:

Symbol for current weather
Symbol for forecast
Symbol for wind direction
RSS feed
Google Calendar

@steinwedel commented on GitHub (Aug 13, 2023): ### OpenEPaper scribe = OEPscribe Here, there are many ideas. Nic, hopefully you won't get a headache ;-) First, an example in the old and new designs: **Old**: ``` [ {"text":[5,0,"Pantry","fonts/bahnschrift20",2]}, {"text":[5,25,"Jam","fonts/calibrib30",1]}, {"text":[5,55,"- Strawberry","fonts/calibrib30",1]}, {"text":[5,90,"2022","fonts/bahnschrift20",1]}, {"text":[248,110,"028","fonts/bahnschrift20",2]} ] ``` **New**: ``` { "language": "OEPscribe", "version":1, "displays": [ { "type":"${ST-GR2900}", [ {"cmd": "write", "value": "Pantry", "pos": {"x": 5, "y": 5}, "font":"/fonts/bahnschrift20", "color":"${red}"}, {"cmd": "write", "value": "\nJam", "font": "/fonts/calibrib30", "color":"${black}"}, {"cmd": "write", "value": "\n- Strawberries"}, {"cmd": "write", "value": "\n2022", "font": "/fonts/bahnschrift20"}, {"cmd": "write", "value": "028", "pos":{"x": 248, "y": 110}, "color":"${red}"}, ] }, ] } ``` Why the departure from the previous "print" commands? From my perspective, they aren't very intuitive and difficult to expand. An example is adding support for TTF fonts. One has to remember the exact command structure, which varies between bitmap fonts and TTFs. Furthermore, there's no cursor, so when adding new text, the precise position must be specified. This is eliminated here. An example of extensibility is adding a "drawBox" command with a "fillPattern" option. If this is added later, existing scripts might need adjustment. In this new syntax, this option is certainly optional. Other options like fill color don't need to be at specific positions within the command. The second code is also simpler for variable substitution, as it allows substitution not only of text but all values. Disadvantage: the code is slightly longer. Given that the new syntax supports multiple tags within a template, the break in command syntax is acceptable, as templates would need adjustment anyway. Versioning also makes sense; if someone publishes a template, its compatibility with the firmware can be checked upon use. Otherwise, an error message appears with a precise description, guiding the user to update the firmware if necessary. #### Commands: varSet(varname, value) varReadRaw(varname, url) varReadArray(url) varReadWeatherCur(location) varDisplayConfig(varname,label,type) write(value, size, color, align, fonturl, fontsize) lineTo(pos, posTo, color) drawBox(pos, posTo, Color) drawImage(url, pos) drawQrCode(pos, val) drawBarCode128(pos, value) //drawCircle (likely obsolete) //drawTriangle (likely obsolete) drawWeatherForecastChart(location, pos) drawPrecipitationForecastChart(location, pos) clearScreen() showErrorDisplay() ##### varSet(varname, value) This command assigns a value (value) to a variable name (varname) in the variable array. If the value doesn't exist yet, it's created. ##### varReadRaw(varname, url) This command is similar to varSet, but the variable's value comes from a URL instead of the script. ##### varReadArray(url) This command is like varReadRaw but reads an array of values instead of a single value. The format is: ``` [ ["name1", "value1"], ["name2", "value2"], … ] ``` ##### varReadWeatherCur(varname, location) This command stores the following values in the variable: Temperature, Windspeed, Winddirection, Weathercode: {"temperature": 13, "windspeed": 1.41, "winddirection":225, "weathercode": 3} *** varDisplayConfig(varname, label, type) This command enables system scripts to query and store parameters on the config webpage (<mac>.json). *** write(value, size, color, align, fonturl, fontsize) Except for value, all parameters are optional. Using write({"value":"This is text"}) prints text at the current cursor position in the current font/size/color/alignment. Additional parameters are cached. The initial cursor position is TopMargin/LeftMargin. "\n" performs a line break. ##### lineTo(pos, posTo, color) ##### drawBox(pos, posTo, Color) ##### drawImage(url, pos) ##### drawQrCode(pos, val) ##### drawBarCode128(pos, value) ##### //drawCircle //possibly unnecessary This function is likely redundant, saving memory. Most TTF fonts include a bold dot. ##### //drawTriangle //likely obsolete This function is likely redundant, saving memory. Most TTF fonts include appropriate characters. ##### drawWeatherForecastChart(location, pos) Fun function. It might be worth asking users if they actually use it before incorporating it or using a #define to comment it out. ##### drawPrecipitationForecastChart(location, pos) Fun function. It might be worth asking users if they actually use it before incorporating it or using a #define to comment it out. This function partially works in Germany (e.g., Hannover). ##### clearScreen() This command makes sense if, after script execution has started, everything needs to be discarded. This command might only be useful when displaying error messages. Perhaps this behaviour of error handling is default. Then this command is unnessary. ##### showErrorDisplay() This command intentionally displays the error page for testing functionality. It shouldn't appear in regular scripts; it's only relevant for development. #### Parameters ##### varname Name of the runtime variable ##### value Value of the parameter ##### url Supported URL protocols: - http:// - https:// - file:// If no protocol is given, the file:// protocol is used ##### fontUrl Similar to file://, but specific to the file:// protocol ##### size Font size; ignored for bitmap fonts ##### color RGB Value: #ff0000; color variables for better reading, e.g., ${red} ##### align Allowed values: left, right, center ##### fontSize Optional. Only for TTF fonts. For bitmap fonts, it has no effect. Stored in curFontSize until changed. ##### pos Position to start the command. Optional. If omitted, uses current cursor position (curPos). Structure: {"x": value, "y": value}. If x or y is omitted, the corresponding value from curPos is used. After operation, new position is stored in curPos. ##### posTo Mandatory. Position for drawing (line, box, etc.); similar to pos ##### label Assigns a name for displaying a value on the config page. Mandatory. ##### type Different display types identified by a unique type. Display type is identified by an ordinal number. For each display type, a variable exists for readability, e.g., 1 corresponds to "ST-GR2900". This value is mandatory. ##### location {"city": "Berlin", "lat": "52.1", "lon": "9.5"} If lat and lon are set, city is optional. If omitted, city is used to potentially display the location name. If lat and/or lon are missing, they are derived from the location name. Optional if missing, derived from global data. Before executing OEPscribe, system variables, global variables, and tag-specific variables are loaded into an array; all variables are stored under /vars. Global variables are saved in "global.json," tag-specific variables under the tag's MAC address. Existing variables can be overwritten. **System variables (immutable):** - Location (City) - LeftMargin: 5 - TopMargin: 5 - RightMargin: 5 - BottomMargin: 5 - SystemFont: "something.ttf" - SystemFontSize: 20 - "red": "#ff0000" - "black": "#000000" - "white": "#ffffff" - "yellow": "#ffff00" - defaultErrorScreen -> Possible design see **Error - date -> Current date - time -> Current time hh:mm - OEPscribeVersion: 1 **Global variables:** Loaded from (current/global.json); system variables can be overridden here **Template Initialization Variables:** - templateName (set automatically) - errorNo: "0" (set automatically; changed in case of errors) - errorName: "No Error" (set automatically; changed in case of errors) - errorDesc: "There is currently no error" (set automatically; changed in case of errors) - errorLineNo: -1 (set automatically; changed in case of errors) - errorLineText: "—" (set automatically; changed in case of errors) **Tag Variables:** Derived from file ... - TagType, e.g., 1 - TagName, e.g., "ST-GR2900" - TagMac, e.g., "0000023C58973B14" - TagAlias, e.g., "My Tag" - TagWidth, e.g., 296 - TagHeight, e.g., 128 **Runtime Variables:** Set by the script - curPos: on start of template: {"x": "${LeftMargin}", "y": "${TopMargin}"} - curFont: on start of template: "${SystemFont}" - curFontSize: on start of template: "${SystemFontSize}" - curColor: on start of template: "${black}" Variables are loaded into the variable array in the order of variable types during template or tag section loading. Existing variables can be overwritten, but sources like global.json are not overwritten. #### Error ##### In case of an error If an error occurs, the message from "Display":"Error" in the script is displayed. If "Display":"Error" is missing, the display is taken from defaultErrorDisplay: ``` {"type": "error", "content": [ {"cmd": "clearScreen"}, {"cmd": "write", "text": "Error ", "font": "/fonts/bahnschrift20", "color": "${red}"}, {"cmd": "write", "text": "in ${templateName}\n", "color": "${black}"}, {"cmd": "write", "text": "in ${errorNo}: ${errorName}\n"}, {"cmd": "write", "text": "in ${errorLineNo}: ${errorLineText}\n"}, {"cmd": "write", "text": "in ${errorDesc}\n"} ] } ``` ##### Error codes: 1: OEPscribe not found 2: Script requires higher OEPscribe version (required: ${OEPscribeVersionExpected}, installed: ${OEPscribeVersion}) 3: No display type definition in OEPscribe 4: Unknown OEPscribe command 5: Necessary parameter missing 20: URL ${url} could not be opened 200: Unknown city (geoLocation) After loading, variable values containing variables themselves are checked and replaced. Multiple iterations are possible with limited interactions; when no more variables are found, the process stops. When opening the template, the init section is executed first. It can be used for weather data initialization, for instance, saving work. Next, the script tries to find a section for the corresponding tag. If not found or if an error occurs, an error section is sought. The error section can be used to communicate errors, such as the template not being available for the display or an error during script execution. There's a default error screen, so it doesn't need to be included in templates. #### Undefined yet: Symbol for current weather Symbol for forecast Symbol for wind direction RSS feed Google Calendar

sascha_hemi commented

2026-03-20 20:05:10 +01:00

@nlimper commented on GitHub (Aug 13, 2023):

There's something nice about writing the documentation first, before implementing it ;-)
My honest thoughts on this: it's very nice, flexible and well-thought. But, I doubt it will fit in the limited flash space there is left. Also, while it has a ton of usefullness, for a novice user (most users are) this is more complicated to understand then the current method (although, I agree on you about the confusing unnamed parameters).
If it will fit in the flash space (it was to be written very minimal and space-saving), of course it will be a great addition. If anybody wants to pick this up to write this: you're welcome!

@nlimper commented on GitHub (Aug 13, 2023): There's something nice about writing the documentation first, before implementing it ;-) My honest thoughts on this: it's very nice, flexible and well-thought. But, I doubt it will fit in the limited flash space there is left. Also, while it has a ton of usefullness, for a novice user (most users are) this is more complicated to understand then the current method (although, I agree on you about the confusing unnamed parameters). If it will fit in the flash space (it was to be written very minimal and space-saving), of course it will be a great addition. If anybody wants to pick this up to write this: you're welcome!

sascha_hemi commented

2026-03-20 20:05:10 +01:00

@steinwedel commented on GitHub (Aug 14, 2023):

It's not the documentation. Thanks for the flowers.
I'll fork the repro and try to write it. A will do the extension in a septette file, so it is later easy to integrate again in the main fork.

@steinwedel commented on GitHub (Aug 14, 2023): It's not the documentation. Thanks for the flowers. I'll fork the repro and try to write it. A will do the extension in a septette file, so it is later easy to integrate again in the main fork.

sascha_hemi commented

2026-03-20 20:05:10 +01:00

@steinwedel commented on GitHub (Sep 19, 2023):

I wrote a script language now. There are a lot of changes compared to the suggestions above. Even the standard displays like date etc. are changed to the template language. So you can try the current version. It's still in development but you can see how it will be. One problem are crashes. I didn't found the reason so far. The problem occurs in the wsSendSysteminfo() function. But it can be caused by my code. If anybody has suggestions I would be glad. Another todo are google calendar and rss feeds. So far I understood they are converted to json by a script and then displayed. If someone could send my the jsons and a picture I will build the templates. Currently only to displays are supported (0 and 1). I don't have the others to test. See https://github.com/steinwedel/OpenEPaperLink. Docu is in the wiki

@steinwedel commented on GitHub (Sep 19, 2023): I wrote a script language now. There are a lot of changes compared to the suggestions above. Even the standard displays like date etc. are changed to the template language. So you can try the current version. It's still in development but you can see how it will be. One problem are crashes. I didn't found the reason so far. The problem occurs in the wsSendSysteminfo() function. But it can be caused by my code. If anybody has suggestions I would be glad. Another todo are google calendar and rss feeds. So far I understood they are converted to json by a script and then displayed. If someone could send my the jsons and a picture I will build the templates. Currently only to displays are supported (0 and 1). I don't have the others to test. See https://github.com/steinwedel/OpenEPaperLink. Docu is in the wiki

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/OpenEPaperLink#1707