{"id":21298413,"url":"https://github.com/airspot-dev/iot-demo","last_synced_at":"2025-03-15T17:43:23.075Z","repository":{"id":95594832,"uuid":"320244598","full_name":"airspot-dev/iot-demo","owner":"airspot-dev","description":null,"archived":false,"fork":false,"pushed_at":"2021-03-12T08:49:14.000Z","size":2884,"stargazers_count":1,"open_issues_count":0,"forks_count":1,"subscribers_count":2,"default_branch":"master","last_synced_at":"2024-11-21T14:52:10.462Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/airspot-dev.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":"support/dashboard_image/Dockerfile","governance":null,"roadmap":null,"authors":"AUTHORS","dei":null,"publiccode":null,"codemeta":null}},"created_at":"2020-12-10T11:01:08.000Z","updated_at":"2021-06-22T10:26:54.000Z","dependencies_parsed_at":"2023-04-26T11:47:08.977Z","dependency_job_id":null,"html_url":"https://github.com/airspot-dev/iot-demo","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/airspot-dev%2Fiot-demo","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/airspot-dev%2Fiot-demo/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/airspot-dev%2Fiot-demo/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/airspot-dev%2Fiot-demo/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/airspot-dev","download_url":"https://codeload.github.com/airspot-dev/iot-demo/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":235078884,"owners_count":18932443,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-21T14:52:14.012Z","updated_at":"2025-01-22T07:31:30.093Z","avatar_url":"https://github.com/airspot-dev.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# IoT demo application\n\nThe aim of this demo is to highlight some [KRules](https://github.com/airspot-dev/krules) core concept like the **subject** and its **reactive properties**. \nReactive properties are used to map a data stream context (e.g. a digital twin of a device or a twin of a \nKubernetes resource) and to give them a state to which changes business logic can react. This behavior \nis shown through this demo in an IoT scenario. In the demo the business logic reacts seamlessly to devices’ \nproduced metrics (e.g. temperature) and to Kubernetes resources update events. When it comes to Kubernetes \nresources we gather pieces of information useful for application logic and we set them as reactive \nproperties. This case is exemplified in the demo through the scenario in which is created a new Knative \nservice for which we want to listen and react when a URL becomes available or changes following the \nprovisioning of the SSL cert. All this logic is developed very easily using KRules reactive properties.\n\nThe Demo also wants to focus on how easy it is to take full advantage of Knative eventing, using brokers \nand triggers and shape logic upon them using subjects extended properties. Any time a _CloudEvent_ related \nto a specific device (the subject) is produced, its metadata automatically contains those properties \ndetermining the activation or not of specific groups of rulesets (business logic).\n\nDemo starts from uploading a .csv file, containing the base information about a set of devices, on a \nGoogle Cloud Storage bucket. This bucket is bound by a Knative CloudStorageSource, and a ruleset subscribes \nto the produced CloudEvents. A device’s subject is created for each line of the csv file. Depending on which \nfolder the file was uploaded, an **extended property** is set defining an hypothetical \"device class\". \nThe device class conditions all subsequent events related to the device allowing triggers to act differently. \nIn the demo telemetry data are routed on a common broker but they are also split in two different brokers, \neach specific for each device class. This architecture allows the activation of a common business logic \nfor all devices (eg: monitoring the _receiving data_ state) and the activation of a specific business logic \nfor each device class. This result is achieved quite simply by subscribing to the appropriate broker. \nIn the demo we have specific business logic related to temperature for the first device class and specific \nbusiness logic related to geo positioning for the second device class.\n\nFor the data ingestion we will simply use an http endpoint provided by a serverless Knative service. \nThe Knative service (and its related secret containing the api key) is created from a database model. \nThe database model is generated in a simple Django application. An ad-hoc extension was developed. \nThis extension produces cloudevents for any create/update/delete operation on Django ORM for the models \nwe are interested in. Each update operation originates a new Knative service revision. \nThis behavior makes the Django application acting as another Knative source.\n\nAnother aspect the demo focuses on is the **observability** of rules activity. \nThis characteristic can help developers in writing applications but it can also be used as part of the \napplication itself. When an event is processed by a rule another event is generated: the event \n“rule X has processed event Y”. This new event gathers all execution runtime information, including errors. \nThese events are all routed on their own broker which of course can be subscribed in order to build new logic. \nAll of this can be particularly useful for general or specific **error management**. \nIn fact the services producing errors and the ones specialized to manage errors will be totally decoupled, \nagnostic and independent. Such a characteristic can be a great advantage in a distributed and asynchronous \napplication, the typical nature of a microservices architecture that takes full advantage of event driven \nparadigm.\n\nFor more detailed information about how the demo works you can take a look to [these slides](https://github.com/airspot-dev/iot-demo/blob/master/Diagrams.pdf)\n\nNote that neither a step-by-step installation guide nor an illustrating video for this demo exist yet, but, \nif you are interested in knowing more about the project or even contribute to it, don't hesitate \nto [contact us](mailto:info@airspot.tech)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fairspot-dev%2Fiot-demo","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fairspot-dev%2Fiot-demo","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fairspot-dev%2Fiot-demo/lists"}