Oumuamua
@Oumuamua
Best posts made by Oumuamua
-
RE: ESP8266 + RFM69 Reset loop (rst cause:4, boot mode:(3,7))
No, actually I use the RPi just as power source. The gateway connects to the hub over WiFi.
The RPi is good (the original one). I will try to move to an independent power source just to test.
Thanks for the reply again.
-
RE: [SOLVED] High battery usage (Pro-Mini / RFM69 / Si7021)
Guys,
Just quick update to help others that may find this topic relevant: problem is solved. Problem was the step-up (probably low quality). Sensor is working well and with very low battery usage (no change in 5 days).
Thanks for the comments.
-
RE: Raspberry Pi 3 (RPI 3) gateway initialization loop
Problem solved: I was using as --my-mqtt-client-id the same name as my previous broker.
Thanks for your help all!
-
RE: Sudden battery drain - Pro-mini + RFM69
I haven’t moved the sensor to a weatherproof case (still figuring out the new design), but I connected it to an external power source.
The circuit is operating perfectly.
If humidity or something alike had damaged it, it should be not working, right?
Although I think it is important to use the weatherproof case, I feel something else is happening here.
@skywatch: where I live in BR temperature ranges between 5-36C. I can see some fluctuations in battery V when temp changes, but usually around 0.05V
Thanks!
-
RE: Consistent NACK + RPI Gateway
Thanks for the hint @mfalkvidd
After much research (mainly here and here), it does look like RFM69+RPI+Mysensors 2.3.x don't like each other very much.
However, I updated my RPI code to the latest version (at RPI, move to MySensors directory, then "git pull", then make+install gateway again) and the NACK problem was completely solved. I also had many NACK during presentation, which all went away. Problem solved and it seems that the radio is performing faster (probably less time waiting ACK).
I also tried to address the low RSSI at gateway (again, it seems a recurring problem for RFM69+RPI) using this code, but it didn't "make".
Would you have any insight on the RSSI issue as well? It seems that you participated in some part of the discussion (here ).
Thanks!
-
RE: Sudden battery drain - Pro-mini + RFM69
Hi all,
Should anyone face the same problem, I found the root cause: brownout threshold. I burned a new bootloader (Optiboot 8.0) without such trigger and the node has been working with used batteries (~2.7V) since May.
Hope this helps.
Latest posts made by Oumuamua
-
RE: Node broadcast loop
Solved. Issue with power supply. Added a capacidade to power source.
-
Node broadcast loop
Hi all,
I have a node with 2 sensor that have been working well for weeks and suddenly starts to loop on some kind of broadcasting message. It comes back if I restart the RPI+Gateway (but not if I just restart the Mysensor service at RPI).
I would like to solve it the right way, instead of having to reboot the server every time it happens.
This is the log at the server:
Oct 13 20:44:27 DEBUG TSF:MSG:READ,2-2-255,s=255,c=3,t=7,pt=0,l=0,sg=0: Oct 13 20:44:27 DEBUG TSF:MSG:BC Oct 13 20:44:27 DEBUG TSF:MSG:FPAR REQ,ID=2 Oct 13 20:44:27 DEBUG TSF:CKU:OK,FCTRL Oct 13 20:44:27 DEBUG TSF:MSG:GWL OK Oct 13 20:44:28 DEBUG !TSF:MSG:SEND,0-0-2-2,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0 Oct 13 20:44:30 DEBUG TSF:MSG:READ,2-2-255,s=255,c=3,t=7,pt=0,l=0,sg=0: Oct 13 20:44:30 DEBUG TSF:MSG:BC Oct 13 20:44:30 DEBUG TSF:MSG:FPAR REQ,ID=2 Oct 13 20:44:30 DEBUG TSF:CKU:OK,FCTRL Oct 13 20:44:30 DEBUG TSF:MSG:GWL OK Oct 13 20:44:31 DEBUG !TSF:MSG:SEND,0-0-2-2,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0 Oct 13 20:44:32 DEBUG TSF:MSG:READ,2-2-255,s=255,c=3,t=7,pt=0,l=0,sg=0: Oct 13 20:44:32 DEBUG TSF:MSG:BC Oct 13 20:44:32 DEBUG TSF:MSG:FPAR REQ,ID=2 Oct 13 20:44:32 DEBUG TSF:CKU:OK,FCTRL Oct 13 20:44:32 DEBUG TSF:MSG:GWL OK Oct 13 20:44:34 DEBUG !TSF:MSG:SEND,0-0-2-2,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0 Oct 13 20:45:35 DEBUG TSF:MSG:READ,2-2-255,s=255,c=3,t=7,pt=0,l=0,sg=0: Oct 13 20:45:35 DEBUG TSF:MSG:BC Oct 13 20:45:35 DEBUG TSF:MSG:FPAR REQ,ID=2 Oct 13 20:45:35 DEBUG TSF:PNG:SEND,TO=0 Oct 13 20:45:35 DEBUG TSF:CKU:OK Oct 13 20:45:35 DEBUG TSF:MSG:GWL OK Oct 13 20:45:37 DEBUG !TSF:MSG:SEND,0-0-2-2,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
This is the node's code:
/** * 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 * Version 1.1 - 2016-07-20: Converted to MySensors v2.0 and added various improvements - Torben Woltjen (mozzbozz) * * DESCRIPTION * This sketch provides an example of how to implement a humidity/temperature * sensor using a DHT11/DHT-22. * * For more information, please visit: * http://www.mysensors.org/build/humidity * */ // Enable debug prints #define MY_DEBUG // Atualizar para nó esperado #define MY_NODE_ID 2 // Novo driver para gateway RPI #define MY_RFM69_NEW_DRIVER // Enable and select radio type attached #define MY_RADIO_RFM69 #define MY_RFM69_FREQUENCY RFM69_433MHZ // Define for frequency setting. Needed if you're radio module isn't 868Mhz (868Mhz is default in lib) #define MY_IS_RFM69HW // Mandatory if you radio module is the high power version (RFM69HW and RFM69HCW), Comment it if it's not the case #include <SPI.h> #include <MySensors.h> #include <DHT.h> #include <NewPing.h> // Set this to the pin you connected the DHT's data pin to #define DHT_DATA_PIN 3 // Sonar parameters #define TRIGGER_PIN 8 // Arduino pin tied to trigger pin on the ultrasonic sensor. #define ECHO_PIN 9 // Arduino pin tied to echo pin on the ultrasonic sensor. #define MAX_DISTANCE 200 // Maximum distance we want to ping for (in centimeters). Maximum sensor distance is rated at 400-500cm. #define ITERATIONS 5 // Number of iterations. // Set this offset if the sensor has a permanent small offset to the real temperatures. // In Celsius degrees (as measured by the device) #define SENSOR_TEMP_OFFSET 0 NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE); // NewPing setup of pins and maximum distance. // Sleep time between sensor updates (in milliseconds) // Must be >1000ms for DHT22 and >2000ms for DHT11 static const uint64_t UPDATE_INTERVAL = 600000; // 600000 = 10 min // Force sending an update of the temperature after n sensor reads, so a controller showing the // timestamp of the last update doesn't show something like 3 hours in the unlikely case, that // the value didn't change since; // i.e. the sensor would force sending an update every UPDATE_INTERVAL*FORCE_UPDATE_N_READS [ms] static const uint8_t FORCE_UPDATE_N_READS = 5; #define CHILD_ID_HUM 0 #define CHILD_ID_TEMP 1 #define CHILD_ID_RSSI 2 //RSSI #define CHILD_ID_VOLT 3 //Voltage #define CHILD_ID_DIST 4 //Distance //float lastTemp; //float lastHum; //uint8_t nNoUpdatesTemp; //uint8_t nNoUpdatesHum; bool metric = true; int8_t rssiVal; //RSSI uint8_t dist; //static const uint8_t update_count = 6; // 6 = every 1 hour //uint8_t count = 100; // > than update_count MyMessage msgHum(CHILD_ID_HUM, V_HUM); MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP); MyMessage msgRSSI(CHILD_ID_RSSI,V_VAR5); MyMessage msgDist(CHILD_ID_DIST, V_DISTANCE); MyMessage msgVOLT(CHILD_ID_VOLT,V_VOLTAGE); DHT dht; void presentation() { // Send the sketch version information to the gateway sendSketchInfo("Temperature+Humidity+Sonar", "2.0"); // sendSketchInfo("Battery Meter", "1.0"); // sendSketchInfo("No02_DHT11+Sonar_v06"); // 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, S_CUSTOM); present(CHILD_ID_DIST, S_DISTANCE); present(CHILD_ID_VOLT, S_MULTIMETER); metric = getControllerConfig().isMetric; } void setup() { // Battery // use the 1.1 V internal reference #if defined(__AVR_ATmega2560__) analogReference(INTERNAL1V1); #else analogReference(INTERNAL); #endif dht.setup(DHT_DATA_PIN); // set data pin of DHT sensor if (UPDATE_INTERVAL <= dht.getMinimumSamplingPeriod()) { Serial.println("Warning: UPDATE_INTERVAL is smaller than supported by the sensor!"); } // Sleep for the time of the minimum sampling period to give the sensor time to power up // (otherwise, timeout errors might occure for the first reading) sleep(dht.getMinimumSamplingPeriod()); } void loop() { // Force reading sensor, so it works also after sleep() dht.readSensor(true); // Get temperature from DHT library float temperature = dht.getTemperature(); if (isnan(temperature)) { Serial.println("Failed reading temperature from DHT!"); } else { // } else if (temperature != lastTemp || nNoUpdatesTemp == FORCE_UPDATE_N_READS) { // Only send temperature if it changed since the last measurement or if we didn't send an update for n times // lastTemp = temperature; // apply the offset before converting to something different than Celsius degrees temperature += SENSOR_TEMP_OFFSET; if (!metric) { temperature = dht.toFahrenheit(temperature); } // Reset no updates counter // nNoUpdatesTemp = 0; send(msgTemp.set(temperature, 2)); #ifdef MY_DEBUG Serial.print("T: "); Serial.println(temperature); #endif // } else { // Increase no update counter if the temperature stayed the same // nNoUpdatesTemp++; } // Get humidity from DHT library float humidity = dht.getHumidity(); if (isnan(humidity)) { Serial.println("Failed reading humidity from DHT"); } else { // } else if (humidity != lastHum || nNoUpdatesHum == FORCE_UPDATE_N_READS) { // Only send humidity if it changed since the last measurement or if we didn't send an update for n times // lastHum = humidity; // Reset no updates counter // nNoUpdatesHum = 0; send(msgHum.set(humidity, 2)); #ifdef MY_DEBUG Serial.print("H: "); Serial.println(humidity); #endif // } else { // Increase no update counter if the humidity stayed the same // nNoUpdatesHum++; } // rssiVal = _radio.readRSSI(); // Old Driver rssiVal = RFM69_getSendingRSSI(); // New Driver send(msgRSSI.set(rssiVal)); #ifdef MY_DEBUG Serial.print("RSSI Sending: "); Serial.println(rssiVal); // Serial.print("RSSI Receiving: "); // Serial.println(RFM69_getReceivingRSSI()); #endif dist = sonar.convert_cm(sonar.ping_median(ITERATIONS, MAX_DISTANCE)); #ifdef MY_DEBUG Serial.print("Dist: "); Serial.print(dist); Serial.println("cm"); #endif if (dist > 0) { dist = 90 - dist; send(msgDist.set(dist, 2)); } long batteryMillivolts = hwCPUVoltage(); send(msgVOLT.set(batteryMillivolts / 1000.0, 2)); #ifdef MY_DEBUG Serial.print(batteryMillivolts / 1000.0); Serial.println(" V"); #endif // Sleep for a while to save energy sleep(UPDATE_INTERVAL); }
This is the configuration of the RPI gateway
./configure --my-gateway=mqtt --my-controller-ip-address=127.0.0.1 --my-mqtt-user=user --my-mqtt-password=password --my-mqtt-publish-topic-prefix=mygateway1-out --my-mqtt-subscribe-topic-prefix=mygateway1-in --my-mqtt-client-id=gw_02 --my-transport=rfm69 --my-rfm69-frequency=433 --my-is-rfm69hw --extra-cxxflags="-DMY_DEBUG_VERBOSE_GATEWAY"
Thanks!
-
RE: Sudden battery drain - Pro-mini + RFM69
Hi all,
Should anyone face the same problem, I found the root cause: brownout threshold. I burned a new bootloader (Optiboot 8.0) without such trigger and the node has been working with used batteries (~2.7V) since May.
Hope this helps.
-
RE: Consistent NACK + RPI Gateway
Thanks for the hint @mfalkvidd
After much research (mainly here and here), it does look like RFM69+RPI+Mysensors 2.3.x don't like each other very much.
However, I updated my RPI code to the latest version (at RPI, move to MySensors directory, then "git pull", then make+install gateway again) and the NACK problem was completely solved. I also had many NACK during presentation, which all went away. Problem solved and it seems that the radio is performing faster (probably less time waiting ACK).
I also tried to address the low RSSI at gateway (again, it seems a recurring problem for RFM69+RPI) using this code, but it didn't "make".
Would you have any insight on the RSSI issue as well? It seems that you participated in some part of the discussion (here ).
Thanks!
-
Consistent NACK + RPI Gateway
Hi all,
Since I moved to RPI gateway (which I prefer), I've been having consistent NACK on some messages. I suspect it is related (but maybe not the cause) with some node reboots / battery drain.
On one node, I always (and I ran multiple tests) NACK when sending the RSSI message, despite temperature and humidity never get NACK.
I already tried sending RSSI before Temp and Hum, but it always get NACK.
The MQTT server still receives the information.
Any insight on why this is happening?
Node debug log
17:31:35.480 -> 32362 TSF:MSG:SEND,2-2-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=1,st=OK:24.00 17:31:35.580 -> 32467 TSF:MSG:SEND,2-2-0-0,s=0,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=OK:95.00 17:31:37.836 -> 34721 !TSF:MSG:SEND,2-2-0-0,s=2,c=1,t=48,pt=2,l=2,sg=0,ft=0,st=NACK:-61
Gateway log
Jun 15 17:31:35 DEBUG TSF:MSG:READ,2-2-0,s=1,c=1,t=0,pt=7,l=5,sg=0:24.00 Jun 15 17:31:35 DEBUG GWT:TPS:TOPIC=mygateway1-out/2/1/1/0/0,MSG SENT Jun 15 17:31:35 DEBUG TSF:MSG:READ,2-2-0,s=0,c=1,t=1,pt=7,l=5,sg=0:95.00 Jun 15 17:31:35 DEBUG GWT:TPS:TOPIC=mygateway1-out/2/0/1/0/1,MSG SENT Jun 15 17:31:36 DEBUG TSF:MSG:READ,2-2-0,s=2,c=1,t=48,pt=2,l=2,sg=0:-61 Jun 15 17:31:36 DEBUG TSF:MSG:ECHO REQ Jun 15 17:31:39 DEBUG !TSF:MSG:SEND,0-0-2-2,s=2,c=1,t=48,pt=2,l=2,sg=0,ft=0,st=NACK:-61 Jun 15 17:31:39 DEBUG GWT:TPS:TOPIC=mygateway1-out/2/2/1/0/48,MSG SENT
Node code
/** * 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 * Version 1.1 - 2016-07-20: Converted to MySensors v2.0 and added various improvements - Torben Woltjen (mozzbozz) * * DESCRIPTION * This sketch provides an example of how to implement a humidity/temperature * sensor using a DHT11/DHT-22. * * For more information, please visit: * http://www.mysensors.org/build/humidity * */ // Enable debug prints #define MY_DEBUG // Atualizar para nó esperado #define MY_NODE_ID 2 // Novo driver para gateway RPI #define MY_RFM69_NEW_DRIVER // Enable and select radio type attached //#define MY_RADIO_RF24 #define MY_RADIO_RFM69 //#define MY_RS485 #define MY_RFM69_FREQUENCY RFM69_433MHZ // Define for frequency setting. Needed if you're radio module isn't 868Mhz (868Mhz is default in lib) #define MY_IS_RFM69HW // Mandatory if you radio module is the high power version (RFM69HW and RFM69HCW), Comment it if it's not the case #include <SPI.h> #include <MySensors.h> #include <DHT.h> // Set this to the pin you connected the DHT's data pin to #define DHT_DATA_PIN 3 // select the input pin for the battery sense point int BATTERY_SENSE_PIN = A0; int oldBatteryPcnt = 0; // Set this offset if the sensor has a permanent small offset to the real temperatures. // In Celsius degrees (as measured by the device) #define SENSOR_TEMP_OFFSET 0 // Sleep time between sensor updates (in milliseconds) // Must be >1000ms for DHT22 and >2000ms for DHT11 static const uint64_t UPDATE_INTERVAL = 600000; // Force sending an update of the temperature after n sensor reads, so a controller showing the // timestamp of the last update doesn't show something like 3 hours in the unlikely case, that // the value didn't change since; // i.e. the sensor would force sending an update every UPDATE_INTERVAL*FORCE_UPDATE_N_READS [ms] static const uint8_t FORCE_UPDATE_N_READS = 5; #define CHILD_ID_HUM 0 #define CHILD_ID_TEMP 1 #define CHILD_ID_RSSI 2 //RSSI #define CHILD_ID_BAT 3 //BATTERY float lastTemp; float lastHum; uint8_t nNoUpdatesTemp; uint8_t nNoUpdatesHum; bool metric = true; int8_t rssiVal; //RSSI char rssiStr[10]; //RSSI MyMessage msgHum(CHILD_ID_HUM, V_HUM); MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP); MyMessage msgRSSI(CHILD_ID_RSSI,V_CUSTOM); DHT dht; void presentation() { // Send the sketch version information to the gateway sendSketchInfo("TemperatureAndHumidity", "1.1"); sendSketchInfo("Battery Meter", "1.0"); /// sendSketchInfo("DHT11-v05"); // 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, S_CUSTOM); metric = getControllerConfig().isMetric; } void setup() { // Battery // use the 1.1 V internal reference #if defined(__AVR_ATmega2560__) analogReference(INTERNAL1V1); #else analogReference(INTERNAL); #endif dht.setup(DHT_DATA_PIN); // set data pin of DHT sensor if (UPDATE_INTERVAL <= dht.getMinimumSamplingPeriod()) { Serial.println("Warning: UPDATE_INTERVAL is smaller than supported by the sensor!"); } // Sleep for the time of the minimum sampling period to give the sensor time to power up // (otherwise, timeout errors might occure for the first reading) sleep(dht.getMinimumSamplingPeriod()); } void loop() { // Force reading sensor, so it works also after sleep() dht.readSensor(true); // Get temperature from DHT library float temperature = dht.getTemperature(); if (isnan(temperature)) { Serial.println("Failed reading temperature from DHT!"); } else if (temperature != lastTemp || nNoUpdatesTemp == FORCE_UPDATE_N_READS) { // Only send temperature if it changed since the last measurement or if we didn't send an update for n times lastTemp = temperature; // apply the offset before converting to something different than Celsius degrees temperature += SENSOR_TEMP_OFFSET; if (!metric) { temperature = dht.toFahrenheit(temperature); } // Reset no updates counter nNoUpdatesTemp = 0; send(msgTemp.set(temperature, 2)); #ifdef MY_DEBUG Serial.print("T: "); Serial.println(temperature); #endif } else { // Increase no update counter if the temperature stayed the same nNoUpdatesTemp++; } // Get humidity from DHT library float humidity = dht.getHumidity(); if (isnan(humidity)) { Serial.println("Failed reading humidity from DHT"); } else if (humidity != lastHum || nNoUpdatesHum == FORCE_UPDATE_N_READS) { // Only send humidity if it changed since the last measurement or if we didn't send an update for n times lastHum = humidity; // Reset no updates counter nNoUpdatesHum = 0; send(msgHum.set(humidity, 2)); #ifdef MY_DEBUG Serial.print("H: "); Serial.println(humidity); #endif } else { // Increase no update counter if the humidity stayed the same nNoUpdatesHum++; } // rssiVal = _radio.readRSSI(); // Old Driver rssiVal = RFM69_getReceivingRSSI(); // New Driver send(msgRSSI.set(rssiVal), true); #ifdef MY_DEBUG Serial.print("RSSI: "); Serial.println(rssiVal); #endif // Sleep for a while to save energy sleep(UPDATE_INTERVAL); }
-
RE: Sudden battery drain - Pro-mini + RFM69
I haven’t moved the sensor to a weatherproof case (still figuring out the new design), but I connected it to an external power source.
The circuit is operating perfectly.
If humidity or something alike had damaged it, it should be not working, right?
Although I think it is important to use the weatherproof case, I feel something else is happening here.
@skywatch: where I live in BR temperature ranges between 5-36C. I can see some fluctuations in battery V when temp changes, but usually around 0.05V
Thanks!
-
RE: Sudden battery drain - Pro-mini + RFM69
Thanks @zboblamont !
I will try changing to a weatherproof case.
Today I realized I started having the sudden battery drain after I moved to a Raspberry PI gateway and therefore had to add #define MY_RFM69_NEW_DRIVER to my code.
Could it also be the case that the new driver has some bug that consumes the battery (e.g. holds the radio on)?
Thanks,
-
RE: Sudden battery drain - Pro-mini + RFM69
In case someone has the same issue, quick update:
I cleaned the battery contacts, added some solder (maybe they would not get oxidized) and put new batteries.
However, after 6 days, there was the sudden drop in battery again. From 3.0 to 2.5 in less than 24 hours.
Still don't know what is the problem...
-
RE: Sudden battery drain - Pro-mini + RFM69
Thanks @skywatch for the reply.
The board is pretty clean. After your comments, I also checked the led and regulator contacts (I removed both, mediocre but good enough job).
However, I think the battery contacts have oxidized. I cleaned that and am testing again.
Does anyone have any tips on how to avoid battery terminals to get oxidized? Adding solder tin on that battery case avoids that?
Thanks!