Closed andrewn closed 6 years ago
I just remembered that for the Radiodan Server we used Commands and Events as a way to split the request / response topics up. Do we want to do that again here?
I think that makes a lot of sense, and will be easier to understand than RPC and Pub/Sub.
@pixelblend Are you happy for me to merge this? I can do another PR that converts all of the physical
service to use command/event naming patterns.
This adds support for some more advanced features of the capacitive touch board.
Reset (92032571354edfc5c0af4579ad73c9865bbce0a5)
Resetting the board re-calibrates the sensors which is very useful when moving wires.
Capacitive/:id/resetRequest
will perform the reset.Capacitive/:id/reset
is emitted when a reset occurs.Getting/setting sensitivity (982e125a81fcd6bd3cbeef5ee5207adae834c72b)
Allows an app to change how sensitive the board is to touches.
Capacitive/:id/statusRequest
request the sensitivity.Capacitive/:id/status
emits a payload of{ sensitivity: NUMBER }
To change the sensitivity send,
Capacitive/:id/sensitivity
with a payload{ params: { level: NUMBER } }
.Capacitive/:id/status
is emitted when the sensitivity changes.Message routing
~As discussed, it'd be nice to have some library support and some naming conventions and patterns for this stuff to apply across the
services
andapps
. I like the patterrn of being able to send a command to a service (e.g.sensitivity
) and know that it has been executed, or failed with an error. But also for other parts of the system to listen for events (status
).~This has been re-based onto the new WebSocket library from #40.