The device manager is currently reading the full layout, settings and chords every time the site is opened or reloaded. This is inefficient since the site can already locally save all of those, but it can't yet check if the locally saved data is the same as the device's data.
Proposal
Internally a value would be incremented every time a chord, setting or layout mapping is changed.
There would be a command to retrieve this state/version id. Integer overflows are not of concern, since this is purely for parity checks.
Ideally, the version ID would be a UNIX time stamp, though I'm not sure if the device has anything in the way of an accurate internal clock (I doubt it).
The device manager can then check if its own saved version is equal to the internal version id, and based on that skip reading new data.
> CML C5
CML C5 1234
> VAR B5
VAR B5 23
> CML C3 00000000E4E2B0160F84B20ACE7638C0 6361727065206469656D
CML C3 00000000E4E2B0160F84B20ACE7638C0 6361727065206469656D 0
> CML C5
CML C5 1235
> VAR B2 2E 46
VAR B2 2E 46 0
> VAR B5
VAR B5 24
> RST
# reboot
> CML C5
CML C5 1235
> VAR B5
VAR B5 23
> VAR B2 2E 46
VAR B2 2E 46 0
> VAR B0
VAR B0 0
> RST
# reboot
> VAR B5
VAR B5 24
Theaninova
commented
12 months ago
The device manager is currently reading the full layout, settings and chords every time the site is opened or reloaded. This is inefficient since the site can already locally save all of those, but it can't yet check if the locally saved data is the same as the device's data.
Proposal
Internally a value would be incremented every time a chord, setting or layout mapping is changed.
There would be a command to retrieve this state/version id. Integer overflows are not of concern, since this is purely for parity checks.
Ideally, the version ID would be a UNIX time stamp, though I'm not sure if the device has anything in the way of an accurate internal clock (I doubt it).
The device manager can then check if its own saved version is equal to the internal version id, and based on that skip reading new data.