https://preview.redd.it/94vzow1p1rhh1.png?width=2233&format=png&auto=webp&s=69971a0119fa5413fa82eb13501d6e3f77259d3c

Over the last few weeks we have been working on a problem that appears in many distributed edge systems:

How can independent edge agents cooperate without building a custom integration for every possible combination of devices?

A typical architecture today looks like this:

Camera -> Cloud Server -> Dashboard -> Operator

or:

Camera -> VMS -> Alarm System -> Security Room

The problem is that every new device or workflow requires another integration layer.

With the new inter-agent communication feature in Banalytics, agents can now exchange events and actions directly through dynamically configured P2P channels.

The signaling service is only used for discovering peers and establishing the connection. The actual communication happens directly between agents using WebRTC DataChannels.

Example: remote site monitoring

Imagine a remote facility:

• Agent A is installed at a remote location with IP cameras.
• Agent B is installed in the security room with local speakers.
• A human operator cannot watch multiple screens continuously.
• When something important happens, the operator needs an immediate local alert.

Instead of streaming everything to a central server, we can configure the agents to exchange only meaningful events.

Example configuration on the management panel:

(1) A video stream classifier detects objects or events and generates an event with detected classes.
(2) The Event Manager intercepts this event and forwards it through a configured P2P communication channel to another agent.
(3) Using WebRTC, the event is delivered directly to the security room agent.
(4) The event appears on the local event bus, where another Event Manager processes it and triggers playback (5) through the local audio system.

The event history is stored separately using a dedicated event logging rule.

The goal is to make edge systems more adaptive:

• fewer hardcoded integrations;
• less dependence on central infrastructure;
• faster deployment of new workflows;
• autonomous cooperation between physical systems.

We are experimenting with this approach and would be interested in feedback from people working with:

• robotics;
• industrial automation;
• security systems;
• IoT platforms;
• distributed edge computing.

What are the biggest blockers you see for P2P agent architectures in real-world deployments?

Guys, what do you think about "Embodied Agent" Mesh Networks?

The idea of a P2P network where humans, autonomous robots and another agents can act as independent nodes interacting with the real world. Is this something we will see in the next 7 years, or is it still too early a concept?

Would be interesting to hear from those who have already experimented with similar architectures and learned some lessons along the way.

Guys, what do you think about "Embodied Agent" Mesh Networks?

The idea of a P2P network where humans, autonomous robots and another agents can act as independent nodes interacting with the real world. Is this something we will see in the next 7 years, or is it still too early a concept?

Would be interesting to hear from those who have already experimented with similar architectures and learned some lessons along the way.

I keep seeing this when moving embedded or edge projects from lab to pilot.

The C or Python code works. The sensor works. Then the system goes to a real site and suddenly the hard part is not the algorithm anymore.

You need to know if a device went offline, data is stale, a queue is growing, storage is full and what should restart automatically. Also, raw video or waveform data often cannot just be pushed to the cloud.

My current approach is to keep the processing module independent and put an orchestration layer around it for monitoring, buffering, local storage, events, alerts and remote access.

I’m still trying to find the right boundary between application logic and operations. Curious how others handle this in embedded deployments.

https://preview.redd.it/ukm4vuygieeh1.png?width=1672&format=png&auto=webp&s=de977b3e5015f3a521d21bd7661077de2c3ecc40

Banalytics and ROS are not substitutes for one another. ROS helps engineers build the software that perceives, plans, navigates, and controls a robot. Banalytics helps teams operate the wider physical environment around that robot: connected infrastructure, events, evidence, device health, dashboards, remote diagnostics, and governed integration with enterprise systems.

// Different layers of the system

ROS runs robotics applications; Banalytics operates the edge boundary around them

ROS and ROS 2 provide a middleware and software ecosystem for robotic applications. A robotics team can use nodes, topics, services, actions, packages, sensor drivers, perception pipelines, navigation stacks, and simulation tools to create the behaviour of a robot. That is the right abstraction for the robot’s internal software system.

Banalytics is a local-first edge orchestration and monitoring platform for cameras, sensors, devices, and physical operations. Its Agent runs on owner-selected Windows, Linux x86_64, or Linux ARM64 hardware. It connects approved resources, runs local tasks, retains configured data, creates events and actions, provides dashboards and System Monitor, and exposes selected outcomes through MQTT, APIs, files, or other controlled integrations.

The distinction matters in production. A robot can navigate successfully while the surrounding operation still lacks a dependable way to see fleet health, share an approved mission result with a warehouse system, retain inspection evidence, diagnose a remote device, or operate multiple sites with limited support staff. Conversely, an edge operations platform should not claim responsibility for the robot’s perception, motion planning, or safety-critical control loop.

// Comparison

Compare the operating responsibility, not the technology label

Concern	ROS / ROS 2	Banalytics
Primary role	Build and run robotics applications and communication between their software components.	Orchestrate and observe edge operations around physical devices, processes, and integrations.
Robot behaviour	Perception, localisation, navigation, planning, manipulation, control, and robot-specific application logic.	Consumes only the selected robot state or result needed for the wider operational workflow.
Device and infrastructure boundary	Use robot and application drivers, packages, and application-defined interfaces.	Connect cameras, sensors, Modbus equipment, MQTT devices, files, services, and custom processes; manage local events and state.
Operational data lifecycle	Application-specific logging and data handling defined by the robotics team.	Configured local storage, event history, dashboards, health monitoring, retention, and controlled external delivery.
Enterprise and multi-site integration	Implemented by the robotics application or a separate integration service.	Explicit MQTT, API, file, database, dashboard, remote-access, and multi-Agent operating boundaries.
Safety and movement authority	May participate in the robot software architecture, subject to the project’s safety design.	Does not replace robot controllers, emergency stop, safety PLCs, certified safeguards, or accountable operating procedures.

Neither column is inherently more general or more complete. A ROS deployment can be the right local runtime for a robot, while Banalytics can be the right operational layer for the robot’s environment and the systems that need selected results from it.

// Combined architecture

Use an explicit bridge between the robot and edge operations

A practical combined deployment keeps ROS on the robot or its companion computer, where it handles robot-specific nodes and local control. Banalytics can run on the same host when the resource and deployment model permit it, or on a separate nearby edge node. A project-specific bridge or sidecar translates only the ROS topics, services, actions, or application outputs that the wider operation needs into a defined interface.

Boundary	What crosses it	What should not be assumed
ROS to bridge	Selected robot telemetry, position, mission state, battery or platform health, detection result, error, or inspection observation.	That every ROS topic should be exported, retained, or visible to every enterprise user.
Bridge to Banalytics	A documented MQTT, API, ZeroMQ, file, or other agreed payload with source time, schema, quality, and version information.	That Banalytics has native access to ROS interfaces without a deliberately supplied bridge or integration component.
Banalytics to operations	Contextual event, dashboard state, evidence reference, maintenance signal, selected alert, or integration package.	That a fleet, WMS, TMS, or control system has changed its system-of-record or safety responsibilities.

The bridge should be treated as a first-class project component. Define its schema, source timestamps, rate, authentication, failure behaviour, version, and owner. For local message exchange, ZeroMQ Socket can provide an explicit low-latency contract; for publish/subscribe delivery, the embedded MQTT Server provides a local broker boundary. The appropriate choice depends on the required contract, not on a generic preference for one protocol.

// Four practical use cases

Where the combined pattern adds operational value

Scenario	ROS responsibility	Banalytics responsibility
AMR or AGV in a warehouse	Navigation, localisation, sensor fusion, route execution, and robot-side application logic.	Connect the robot’s approved state to dock, conveyor, facility, or WMS/TMS workflows; create maintenance and operational events; expose health and local evidence.
Drone or inspection robot	Mission logic, perception, platform state, navigation, and payload control.	Route selected inspection observations, latest reported position, mission context, and device health to authorised dashboards and maintenance or infrastructure systems.
University research prototype at an enterprise site	Research package, perception or control experiment, and model iteration on the companion computer.	Provide the operational shell for local devices, data collection, shadow-mode validation, health monitoring, access control, events, and selected enterprise delivery.
Multi-site robotic estate	Local robotics runtime and behaviour of each robot or robot class.	Repeatable site patterns, remote diagnostics, governed dashboards, selected multi-site visibility, and explicit integration boundaries for each operating location.

These scenarios link robotics to the same physical-operation concerns described in Logistics Edge Computing, Transportation Edge, and Modernizing Infrastructure with Banalytics.

// From prototype to operation

Promote a robotics prototype through a controlled operating path

1. Define the local outcome. Choose a bounded mission, inspection, material-handling, or maintenance question with a named operational owner.
2. Specify the bridge contract. Agree which ROS/application outputs cross the boundary, their schemas, timestamps, quality fields, retention, recipients, and security controls.
3. Run in shadow mode. Observe the robot’s selected outputs and their operational context without allowing the bridge to trigger high-consequence action.
4. Validate the human workflow. Confirm that maintenance, warehouse, facilities, or research users can interpret the event, reach the evidence, and provide feedback.
5. Make lifecycle ownership explicit. Version the ROS package, bridge, Banalytics configuration, and payload contract; define update, rollback, support, and incident procedures.
6. Expand only after the boundary is supportable. Replicate a proven robot/site pattern with documented deviations for each platform, network, facility, and safety regime.

The broader enterprise-university pattern is covered in From University Research to Enterprise Edge Operations. It applies equally when the research module is a ROS package, a Python service, a native pipeline, or another specialist edge workload.

// Operations and safety

Keep operational observability separate from safety authority

Banalytics Event Manager can evaluate configured events and invoke preconfigured actions such as a notification, retained record, selected MQTT publication, or approved integration call. An event should retain its source, time, robot or site identity, state, quality, severity, evidence reference, and expected response owner. See Event Manager for the local rule-and-action model.

Banalytics System Monitor monitors CPU, memory, disk, thread, media, WebRTC, and user-activity state. Pair this with robot-side health outputs so a support team can distinguish a ROS/application error, stale bridge message, constrained companion computer, full edge disk, unavailable camera, or blocked enterprise consumer.

None of these integrations should override the robot’s independently engineered emergency stop, collision avoidance, hardware protection, controller safety logic, or accountable human operating procedure. The Banalytics layer can make the surrounding operation visible and actionable; it does not acquire movement or safety authority through the bridge.

// Selection guide

Use both when the robot must become part of a wider operation

• Use ROS or ROS 2 when the primary task is building and running the robot’s software behaviour.
• Use Banalytics when the project needs local device integration, events, evidence, dashboards, runtime health, controlled remote access, or enterprise integration around the robot.
• Use an explicit bridge when selected ROS/application results need to become operational information for another team or system.
• Keep the bridge narrow, versioned, observable, and owned; export the useful result, not every internal robotics message.
• Keep safety, movement, and high-consequence authority with the designated robot and control systems.

The most effective comparison is therefore not Banalytics or ROS. It is a clear division of responsibility: ROS builds the robot’s intelligence; Banalytics makes the robot’s contribution to the wider physical operation supportable, observable, and governable.

// Definition

What an edge orchestration platform is

An edge orchestration platform coordinates the operational work around physical data sources. It discovers or connects devices, maintains communications, runs local tasks, records the data that must remain on site, evaluates events, and routes the resulting decisions to people and other systems.

This is a different problem from deploying a container, managing a cloud account, or installing a single camera application. The difficult part of an edge system is the boundary between hardware and operations: devices go offline, networks are intermittent, storage fills up, a detector needs to restart, and an event must still reach the right consumer with useful context. The orchestration layer owns those concerns so that domain-specific logic can remain focused on the signal, model, or business rule it was built to solve.

Banalytics implements this layer for cameras, sensors, and physical systems. A local Banalytics Agent runs on equipment owned by the operator; the browser console provides remote administration and visibility without moving raw recordings or measurement data into a mandatory cloud archive. For a platform overview, see What is Banalytics?.

// Reference architecture

Keep acquisition and intelligence separate from operations

A robust design separates the acquisition path, the domain processing module, and the operating layer. Cameras, DAQ hardware, Modbus devices, and MQTT sensors produce raw streams and measurements at the edge. A purpose-built algorithm may analyse those inputs. The orchestration platform then turns structured results into state, dashboards, retained history, notifications, and machine-to-machine messages.

Banalytics can operate on both sides of a domain processing module: it manages acquisition and delivery of raw data, then converts structured results into operational outputs.

In an industrial sensing deployment, for example, the processing module may perform acoustic analysis, image processing, fusion, or confidence scoring. Banalytics handles the surrounding system: connectivity, buffering, local storage, lifecycle, rules, dashboards, MQTT publication, and remote operator access. The detailed pattern is documented in How Banalytics Works for Industrial Sensing.

// Operating model

From a device event to an operational decision

Layer	Responsibility	Typical Banalytics capability
Device connectivity	Reach equipment through appropriate local protocols and recover from normal communication failures.	ONVIF, RTSP, USB, Modbus RTU/TCP, MQTT, ZeroMQ, network discovery, and agent connectors.
Local execution	Run acquisition, detection, recording, and control tasks where the equipment and data reside.	Components, tasks, local file storage, configurable restart behaviour, and custom Java/CMD/Process extensions.
Event orchestration	Evaluate state changes and initiate the correct response.	Event Manager rules, filtering, calendars, action groups, notifications, MQTT publishing, device commands, and task lifecycle actions.
Operational visibility	Present health, events, recordings, dashboards, and configuration to authorised users.	Browser console, agent-owned dashboards, event history, access controls, P2P/WebRTC remote sessions, and System Monitor.
External integration	Expose only the events, metadata, and data packages that downstream systems require.	MQTT, APIs, file-based handoff, databases, ZeroMQ, and controlled custom integrations.

The value of this model is not that every deployment uses every integration. It is that a camera-only installation, an instrumented production line, and a distributed AI data-collection project can use the same operational vocabulary: source, task, event, rule, action, storage, and health.

// Modularity and lifecycle

Orchestration must include change management

Edge installations are not static. Hardware changes, protocol adapters are introduced, models are updated, and sites develop independently. A platform therefore needs a predictable way to add capability, inspect its version, apply an update, and roll back when a change is unsuitable for production.

Banalytics packages capability into independently versioned modules. The local agent performs the work; the portal is used to inspect servers and select installed module versions. This design keeps a deployment lean while allowing a site to add media, ONVIF, dashboard, AI, or other capabilities as its scope grows. The module catalogue and upgrade model are documented in Banalytics Modules and Version and Module Management.

Capability is managed as modules rather than as a monolithic edge image. Version selection and change control remain visible to the operator.

At runtime, the model is deliberately explicit: components represent connected resources; tasks perform work on their data; events carry state changes; and actions express the response. This makes it possible to review a system as an operating design rather than as a collection of independent scripts.

// Local resilience

Local-first is an operational property, not a storage preference

Physical systems continue to produce data when the upstream network is slow or unavailable. An edge platform must therefore preserve the local acquisition and response path. Banalytics agents run independently at each location: data processing, recording, detection, and local rules take place on the host near the devices. The remote console is a management and visibility layer, not the place where a camera stream or a sensor signal must first be processed.

Local resilience also depends on observing the node itself. The System Monitor publishes CPU load, memory use, disk capacity, thread counters, WebRTC buffers, and media-stream activity as events that can be displayed, recorded, or used to trigger rules. This allows an operator to act before a full disk, resource exhaustion, or an overloaded stream turns into data loss.

For multi-site environments, each site keeps its local boundary while authorised users obtain a single browser view of the participating agents. The relevant architecture and connection model are described in Portal Integration and Agent Connector.

// Selection criteria

When an orchestration platform is the right abstraction

• Mixed devices share an operational outcome. Cameras, sensors, and controllers must contribute to the same event or operator workflow.
• Raw data should remain local. The system needs local recording, buffering, or a controlled export boundary rather than continuous cloud transfer.
• Domain logic already exists. A team has a Python, C++, CUDA, PLC gateway, or other specialist component and needs the surrounding operational layer rather than a replacement for its algorithm.
• Sites must be independent but visible together. Each location requires local autonomy while a central team needs consistent health, configuration, and event visibility.
• Automation must be accountable. Actions need to be expressed as rules, logged as events, and linked to the system state that caused them.

Banalytics is not intended to replace a general-purpose container scheduler, a complete enterprise PSIM, or every vertical protocol gateway. It is most effective as the edge operating layer around connected physical systems: close enough to hardware to act reliably, but structured enough to integrate with the broader estate.

// Implementation sequence

Start with an operational contract

1. Define the equipment boundary. List the devices, protocols, local storage requirement, expected data rates, and who owns each connection.
2. Define the event contract. Specify which conditions produce an event, the required metadata, severity, retention, and the consumers that need it.
3. Place processing deliberately. Keep acquisition and safety-critical response local; place training, long-term aggregation, or enterprise workflows where their latency and data-governance requirements allow.
4. Design recovery before scale-out. Decide how tasks restart, what happens when storage is constrained, and how a site reports degraded health.
5. Prove one representative path. Validate an end-to-end sequence from device input through event and action to the operator or downstream system, then replicate that pattern.

This approach avoids a common failure mode in edge projects: building an impressive data path that cannot be operated safely once it leaves the lab.

Banalytics is an innovative edge orchestration platform designed to seamlessly connect, monitor, and automate the physical world. It provides a robust, edge-first operational layer for diverse cameras, sensors, and physical systems, emphasizing local-first processing, vendor independence, and automation readiness. This platform targets a broad audience, including industrial researchers, SMB owners, AI data teams, and technically capable individuals managing home monitoring systems.

Key Features

• Universal Device Integration: Connects IP cameras, ONVIF, RTSP, USB devices, DAQ systems, and various sensors, supporting mixed brands and protocols like Modbus and MQTT.
• Local-First Storage: Ensures recordings and raw data remain on your hardware (NAS, local disk, edge node), eliminating forced cloud dependencies.
• Event-Based Workflows: Allows definition of triggers, filters, and automations, routing events to MQTT, APIs, Telegram, or external systems for selective capture.
• Browser-Based Remote Access: Provides live feeds, dashboards, event history, and system health visibility through any web browser.
• Actionable Alerts: Delivers Telegram notifications with video context, enabling users to understand and act on events directly.
• Vendor-Independent: Offers freedom from lock-in to specific camera brands, cloud platforms, or ecosystems, allowing flexible infrastructure evolution.

Use Cases

Banalytics is purpose-built for diverse scenarios. For Industrial Sensing, it empowers researchers and technical founders to deploy high-bandwidth measurement pipelines, making complex systems observable without extensive rebuilding. SMB Operations benefit by unifying mixed-brand cameras across multiple locations into a single view with actionable alerts, ideal for retail and multi-site businesses. AI Data Teams leverage Banalytics to overcome the bottleneck of reliable field data collection, transforming physical infrastructure into structured data pipelines for model training. Lastly, Makers & Homelabs can achieve local-first, vendor-independent home monitoring, integrating with Home Assistant, MQTT, and NAS setups to avoid cloud lock-in.

User Experience and Support

The platform prioritizes ease of use with browser-based remote access, allowing users to view live feeds, dashboards, and system health from anywhere without installing heavy client software. Banalytics provides comprehensive documentation and downloads for various hardware environments, including Windows and Linux (x86_64/ARM). A community forum and direct contact options for booking demos or architecture-fit sessions ensure users have access to support and guidance.

Technical Details

Banalytics is designed for edge-first deployment, running on existing hardware such as Windows 10/11 64-bit, Linux (x86_64/ARM), Raspberry Pi, industrial PCs, and mini servers. It supports a wide array of field devices and protocols, including IP cameras, ONVIF, RTSP, USB, DAQ, sensors, Modbus, and MQTT. The modular architecture ensures that users' processing code, intellectual property, and hardware remain theirs, with Banalytics providing the operational infrastructure around devices and data, keeping raw data local and processing user-controlled.

Linux or Windows

Raspbery PI 4 & Modbus Ethernet

N97 & Arduino

D3.js integrated into Banalytics as a programmable chart component.

Instead of being limited to predefined chart types, each component uses its own JavaScript file. The script controls data loading, conversion, event processing, and rendering with D3.js.

1. Script tab

https://preview.redd.it/udkuh6als6dh1.png?width=1838&format=png&auto=webp&s=009b75fbd4286a97f7aeb30657c0094c53f32d83

The built-in editor lets you modify the chart directly from the portal. The script is stored on the agent and can define:

• poll() to load data through the agent API;
• convert() to normalize the incoming payload;
• render() to create or update the visualization;
• onEvent() to process real-time events;
• init() and destroy() for lifecycle management.

Changes are autosaved and applied to the chart without manually deploying frontend files.

2. Chart tab

https://preview.redd.it/n65sh1zaw6dh1.png?width=1629&format=png&auto=webp&s=0f8afc72764fe87336a7f24bb7f39097e0af11c1

The default template displays CPU and memory utilization reported by the Banalytics System Monitor. It uses D3.js to draw a responsive gauge with two needles and configurable utilization zones.

The template is only a starting point - you can replace it with line charts, timelines, bar charts, topology views, maps, hierarchies, or another visualization supported by D3.js.

The component supports several data delivery strategies:

• one-time loading;
• periodic polling;
• real-time events;
• one-time loading of historical data followed by live events.

The last strategy is useful for timelines: the chart loads existing records from storage once and then extends the same dataset as new events arrive.

3. Component on a dashboard

https://preview.redd.it/z80nn33lw6dh1.png?width=1629&format=png&auto=webp&s=1000c20f3c6cc6d428a321532efc35b0148a12e7

The resulting chart can be placed on a Banalytics dashboard alongside cameras, controls, maps, device states, and other components.

Rendering happens in the browser, while data can come from Things running on the agent through the authenticated environment channel. Chart scripts can also maintain browser-specific state such as filters, selected ranges, or presentation preferences.

The documentation includes configuration details, the script contract, Remote API methods, event subscriptions, and examples based on the packaged chart-template.js:

https://banalytics.live/kb/d3js/

D3.js project:

https://d3js.org/

Disclosure: I’m the developer of Banalytics and would appreciate feedback, particularly on the script API and the historical-data-plus-live-events workflow.

https://preview.redd.it/owi8hh82m0dh1.png?width=1080&format=png&auto=webp&s=795c684017ff54a2744c268e2f028189b722d4eb

Google Home, Alexa and similar platforms are great for everyday automation: switching lights, adjusting thermostats, viewing cameras and controlling devices by voice.

For many people, that is enough. But as a smart home grows, several limitations can appear:

• Devices from different vendors do not always work well together.
• Cloud-dependent automations may stop when the Internet or an external service is unavailable.
• Camera footage and sensor data may need to remain local.
• Standard routines cannot express more complex conditions.
• Users may want to connect relays, GPIO, Modbus equipment or custom sensors.

This is where Banalytics can complement an existing smart-home platform rather than replace it.

Google Home can remain the convenient everyday interface, while Banalytics handles local processing, monitoring, storage and advanced automation.

Local cameras and video processing

Banalytics can process camera streams and store recordings locally:

• ONVIF Camera connects compatible network cameras.
• Motion Detection generates events when movement is detected.
• Continuous Recording records selected streams locally.
• Motion Recording records only when activity occurs.
• YOLO Detection adds local object detection to camera workflows.

For example, a camera event can trigger local recording and send a notification without uploading the video to a general-purpose cloud platform.

Local media playback through DLNA

Banalytics can make locally stored recordings and media available to televisions, media players and other devices on the home network:

• DLNA Server publishes selected media through the standard DLNA/UPnP protocol.
• File Storage manages recordings and media files.
• File Media Stream provides access to previously recorded media inside Banalytics.

This allows locally recorded video to be viewed on compatible smart TVs and media players without uploading it to cloud storage.

It is particularly useful when the home already has a NAS, media center or television with built-in DLNA support.

Connecting smart-home ecosystems

Banalytics does not need to replace Google Home or Home Assistant. It can exchange events and commands with other systems through MQTT:

• MQTT Server provides a local broker.
• MQTT v3 Connector and MQTT v5 Connector connect to an existing broker.
• MQTT Topic Listener converts incoming messages into Banalytics events.
• MQTT Publish Action sends commands or state updates to other platforms.

This makes MQTT an integration layer between consumer smart-home products and more advanced local automation.

Raspberry Pi and DIY hardware

For users adding custom electronics:

• Pi4J GPIO manages Raspberry Pi digital inputs, outputs and PWM pins.
• PCA9685 PWM Controller controls up to 16 PWM channels over I2C.
• Pi4J Set Digital Output switches configured GPIO outputs.
• Pi4J Set PWM controls servos, dimmers or external driver inputs.

These components can connect buttons, contacts, indicators, isolated relays and other DIY hardware to the same event system used by cameras and network services.

Industrial and wired devices

Banalytics can connect equipment that typical consumer ecosystems do not support:

• Modbus Device connects directly to a serial Modbus device.
• Modbus Line manages multiple devices on a shared RTU or TCP line.
• Modbus Set Coils Action controls digital outputs.
• Modbus Set Register Action writes device registers.

This is useful for energy meters, relay boards, environmental sensors, pumps, gates and other equipment outside the usual smart-home catalog.

Advanced local automation

The Event Manager connects all these components.

A rule can combine a camera event, sensor state, schedule or MQTT message with actions such as:

• Send Mail Message
• Telegram Bot
• Command Action
• SQL Action
• JMS Send Action

The result is closer to a local automation engine than a collection of isolated smart-device routines.

Monitoring everything in one place

Banalytics provides customizable dashboards for cameras, sensors, events and controls.

A dashboard can combine information from several components or locations. Available providers include fixed 2D layouts, 3D scenes, SVG diagrams, Cesium, Mapbox and OpenStreetMap.

This can be useful when consumer applications show each device separately but do not provide a complete operational view.

When should an ordinary user consider it?

Banalytics becomes useful when:

1. Your home contains devices from several incompatible ecosystems.
2. Important automations should continue without cloud access.
3. You want camera footage and telemetry to remain local.
4. Standard “if this, then that” routines are no longer enough.
5. You already have a Raspberry Pi, NAS, mini-PC or home server.
6. You want to connect cameras, custom sensors or wired equipment.
7. You want to watch locally recorded media on DLNA-compatible devices.
8. You need one dashboard for several systems or locations.

Banalytics is not intended to make a single smart bulb easier to use.

It becomes valuable when a smart home starts turning into infrastructure - something that should be observable, customizable and capable of operating locally.

A practical introduction is available in How Banalytics works for Makers and Homelabs.

Full documentation: https://banalytics.live/kb/index/

Someone asked a week ago about digital twins with real-time telemetry. With Three JS, it's as simple as CAD -> Blender -> GLB -> Three JS.

https://preview.redd.it/szja2ix34h1h1.png?width=1280&format=png&auto=webp&s=52bf564fe9b4c6561f00914e7888bf4593689856

https://preview.redd.it/klrz0pi44h1h1.png?width=1280&format=png&auto=webp&s=444c452ff1f4344677b5b30bd0f612e240c23b38