Wednesday, February 18, 2015

Web interface - log

One of the important pages provided by the embedded web server is a log. It translates various system messages to meaningful text(at least for me :). The table is showing 20 entries at once and you can list through them by buttons << and >>. Button "now" will take you to the most recent message. As you can see on the left, there is numeric id of the message, time stamp, the message text and status of the SMS function. Above the table is a button to clear all the log table, but it takes a while.

Physically the log is located in 512kb I2C controlled EEPROM, and the logging mechanism using 16 bytes for every event. This makes together maximum number of 4096 log messages stored. Any call to log message  function pushes the message to FIFO along with actual time stamp. Then there is a logger thread that takes care about the EEPROM circular buffer, and also about the SMS. Every message can be send as SMS to appropriate group of people.

The message itself looks like this:

150218104158;SCW

As you can deduce the "15 02 18" is date, "10 41 45" is time, next is the status of SMS function:
  • "." requested, failed
  • "," not requested, failed
  • ";" not requested, acknowledged
  • "|" not connected
  • ":" sent
And last 3 characters is the message itself, well not actually, but it is its acronym or code. SCW is "System configuration saved, by pressing button on web interface". All these are decoded by web server and SMS function. You can look for more in code.

Logger thread also pushes all messages into following MQTT topics:

OHS/Log 150218104158;SCW

I'm planning to create on/off button for MQTT push.

Saturday, February 7, 2015

Web interface - sensors

Sensor configuration page has a lot similar with authentication units. Sensor can be connected by wire(RS485) or wireless(RFM12B). It is shown in the address field. "W" stands for wired and "R" for Radio. Units in range 1-14 are wired and 17-143 are connected wireless. Currently the firmware recognize following types:
  • Temperature
  • Humidity
  • Pressure
The type and address is coded in the registration message in the sensor firmware. Other values can be configured and are stored in unit in chip EEPROM. As you can see above you can turn the sensor On or Off. Also you can allow the sensor value to be propagated to MQTT. The default path is "OHS/Group_name/Sensor/Sensor_Type/Sensor_local_address". Example looks like this:

OHS/Zahrada/Sensor/Temperature/0  23.00
OHS/Zahrada/Sensor/Humidity/0  53.00
OHS/Zahrada/Sensor/Temperature/1  24.04
OHS/Zahrada/Sensor/Pressure/0 998.38
OHS/Dilna/Sensor/Temperature/0   9.48
OHS/Domek/Sensor/Temperature/0  13.02
OHS/Garaz/Sensor/Temperature/0  12.06

Last setting is the group name the sensor belongs to.

Sensors are dynamically added when they first join the network. The Sensor type can be chosen to any possible, as long as its value can be stored i a float variable. Main unit does not care about the sensors at all, it doesn't do any computation with it values, and also it does not verify the content. Main purpose is to act as a gateway for MQTT to NodeRed or similar tool. Only value that indicate the health of the sensor is time-stamp called last OK, that indicates delivery time of last message from sensor.

Sensors are defined in the code by following struct:


  uint8_t address;
  char    type;
  uint8_t number;
//          |- MQTT publish
//          ||- Free    
//          |||- Free
//          |||||||- Group number
//          |||||||- 0 .. 15
//          |||||||- 
//          |||||||- 
//          ||||||||-  Enabled   
//          00000000
  uint8_t setting;
  float   value;
  systime_t last_OK = 0;

In the future, the parameters for sensors, and also for authentication units, will extend as they will be battery monitored. I would like main board to take care of the sensors battery life in form of some flag and also sms.