Skip to content
  • MySensors
  • OpenHardware.io
  • Categories
  • Recent
  • Tags
  • Popular
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo
  1. Home
  2. Feature Requests
  3. RFM69 RSSI value report

RFM69 RSSI value report

Scheduled Pinned Locked Moved Feature Requests
41 Posts 11 Posters 15.8k Views 12 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • G Offline
    G Offline
    gieemek
    wrote on last edited by
    #31

    I do not know Domotich - I am working with openHAB through MQTT protocol, which simply reads the sent value of variable and does not wonder what type they are. Yes, I use S_CUSTOM variable to send RSSI value.
    But it really doesn't matter what kind of variable you use. The variable type tells to MySensors that its value is for example: light level, temperature, or voltage, but you can send a temperature value using the S_POWER variable - no problem with that.
    RSSI should be expressed as an integer, so what is realy important that you choose the variable type declared as integer value, such as i.e. S_LIGHT_LEVEL.
    Once you have that value in the controller (openHAB), you can do whatever you want with it.
    So it is in openHAB, and I hope in Domoticz the same.

    1 Reply Last reply
    0
    • gohanG Offline
      gohanG Offline
      gohan
      Mod
      wrote on last edited by
      #32

      I used S_SOUND so it will report it as 'db', so for now I am happy with it.

      1 Reply Last reply
      0
      • J jpaulin

        @rmtucker Here's the complete sketch. It's a DHT22 temp/humidity battery powered sensor node with an RFM69 radio.

        /**
         * The MySensors Arduino library handles the wireless radio link and protocol
         * between your home built sensors/actuators and HA controller of choice.
         * The sensors forms a self healing radio network with optional repeaters. Each
         * repeater and gateway builds a routing tables in EEPROM which keeps track of the
         * network topology allowing messages to be routed to nodes.
         *
         * Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
         * Copyright (C) 2013-2015 Sensnology AB
         * Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
         *
         * Documentation: http://www.mysensors.org
         * Support Forum: http://forum.mysensors.org
         *
         * This program is free software; you can redistribute it and/or
         * modify it under the terms of the GNU General Public License
         * version 2 as published by the Free Software Foundation.
         *
         *******************************
         *
         * REVISION HISTORY
         * Version 1.0 - Henrik EKblad
         * 
         * DESCRIPTION
         * This sketch provides an example how to implement a humidity/temperature
         * sensor using DHT11/DHT-22 
         * http://www.mysensors.org/build/humidity
         */
        
        // Enable debug prints
        #define MY_DEBUG
        
        // Enable and select radio type attached
        //#define MY_RADIO_NRF24
        #define MY_RADIO_RFM69
        
        #define MY_RFM69_FREQUENCY   RF69_433MHZ
        
        #define MY_NODE_ID 13                        // Identity for temp/hum sensor
        
        // Set blinking period
        #define MY_DEFAULT_LED_BLINK_PERIOD 50
        
        // Flash leds on rx/tx/err
        //#define MY_DEFAULT_ERR_LED_PIN 7           // Error led pin  red
        //#define MY_DEFAULT_RX_LED_PIN  6           // Receive led pin  yellow
        #define MY_DEFAULT_TX_LED_PIN  9             // Transmit led pin  green
        
        #define MY_WITH_LEDS_BLINKING_INVERSE
        
        const byte BATT_ADC = 1;                     // ADC Pin to measure battery level
        
        #include <MySensors.h>
        #include <DHT.h>
        
        
        unsigned long SLEEP_TIME = 300000;           // Sleep time between reads (in milliseconds)
        
        
        
        #define CHILD_ID_HUM 0
        #define CHILD_ID_TEMP 1
        #define DHTPIN 18                            // Input pin from DHT22
        #define DHT22_PWR 6                          // Vdc pin DHT22 to get it to sleep
        #define DHTTYPE DHT22
        
        DHT dht(DHTPIN, DHTTYPE);
        
        
        #define CHILD_ID_RSSI_HIGH  7                // RSSI received signal level
        #define CHILD_ID_RSSI_LOW   8                // RSSI background noise level
        #define CHILD_ID_TEMP2      9                // internal temperature RFM69 chip
        
        int rssi;                                    // RSSI RFM69 chip
        int temp2;                                   // Internal temperature RFM69 chip
        
        int batteryLevel;                            // measured battery level
        int batteryPcnt;                             // measured battery level in percentage
        
        MyMessage msgHum(CHILD_ID_HUM, V_HUM);
        MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP);
        
        MyMessage msgRSSI1(CHILD_ID_RSSI_HIGH, V_VAR1);
        MyMessage msgRSSI2(CHILD_ID_RSSI_LOW, V_VAR1);
        MyMessage msgTemp2(CHILD_ID_TEMP2, V_TEMP);
        
        
        void setup()  
        { 
          pinMode(DHT22_PWR,OUTPUT);
          digitalWrite(DHT22_PWR,HIGH);              // power-on dht22
          wait(2000);
        
          dht.begin();                               // Start-up DHT22 sensor Temperature/Humidity
        }
        
        void presentation() 
        {
          // Send the sketch version information to the gateway and Controller
          sendSketchInfo("Temp_Hum", "1.0");
        
          // Register all sensors to gw (they will be created as child devices)
          present(CHILD_ID_HUM, S_HUM);
          present(CHILD_ID_TEMP, S_TEMP);
        
          present(CHILD_ID_RSSI_HIGH, S_CUSTOM);
          present(CHILD_ID_RSSI_LOW, S_CUSTOM);
          present(CHILD_ID_TEMP2, S_TEMP);
        }
        
        void loop()      
        {
          float humidity = dht.readHumidity();       // get dht22 humidity
          if (isnan(humidity)) {
            Serial.println("Failed reading humidity from DHT");
          } else {
            send(msgHum.set(humidity, 1));           // send dht22 humidity
            wait(200);
          }
        
          float temperature = dht.readTemperature(); // get dht22 temperature
          if (isnan(temperature)) {
            Serial.println("Failed reading temperature from DHT");
          } else {
            send(msgTemp.set(temperature, 1));       // send dht22 temperature
          }
          digitalWrite(DHT22_PWR,LOW);               // save some power
          
          rssi = _radio.readRSSI();                  // read RSSI in RFM69. Measure reception signal from gw
          send(msgRSSI1.set(rssi));                  // send RSSI level
          wait(500);                                 // wait to get idle
          
          rssi = _radio.readRSSI();                  // read RSSI in RFM69. Wait and measure background noise
          send(msgRSSI2.set(rssi));                  // send RSSI level
          wait(200);                                 // wait for next send
          
          temp2 = _radio.readTemperature(1);         // read temperature in RFM69
          send(msgTemp2.set(temp2));                 // send temperature
        
          batteryLevel = analogRead(BATT_ADC);       //  (* 0.0032225806)
          batteryPcnt = batteryLevel / 10;           // battery percentage
          
          sendBatteryLevel(batteryPcnt);             // send battery level in percentage to controller
        
          // if (oldBatteryPcnt != batteryPcnt) {    // use if not to send every cycle
          //     sendBatteryLevel(batteryPcnt);
          //     oldBatteryPcnt = batteryPcnt;
          // }
        
          
          sleep(SLEEP_TIME);                         // sleep a bit
          digitalWrite(DHT22_PWR,HIGH);              // wake up DHT sensor
          wait(2000);                                // warm up DHT sensor
        }
        
        void receive(const MyMessage &message) {
          // We only expect one type of message from controller. But we better check anyway.
          Serial.println("something came in");
          
          if (message.type==V_VAR1) {                // reception to change SLEEP_TIME.
             SLEEP_TIME = message.getULong();        // send topic: eg. my_RFM69_gw1-in/3/1/1/0/24 30000 (payload in ms)
           }                                         // MQTT_publish_topic_prefix/Node_Id/Sensor_Id/Cmd_Type/Ack_flag/type(V_VAR1=24) payload
        }
        
        

        readRSSI(); is an internal function in the RFM69.h / RFM69.cpp library that I'm calling in the sketch to get the RSSI and background noise level.

        zboblamontZ Offline
        zboblamontZ Offline
        zboblamont
        wrote on last edited by
        #33

        @jpaulin I can see the value of obtaining Gateway RSSI for individual battery powered nodes to inform programmed power settings on them in the absence of ATC implementation at the Node itself, but not sure I understand the purpose of RSSI readings at the node other than to establish noise thresholds on the Gateway signal.

        Although the function of the Gateway is to forward messages to the Controller, is it possible for the Gateway to read and forward RSSI readings for nodes as if locally attached sensors?

        1 Reply Last reply
        0
        • gohanG Offline
          gohanG Offline
          gohan
          Mod
          wrote on last edited by
          #34

          Reading rssi and power on the node it gives you an idea of how much signal that node is getting and if there are interferences around it

          zboblamontZ 1 Reply Last reply
          0
          • gohanG gohan

            Reading rssi and power on the node it gives you an idea of how much signal that node is getting and if there are interferences around it

            zboblamontZ Offline
            zboblamontZ Offline
            zboblamont
            wrote on last edited by
            #35

            @gohan Yes, I understood that aspect. I can imagine certain environments where the SNR might inform change of Node location or shielding or directivity of antenna, or increased output from the Gateway, but I would have thought that a one-off task unless the node noise background changes frequently...

            1 Reply Last reply
            0
            • gohanG Offline
              gohanG Offline
              gohan
              Mod
              wrote on last edited by
              #36

              You can always put a counter to send rssi reports after X amount of other data being sent

              zboblamontZ 1 Reply Last reply
              0
              • gohanG gohan

                You can always put a counter to send rssi reports after X amount of other data being sent

                zboblamontZ Offline
                zboblamontZ Offline
                zboblamont
                wrote on last edited by
                #37

                @gohan True, but if no change to the environment is anticipated, why use battery power to convey it at all?
                My own interest in what RSSI the Gateway is receiving should also be a one-time exercise, but is more difficult to implement I suppose.

                Until such time the 2.2 version is released, and what it provides becomes clearer, I might just do the checking with two portable nodes...

                1 Reply Last reply
                0
                • gohanG Offline
                  gohanG Offline
                  gohan
                  Mod
                  wrote on last edited by
                  #38

                  I can show you how background noise rssi and power output changes during the day and I'm not moving things around

                  zboblamontZ 1 Reply Last reply
                  0
                  • gohanG gohan

                    I can show you how background noise rssi and power output changes during the day and I'm not moving things around

                    zboblamontZ Offline
                    zboblamontZ Offline
                    zboblamont
                    wrote on last edited by
                    #39

                    @gohan Not disputing SNRs vary, what I meant by change to the environment at the node was unforeseen pollution influences, such as somebody working with a welder right beside the node after you had already established the peak diurnal noise and set everything up.

                    The Gateway usually can run permanently at high gain, the Node can only do so at the expense of battery life...

                    1 Reply Last reply
                    0
                    • gohanG Offline
                      gohanG Offline
                      gohan
                      Mod
                      wrote on last edited by
                      #40

                      ACS helps a lot, but by recording rssi and tx power I noticed why thenode occasionally was going offline

                      zboblamontZ 1 Reply Last reply
                      0
                      • gohanG gohan

                        ACS helps a lot, but by recording rssi and tx power I noticed why thenode occasionally was going offline

                        zboblamontZ Offline
                        zboblamontZ Offline
                        zboblamont
                        wrote on last edited by
                        #41

                        @gohan Fair comment, it was the best tool to resolve the problem.
                        I spent 3 days reviewing what I had programmed, inspected wiring, and testing all DS18B20s, two of which are in the loft, only to discover that a faulty telephone socket had partially dislodged it's pins, my tool to resolve? A magnifying glass.... Isn't technology wonderful...:snail:

                        1 Reply Last reply
                        0
                        Reply
                        • Reply as topic
                        Log in to reply
                        • Oldest to Newest
                        • Newest to Oldest
                        • Most Votes


                        11

                        Online

                        11.7k

                        Users

                        11.2k

                        Topics

                        113.0k

                        Posts


                        Copyright 2019 TBD   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service
                        • Login

                        • Don't have an account? Register

                        • Login or register to search.
                        • First post
                          Last post
                        0
                        • MySensors
                        • OpenHardware.io
                        • Categories
                        • Recent
                        • Tags
                        • Popular