@Joe I'd live to be part of that conversation

Great, thanks

There is no “data plane” in Open Horizon; outside of the “edge sync service” — I am confused. If you want to connect to a device from “outside” you will need to have the device reach out from “inside” and establish a reverse-connection ala Kaazing

@DCM Absolutely yes. And let’s make sure I don’t color outside the lines here. I am assuming control plane data and telemetry.

BRB

github.com/dcmartin/open-horizon includes some existing services to process signal data using MQTT; I also have a Kuiper example to consume that MQTT traffic and process it for output (e.g. summary)

For example a license plate reader AI: https://github.com/dcmartin/open-horizon/tree/master/services/alpr4motion

@david looks interesting thanks for sharing the link

Feeds into github.com/motion-ai/motion-ai

@JoePearson “telemetry” is a suitcase word :-)

@Brad and motion-ai feeds into age-at-home.com

@David think heartbeat, status, performance, configuration, and so on. Typically anything that would go into a service log.

@Joe currently agent sends base information to exchange (e.g. heartbeat); application-specific data about state (or logging) is a bridge too far, IMHO, for initial exercise since logging to a big bite; I currently utilize Kafka to send data from device to cloud with all credentials etc transmitted via edge sync service with the application polling for new sync data

The data transmitted by the application via Kafka is based upon a SDK I developed which when utilized captures all the relevant data for external analysis of success (e.g. Docker info directly from Docker daemon, not what agent reports to exchange, which is one thing I validate to determine malfunction)

My `startup` service contains the Docker inspection and requires my `Hal` (hardware abstraction layer), `wan` (IP information), and `cpu` for system resource consumption