Sinapse Devices - Sinapse-Energia/CMS-Revolution GitHub Wiki

Introduction

Here are explained the Sinapse Devices to be managed through the CMS. Each device explanation contains at least four parts:

  • Static Data
  • Operation Data
  • Features
  • MQTT API

CMC

This device is normally installed in a control panel of a electrical installation, mostly are lighting installations. The CMC speaks the Sinapse MQTT protocol, easing actuation over it and its monitoring. The CMC contains up to 7 relays and several analog / digital IO that ease the installation of third party sensors and actuators.

Static Data For CMC

Name Type Required Comment
Name text Y
ID_Code text Y Unique
ID_Communication text Y Unique
Location text Y
Longitude double Y
Latitude double Y
Altitude double Y
Date_Installation timestamp Y
Circuit_Number integer Y Number of circuits managed by the CMC. Minimum = 0, Maximum = 7
Name_Street text N
Number_Street text N
Power_Installed text N
Power_Contracted text N
ID_Supply_Contract text N
Clock_Brand text N
Clock_Model text N

Operation Data

The operational data of a CMC is divided in three different parts, all of them linked with an existing CMC.

Monitoring data

Data sent by a CMC that characterizes how is working the CMC.

Name Type Required Comment
I1 float Y
I2 float Y
I3 float Y
IN float Y
U12 float Y
U23 float Y
U32 float Y
V1N float Y
V2N float Y
V3N float Y
P1 float Y
P2 float Y
P3 float Y
Q1 float Y
Q2 float Y
Q3 float Y
FDP1 float Y
FDP2 float Y
FDP3 float Y
FDPS1 float Y
FDPS2 float Y
FDPS3 float Y
EP1 float Y
EP2 float Y
EP3 float Y
EQ1 float Y
EQ2 float Y
EQ3 float Y
ES1 float Y
ES2 float Y
ES3 float Y
F float Y
TIMESTAMP timestamp Y

Relay status data

The relay status are set by the user sending a command. The CMC send also how are they relays after a question. The relay status set bu the user should be saved in a table. The relay status sent by the CMC should be also saved in another table

Name Type Required Comment
Relay_Status_user array Y Represents the status of the seven (7) relays
TIMESTAMP timestamp Y
Name Type Required Comment
Relay_Status_device array Y Represents the status of the seven (7) relays
TIMESTAMP timestamp Y

Schedulers

Data set by the user in the CMS-R. It represents how will be set the relays in a concrete date.

DATA MODEL TO BE DESIGNED

Features

  1. CMS-Revolution should be able to manage N CMCs. Max N = 200
  2. CMS-Revolution should provide an easy to use interface in order to act (On Demand) over the relays of a CMC
  3. CMS-Revolution should provide an easy to use interface in order to act (On Demand) over the relays of M CMCs
  4. CMS-Revolution should provide an easy to use interface in order to act (Scheduler) over the relays of a CMC
  5. CMS-Revolution should provide an easy to use interface in order to act (Scheduler) over the relays of M CMCs
  6. CMS-Revolution should provide a way to see the current status of the relays of a CMC
  7. CMS-Revolution should provide a way to see the current status of the relays of M CMC
  8. CMS-Revolution should provide a way to see the monitored magnitudes in real time and historically. Table / Graphical representation should be used.
  9. All the representation of the monitored magnitudes should be downloadable in .pdf

MQTT API

The Sinapse MQTT API is provided through a RoR gem. Here are explained the messages itself and also how to use the gem in order to desired message

TOPICS

From CMS-Revolution point of view

Type Topic Messages Comment
PUBLISH {INSTALLATION_NAME}/CMC/ACT/{CMC_ID} TBD CMS publish a message in order to act over the CMC with CMC_ID
SUBSCRIPTION {INSTALLATION_NAME}/CMC/MEASUREMENTS TBD CMS receives responses to on demand questions
SUBSCRIPTION {INSTALLATION_NAME}/CMC/PERIODIC TBD CMS receives responses to periodic questions
SUBSCRIPTION {INSTALLATION_NAME}/CMC/ALERTS TBD CMS receives alerts calculated in the CMC device
SUBSCRIPTION {INSTALLATION_NAME}/CMC/DEBUG TBD CMS receives debug messages from CMC

Explanation of variables

  • INSTALLATION_NAME : Is the identification of a concrete project. Each CMS-Revolution instance have an INSTALLATION_NAME
  • CMC_ID: Is the ID_Communication of the CMC. Each CMC has a communication ID. Normally is the 6 last digits of the transceiver MAC. It can be also a Broadcast ID where all the CMCs are listening, used normally to act over all the CMCs of an installation at the same time

MESSAGES

ACT over Relays (On demand)

  • Message : 11;ACTN1;ACTN2;ACTN3;ACTN4;ACTN5;ACTN6;ACTN7;OVERWRITE_SCHEDULER; , where NM could have the values [1 / 0 / X] and OVERWRITE_SCHEDULER is can be TRUE / FALSE
  • Example : 11;ACT1;ACT1;ACT1;ACT0;ACT0;ACT0;ACTX; : Set relays 1,2 and 3 to ON, 4,5 and 6 to OFF and 7 leave as actual status
  • Published through: {INSTALLATION_NAME}/CMC/ACT/{CMC_ID}
  • Response: -
  • Behaviour: Message published to act on demand over the relays of the device. 1 means ON, 0 means OFF and X means leave as the actual status

Note The CMC has 7 relays

ACT over Relays (Periodic / scheduled)

  • Message : 10;RELNS;H1H1:M1M1;H2H2:M2M2;NTIMES;,where N is the number of the relay and S is the status to be applied, so N : [0 .. 7] and S is [1 / 0 / X] and NTIMES represents the number of the days or always (-1)
  • Example : 10;REL41;20:00;23:00;-1; , The relay 4 for be set to ON between 20:00 and 23:00 always, the rest of the day will the relay will be set to OFF (See Note1)
  • Published through: {INSTALLATION_NAME}/CMC/ACT/{CMC_ID}
  • Response: -
  • Behaviour: Message to act periodically at scheduled times over the relays. A message applies ONLY to one relay.

Note 1 Relays actuation are bi-state signals, can be 1 (ON) or 0 (OFF). When a scheduled action is set in an interval, a day will be considered as a complete interval with 2 sub-intervals with each state.

Note 2 The time (HH:MM) can be related with a offset over Sunset / Sunrise. It is used a special notation in this case: SR+-OFFSET or SS+-OFFSET where SR means Sunrise and SS means Sunset and the OFFSET is set in minutes (1440 is the Maximum). Example: 10;REL41;SR+15;SS-15;-1;

Interaction between actuation. OnDemand vs Scheduler

If a ondemand (11;) command is sent during an scheduler (10;), the behaviour should be the following one:

  • 11; with OVERWRITE_SCHEDULER == FALSE: The relays should get the value set by 11; until the next step of 10;, then continue with the scheduler set by 10;

  • 11; with OVERWRITE_SCHEDULER == TRUE: The relays should get the value set by 11; and remove the scheduler set by 10; of the relays with values different to X. (Default behaviour)

Ask about status (On demand)

  • Message : L3_READ_METERING_OD;
  • Published through: {INSTALLATION_NAME}/CMC/ACT/{CMC_ID}
  • Response : L3_READ_METERING_R;...; See Measurement command
  • Behaviour : Get the current status of the network analyzer via Modbus and return the status

Ask about status (Periodically)

  • Message : L3_READ_METERING_P;MIN;H1H1:M1M1;H2H2:M2M2;NTIMES; Same as EPD but the hours could be relative to Sunset / Sunrise. See Note 1
  • Published through: INSTALLATION_NAME/CMC/ACT/CMC_ID
  • Response : L3_READ_METERING_R;...; See Measurement command
  • Behaviour : Get the current status of the network analyzer via Modbus and return the status

Note 1 The time (HH:MM) can be related with a offset over Sunset / Sunrise. It is used a special notation in this case: SR+-OFFSET or SS+-OFFSET where SR means Sunrise and SS means Sunset and the OFFSET is set in minutes (1440 is the Maximum). Example: 10;REL41;SR+15;SS-15;-1;

Measurements

  • Message: L3_READ_METERING_R;CMC_ID;I1;I2;I3;IN;U12;U23;U31;V1N;V2N;V3N;P1;P2;P3;Q1;Q2;Q3;S1;S2;S3;FDP1;FDP2;FDP3;FDPS1;FDPS2;FDPS3;EP1;EP2;EP3;EQ1;EQ2;EQ3;ES1;ES2;ES3;F;TIMESTAMP;. Meaning of each field is explained in the Note 1
  • Received through: {INSTALLATION_NAME}/CMC/MEASUREMENTS or {INSTALLATION_NAME}/CMC/PERIODIC
  • Response_to: L3_READ_METERING_OD; and L3_READ_METERING_P;
  • Behaviour: Response to the Read Metering commands. The message contains the values got from the Network Analyzer via Modbus. See Note 2

Note 1

  • L3_READ_METERING_R: Command ID
  • CMC_ID: Device ID.
  • I1: phase1, maximum current threshold. [+/-1mA precision].
  • I2: phase2, maximum current threshold. [+/-1mA precision].
  • I3: phase3, maximum current threshold. [+/-1mA precision].
  • IN: neutral, maximum current threshold. [+/-1mA precision].
  • U12: phase1, maximum voltage threshold. [+/-0.1V precision].
  • U23: phase2, maximum voltage threshold. [+/-0.1V precision].
  • U31: phase3, maximum voltage threshold. [+/-0.1V precision].
  • V1N: line1, maximum voltage threshold. [+/-0.1V precision].
  • V2N: line2, maximum voltage threshold. [+/-0.1V precision].
  • V3N: line3, maximum voltage threshold [+/-0.1V precision].
  • P1: phase1 active power [+/-0.1W precision].
  • P2: phase2 active power [+/-0.1W precision].
  • P3: phase3 active power [+/-0.1W precision].
  • Q1: phase1 reactive power [+/-0.1VAr precision].
  • Q2: phase2 reactive power [+/-0.1VAr precision].
  • Q3: phase3 reactive power [+/-0.1VAr precision].
  • S1: phase1 apparent power [+/-0.1VA precision].
  • S2: phase2 apparent power [+/-0.1VA precision].
  • S3: phase3 apparent power [+/-0.1VA precision].
  • FDP: power factor [+/- 0.01 precision].
  • FDPS: power factor sector: -1 = inductive, 1 = capacitive.
  • EP: Aggregated active energy consumption since last publication [+/-0.1Wh precision].
  • EQ: Aggregated reactive energy consumption since last publication [+/-0.1VArh precision].
  • ES: Aggregated apparent energy consumption since last publication [+/-0.1Vah precision].
  • F: Frequency of lines [+/-0.1Hz precision].
  • TIMESTAMP: Timestamp of the measurement, format 4 bytes UNIX Time*

GEM Mapping

TBD