Skip to content

NilsBohr/arcusplatform

 
 
== Agent ==

Contains the agent application that runs on the Arcus hub.  The hub's primary role is a bridge/gateway between devices in the and the platform.  In addition, it may run device drivers locally and execute the alarm state machine to make noises when security or safety events are detected.

* arcus-agent:  The agent's main launcher
* arcus-alarm-controller:  The alarm state machine
* arcus-gateway:  This subproject contains the source code the hub uses for connection to the platform
* arcus-hal:   The agent's hardware abstraction layer for interacting with speakers in the hub or LEDs
* arcus-hub-controller:  Contains handling logic for messages issued from the platfrom directly to the hub
* arcus-os:  Handles direct OS level functionality for serial i/o and process monitoring
* arcus-reflex-controller:  Logic specific for device drivers that run directly on the hub
* arcus-router:  Logic and building blocks the hub uses for routing messages internally
* arcus-spy-controller:  Development only controller for diagnostics
* arcus-system:  Core agent functionality and building blocks managing startup/shutdown, database operations, configuration, addressing, etc.
* arcus-test-agent:  Subproject providing the ability to startup the agent in a system/integration test manner
* arcus-zw-controller:  Controller for integrating with ZWave devices

== Common ==

Shared code that may be shared by the platform and/or agent.  In particular, this is the home of a multitude of descriptors that are used to generate code such as capability or service descriptors that act as the primary APIs.

* arcus-billing:  Common billing infrastructure used by the platform and integration APIs for Recurly if and only if propery API keys are available
* arcus-client:  Common client for the platform used by the tools and the Android client
* arcus-common:  Suite of common utilities used throughout the platform
* arcus-drivers/drivers-commmon:  Shared set of functionality, interfaces and event definitions for drivers that may run in the platform or hub
* arcus-drivers/groovy-bindings:  The bindings that define the Groovy DSL used for writing device driver for the Arcus platform
* arcus-drivers/reflex-generator:  Tool used during assembly of the platform to generate the necessary reflex driver information to pass down to the hub allowing it to execute driver logic
* arcus-metrics:  Common API used to gather metrics across the platform and hub
* arcus-model:  Common descriptor beans for describing capabilites, services and types
* arcus-model/capability-generator:  Assembly time tool that generates Java bindings from the capability, service and type descriptors
* arcus-model/model-query:  Utilities used within the platform for querying a set of models where a model is essentially a map of attributes
* arcus-model/platform-client:  Combination of common classes and generated code providing clients the necessary APIs for interacting with devices and services
* arcus-model/platform-messages:  Combination of common class and generated code for APIs that are internal only to the platform
* arcus-protoc:  Tool used during assembly that generates protocol specific code for integration into the Groovy bindings
* arcus-protoco-runtime:  Interfaces that supported protocol must adhere to.  Concrete implementations are generated by the arcus-protoc
* arcus-protocol:  Protocol specific implementation for integration, much of which is generated via arcus-protoc during assembly time
* arcus-reflection:  Common shared utilities for Java reflection
* protocol-generator:  Another protocol to concrete implementation generator but specific to the IPCD protocol.

== Khakis ==

Set of core docker containers required to run the platform (kafka, cassandra, zookeeper and base java container)

== Platform ==

This contains common code used within platform as well as all containers that get deployed into production.

* arcus-alarm:  Common code shared between the subsystem that runs the alarm state machine and the alarm service that manages the tracking of an alarm incident
* arcus-alexa:  Common code shared between the bridge service for Alexa and the backing voice service that handles the incoming messages
* arcus-containers/alarm-service:  Microservice that manages the state of alarm incidents that the platform has detected
* arcus-containers/alexa-bridge:  Bridge service that handles incoming REST requests from Amazon Alexa, translation of them and placement on the bus
* arcus-containers/billing-callback-server:  RESTful endpoint that Recurly can hit for delinquent accounts if and only if a Recurly account key is available
* arcus-containers/client-bridge:  The primary entry point for web and mobile clients providing the web socket connection for messaging and RESTful APIs.  This is also responsible for placement of messages on the appropriate bus for handling by internal microservices.
* arcus-containers/driver-services:  Microservice that manages all device drivers and instances of them for handling incoming events or issuing control messages to end devices
* arcus-containers/google-bridge:  Bridge service that handles incoming REST requests from Google Home/Assistant, translation of them and placement on the bus
* arcus-containers/history-service:  Microservice responsible for consuming events and persisting history for each place and device
* arcus-containers/hub-bridge:  Entry point for hubs to connect to the platform via web sockets and placement of messages onto the appropriate bus
* arcus-containers/ipcd-bridge:  Entry point for IPCD devices to connect to the platform via web sockets and placement of messages onto the appropriate bus
* arcus-containers/ivr-callback-server:  RESTful endpoint that Twilio may hit if a Twilio account key is available and the IVR dialog requires consumer input
* arcus-containers/ivr-fallback-server:  RESTful endpoint that Twilio may hit if a Twilio account key is available and the ivr-callback-server is down
* arcus-containers/metrics-server:  Microservice that consumes metric information from each of containers, translates it and persists in a time-series format
* arcus-containers/notification-services:  Microservice that consumes specific messages emitted from other services that cause notifications to be sent via IVR, GCM, APNS or email
* arcus-containers/platform-services:  Set of core cluster-wide singleton services primarily for tracking hub/ipcd device online/offline state and creation of accounts
* arcus-containers/rule-service:  Microservice that runs the Arcus rule engine
* arcus-containers/scheduler-service:  Microservice that runs and enforcees any scheduling that end users have configured
* arcus-containers/subsystem-service:  Microservice that runs all primary business logic for the end users, including security/safety alarms, irrigation, lights & switches, doors and locks, etc.
* arcus-containers/tag-service:  Microservice that accepts tagged messages from web and mobile clients for tracking metrics around application usage
* arcus-containers/video-download-server:  HTTPs endpoint that allows users to download recording videos
* arcus-containers/video-preview-server:  HTTPs endpoint that allows users to fetch preview images from their cameras
* arcus-containers/video-preview-ul-server:  HTTPs endpoint for hubs to upload image snapshots from cameras
* arcus-containers/video-purge:  Schedulable background job that purges videos that have been deleted from physical storage
* arcus-containers/video-recording-server:  HTTPs endpoint where supported cameras can upload video for recording or live streaming
* arcus-containers/video-service:  Microservice that provides web and mobile clients information regarding recordings as well as orchestration of the recording flows
* arcus-containers/video-streaming-server:  HTTPs endpoint that playback clients interact with to retrieve HLS playlists for video playback
* arcus-containers/voice-service:  Common backend for Alexa/Google voice integrations.  This microservice handles messages coming from the alexa-bridge/google-bridge and issues response messages.
* arcus-google:  Common code shared between the bridge service for Google and the backing voice service that handles the incoming messages
* arcus-hubsession:  Code used by hub bridge for managing hub sessions
* arcus-info:  Common code used by Arcus applications providing infromation such as the version
* arcus-khakis:  Utilities for building/deploying docker containers for developers
* arcus-lib:  Primary library directory used for all things in the platform containing such common functionality as database access, message structures, application lifecycle, etc.
* arcus-log:  Common code used by Arcus applications that publishes log messages through the bus for consumption by a tool such as Kibana
* arcus-modelmanager:  Tool used during deployment and development to ensure that the database schema is installed into Cassandra correctly
* arcus-oauth:  Common code used by bridges that require a third party to go through an OAuth flow with the Arcus platform, such as Alexa or Google.
* arcus-platform-drivers:  Code used by the driver-service for execution of device drivers in the cloud
* arcus-prodcat:  Common infrastructure used by several services for access to an exposure to the product catalog
* arcus-rules:  Code used by the rule-service for representing rules and consuming the catalog of rules
* arcus-security:  Common code used by bridges for authenticating and authorizing users
* arcus-subsystems:  Code sued by the subsystem-service for executing several of the subsystems, such as irrigation
* arcus-test:  Common set of base test cases classes
* arcus-video:  Common video infrastructure code such as database access used by all video services
* arcus-voice-bridge:  Common infrastructure used by bridges that service a voice service, such as Alexa or Google
* bridge-common:  Common code and building blocks for all bridges within the platform.  In particular, wiring up Netty and applying security policies.
* ipcd-common:  Common code used for managing IPCD devices

== Tools ==

A set of tools that will be useful for others trying to develop against Arcus.

* arcus-captools:  A set of tools that generate code bindings based on the Arcus capability and service descriptors (for ex. to generate swift or Objective-C bindings)
* eye-kat:  A tool that allows streaming and monitoring a kafka bus
* oculus:  Rough UI for interacting with the Arcus platform during development

== Others ==

* gradle:  Common build scripts used by all projects
* libs:  Common shared libraries that are not published on Maven Central or Jcenter

About

No description, website, or topics provided.

Resources

License

Apache-2.0, Apache-2.0 licenses found

Licenses found

Apache-2.0
LICENSE
Apache-2.0
LICENSE.txt

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Java 87.1%
  • Gherkin 10.6%
  • HTML 1.6%
  • Groovy 0.3%
  • Shell 0.3%
  • Smarty 0.1%