📜 Care2Graph Alarm Interface EZ Care
Se connecter
📜

Care2Graph Alarm Interface EZ Care


Table of Contents

Overview

The C2G Alarm Interface for EZCare is a bidirectional bridge service that translates alarms between two different systems:

  • C2G Alarm Server: Receives and sends alarms via WebSocket using JSON format
  • EZCare System: Receives and sends alarms via TCP using XML format

This service enables seamless integration between Care2Graph's alarm management system and EZCare's nurse call system, allowing alarms to flow bidirectionally between both platforms.

Key Capabilities

  •  Real-time bidirectional alarm forwarding
  •  Automatic protocol translation (JSON ↔ XML)
  •  Database integration for location and person data
  •  Automatic reconnection and error handling
  •  Periodic data synchronization
  •  Systemd service integration
  •  Debian package distribution

Architecture

High-Level System Architecture

System Deployment Diagram

System Flow Diagram

┌──────────────────┐      WebSocket (JSON)        ┌─────────────────┐
│  C2G Alarm       │<──────────────────────────── │   C2G Alarm     │
│  Server (WSS)    │────────────────────────────> │   Interface     │
└──────────────────┘      WebSocket (JSON)        └────────┬────────┘
                                                           │
                                    ┌──────────────────────┘
                                    │
                    ┌───────────────┴───────────────┐
                    │   TCP + XML (Bidirectional)   │
                    │                               │
                    ▼                               ▼
           ┌─────────────────┐          ┌─────────────────┐
           │   EZCare        │          │   EZCare        │
           │   System        │          │   System        │
           │   (Receives)    │          │   (Sends)       │
           └─────────────────┘          └─────────────────┘

Bidirectional Flow

WebSocket → EZCare (Forward Direction)

  1. Connects to C2G alarm server WebSocket as a client
  2. Receives alarms via WebSocket in JSON format
  3. Fetches additional data from database/APIs (location, person info)
  4. Converts alarms to EZCare XML format
  5. Sends to EZCare system via TCP connection

EZCare → WebSocket (Reverse Direction)

  1. Receives alarms from EZCare via TCP connection in XML format
  2. Parses XML messages (ITEM_CALL with different CST states)
  3. Transforms to WebSocket JSON format
  4. Sends to C2G alarm server via WebSocket

Components

  • WebSocket Manager: Handles connection to C2G Alarm Server
  • TCP Client: Handles connection to EZCare system
  • XML Parser: Parses EZCare XML messages
  • Message Transformer: Converts between JSON and XML formats
  • Data Synchronization: Periodic sync from REST APIs to local database
  • Database Interface: PostgreSQL database for location and person data

Main Data Structures

Features

Implemented Features

  • WebSocket Client

    • Secure TLS connection to C2G Alarm Server
    • SHA512 authentication with salt
    • Automatic reconnection on failure
    • Message type handling (Auth, Alarms, Subscribe)

  • Bidirectional Transformation

    • WebSocket JSON → EZCare XML
    • EZCare XML → WebSocket JSON
    • All operations supported (Create, Update, Accept, Quit, Undo)

  • EZCare XML Integration

    • ITEM_REG (Registration messages)
    • ITEM_CALL (Virtual call creation and state changes)
    • ITEM_TAG (Person location reporting)

  • Database Integration

    • Location data retrieval
    • Person/Tag data retrieval
    • Complete alarm info assembly

  • Data Synchronization

    • Periodic synchronization from REST APIs
    • Location, building, unit, and tag data sync
    • Automatic retry on failures

  • System Integration

    • Systemd service support
    • Logging with log4c configuration
    • Debian package distribution

Alarm Type Mappings

The service maps C2G alarm types to EZCare call categories and types:

C2G Alarm Type Device Types Alarm Name EZCare CCAT EZCare CTNR Priority
9 2, 8, 9 NURSE_CALL 6 6 Medium
6 5 INFANT_ABDUCTION 11 10 Critical
10 3, 4 DURESS_ALARM 11 12 Critical
14 4 FALL_DETECTION 11 12 Critical
15 4 DEAD_MAN_ALARM 11 12 Critical
6 1, 2 WANDER_ALARM 13 13 High
7 13 DOOR_ALARM 13 13 High
1 9-16 DEVICE_LOST 2 102 Low
3 1-17 DEVICE_BATTERY 2 102 Low

See c2g-alarm-types.json for complete mapping configuration.

Installation

Prerequisites

  • Operating System: Linux (Debian/Ubuntu)
  • Go: Version 1.19 or higher (for building from source)
  • PostgreSQL: Database server for storing location and person data
  • Network Access: To C2G Alarm Server and EZCare system

Installation Methods

Method 1: Debian Package (Recommended)

  1. Download the package:

    # Example: c2g-alarm-interface-ezcare-1.0.0+35.amd64.deb

  2. Install the package:

    sudo dpkg -i c2g-alarm-interface-ezcare-1.0.0+35.amd64.deb

  3. Configure the service (see Configuration section)

  4. Start the service:

    sudo systemctl start c2g-alarm-interface-ezcare
sudo systemctl enable c2g-alarm-interface-ezcare

Method 2: Build from Source

  1. Clone or download the source code

  2. Install dependencies:

    make install-deps

  3. Build the binary:

    make build
# or for production:
make build-prod

  4. Install manually:

    make install

Directory Structure

After installation, the service is installed in:

/opt/martin/care2graph/c2g-alarm-interface-ezcare/
├── c2g-alarm-interface-ezcare          # Main binary
├── bridge_config.json                   # WebSocket and EZCare configuration
├── sync_config.json                     # Database and API configuration
├── c2g-alarm-types.json                 # Alarm type mappings
└── ezcare-call-types.json              # EZCare call type definitions

/etc/care2graph/alarm-interface-ezcare/
├── c2g-alarm-interface-ezcare-log4c.xml # Logging configuration
└── c2g-alarm-interface-ezcare.conf      # Application configuration

/etc/systemd/system/
└── c2g-alarm-interface-ezcare.service  # Systemd service file

Configuration

Configuration Files

The service uses two main configuration files:

  1. bridge_config.json: WebSocket and EZCare connection settings
  2. sync_config.json: Database and REST API settings

Bridge Configuration (bridge_config.json)

Located at: /opt/martin/care2graph/c2g-alarm-interface-ezcare/bridge_config.json

{
  "_comment": "C2G Alarm Server → EZCare Bridge Configuration",
  
  "C2G_SERVER_ADDRESS": "demo.care2graph.com",
  "C2G_SERVER_PORT": 9001,
  "C2G_USERNAME": "admin",
  "C2G_PASSWORD": "$2b$10$RkwCJH5VX.HxA9H0nh/9KutuM/RWgxaZ0hXeQGXgfXQF6SwZNQGtS",
  "C2G_USE_TLS": true,
  "C2G_PEM": "/etc/care2graph/alarm-interface-ezcare/ssl-certificate.pem",
  
  "EZCARE_SERVER": "192.168.1.100",
  "EZCARE_PORT": 7777,
  "EZCARE_CLIENT_ID": "C2GBridge",
  "EZCARE_SUBNET_ID": 1,
  "EZCARE_USE_TLS": false,
  "EZCARE_CERT": "/etc/care2graph/alarm-interface-ezcare/c2g_134061150567711863.crt",
  "EZCARE_KEY": "/etc/care2graph/alarm-interface-ezcare/c2g_134061150567711863.key",
  "EZCARE_PEM": "/etc/care2graph/alarm-interface-ezcare/c2g_134061150567711863.pem",
  
  "ALARM_TYPES_FILE": "c2g-alarm-types.json"
}

Configuration Parameters

C2G Alarm Server Settings:

  • C2G_SERVER_ADDRESS: Hostname or IP of C2G Alarm Server
  • C2G_SERVER_PORT: WebSocket port (typically 9001)
  • C2G_USERNAME: Username for authentication
  • C2G_PASSWORD: SHA512 hashed password (bcrypt format)
  • C2G_USE_TLS: Enable TLS for WebSocket connection
  • C2G_PEM: Path to TLS certificate file

EZCare Settings:

  • EZCARE_SERVER: IP address of EZCare system
  • EZCARE_PORT: TCP port for EZCare (typically 7777)
  • EZCARE_CLIENT_ID: Client identifier for registration
  • EZCARE_SUBNET_ID: Subnet ID for EZCare network
  • EZCARE_USE_TLS: Enable TLS for EZCare connection (required for remote)
  • EZCARE_CERT: Path to client certificate (if using TLS)
  • EZCARE_KEY: Path to client private key (if using TLS)
  • EZCARE_PEM: Path to CA certificate (if using TLS)

File References:

  • ALARM_TYPES_FILE: Path to alarm type mapping file

Synchronization Configuration (sync_config.json)

Located at: /opt/martin/care2graph/c2g-alarm-interface-ezcare/sync_config.json

Data Synchronization Flow

Synchronization State Machine

{
  "environment_api_base": "https://demo.care2graph.com:42031",
  "tags_api_base": "https://demo.care2graph.com:42032",
  "sync_interval_minutes": 5,
  "database": {
    "host": "localhost",
    "port": 5432,
    "user": "postgres",
    "password": "Standard1",
    "dbname": "c2gezcare",
    "sslmode": "disable"
  }
}

Configuration Parameters

  • environment_api_base: Base URL for environment/location API
  • tags_api_base: Base URL for tags/persons API
  • sync_interval_minutes: Interval for periodic data synchronization

  • database: PostgreSQL connection settings

    • host: Database hostname
    • port: Database port (default: 5432)
    • user: Database username
    • password: Database password
    • dbname: Database name
    • sslmode: SSL mode (disable/require/verify-full)

Database Schema

The service requires a PostgreSQL database with the following tables:

  • buildings: Building information
  • units: Unit/ward information
  • locations: Location/room information
  • tags: Person/tag information

See tmp/database_schema_postgres.sql for the complete schema.

Logging Configuration

Located at: /etc/care2graph/alarm-interface-ezcare/c2g-alarm-interface-ezcare-log4c.xml

The service uses log4c-style configuration for structured logging. Logs are written to:

  • Console: Standard output (if running in foreground)
  • File: /var/log/care2graph/c2g-alarm-interface-ezcare/c2g-alarm-interface-ezcare-YYYY-MM-DD.log

Log files are rotated daily and kept for 10 days by default. Configure log levels, output destinations, and rotation policies in the XML configuration file.

Usage

Service Management

Start the Service

sudo systemctl start c2g-alarm-interface-ezcare

Stop the Service

sudo systemctl stop c2g-alarm-interface-ezcare

Restart the Service

sudo systemctl restart c2g-alarm-interface-ezcare

Enable at Boot

sudo systemctl enable c2g-alarm-interface-ezcare

Check Status

sudo systemctl status c2g-alarm-interface-ezcare

View Logs

# Real-time logs (follow today's log file)
tail -f /var/log/care2graph/c2g-alarm-interface-ezcare/c2g-alarm-interface-ezcare-$(date +%Y-%m-%d).log

# Or follow the most recent log file (alternative method)
LATEST_LOG=$(ls -t /var/log/care2graph/c2g-alarm-interface-ezcare/*.log | head -1)
tail -f "$LATEST_LOG"

# Recent logs (last 100 lines)
tail -n 100 /var/log/care2graph/c2g-alarm-interface-ezcare/c2g-alarm-interface-ezcare-$(date +%Y-%m-%d).log

# View all log files
ls -lh /var/log/care2graph/c2g-alarm-interface-ezcare/

# View specific log file
cat /var/log/care2graph/c2g-alarm-interface-ezcare/c2g-alarm-interface-ezcare-2025-01-29.log

Command Line Options

Run the binary directly for testing:

# Show version
/opt/martin/care2graph/c2g-alarm-interface-ezcare/c2g-alarm-interface-ezcare -version

# Run once (sync and exit)
/opt/martin/care2graph/c2g-alarm-interface-ezcare/c2g-alarm-interface-ezcare -once -config=sync_config.json

# Verbose logging
/opt/martin/care2graph/c2g-alarm-interface-ezcare/c2g-alarm-interface-ezcare -verbose

Makefile Targets

The project includes a comprehensive Makefile:

# Build
make build                  # Build binary
make build-prod            # Production build (optimized)

# Service management
make install               # Install service
make uninstall             # Remove service
make start                 # Start service
make stop                  # Stop service
make restart               # Restart service
make status                # Show status
make logs                  # Show logs

# Development
make install-deps          # Install Go dependencies
make test                  # Run tests
make fmt                   # Format code
make lint                  # Lint code

# Packaging
make package               # Create Debian package
make release               # Clean, build, and package

# Utilities
make version               # Show version
make help                  # Show all target

Protocol Details

WebSocket Protocol (C2G Alarm Server)

WebSocket Connection Lifecycle

WebSocket Connection State Machine

WebSocket Message Operations

Message Types

Type 1: Authentication

{
  "type": 1,
  "operation": 0,
  "credentials": "base64_encoded_credentials"
}

Credentials format: base64(username@salt@sha512(salt+password_hash))

Authentication Response:

{
  "type": 1,
  "operation": 0,
  "code": 200,
  "reason": "OK"
}

Type 4: Subscribe After authentication confirmation, the service sends:

{
  "type": 4,
  "operation": 2
}

Type 3: Alarm Operations

Operation 1 - Create Alarm (Request):

{
  "type": 3,
  "operation": 1,
  "alarm": {
    "id": "alarm-uuid",
    "type": 9,
    "location": 30,
    "deviceid": 66935,
    "devicetype": 9,
    "timestamp": 1743577927320,
    "accept": 0,
    "acceptmax": 3,
    "userid": 123,
    "message": ""
  }
}

Operation 1 - Response:

{
  "type": 3,
  "operation": 1,
  "code": 200,
  "reason": "OK",
  "alarm": { /* Alarm object */ }
}

Operation 3 - Update Alarm:

{
  "type": 3,
  "operation": 3,
  "alarm": {
    "id": "alarm-uuid",
    "type": 9,
    "location": 30
  }
}

Operation 4 - Cancel/Quit Alarm:

{
  "type": 3,
  "operation": 4,
  "cancellation": {
    "alarm": "alarm-uuid",
    "message": "Cancellation reason"
  }
}

Operation 5 - Accept Alarm:

{
  "type": 3,
  "operation": 5,
  "alarm": "alarm-uuid"
}

Operation 6 - Undo Accept:

{
  "type": 3,
  "operation": 6,
  "alarm": "alarm-uuid"
}

All operations return responses with:

  • code: HTTP-style status code (200 = success)
  • reason: Status message
  • alarm: Alarm ID or alarm object

EZCare XML Protocol

All EZCare messages use XML format with version 3.0.

Registration Message (ITEM_REG)

Sent on connection to register the bridge client with EZCare:

<?xml version="1.0" encoding="utf-8"?>
<MC800 version="3.0">
  <ITEM_REG>
    <LOC>
      <LTXT>C2GFwd</LTXT>
      <LS>1</LS>
      <LCLNTID>C2GBridge</LCLNTID>
    </LOC>
    <FILTER>
      <FN>0</FN>
      <FS>255</FS>
      <FCALL>0</FCALL>
      <FTAG>0</FTAG>
      <FNP>0</FNP>
      <FICON>0</FICON>
    </FILTER>
  </ITEM_REG>
</MC800>

Fields:

  • LTXT: Client location text (identifier)
  • LS: Subnet ID
  • LCLNTID: Client ID (from EZCARE_CLIENT_ID config)
  • FILTER: Message filtering settings (0 = receive all)

Virtual Call Creation (ITEM_CALL with CODE=VIRT)

Creates a new alarm in EZCare:

<?xml version="1.0" encoding="utf-8"?>
<MC800 version="3.0">
  <ITEM_CALL>
    <CODE>VIRT</CODE>
    <LOC>
      <LS>1</LS>
      <LCLT>Room101</LCLT>
      <LTXT>BuildingA-Unit2</LTXT>
    </LOC>
    <CALL>
      <CNR>1</CNR>
      <CLNR>1</CLNR>
      <CST>1</CST>
      <CTNR>6</CTNR>
      <CCAT>6</CCAT>
    </CALL>
  </ITEM_CALL>
</MC800>

Fields:

  • CODE: "VIRT" for virtual call creation
  • LS: Subnet ID
  • LCLT: Location name (room name)
  • LTXT: Location text (building-unit)
  • CNR: Call number (typically 1)
  • CLNR: Call line (typically 1)
  • CST: Call state (1 = activated)
  • CTNR: Call type number (from c2g-alarm-types.json)
  • CCAT: Call category (from c2g-alarm-types.json)

Call State Update (ITEM_CALL with CODE=BEF)

Updates or deletes an existing call:

<?xml version="1.0" encoding="utf-8"?>
<MC800 version="3.0">
  <ITEM_CALL>
    <CODE>BEF</CODE>
    <LOC>
      <LS>1</LS>
      <LN>0</LN>
    </LOC>
    <CALL>
      <CID>alarm-123</CID>
      <CST>4</CST>
    </CALL>
  </ITEM_CALL>
</MC800>

Fields:

  • CODE: "BEF" for existing call modification
  • CID: Call ID to update
  • CST: New call state
  • LN: Node ID (location node)

Call State (CST) Values:

  • 1: Activated (new alarm or reactivate)
  • 3: Confirmed/Acknowledged (accepted)
  • 4: Deleted/Cancelled (quit)

EZCare Call State Machine

Tag Location (ITEM_TAG)

Reports person location in EZCare:

<?xml version="1.0" encoding="utf-8"?>
<MC800 version="3.0">
  <ITEM_TAG>
    <LOC>
      <LS>1</LS>
      <LN>0</LN>
      <LCLT>Room101</LCLT>
      <LTXT>BuildingA-Unit2</LTXT>
    </LOC>
    <TAG>
      <TID>12345</TID>
      <TNAME>John Doe</TNAME>
      <TTYPE>4097</TTYPE>
      <TIN>1</TIN>
      <TSW1>0</TSW1>
      <TSW2>0</TSW2>
      <TBTL>0</TBTL>
      <TMOT>1</TMOT>
    </TAG>
    <SENS>
      <STYP>1</STYP>
      <SADR>66935</SADR>
    </SENS>
  </ITEM_TAG>
</MC800>

Fields:

  • TID: Transponder/Tag ID (32-bit lower part of UID)
  • TNAME: Person name
  • TTYPE: Tag type (upper 32 bits of UID)
  • TIN: In room indicator (1 = present)
  • TSW1, TSW2: Button press indicators
  • TBTL: Battery low indicator
  • TMOT: Motion detected indicator
  • STYP: Sensor type
  • SADR: Sensor address (device ID)

Message Flow Examples

Example 1: Alarm from C2G → EZCare

  1. C2G sends alarm via WebSocket:

    {
  "type": 3,
  "operation": 1,
  "alarm": {
    "id": "alarm-123",
    "type": 9,
    "location": 30,
    "deviceid": 66935,
    "devicetype": 9,
    "timestamp": 1743577927320
  }
}

  2. Bridge fetches additional data:

    • Location 30 → "Room101", "BuildingA-Unit2"
    • Device 66935 → Tag ID: "12345", Person: "John Doe"

  3. Bridge sends to EZCare:

    • Message 1: ITEM_CALL (VIRT) - Creates alarm
    • Message 2: ITEM_TAG - Reports person location

Example 2: Alarm Cancellation from C2G → EZCare

  1. C2G sends cancellation:

    {
  "type": 3,
  "operation": 4,
  "cancellation": {
    "alarm": "alarm-123",
    "message": "Alarm resolved"
  }
}

  2. Bridge transforms to EZCare:

    <?xml version="1.0" encoding="utf-8"?>
<MC800 version="3.0">
  <ITEM_CALL>
    <CODE>BEF</CODE>
    <LOC>
      <LS>1</LS>
      <LN>0</LN>
    </LOC>
    <CALL>
      <CID>alarm-123</CID>
      <CST>4</CST>
    </CALL>
  </ITEM_CALL>
</MC800>

Example 3: Alarm from EZCare → C2G

  1. EZCare sends alarm:

    <?xml version="1.0" encoding="utf-8"?>
<MC800 version="3.0">
  <ITEM_CALL>
    <LOC>
      <LS>1</LS>
      <LCLT>Room101</LCLT>
      <LTXT>BuildingA-Unit2</LTXT>
    </LOC>
    <CALL>
      <CID>ezcare-call-123</CID>
      <CNR>1</CNR>
      <CLNR>1</CLNR>
      <CST>1</CST>
      <CTNR>6</CTNR>
      <CCAT>6</CCAT>
    </CALL>
  </ITEM_CALL>
</MC800>

  2. Bridge transforms to WebSocket:

    {
  "type": 3,
  "operation": 1,
  "alarm": {
    "id": "ezcare-call-123",
    "type": 6,
    "location": 1,
    "deviceid": 0,
    "devicetype": 6,
    "timestamp": 0,
    "accept": 0,
    "acceptmax": 0,
    "userid": 0,
    "message": "EZ Care Alarm: BuildingA-Unit2"
  }
}

Transformation Notes:

  • CID → alarm ID
  • CTNR → alarm type
  • LS → location ID
  • CCAT → device type
  • Message includes location text from LTXT

Example 4: Alarm Accept from C2G → EZCare

When an alarm is accepted on the C2G side, the bridge sends a BEF message with CST=3 to EZCare to mark it as confirmed/acknowledged.

Example 5: Alarm Cancellation from EZCare → C2G

When an alarm is cancelled/quit in EZCare (CST=4), the bridge transforms it to a Type 3, Operation 4 cancellation message and sends it to the C2G server.

Development

Project Structure

c2g-alarm-interface-ezcare/
├── opt/martin/care2graph/c2g-alarm-interface-ezcare/
│   ├── main.go              # Main entry point
│   ├── websocket.go          # WebSocket client management
│   ├── ezcare_xml.go         # EZCare XML message handling
│   ├── data_retrieval.go     # Database queries
│   ├── sync_system.go        # Data synchronization
│   ├── logger.go             # Logging utilities
│   └── *.json                # Configuration files
├── etc/
│   ├── care2graph/alarm-interface-ezcare/
│   │   └── *.xml, *.conf     # Configuration files
│   └── systemd/system/
│       └── *.service         # Systemd service file
├── DEBIAN/                   # Debian package metadata
├── Makefile                  # Build and packaging
├── go.mod                    # Go module definition
└── README.md                 # Project readme

Building from Source

  1. Install Go 1.19+

    # Verify installation
go version

  2. Clone/download the source code

  3. Install dependencies

    make install-deps
# or manually:
go mod download

  4. Build

    make build

  5. Test

    make test

Adding New Alarm Types

Edit c2g-alarm-types.json:

{
  "ALARM_TYPE": {
    "DEVICE_TYPE": {
      "ccat": EZCARE_CATEGORY,
      "ctnr": EZCARE_TYPE,
      "name": "ALARM_NAME"
    }
  }
}

Adding New Features

  1. New source files: Add to opt/martin/care2graph/c2g-alarm-interface-ezcare/
  2. Dependencies: Add to go.mod and run go mod tidy
  3. Configuration: Update configuration files as needed
  4. Tests: Add tests alongside source files
  5. Documentation: Update this file

Code Style

  • Follow Go standard formatting (go fmt)
  • Use meaningful variable and function names
  • Add comments for exported functions
  • Handle errors explicitly
  • Use structured logging

Troubleshooting

Common Issues

Service Won't Start

Symptoms: Service fails to start or exits immediately

Solutions:

  1. Check configuration files exist and are valid JSON:

    cat /opt/martin/care2graph/c2g-alarm-interface-ezcare/bridge_config.json | jq .
cat /opt/martin/care2graph/c2g-alarm-interface-ezcare/sync_config.json | jq .

  2. Check logs:

    tail -n 50 /var/log/care2graph/c2g-alarm-interface-ezcare/c2g-alarm-interface-ezcare-$(date +%Y-%m-%d).log

  3. Verify database connection:

    psql -h localhost -U postgres -d c2gezcare

  4. Check file permissions:

    ls -la /opt/martin/care2graph/c2g-alarm-interface-ezcare/

WebSocket Connection Fails

Symptoms: Cannot connect to C2G Alarm Server

Solutions:

  1. Verify network connectivity:

    telnet demo.care2graph.com 9001

  2. Check TLS certificate:

    ls -la /etc/care2graph/alarm-interface-ezcare/ssl-certificate.pem

  3. Verify credentials in bridge_config.json

  4. Check firewall rules

EZCare Connection Fails

Symptoms: Cannot connect to EZCare system

Solutions:

  1. Verify EZCare server is running:

    telnet 192.168.1.100 7777

  2. For TLS connections, verify certificates:

    ls -la /etc/care2graph/alarm-interface-ezcare/*.crt
ls -la /etc/care2graph/alarm-interface-ezcare/*.key

  3. Check subnet ID matches EZCare configuration

  4. Verify client ID is unique and valid

Database Connection Errors

Symptoms: Cannot connect to PostgreSQL database

Solutions:

  1. Verify PostgreSQL is running:

    sudo systemctl status postgresql

  2. Test connection:

    psql -h localhost -U postgres -d c2gezcare

  3. Check credentials in sync_config.json

  4. Verify database exists:

    psql -U postgres -l | grep c2gezcare

Data Synchronization Fails

Symptoms: REST API sync errors in logs

Solutions:

  1. Verify API endpoints are accessible:

    curl https://demo.care2graph.com:42031/v1/environment/buildings

  2. Check API authentication (if required)

  3. Verify network connectivity to API servers

  4. Check sync interval configuration

Debug Mode

Enable verbose logging:

  1. Edit systemd service:

    sudo systemctl edit c2g-alarm-interface-ezcare

  2. Add verbose flag:

    [Service]
ExecStart=
ExecStart=/opt/martin/care2graph/c2g-alarm-interface-ezcare/c2g-alarm-interface-ezcare -verbose

  3. Reload and restart:

    sudo systemctl daemon-reload
sudo systemctl restart c2g-alarm-interface-ezcare

Log Analysis

The service writes logs to /var/log/care2graph/c2g-alarm-interface-ezcare/ with daily rotation. Log files are named:

c2g-alarm-interface-ezcare-YYYY-MM-DD.log

View Recent Errors

# View errors in today's log
grep -i error /var/log/care2graph/c2g-alarm-interface-ezcare/c2g-alarm-interface-ezcare-$(date +%Y-%m-%d).log | tail -n 50

# View errors in all log files
grep -i error /var/log/care2graph/c2g-alarm-interface-ezcare/*.log | tail -n 50

Monitor Real-time Activity

# Follow today's log file
tail -f /var/log/care2graph/c2g-alarm-interface-ezcare/c2g-alarm-interface-ezcare-$(date +%Y-%m-%d).log

# Follow the most recent log file (automatically selects latest)
LATEST_LOG=$(ls -t /var/log/care2graph/c2g-alarm-interface-ezcare/*.log | head -1)
tail -f "$LATEST_LOG"

Search for Specific Patterns

# Search in today's log
grep "ERROR" /var/log/care2graph/c2g-alarm-interface-ezcare/c2g-alarm-interface-ezcare-$(date +%Y-%m-%d).log
grep "WebSocket" /var/log/care2graph/c2g-alarm-interface-ezcare/c2g-alarm-interface-ezcare-$(date +%Y-%m-%d).log
grep "EZCare" /var/log/care2graph/c2g-alarm-interface-ezcare/c2g-alarm-interface-ezcare-$(date +%Y-%m-%d).log

# Search in all log files
grep "ERROR" /var/log/care2graph/c2g-alarm-interface-ezcare/*.log
grep "WebSocket" /var/log/care2graph/c2g-alarm-interface-ezcare/*.log
grep "EZCare" /var/log/care2graph/c2g-alarm-interface-ezcare/*.log

List Available Log Files

# View all log files with details
ls -lh /var/log/care2graph/c2g-alarm-interface-ezcare/

# View log files sorted by date
ls -lht /var/log/care2graph/c2g-alarm-interface-ezcare/

API Reference

Database Queries

The service provides database query functions to retrieve location and person information:

GetLocationInfo

Retrieves complete location information including building and unit by joining multiple tables.

SQL Query:

SELECT 
    l.id, l.name as location_name,
    u.id as unit_id, u.name as unit_name,
    b.id as building_id, b.name as building_name
FROM locations l
JOIN units u ON l.ward_id = u.id
JOIN buildings b ON u.building_id = b.id
WHERE l.id = $1

Parameters:

  • locationID (int): Location identifier

Returns:

  • LocationInfo struct containing:

    • LocationID: Location database ID
    • LocationName: Room/location name
    • UnitID: Unit/ward ID
    • UnitName: Unit/ward name
    • BuildingID: Building ID
    • BuildingName: Building name

GetPersonInfo

Retrieves person information by device/tag ID.

SQL Query:

SELECT uid, tag_id, tag_type, firstname, lastname
FROM tags 
WHERE tag_id = $1

Parameters:

  • deviceID (int): Device/Tag identifier (32-bit tag ID)

Returns:

  • PersonInfo struct containing:

    • UID: 64-bit unique identifier (tag_type << 32 | tag_id)
    • TagID: 32-bit tag identifier
    • TagType: Tag type (upper 32 bits of UID)
    • FirstName: Person's first name
    • LastName: Person's last name

GetCompleteAlarmInfo

Combines location and person data for a complete alarm context.

Parameters:

  • locationID (int): Location identifier
  • deviceID (int): Device/tag identifier

Returns:

  • CompleteAlarmInfo struct containing both LocationInfo and PersonInfo
  • Returns fallback data if either location or person is not found

REST API Endpoints

The service uses REST APIs for data synchronization with incremental updates:

Buildings APIs

GET {environment_api_base}/v1/environment/buildings
GET {environment_api_base}/v1/events/environment/buildings?since={timestamp}

Units (Wards) APIs

GET {environment_api_base}/v1/environment/wards
GET {environment_api_base}/v1/events/environment/wards?since={timestamp}

Locations APIs

GET {environment_api_base}/v1/environment/locations
GET {environment_api_base}/v1/events/environment/locations?since={timestamp}

Tags APIs

GET {tags_api_base}/v1/tags
GET {tags_api_base}/v1/events/tags?since={timestamp}

Event Sync Mechanism:

  • Events endpoints return incremental changes since the last timestamp
  • Event operations: 1 = created, 2 = updated, 3 = deleted
  • The service stores last sync timestamp per endpoint
  • Full data is fetched only for changed items

Configuration API

The service reads configuration from JSON files. All configuration changes require a service restart:

sudo systemctl restart c2g-alarm-interface-ezcar

Support and Contact

For issues, questions, or contributions:

  • Maintainer: Muhammed muhammed@martin.care
  • Project: C2G Alarm Interface for EZCare
  • Repository: Internal Care2Graph project

License

This is an internal Care2Graph project. All rights reserved.