Skip to main content

2-N-2 high-performance protocol stack

Project description

OpenSynaptic

2-N-2 high-performance IoT protocol stack โ€” standardises sensor readings into UCUM units, compresses them via Base62 encoding, wraps them in a binary packet, and dispatches over pluggable transporters (TCP / UDP / UART / LoRa / MQTT / CAN).

๐Ÿ“š Documentation Hub

๐ŸŒ All documentation has been moved to our comprehensive Wiki. Choose your language and start exploring:

English Documentation

ไธญๆ–‡ๆ–‡ๆกฃ

Python Windows Linux macOS Architecture Core Backend Transport License Tests CI Coverage Rust UCUM IoT

Try In 30 Seconds

pip install -e .
os-node demo --open-browser

Windows (no Activate.ps1 required):

.\run-main.cmd demo --open-browser
  • Default user config path: ~/.config/opensynaptic/Config.json
  • First run launches onboarding wizard (--yes / --no-wizard supported)

CLI Completion (Tab)

py -3 -m pip install argcomplete
powershell -ExecutionPolicy Bypass -File .\scripts\enable_argcomplete.ps1

Manual (without script):

Invoke-Expression (register-python-argcomplete os-node --shell powershell)

Restart PowerShell after activation.

OpenSynaptic Demo Quickstart


Table of Contents


Architecture

%%{init: {'flowchart': {'rankSeparation': 60, 'nodeSeparation': 50}}}%%
graph LR
    A["Sensors List"] -->|Raw Data| B["Standardizer<br/>(UCUM Normalisation)"]
    B -->|Standardised| C["Compressor<br/>(Base62 Encoding)"]
    C -->|Compressed| D["Fusion Engine<br/>(FULL/DIFF Packet)"]
    D -->|Binary Packet| E["Dispatcher<br/>(TCP/UDP/LoRa/MQTT/CAN)"]
    E -->|Transmitted| F["Remote Node"]
    
    style A fill:#e1f5ff
    style B fill:#fff3e0
    style C fill:#f3e5f5
    style D fill:#e8f5e9
    style E fill:#fce4ec
    style F fill:#e0f2f1

Pipeline Overview (Text):

sensors list
    โ†’ OpenSynapticStandardizer.standardize()   # UCUM normalisation
    โ†’ OpenSynapticEngine.compress()            # Base62 solidity compression
    โ†’ OSVisualFusionEngine.run_engine()        # binary packet (FULL / DIFF strategy)
    โ†’ OpenSynaptic.dispatch(medium="UDP")      # physical send via transporter
src/opensynaptic/
โ”œโ”€โ”€ core/
โ”‚   โ”œโ”€โ”€ __init__.py             # Public core facade + active backend loader
โ”‚   โ”œโ”€โ”€ pycore/
โ”‚   โ”‚   โ”œโ”€โ”€ core.py             # Orchestrator โ€“ OpenSynaptic class
โ”‚   โ”‚   โ”œโ”€โ”€ standardization.py  # UCUM normalisation
โ”‚   โ”‚   โ”œโ”€โ”€ solidity.py         # Base62 compress / decompress
โ”‚   โ”‚   โ”œโ”€โ”€ unified_parser.py   # Binary packet encode/decode, template learning
โ”‚   โ”‚   โ”œโ”€โ”€ handshake.py        # CMD byte dispatch, device ID negotiation
โ”‚   โ”‚   โ””โ”€โ”€ transporter_manager.py # Auto-discovers pluggable transporters
โ”‚   โ”œโ”€โ”€ rscore/                 # Rust core backend + build/check helpers
โ”‚   โ”œโ”€โ”€ transport_layer/        # L4 protocol managers and protocols/
โ”‚   โ”œโ”€โ”€ physical_layer/         # PHY protocol managers and protocols/
โ”‚   โ”œโ”€โ”€ layered_protocol_manager.py # 3-layer protocol orchestration
โ”‚   โ”œโ”€โ”€ coremanager.py          # Core selection/runtime manager
โ”‚   โ””โ”€โ”€ loader.py               # Core/plugin loader
โ”œโ”€โ”€ services/
โ”‚   โ”œโ”€โ”€ service_manager.py      # Plugin mount / load / dispatch hub
โ”‚   โ”œโ”€โ”€ plugin_registry.py      # Built-in plugin mapping + config default sync
โ”‚   โ”œโ”€โ”€ tui/                    # Terminal UI service (section-aware, interactive)
โ”‚   โ”œโ”€โ”€ web_user/               # Lightweight web UI + user management API
โ”‚   โ”œโ”€โ”€ dependency_manager/     # Dependency check/repair/install plugin
โ”‚   โ”œโ”€โ”€ env_guard/              # Environment guard service
โ”‚   โ”œโ”€โ”€ transporters/           # Application-layer transporter service
โ”‚   โ”œโ”€โ”€ db_engine/              # Database integration service
โ”‚   โ””โ”€โ”€ test_plugin/            # Built-in component & stress test suite
โ”œโ”€โ”€ utils/
โ”‚   โ”œโ”€โ”€ constants.py            # LogMsg enum, MESSAGES, CLI_HELP_TABLE
โ”‚   โ”œโ”€โ”€ logger.py               # os_log singleton
โ”‚   โ”œโ”€โ”€ paths.py                # OSContext, read_json, write_json, get_registry_path
โ”‚   โ”œโ”€โ”€ base62/                 # Base62 codec bindings/utilities
โ”‚   โ”œโ”€โ”€ security/               # crc/xor/session-key helpers
โ”‚   โ””โ”€โ”€ c/                      # Native loader/build helpers
โ”œโ”€โ”€ CLI/
โ”‚   โ””โ”€โ”€ app.py                  # Argparse CLI (os-node entrypoint)
plugins/
โ””โ”€โ”€ id_allocator.py             # uint32 ID pool, persisted to data/id_allocation.json
libraries/
โ””โ”€โ”€ Units/                      # UCUM unit definition JSON files
scripts/
โ”œโ”€โ”€ integration_test.py
โ”œโ”€โ”€ udp_receive_test.py
โ”œโ”€โ”€ audit_driver_capabilities.py
โ”œโ”€โ”€ services_smoke_check.py
โ””โ”€โ”€ cli_exhaustive_check.py
Config.json                     # Single source of truth for all runtime settings

Prerequisites

  • Python 3.11+
  • Optional: mysql-connector-python, psycopg[binary], aioquic (see pyproject.toml)

Install

pip install -e .

Windows PowerShell Startup Note

If you see this error when activating a virtual environment:

Activate.ps1 cannot be loaded because running scripts is disabled on this system.

Use the project wrappers and run without activation:

.\scripts\venv-python.cmd -m pip install -e .
.\scripts\venv-python.cmd -m pytest tests/unit tests/integration -q
.\scripts\venv-python.cmd -u src/main.py --help
.\run-main.cmd --help

If you need activation in the current shell only:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
& ".\.venv\Scripts\Activate.ps1"

First-Run Native Auto Repair

On first run, OpenSynaptic now auto-attempts native C binding repair if required runtime libraries are missing.

  • Trigger point: first run startup preflight and node initialization failure fallback.
  • What it does: runs the same native build pipeline as native-build, then retries node startup once.
  • If compiler/toolchain is missing, it returns structured guidance and records environment hints through env_guard.

Disable this behavior only when needed:

$env:OPENSYNAPTIC_AUTO_NATIVE_REPAIR = "0"

Why OpenSynaptic?

OpenSynaptic is not a replacement for MQTT or CoAP โ€” it solves a different problem. While MQTT/CoAP handle transport, OpenSynaptic focuses on what you do with sensor data before it hits the wire.

The Real Problem

When you deploy IoT sensors from different vendors, you face three universal headaches:

Problem Example
Unit chaos Sensor A sends "pressure": 101.3, "unit": "kPa", Sensor B sends "p": 14.7, "u": "psi"
Verbose encoding {"sensor_id": "temp_01", "value": 23.5, "unit": "celsius"} โ†’ 62 bytes for 4 bytes of data
Transport fragmentation Need TCP for reliability, UDP for speed, LoRa for range, CAN for automotive โ€” five different codebases

What OpenSynaptic Does Differently

Layer Traditional Approach OpenSynaptic
Semantic normalization Application code โœ… Built-in UCUM
Payload compression Optional library (zlib/lz4) โœ… Built-in Base62 + DIFF (60โ€“80% reduction vs. JSON)
Transport abstraction Rewrite per medium โœ… Single API: TCP/UDP/LoRa/CAN/MQTT
Binary encoding Custom or Protobuf โœ… Zero-copy pipeline

Performance Comparison (Apples-to-Apples)

The numbers below compare CPU processing time only โ€” what happens inside your application before network transmission. Network latency (which dominates end-to-end delay) is excluded because it depends on your infrastructure, not your protocol choice.

Metric MQTT + JSON (paho-mqtt) CoAP (aiocoap) OpenSynaptic
Processing latency (single sensor, Python) ~150โ€“300 ฮผs ~80โ€“200 ฮผs 9.7 ฮผs
Throughput (single core) ~8Kโ€“15K ops/s ~10Kโ€“20K ops/s 1.2M ops/sโ€ 
Payload size (temperature: 23.5ยฐC) ~60 bytes ~40 bytes ~16 bytes
Compression ratio (vs. JSON) N/A N/A 60โ€“80% reduction

OpenSynaptic: batch_fused mode, 16 processes, R5 9600X. See Performance at a Glance.

โš ๏ธ Important: These are protocol + serialization benchmarks, not end-to-end network latency. MQTT/CoAP add 1โ€“10 ms for broker/network round trips โ€” OpenSynaptic would add the same when deployed over real networks. The advantage is in processing efficiency, not physics-defying network speed.

When to Use What

If you need... Use...
Standard IoT cloud connectivity (AWS IoT, Azure IoT Hub) MQTT
REST-like request/response over UDP CoAP
Sensor normalization + compression + multi-transport in one stack OpenSynaptic
Maximum processing throughput on constrained hardware OpenSynaptic
Already have a working MQTT/CoAP deployment Keep it. Add OpenSynaptic for preprocessing.

OpenSynaptic as a Preprocessor

OpenSynaptic doesn't force you to abandon existing infrastructure. Use it as a preprocessing layer before MQTT:

# Standardize and compress sensor data, then send via MQTT
node = OpenSynaptic()
packet, _, _ = node.transmit(sensors=[["temp", "OK", 23.5, "cel"]])
mqtt_client.publish("sensors/data", packet.hex())  # 16 bytes instead of 60

โšก Performance at a Glance

Color legend: R5 9600X = active, i7-9750H = crit, i7_9750H = active.

Note: The chart above uses user-provided run data. Because run profiles differ (total, processes, threads, batch, chain_mode), treat it as an engineering reference rather than a strict A/B benchmark.

gantt
  title CPU Processing Time by Percentile (us)
  dateFormat x
  axisFormat %Q
  section AVG
  R5_9600X 10.7us   : a1, 0, 11
  RK3588 31.5us   :crit, a2, 0, 32
  i7_9750H 21.8us     :active, a3, 0, 22

  section P95
  R5_9600X 36.8us   :b1, 0, 37
  RK3588 88.4us   :crit, b2, 0, 88
  i7_9750H 54.7us     :active, b3, 0, 55

  section P99
  R5_9600X 68.6us   : c1, 0, 69
  RK3588 186.1us  :crit, c2, 0, 186
  i7_9750H 89.7us     :active, c3, 0, 90

  section P99.9
  R5_9600X 109.8us  : d1, 0, 110
  RK3588 461.2us  :crit, d2, 0, 461
  i7_9750H 192.9us    :active, d3, 0, 193

  section P99.99
  R5_9600X 109.8us  : e1, 0, 110
  RK3588 811.6us  :crit, e2, 0, 812
  i7_9750H 338.8us    :active, e3, 0, 339

  section MAX
  R5_9600X 141.5us  : f1, 0, 142
  RK3588 2012.9us :crit, f2, 0, 2013
  i7_9750H 436.4us    :active, f3, 0, 436

Chart scale note: bars are shown in approximate microseconds (us) for readability, grouped by percentile for faster cross-CPU comparison.

Note: This simplified view shows only total per-packet CPU processing latency from user-provided batch_fused runs. If you need stage-level timing (standardize_ms / compress_ms / fuse_ms), use --pipeline-mode legacy in single-process mode.

Legacy Mode (Precise Per-Stage Timing)

For accurate per-stage breakdown, use --pipeline-mode legacy with single process only:

python -u src/main.py plugin-test --suite stress --total 1 \
  --chain-mode core --pipeline-mode legacy --processes 1 --threads-per-process 1

Legacy Mode Pipeline Timing Breakdown:

pie title Per-Stage Latency Distribution
    "Standardize (3.8%)" : 3.8
    "Compress (6.3%)" : 6.3
    "Fuse (89.7%)" : 89.7

Key Insight: Fusion (binary packet construction) dominates latency in legacy mode; batch_fused optimization reduces this bottleneck significantly.

โš ๏ธ Legacy Mode Caveats:

  • Throughput artificially low (~1-5K pps) due to global lock in result collector, not representative of actual system speed
  • Latency data accuracy , but don't use pps metric for performance tuning
  • Use batch_fused (above) for realistic performance profiling

Full Benchmark Report


Use Cases

timeline
    title Deployment Scenarios
    Smart Agriculture (Offline)
        : $30 SBC = Local Cloud
        : LoRa Sensor Network
        : Zero Internet Dependency
        : Real-time Data Aggregation
    
    Industrial IoT (Unified)
        : Single Protocol Stack
        : Replace Proprietary Solutions
        : 50% Cost Reduction
        : Multi-transport Flexibility
    
    Privacy-First Smart Home
        : Local Data Sovereignty
        : SBC = Home Gateway
        : Cloud-agnostic Control
        : Mobile App Integration

Detailed Scenarios:

Smart Agriculture (Offline)

Deploy a $30 SBC as a local cloud, aggregating data from LoRa sensors. No internet required.

Industrial IoT (Unified)

Replace multiple proprietary protocols with a single OpenSynaptic stack, reducing integration cost by 50%.

Privacy-First Smart Home

Keep all sensor data on a local SBC; control via mobile app without exposing data to public cloud.


Minimal Usage

from opensynaptic.core import OpenSynaptic

node = OpenSynaptic()                        # reads Config.json automatically
node.ensure_id("192.168.1.100", 8080)        # request device ID from server
packet, aid, strategy = node.transmit(sensors=[["V1", "OK", 3.14, "Pa"]])
node.dispatch(packet, medium="UDP")
from opensynaptic.core import get_core_manager

manager = get_core_manager()
print(manager.available_cores())             # e.g. ['pycore', 'rscore']
manager.set_active_core('pycore')
OpenSynaptic = manager.get_symbol('OpenSynaptic')

CLI Quick Reference

All commands are available via os-node (installed entrypoint), ./run-main.cmd (Windows), or python -u src/main.py:

Command Categories:

  • Runtime: run, restart, snapshot, ensure-id, transmit, inject, decode, watch, tui
  • ๏ธ Config: config-show, config-get, config-set, core, transporter-toggle
  • Plugin: plugin-list, plugin-load, plugin-cmd, web-user, deps
  • Testing: plugin-test, native-check, native-build, rscore-build, rscore-check
  • Monitor: transport-status, db-status, help

All Commands

Category Command Description
Runtime run Persistent run loop with heartbeat
Runtime restart Gracefully restart the run loop (stop + auto-start new process)
Runtime snapshot Print node/service/transporter JSON snapshot
Runtime ensure-id Request device ID from server
Runtime transmit Encode one sensor reading and dispatch
Runtime inject Push data through pipeline stages and inspect output
Runtime decode Decode a binary packet (hex) or Base62 string back to JSON
Runtime watch Real-time poll a module's state (config / registry / transport / pipeline)
Runtime tui Render TUI snapshot (add --interactive for live mode)
Config config-show Display Config.json or a specific section
Config config-get Read a dot-notation key path from Config
Config config-set Write a typed value to a Config key path
Config core Show/switch core backend (pycore / rscore)
Config transporter-toggle Enable or disable a transporter in Config
Plugin plugin-list List mounted service plugins
Plugin plugin-load Load a mounted plugin by name
Plugin plugin-cmd Route a sub-command to a plugin's CLI handler
Plugin web-user Run web_user plugin directly from CLI
Plugin deps Run dependency_manager plugin directly from CLI
Testing plugin-test Run component or stress tests
Testing native-check Check native compiler/toolchain availability
Testing native-build Build native C bindings (optionally include RS core)
Testing rscore-build Build and install Rust RS core shared library
Testing rscore-check Check RS core DLL/runtime readiness and active core
Monitor transport-status Show all transporter layer states
Monitor db-status Show DB engine status
Monitor help Print full help

Full usage examples โ†’ CLI README


Config.json

Config.json at the project root is the single source of truth. Key fields:

Key Type Default Effect
assigned_id uint32 4294967295 Device ID; 4294967295 = unassigned
engine_settings.precision int 4 Base62 decimal places
engine_settings.active_standardization bool true Toggle UCUM normalisation stage
engine_settings.active_compression bool true Toggle Base62 compression stage
RESOURCES.transporters_status map {} Legacy merged compatibility map (mirrors layer-specific status maps)
security_settings.drop_on_crc16_failure bool true Drop packets with bad CRC

Full schema โ†’ docs/CONFIG_SCHEMA.md


Testing

Test Suite Options:

Suite Purpose Command
component Unit-level component tests plugin-test --suite component
stress High-volume performance tests plugin-test --suite stress --workers 8 --total 200
integration End-to-end integration tests plugin-test --suite integration
all Complete test coverage plugin-test --suite all

Quick Commands:

# Windows shortcut (no Activate.ps1 needed)
.\run-main.cmd plugin-test --suite component

# Component tests (unit-level)
python -u src/main.py plugin-test --suite component

# Stress test (high throughput)
python -u src/main.py plugin-test --suite stress --workers 8 --total 200

# All suites combined
python -u src/main.py plugin-test --suite all

# If tests fail, repair dependencies
python -u src/main.py deps --cmd check
python -u src/main.py deps --cmd repair

# Then retry the test suite

# Additional testing scripts
python scripts/integration_test.py
python scripts/udp_receive_test.py --protocol udp --host 127.0.0.1 --port 8080 --config Config.json
python scripts/audit_driver_capabilities.py
python scripts/services_smoke_check.py

# Exhaustive test suites (full protocol, plugin, security infra, orthogonal)
python scripts/exhaustive_business_logic.py
python scripts/exhaustive_plugin_test.py
python scripts/exhaustive_security_infra_test.py
python scripts/exhaustive_orthogonal_test.py

# Unified local test runner (all suites in one command)
python test.py              # run all 6 suites
python test.py --fast       # skip slow suites (business logic + plugin)
python test.py --suite infra  # run a single suite by name
python test.py --list       # list all available suites

Comprehensive Repeatable Pipeline:

# Full-scale reproducible validation (recommended default)
python -u scripts/extreme_validation_pipeline.py --scale full

# Lightweight CI smoke pass
python -u scripts/extreme_validation_pipeline.py --scale smoke

# Maximum workload, fail on any step
python -u scripts/extreme_validation_pipeline.py --scale extreme --strict

The runner writes a single aggregated JSON report to:

data/benchmarks/extreme_validation_report_latest.json

It also updates per-suite benchmark artifacts under data/benchmarks/ (compare, stress, protocol matrix, CLI exhaustive report).

Full test report: See TEST_REPORT_v1.3.0.md โ€” 1275 tests across 6 suites, 1273 pass, 0 fail.


Native And Rust Build

Backend Options:

Backend Type Toolchain Required Best For
pycore Pure Python Optional (C compiler) Balanced, easy setup
rscore Rust + FFI Required (Rust + MSVC/Clang) Maximum performance

Quick Start:

  1. Check what you have:

    python -u src/main.py native-check      # Check toolchain availability
    
  2. Build native bindings (for pycore):

    python -u src/main.py native-build      # Build C bindings
    
  3. Build Rust backend (optional, for rscore):

    python -u src/main.py rscore-build      # Build Rust core
    python -u src/main.py rscore-check      # Verify installation
    
  4. Switch active core (persistent):

    # Use Rust core
    python -u src/main.py core --set rscore --persist
    
    # Or switch back to Python core
    python -u src/main.py core --set pycore --persist
    

Windows Shortcuts (no Activate.ps1 needed):

.\run-main.cmd native-check
.\run-main.cmd native-build

Adding a Transporter

See docs/TRANSPORTER_PLUGIN.md.


API Reference

See docs/API.md.

Core facade and loader reference -> docs/CORE_API.md


Documentation Hub


Plugin Config Auto-Sync

Built-in plugin settings are stored in Config.json at:

RESOURCES.service_plugins.<plugin_name>

These entries are auto-created with defaults if missing; plugins remain manual-start and do not auto-run at process

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

opensynaptic-1.4.0.tar.gz (2.5 MB view details)

Uploaded Source

Built Distributions

If you're not sure about the file name format, learn more about wheel file names.

opensynaptic-1.4.0-cp313-cp313-win_amd64.whl (779.0 kB view details)

Uploaded CPython 3.13Windows x86-64

opensynaptic-1.4.0-cp313-cp313-manylinux2014_x86_64.manylinux_2_17_x86_64.whl (736.3 kB view details)

Uploaded CPython 3.13manylinux: glibc 2.17+ x86-64

opensynaptic-1.4.0-cp313-cp313-macosx_11_0_arm64.whl (692.4 kB view details)

Uploaded CPython 3.13macOS 11.0+ ARM64

opensynaptic-1.4.0-cp312-cp312-win_amd64.whl (778.9 kB view details)

Uploaded CPython 3.12Windows x86-64

opensynaptic-1.4.0-cp312-cp312-manylinux2014_x86_64.manylinux_2_17_x86_64.whl (736.3 kB view details)

Uploaded CPython 3.12manylinux: glibc 2.17+ x86-64

opensynaptic-1.4.0-cp312-cp312-macosx_11_0_arm64.whl (692.5 kB view details)

Uploaded CPython 3.12macOS 11.0+ ARM64

opensynaptic-1.4.0-cp311-cp311-win_amd64.whl (778.9 kB view details)

Uploaded CPython 3.11Windows x86-64

opensynaptic-1.4.0-cp311-cp311-manylinux_2_28_aarch64.whl (712.5 kB view details)

Uploaded CPython 3.11manylinux: glibc 2.28+ ARM64

opensynaptic-1.4.0-cp311-cp311-manylinux2014_x86_64.manylinux_2_17_x86_64.whl (737.1 kB view details)

Uploaded CPython 3.11manylinux: glibc 2.17+ x86-64

opensynaptic-1.4.0-cp311-cp311-macosx_11_0_arm64.whl (692.7 kB view details)

Uploaded CPython 3.11macOS 11.0+ ARM64

opensynaptic-1.4.0-cp311-cp311-macosx_10_12_x86_64.whl (706.6 kB view details)

Uploaded CPython 3.11macOS 10.12+ x86-64

File details

Details for the file opensynaptic-1.4.0.tar.gz.

File metadata

  • Download URL: opensynaptic-1.4.0.tar.gz
  • Upload date:
  • Size: 2.5 MB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/6.1.0 CPython/3.13.12

File hashes

Hashes for opensynaptic-1.4.0.tar.gz
Algorithm Hash digest
SHA256 6213f968e56300e0b0aec35233fe8d6dfd68676647b4961bb568570b239d7f21
MD5 f9b14310f529c2f62e89cd5435ddd27f
BLAKE2b-256 47fc6018d3b7edc540a8c41ce2628416c99240ff020b0517d666b67747609cf0

See more details on using hashes here.

File details

Details for the file opensynaptic-1.4.0-cp313-cp313-win_amd64.whl.

File metadata

File hashes

Hashes for opensynaptic-1.4.0-cp313-cp313-win_amd64.whl
Algorithm Hash digest
SHA256 a695dc6a861f377ce863cfdbf69b901d29c057225ff0c39f75e4234314446156
MD5 edc0b4f5ed29af6b7e33cb6cb68594dd
BLAKE2b-256 c5126589a7234889e7a236211bddce0ccc7439585ecedd4f59fb7d39e06cd5d5

See more details on using hashes here.

File details

Details for the file opensynaptic-1.4.0-cp313-cp313-manylinux2014_x86_64.manylinux_2_17_x86_64.whl.

File metadata

File hashes

Hashes for opensynaptic-1.4.0-cp313-cp313-manylinux2014_x86_64.manylinux_2_17_x86_64.whl
Algorithm Hash digest
SHA256 6a635cede400ab337b1217ac266f94b5a37be3e7fc85722d4265602e9b055e64
MD5 4fad813767ef311cfb5ad477a42d245b
BLAKE2b-256 8eb70d1592f60841ef61aed4245afbad92855d1d26b70dba1f89c6040d6a5003

See more details on using hashes here.

File details

Details for the file opensynaptic-1.4.0-cp313-cp313-macosx_11_0_arm64.whl.

File metadata

File hashes

Hashes for opensynaptic-1.4.0-cp313-cp313-macosx_11_0_arm64.whl
Algorithm Hash digest
SHA256 4aac9ac9c27e97cc12df479f97c71cae2a0011a2db71d49accad2d1d0fc5113c
MD5 a1e817c548c91ed9bc62c899bc81769d
BLAKE2b-256 341080b85c48d85a24595262ca10afcd59728b5ce214299d8ed98c668f37dca4

See more details on using hashes here.

File details

Details for the file opensynaptic-1.4.0-cp312-cp312-win_amd64.whl.

File metadata

File hashes

Hashes for opensynaptic-1.4.0-cp312-cp312-win_amd64.whl
Algorithm Hash digest
SHA256 68ad7f64e70bb8694bcef01cce43c8ce01c1458ab68e78416b3ec05360307d9b
MD5 c9b6e6988e3f64b0c5a55c94e39242f3
BLAKE2b-256 2e4907110e52901446e3766ac7651e902af2070fed424bf76510e3d555bc7970

See more details on using hashes here.

File details

Details for the file opensynaptic-1.4.0-cp312-cp312-manylinux2014_x86_64.manylinux_2_17_x86_64.whl.

File metadata

File hashes

Hashes for opensynaptic-1.4.0-cp312-cp312-manylinux2014_x86_64.manylinux_2_17_x86_64.whl
Algorithm Hash digest
SHA256 ce521c4c82740c87e6ebac78c03c707307c8ea20e3e4eccd208309abe1e0384a
MD5 1d12161f28aaa713ccf2f45dfe61cfc6
BLAKE2b-256 3aeb872b93652473bc3e774ea5c8ab57321ef368eaa9d3fa3dd64236b6f504a5

See more details on using hashes here.

File details

Details for the file opensynaptic-1.4.0-cp312-cp312-macosx_11_0_arm64.whl.

File metadata

File hashes

Hashes for opensynaptic-1.4.0-cp312-cp312-macosx_11_0_arm64.whl
Algorithm Hash digest
SHA256 a8eb44ba3f337c1a6c0417cbc3ab0f892c394272d3d9b3d725b3e1f001909ae1
MD5 092b183373e549f462efe36a7db7fb00
BLAKE2b-256 5d53b8788034ee4b81efdbeaa8ab827465a1376fd573a32ffa622467d2a0b341

See more details on using hashes here.

File details

Details for the file opensynaptic-1.4.0-cp311-cp311-win_amd64.whl.

File metadata

File hashes

Hashes for opensynaptic-1.4.0-cp311-cp311-win_amd64.whl
Algorithm Hash digest
SHA256 6917c2c669dae55d3b593a28970534700666c53cee9f68b3bd21ff4c9256b688
MD5 543a9af5140d120efb1a33167d53334b
BLAKE2b-256 5cdc48b5e0c844eb704e6171fab0c34ab1a60fea8518528ebd89c2a5d0cc312a

See more details on using hashes here.

File details

Details for the file opensynaptic-1.4.0-cp311-cp311-manylinux_2_28_aarch64.whl.

File metadata

File hashes

Hashes for opensynaptic-1.4.0-cp311-cp311-manylinux_2_28_aarch64.whl
Algorithm Hash digest
SHA256 e3f021d9251fb441482bdd6d58ea9b35894f0018a7cbaace5ad09cd4f4390db7
MD5 3ec3e35b92a8d65f70251c04e1787583
BLAKE2b-256 a41c383db07ba7c6a2169e8cc86713947723d09d871e90533e9c3cb77e2aea65

See more details on using hashes here.

File details

Details for the file opensynaptic-1.4.0-cp311-cp311-manylinux2014_x86_64.manylinux_2_17_x86_64.whl.

File metadata

File hashes

Hashes for opensynaptic-1.4.0-cp311-cp311-manylinux2014_x86_64.manylinux_2_17_x86_64.whl
Algorithm Hash digest
SHA256 4ac5b56ea24b6c05b214ef4e4635a6c7f464aef20c1bf44b55ec1fd806e3775e
MD5 ac3bfd451afee29c8845afa027b970f7
BLAKE2b-256 12ee8c67cb9ee8afe5d0329b6e321fbfde9f5e11ff98eef5a09a1d9ef123d6f7

See more details on using hashes here.

File details

Details for the file opensynaptic-1.4.0-cp311-cp311-macosx_11_0_arm64.whl.

File metadata

File hashes

Hashes for opensynaptic-1.4.0-cp311-cp311-macosx_11_0_arm64.whl
Algorithm Hash digest
SHA256 4f6b21ace3689c77f62f8b4380b125126b5931d002f341340b33f99712d2b7ba
MD5 2564cfc1345e2498aa77e6b62550613c
BLAKE2b-256 d4e3eb99548a6c25899cf5181d4e3160fd35568829b26e24f7e288cdc465532d

See more details on using hashes here.

File details

Details for the file opensynaptic-1.4.0-cp311-cp311-macosx_10_12_x86_64.whl.

File metadata

File hashes

Hashes for opensynaptic-1.4.0-cp311-cp311-macosx_10_12_x86_64.whl
Algorithm Hash digest
SHA256 110b89154ee39b257fc02f29fd0d9ed0dbfce3f9fa6352a6057e1311d930a7fa
MD5 b36dcb7f318b27462edd8785a5cffa89
BLAKE2b-256 3a45dc8f0009587e2a42afd5c26e2679a7f8435c35daff9297c9b51c49ea69ad

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page