diff options
| -rw-r--r-- | .gitignore | 1 | ||||
| -rw-r--r-- | python-brewblox-devcon-spark.spec | 357 | ||||
| -rw-r--r-- | sources | 1 |
3 files changed, 359 insertions, 0 deletions
@@ -0,0 +1 @@ +/brewblox-devcon-spark-0.5.2.tar.gz diff --git a/python-brewblox-devcon-spark.spec b/python-brewblox-devcon-spark.spec new file mode 100644 index 0000000..d64b929 --- /dev/null +++ b/python-brewblox-devcon-spark.spec @@ -0,0 +1,357 @@ +%global _empty_manifest_terminate_build 0 +Name: python-brewblox-devcon-spark +Version: 0.5.2 +Release: 1 +Summary: Communication with Spark controllers +License: GPLv3 +URL: https://github.com/BrewBlox/brewblox-devcon-spark +Source0: https://mirrors.nju.edu.cn/pypi/web/packages/52/71/fab2bd0fb036ef489f861e68e52812caad08067c63df9ffad0cc11e9cb8e/brewblox-devcon-spark-0.5.2.tar.gz +BuildArch: noarch + + +%description + + +# Spark Service + +The Spark service handles connectivity for the BrewPi Spark controller. + +This includes USB/TCP communication with the controller, but also encoding, decoding, and broadcasting data. + + + +## Features + +### SparkConduit ([communication.py](./brewblox_devcon_spark/communication.py)) + +Direct communication with the Spark is handled here, for both USB and TCP connections. Data is not decoded or interpreted, but passed on to the `SparkCommander`. + +### Controlbox Protocol ([commands.py](./brewblox_devcon_spark/commands.py)) + +The Spark communicates using the [Controlbox protocol](https://brewblox.netlify.com/dev/reference/spark_commands.html). A set of commands is defined to manage blocks on the controller. + +In the commands module, this protocol of bits and bytes is encapsulated by `Command` classes. They are capable of converting a Python dict to a hexadecimal byte string, and vice versa. + +### SparkCommander ([commander.py](./brewblox_devcon_spark/commander.py)) + +Serial communication is asynchronous: requests and responses are not linked at the transport layer. + +`SparkCommander` is responsible for building and sending a command, and then matching it with a subsequently received response. + +### SimulationCommander ([commander_sim.py](./brewblox_devcon_spark/commander_sim.py)) + +For when using an actual Spark is inconvenient, there is a simulation version. It serves as a drop-in replacement for the real commander: it handles commands, and returns sensible values. +Commands are encoded/decoded, to closely match the real situation. + +### Datastore ([datastore.py](./brewblox_devcon_spark/datastore.py)) + +The service must keep track of object metadata not directly persisted by the controller. This includes user-defined object names and descriptions. + +Services are capable of interacting with a BrewPi Spark that has pre-existing blocks, but will be unable to display objects with a human-meaningful name. + +Object metadata is persisted to files. This does not include object settings - these are the responsibility of the Spark itself. + +### Codec ([codec.py](./brewblox_devcon_spark/codec/codec.py)) + +While the controller <-> service communication uses the Controlbox protocol, individual objects are encoded separately, using Google's [Protocol Buffers](https://developers.google.com/protocol-buffers/). + +The codec is responsible for converting JSON-serializable dicts to byte arrays, and vice versa. A specific transcoder is defined for each object. + +For this reason, the object payload in Controlbox consists of two parts: a numerical `object_type` ID, and the `object_data` bytes. + +### SparkController ([device.py](./brewblox_devcon_spark/device.py)) + +`SparkController` combines the functionality of `commands`, `commander`, `datastore`, and `codec` to allow interaction with the Spark using Pythonic functions. + +Any command is modified both incoming and outgoing: ID's are converted using the datastore, data is sent to codec, and everything is wrapped in the correct command before it is sent to `SparkCommander`. + +### Broadcaster ([broadcaster.py](./brewblox_devcon_spark/broadcaster.py)) + +The Spark service is not responsible for retaining any object data. Any requests are encoded and forwarded to the Spark. + +To reduce the impact of this bottleneck, and to persist historic data, `Broadcaster` reads all objects every few seconds, and broadcasts their values to the eventbus. + +Here, the data will likely be picked up by the [History Service](https://github.com/BrewBlox/brewblox-history). + + +### Seeder ([seeder.py](./brewblox_devcon_spark/seeder.py)) + +Some actions are required when connecting to a (new) Spark controller. +The Seeder feature waits for a connection to be made, and then performs these one-time tasks. + +Examples are: +* Setting Spark system clock +* Reading controller-specific data from the remote datastore + +## REST API + +### ObjectApi ([object_api.py](./brewblox_devcon_spark/api/object_api.py)) + +Offers full CRUD (Create, Read, Update, Delete) functionality for Spark objects. + +### SystemApi ([system_api.py](./brewblox_devcon_spark/api/system_api.py)) + +System objects are distinct from normal objects in that they can't be created or deleted by the user. + +### RemoteApi ([remote_api.py](./brewblox_devcon_spark/api/remote_api.py)) + +Occasionally, it is desirable for multiple Sparks to work in concert. One might be connected to a temperature sensor, while the other controls a heater. + +Remote blocks allow synchronization between master and slave blocks. + +In the sensor/heater example, the Spark with the heater would be configured to have a dummy sensor object linked to the heater. + +Instead of directly reading a sensor, this dummy object is updated by the service whenever it receives an update from the master object (the real sensor). + +### AliasApi ([alias_api.py](./brewblox_devcon_spark/api/alias_api.py)) + +All objects can have user-defined names. The AliasAPI allows users to set or change those names. + +%package -n python3-brewblox-devcon-spark +Summary: Communication with Spark controllers +Provides: python-brewblox-devcon-spark +BuildRequires: python3-devel +BuildRequires: python3-setuptools +BuildRequires: python3-pip +%description -n python3-brewblox-devcon-spark + + +# Spark Service + +The Spark service handles connectivity for the BrewPi Spark controller. + +This includes USB/TCP communication with the controller, but also encoding, decoding, and broadcasting data. + + + +## Features + +### SparkConduit ([communication.py](./brewblox_devcon_spark/communication.py)) + +Direct communication with the Spark is handled here, for both USB and TCP connections. Data is not decoded or interpreted, but passed on to the `SparkCommander`. + +### Controlbox Protocol ([commands.py](./brewblox_devcon_spark/commands.py)) + +The Spark communicates using the [Controlbox protocol](https://brewblox.netlify.com/dev/reference/spark_commands.html). A set of commands is defined to manage blocks on the controller. + +In the commands module, this protocol of bits and bytes is encapsulated by `Command` classes. They are capable of converting a Python dict to a hexadecimal byte string, and vice versa. + +### SparkCommander ([commander.py](./brewblox_devcon_spark/commander.py)) + +Serial communication is asynchronous: requests and responses are not linked at the transport layer. + +`SparkCommander` is responsible for building and sending a command, and then matching it with a subsequently received response. + +### SimulationCommander ([commander_sim.py](./brewblox_devcon_spark/commander_sim.py)) + +For when using an actual Spark is inconvenient, there is a simulation version. It serves as a drop-in replacement for the real commander: it handles commands, and returns sensible values. +Commands are encoded/decoded, to closely match the real situation. + +### Datastore ([datastore.py](./brewblox_devcon_spark/datastore.py)) + +The service must keep track of object metadata not directly persisted by the controller. This includes user-defined object names and descriptions. + +Services are capable of interacting with a BrewPi Spark that has pre-existing blocks, but will be unable to display objects with a human-meaningful name. + +Object metadata is persisted to files. This does not include object settings - these are the responsibility of the Spark itself. + +### Codec ([codec.py](./brewblox_devcon_spark/codec/codec.py)) + +While the controller <-> service communication uses the Controlbox protocol, individual objects are encoded separately, using Google's [Protocol Buffers](https://developers.google.com/protocol-buffers/). + +The codec is responsible for converting JSON-serializable dicts to byte arrays, and vice versa. A specific transcoder is defined for each object. + +For this reason, the object payload in Controlbox consists of two parts: a numerical `object_type` ID, and the `object_data` bytes. + +### SparkController ([device.py](./brewblox_devcon_spark/device.py)) + +`SparkController` combines the functionality of `commands`, `commander`, `datastore`, and `codec` to allow interaction with the Spark using Pythonic functions. + +Any command is modified both incoming and outgoing: ID's are converted using the datastore, data is sent to codec, and everything is wrapped in the correct command before it is sent to `SparkCommander`. + +### Broadcaster ([broadcaster.py](./brewblox_devcon_spark/broadcaster.py)) + +The Spark service is not responsible for retaining any object data. Any requests are encoded and forwarded to the Spark. + +To reduce the impact of this bottleneck, and to persist historic data, `Broadcaster` reads all objects every few seconds, and broadcasts their values to the eventbus. + +Here, the data will likely be picked up by the [History Service](https://github.com/BrewBlox/brewblox-history). + + +### Seeder ([seeder.py](./brewblox_devcon_spark/seeder.py)) + +Some actions are required when connecting to a (new) Spark controller. +The Seeder feature waits for a connection to be made, and then performs these one-time tasks. + +Examples are: +* Setting Spark system clock +* Reading controller-specific data from the remote datastore + +## REST API + +### ObjectApi ([object_api.py](./brewblox_devcon_spark/api/object_api.py)) + +Offers full CRUD (Create, Read, Update, Delete) functionality for Spark objects. + +### SystemApi ([system_api.py](./brewblox_devcon_spark/api/system_api.py)) + +System objects are distinct from normal objects in that they can't be created or deleted by the user. + +### RemoteApi ([remote_api.py](./brewblox_devcon_spark/api/remote_api.py)) + +Occasionally, it is desirable for multiple Sparks to work in concert. One might be connected to a temperature sensor, while the other controls a heater. + +Remote blocks allow synchronization between master and slave blocks. + +In the sensor/heater example, the Spark with the heater would be configured to have a dummy sensor object linked to the heater. + +Instead of directly reading a sensor, this dummy object is updated by the service whenever it receives an update from the master object (the real sensor). + +### AliasApi ([alias_api.py](./brewblox_devcon_spark/api/alias_api.py)) + +All objects can have user-defined names. The AliasAPI allows users to set or change those names. + +%package help +Summary: Development documents and examples for brewblox-devcon-spark +Provides: python3-brewblox-devcon-spark-doc +%description help + + +# Spark Service + +The Spark service handles connectivity for the BrewPi Spark controller. + +This includes USB/TCP communication with the controller, but also encoding, decoding, and broadcasting data. + + + +## Features + +### SparkConduit ([communication.py](./brewblox_devcon_spark/communication.py)) + +Direct communication with the Spark is handled here, for both USB and TCP connections. Data is not decoded or interpreted, but passed on to the `SparkCommander`. + +### Controlbox Protocol ([commands.py](./brewblox_devcon_spark/commands.py)) + +The Spark communicates using the [Controlbox protocol](https://brewblox.netlify.com/dev/reference/spark_commands.html). A set of commands is defined to manage blocks on the controller. + +In the commands module, this protocol of bits and bytes is encapsulated by `Command` classes. They are capable of converting a Python dict to a hexadecimal byte string, and vice versa. + +### SparkCommander ([commander.py](./brewblox_devcon_spark/commander.py)) + +Serial communication is asynchronous: requests and responses are not linked at the transport layer. + +`SparkCommander` is responsible for building and sending a command, and then matching it with a subsequently received response. + +### SimulationCommander ([commander_sim.py](./brewblox_devcon_spark/commander_sim.py)) + +For when using an actual Spark is inconvenient, there is a simulation version. It serves as a drop-in replacement for the real commander: it handles commands, and returns sensible values. +Commands are encoded/decoded, to closely match the real situation. + +### Datastore ([datastore.py](./brewblox_devcon_spark/datastore.py)) + +The service must keep track of object metadata not directly persisted by the controller. This includes user-defined object names and descriptions. + +Services are capable of interacting with a BrewPi Spark that has pre-existing blocks, but will be unable to display objects with a human-meaningful name. + +Object metadata is persisted to files. This does not include object settings - these are the responsibility of the Spark itself. + +### Codec ([codec.py](./brewblox_devcon_spark/codec/codec.py)) + +While the controller <-> service communication uses the Controlbox protocol, individual objects are encoded separately, using Google's [Protocol Buffers](https://developers.google.com/protocol-buffers/). + +The codec is responsible for converting JSON-serializable dicts to byte arrays, and vice versa. A specific transcoder is defined for each object. + +For this reason, the object payload in Controlbox consists of two parts: a numerical `object_type` ID, and the `object_data` bytes. + +### SparkController ([device.py](./brewblox_devcon_spark/device.py)) + +`SparkController` combines the functionality of `commands`, `commander`, `datastore`, and `codec` to allow interaction with the Spark using Pythonic functions. + +Any command is modified both incoming and outgoing: ID's are converted using the datastore, data is sent to codec, and everything is wrapped in the correct command before it is sent to `SparkCommander`. + +### Broadcaster ([broadcaster.py](./brewblox_devcon_spark/broadcaster.py)) + +The Spark service is not responsible for retaining any object data. Any requests are encoded and forwarded to the Spark. + +To reduce the impact of this bottleneck, and to persist historic data, `Broadcaster` reads all objects every few seconds, and broadcasts their values to the eventbus. + +Here, the data will likely be picked up by the [History Service](https://github.com/BrewBlox/brewblox-history). + + +### Seeder ([seeder.py](./brewblox_devcon_spark/seeder.py)) + +Some actions are required when connecting to a (new) Spark controller. +The Seeder feature waits for a connection to be made, and then performs these one-time tasks. + +Examples are: +* Setting Spark system clock +* Reading controller-specific data from the remote datastore + +## REST API + +### ObjectApi ([object_api.py](./brewblox_devcon_spark/api/object_api.py)) + +Offers full CRUD (Create, Read, Update, Delete) functionality for Spark objects. + +### SystemApi ([system_api.py](./brewblox_devcon_spark/api/system_api.py)) + +System objects are distinct from normal objects in that they can't be created or deleted by the user. + +### RemoteApi ([remote_api.py](./brewblox_devcon_spark/api/remote_api.py)) + +Occasionally, it is desirable for multiple Sparks to work in concert. One might be connected to a temperature sensor, while the other controls a heater. + +Remote blocks allow synchronization between master and slave blocks. + +In the sensor/heater example, the Spark with the heater would be configured to have a dummy sensor object linked to the heater. + +Instead of directly reading a sensor, this dummy object is updated by the service whenever it receives an update from the master object (the real sensor). + +### AliasApi ([alias_api.py](./brewblox_devcon_spark/api/alias_api.py)) + +All objects can have user-defined names. The AliasAPI allows users to set or change those names. + +%prep +%autosetup -n brewblox-devcon-spark-0.5.2 + +%build +%py3_build + +%install +%py3_install +install -d -m755 %{buildroot}/%{_pkgdocdir} +if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi +if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi +if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi +if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi +pushd %{buildroot} +if [ -d usr/lib ]; then + find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/lib64 ]; then + find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/bin ]; then + find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/sbin ]; then + find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst +fi +touch doclist.lst +if [ -d usr/share/man ]; then + find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst +fi +popd +mv %{buildroot}/filelist.lst . +mv %{buildroot}/doclist.lst . + +%files -n python3-brewblox-devcon-spark -f filelist.lst +%dir %{python3_sitelib}/* + +%files help -f doclist.lst +%{_docdir}/* + +%changelog +* Fri May 05 2023 Python_Bot <Python_Bot@openeuler.org> - 0.5.2-1 +- Package Spec generated @@ -0,0 +1 @@ +9967773fc4282c092235cb9739e6ddac brewblox-devcon-spark-0.5.2.tar.gz |