config.json and state.json

Deze pagina beschrijft de ontwikkelversie: een deel ervan zit nog niet in v1.3.0. Deze pagina in v1.3.0 · Wat er komt

Deze pagina is nog niet vertaald: hier is ze in het Engels.

PlayGuard's settings, in sd:/config/playguard/config.json, shared by every system on the SD card; and what one system's parental controls need remembered (Block all games, the extra time, a pending relock, the firmware choice), in its own sd:/config/playguard/nand/<system>/state.json (below). Everything here is set from the app; the file is only worth editing by hand to get back in (see pin_lock) or to check what PlayGuard remembered.

The code is the reference: source/util/config.hpp (fields and defaults) and source/util/config.cpp (reading, checks, writing). The remote link's settings are not here but in sync.conf (sync-protocol.md).

How the file is read

• A missing file gives the defaults, silently (a first run). PlayGuard writes the whole file at the next change.
• A file that is there but cannot be read, or is not a JSON object, is kept as config.json.bad before anything is saved (PlayGuard saves by itself at start-up), and the defaults are used. A config.json.bad already there becomes config.json.bad.1 (an older .bad.1 is deleted): the two most recent damaged files are kept. PlayGuard says so once, at start-up (the settings could not be read and were reset), and the change history records Settings reset. What the old file held (the limits Block all games saved, a pending relock or extra time, the firmware choice …) is not carried over: check those settings, or copy values back from the .bad file by hand. Should the file not be movable either, nothing is saved until the next start, so it is never overwritten.
• Each key is read on its own. A missing key keeps its default; a key of the wrong type keeps its default too, and the others are still read. Types are strict: true, not 1; 90, not 90.5 or "90".
• A value outside the list below goes back to its default, without a message.
• Keys PlayGuard does not know are ignored, and dropped at the next save.
• Some groups of keys are all-or-nothing: the firmware choice and the extra time of the day. One key refused, and the whole group is cleared.
• The file is written atomically (a temporary file, then a rename), indented with two spaces.

Preferences

pin_lock

Security › Protect PlayGuard with the PIN. A string:

• With pin_ask_again on, the PIN holds 5 minutes instead: Before a change asks again after them, and To open PlayGuard's lock screen comes back when PlayGuard returns after 5 minutes or more out of focus.

• With no PIN on the console, nothing is asked whatever the value.

• Show the PIN asks for it every time, whatever the value, even right after it was entered.
• A missing file, a missing key or a value not in the list gives "changes": a damaged file never turns the prompt off. Only "off" written on purpose does.
• In the app, a lower setting asks for the PIN first. The file itself is not protected: it keeps a child out of PlayGuard, not someone who edits the SD card.
• PIN forgotten while this is "changes" or "open": put the SD card in a computer and set "pin_lock": "off". Show the PIN still asks for it, and the recovery sysmodule's screen sets a new one rather than showing it.

Network clock

Updates

update_via and update_daily are set in Preferences › Updates; About › Check for updates checks at once.

Reminders

Developer

Set in About › Help & diagnostics › Developer, shown once developer mode is on.

State kept between launches

Written by PlayGuard to finish what it started. Better left alone: a wrong value here can make PlayGuard put back a limit nobody asked for.

These keys are in state.json, one per system: nand/sysmmc/ for the sysMMC, nand/emummc/ for the emuMMC (every emuMMC of the SD card shares it), nand/unknown/ when the system could not be told (source/util/nand.hpp). Each system has its own parental controls: Block all games turned on on the sysMMC must not put its limits back on an emuMMC. state.json is read like config.json (a damaged one is kept as state.json.bad, with the same notice); when a system has none yet, these keys are read from config.json, where the versions before it kept them, and leave it at the next save. extra_auto_restore, a preference, stays in config.json.

Block all games

Play timer › Block all games: every day's limit set to 0, so the PIN is needed to play.

Extra time today

Extra time today or No more play today: one day's limit changed for that day only. All four keys go together.

Extra time on another day

Extra time › Another day…: a later day's limit raised now, for that date only, and put back by itself the next time PlayGuard is opened once the day is over (unless that day's limit was changed since). All four keys go together.

Scheduled profile

Play timer › Profiles › Scheduled profile: a profile for a period, set by an earlier version (a new one is Home Assistant's: Console › Remote access). When the period begins, PlayGuard asks to put it in force (once a day, when it is opened); once it is over, to put back the limits it replaced. A period that went by with the profile never in force is forgotten. The six keys go together.

Firmware not supported yet

The choice made on that screen, remembered for one firmware with one app version. The three keys go together.

Locking again

Example

Every key with Protect PlayGuard with the PIN set to To open PlayGuard, in the order of this page: config.json, then a system's state.json. PlayGuard itself writes the keys in alphabetical order, with each array element on its own line; the order does not matter when it reads them:

{
  "schema": 1,
  "language": "fr",
  "theme": "dark",
  "theme_file": "",
  "text_size": "auto",
  "effects": "auto",
  "rail": "auto",
  "start_tab": "dashboard",
  "advanced": false,
  "auto_relock": true,
  "pin_ask_again": false,
  "pin_pauses": false,
  "onboarding_at_start": true,
  "clock_check_at_start": false,
  "intro": true,
  "activity_period": 1,
  "games_grid": true,
  "activity_account": "last",
  "activity_account_last": "",
  "export_format": 0,
  "backup_keep": 0,
  "logs_keep": 20,
  "logs_keep_days": 0,
  "logs_keep_mb": 0,
  "extra_amounts": [15, 30, 60],
  "pin_lock": "open",
  "ntp_server": "",
  "custom_servers": [],
  "update_via": "",
  "update_daily": false,
  "update_checked": "",
  "update_latest": "",
  "sys_latest": "",
  "sys_checked": "",
  "ha_latest": "",
  "ha_checked": "",
  "update_snooze_version": "",
  "update_snooze_until": "",
  "support_reminder": true,
  "support_reminded": "",
  "seen_version": "",
  "agent_update_skipped": "",
  "crash_seen": "",
  "notices_system": true,
  "notices_summary": true,
  "notices_reminders": true,
  "notices_read": [],
  "summary_seen": "",
  "dev_mode": false,
  "pt_log": false,
  "frame_stats": false,
  "cadran_glow": true,
  "dev_builds_order": "newest",
  "extra_auto_restore": false
}

{
  "schema": 1,
  "console_lock": false,
  "console_lock_prev": [],
  "console_lock_since": "",
  "extra_weekday": -1,
  "extra_date": "",
  "extra_base": 0,
  "extra_value": 0,
  "bonus_weekday": -1,
  "bonus_date": "",
  "bonus_base": 0,
  "bonus_value": 0,
  "schedule_file": "",
  "schedule_name": "",
  "schedule_from": "",
  "schedule_to": "",
  "schedule_applied": false,
  "schedule_prev": [],
  "fw_gate_fw": "",
  "fw_gate_app": "",
  "fw_gate_choice": "",
  "relock_pending": false
}

A file with only {"pin_lock": "off"} is valid too: every other key keeps its default.

watch.json

One per system, next to its state.json, in sd:/config/playguard/nand/<system>/watch.json: what PlayGuard last saw of the console, to tell the parent what changed outside it (the amber card on Today, the outside_* and new_account entries of the change history, the Activity tab's new-account flag). The code: source/action/outside_change_logic.cpp (the rules), source/action/outside_watch.cpp (the readings).

Only what PlayGuard sees. Nothing runs in the background: the file is compared with the console at each refresh of Today or the Play timer (every 5 s while one is on screen) and at the next start. A change made and undone while PlayGuard was closed, or a clock changed and the day over before PlayGuard opens again, goes unseen.

• The play time started over: spent_s went down by more than a minute on the same date. The console's own reset comes with a new day; when it happens exactly (midnight or the "allowed again" time) is not confirmed yet (parental-controls.md), so a reset at the "allowed again" time could show here.
• The clock was changed: offset_s moved by more than 5 minutes. The automatic correction moves it by seconds only.
• The limits were changed outside PlayGuard: they differ from limits.
• A new user account: the console lists one that is not in accounts (read once per start). It goes in the change history (new_account) and is flagged on the Activity tab for 30 days after since, not on Today. Without accounts (a first run, or a file from an older version) the accounts listed are only recorded.
• Every change PlayGuard makes itself (anything it records in the change history) makes it take what it reads next as is, so its own limit and clock changes are not reported.
• A missing or damaged file, or a key out of range, is a first reading: nothing is reported, the values are only recorded. Deleting the file is harmless.

Bekijken op GitHub