Skip to content

Conversation

@rneswold
Copy link
Contributor

This PR adds a new type of device handler, a SharedReadWriteDevice. This device type is to be used for devices that are controlled by DrMem, but can also be controlled manually. A driver will typically poll the hardware to get its current state. It also waits for settings from clients. This handler allows the device to be overridden and then get back in sync after a timeout.

It should be used for devices, like Wifi LED bulbs.

My house had a power outage in the middle of the night that lasted
longer than my UPS. My SSD's filesystem had some corruption. I was
able to recover some of the work that I did, but lost some, too.

This commit has some of the work and compiles and passes unit tests.
I'll need to recreate the rest of the work in future commits.
This removes a `todo!` macro. When reporting a polled value, we
weren't handleing the `SettingTrans` state. Now we are.
If the device is synced and a setting comes in with the same value, we
weren't letting the client know the setting succeeded.
Now all the states are handled by both update methods.
Add messages that announce when we enter and leave override mode.
I've started switching my shell script's commands into a single `just`
file.
This allows us to run the tests on just this driver.
@rneswold rneswold merged commit 7ef1b5d into DrMemCS:main Nov 28, 2025
3 checks passed
@rneswold rneswold deleted the shared-device branch November 28, 2025 06:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant