Hi guys
I'm using emoncms on a Pi and all is running as it should on the pi, after some help (mharizanov)..
I'm in the process of building the emonTx and emonGLCD for this but at the mo I'm trying to get some home made sensors working that monitor humidity etc working..
They report in the feeds section with the correct node id etc but the values are rubbish..
they vary from positive numbers to negative numbers and I'm wondering what iv done wrong..
Iv got the Pi setup as Group 0, as i want to have lots of sensors all on different groups. EG Heating Group 1, Emon 210,Temp, 5,Etc Could this be causing me a problem?
struct {
int hum;
int temp1;
int duep;
int BVolt1;
}
payload;
is the structure of the packet and the values being shown in emoncms are
5 Node 201_1 23556
6 Node 201_2 -11518
7 Node 201_3 -32256
8 Node 201_4 -15360
or
5 Node 201_1 23556
6 Node 201_2 -11774
7 Node 201_3 -32256
8 Node 201_4 5633
The values from the jeenode are (iv multiplied the values to remove the decimal point) so the humidity is 59.7%
From the serial port of the JeeNode.
"Pay Humity dht: 597 Pay Temp dht: 212 Dew PointFast (oC): 130 batt :2903 end ****"
Any ideas?
Code.
// 2009-02-17 <jc@wippler.nl> http://opensource.org/licenses/mit-license.php
// 2010-05-22: added support for all resolution modes
// 2010-05-25: extended to also broadcast all readings over wireless
// 2010-06-17: add power saving logic, should reduce consumption by over 90%
// 2010-06-24: improved power savings, several "hot spots" optimized
// see http://news.jeelabs.org/2010/06/20/battery-savings-for-the-pressure-plug/
// see http://news.jeelabs.org/2010/06/30/going-for-gold-with-the-bmp085/
#include <JeeLib.h>
#include <PortsBMP085.h>
#include <avr/sleep.h>
#include <avr/pgmspace.h>
MilliTimer timer;
// Humidity sensor
#include "DHT.h"
#define DHTPIN 4
#define DHTTYPE DHT22 // DHT 22 (AM2302)
DHT dht(DHTPIN, DHTTYPE);
// end humidity setup
volatile bool adcDone;
// for low-noise/-power ADC readouts, we'll use ADC completion interrupts
ISR(ADC_vect) { adcDone = true; }
// this must be defined since we're using the watchdog for low-power waiting
ISR(WDT_vect) { Sleepy::watchdogEvent(); }
// Structure of data packet rfm12b
struct {
int hum;
int temp1;
int duep;
int BVolt1;
}
payload;
void setup() {
delay(1000); // wait 1 second before start.
Serial.begin(57600);
Serial.println("Running");
rf12_initialize(4, RF12_868MHZ, 201); // 868 Mhz, net group 201, node 5
rf12_control(0xC040); // set low-battery level to 2.2V i.s.o. 3.1V
}
void loop() {
// spend most of the waiting time in a low-power sleep mode
// note: the node's sense of time is no longer 100% accurate after sleeping
rf12_sleep(RF12_SLEEP); // turn the radio off
loseSomeTime(timer.remaining()); // go into a (controlled) comatose state
while (!timer.poll(30000))
lowPower(SLEEP_MODE_IDLE); // still not running at full power
// Humidity Section
float h = dht.readHumidity();
float t = dht.readTemperature();
int duep;
// Calc before t+h * 10
duep = dewPointFast(t, h);
//duep = dewPoint(t, h);
duep = duep * 10; // remove the decimal point from values before sending
h = h * 10; // Temp
t = t * 10; // Humidity
payload.hum = h; // set humidirty payload
payload.temp1 = t; // set humidity temp payload
payload.duep = duep; // set duepoint payload
// End Humidity
payload.BVolt1 = map(analogRead(6), 0, 1023, 0, 6600); // Set payload of bvolt.
// this code is not needed for use as remote node, keep it for debugging
// display payload data.
Serial.print(" Pay Humity dht: ");
Serial.print(payload.hum);
Serial.print(" Pay Temp dht: ");
Serial.print(payload.temp1);
Serial.print(" Dew PointFast (oC): ");
Serial.print(payload.duep);
Serial.print (" batt :");
Serial.print(payload.BVolt1);
Serial.println(" end ****");
Serial.flush();
rf12_sleep(RF12_WAKEUP); // turn radio back on at the last moment
MilliTimer wait; // radio needs some time to power up, why?
while (!wait.poll(5)) {
rf12_recvDone();
lowPower(SLEEP_MODE_IDLE);
}
while (!rf12_canSend())
rf12_recvDone();
rf12_sendStart(0, &payload, sizeof payload,1); // sync mode!
delay(5); // Needs this or the data sometimes gets cut off.. the sync above is suppost to stop this.
}
//EMPTY_INTERRUPT(WDT_vect); // just wakes us up to resume
/////////////////////////////////////////
// End Loop
/////////////////////////////////////////
// ***********************************************************************
// Duepoint calc
// ***********************************************************************
// dewPoint function NOAA
// reference: http://wahiduddin.net/calc/density_algorithms.htm
double dewPoint(double celsius, double humidity)
{
double A0= 373.15/(273.15 + celsius);
double SUM = -7.90298 * (A0-1);
SUM += 5.02808 * log10(A0);
SUM += -1.3816e-7 * (pow(10, (11.344*(1-1/A0)))-1) ;
SUM += 8.1328e-3 * (pow(10,(-3.49149*(A0-1)))-1) ;
SUM += log10(1013.246);
double VP = pow(10, SUM-3) * humidity;
double T = log(VP/0.61078); // temp var
return (241.88 * T) / (17.558-T);
}
// delta max = 0.6544 wrt dewPoint()
// 5x faster than dewPoint()
// reference: http://en.wikipedia.org/wiki/Dew_point
int dewPointFast(double celsius, double humidity)
{
double a = 17.271;
double b = 237.7;
double temp = (a * celsius) / (b + celsius) + log(humidity/100);
double Td = (b * temp) / (a - temp);
return Td;
}
// ***********************************************************************
// Jeelabs Code.
// ***********************************************************************
static void watchdogInterrupts (char mode) {
MCUSR &= ~(1<<WDRF); // only generate interrupts, no reset
cli();
WDTCSR |= (1<<WDCE) | (1<<WDE); // start timed sequence
WDTCSR = mode >= 0 ? bit(WDIE) | mode : 0;
sei();
}
// This power-saving code was shamelessly stolen from the rooms.pde sketch,
// see http://code.jeelabs.org/viewvc/svn/jeelabs/trunk/jeemon/sketches/rooms/
static void lowPower (byte mode) {
// prepare to go into power down mode
set_sleep_mode(mode);
// disable the ADC
byte prrSave = PRR, adcsraSave = ADCSRA;
ADCSRA &= ~ bit(ADEN);
PRR |= bit(PRADC);
// zzzzz...
sleep_mode();
// re-enable the ADC
PRR = prrSave;
ADCSRA = adcsraSave;
}
static byte loseSomeTime (word msecs) {
// only slow down for periods longer than the watchdog granularity
if (msecs >= 16) {
// watchdog needs to be running to regularly wake us from sleep mode
watchdogInterrupts(0); // 16ms
for (word ticks = msecs / 16; ticks > 0; --ticks) {
lowPower(SLEEP_MODE_PWR_DOWN); // now completely power down
// adjust the milli ticks, since we will have missed several
extern volatile unsigned long timer0_millis;
timer0_millis += 16;
}
watchdogInterrupts(-1); // off
return 1;
}
return 0;
}
// End of new power-saving code.
Re: Problems with other sensors and emoncms. -RFM12Pi-
OK a bit more info
Iv got my old emonTX showing up in my results.. So what i hear you ask..
Well its a 433Mhz version set to 433Mhz and the Pi is running a 868Mhz version set to 868Mhz.
The EmonTx is reporting fine to the nanode fine so i know its set to 433 and my Glcd is ok at 433 so the pi is set wrong or something strange is happening.. Im not seeing the Glcd Data show up on the pi so WTH? The emonTX is further away than the GLCD.
The data comming through is ok ish...
ct1 is OUT.. Way out.. -15596.00
CT2 may be ok its showing +1 currently but it is dark and the solar is off / not generating so this may be true / in the error range.
Ct3 N/A
Voltage is correct Some of the time other time is reporting rubbish...
Is there an easy way to check the data?
Re: Problems with other sensors and emoncms. -RFM12Pi-
Ok the 433Mhz setting may of been a weird problem.. setting to 433 and back to 868 in emoncms seems to fixed this..
Also by setting the correct group eg not 0 for broadcast i can receive data correctly.. as soon as i set it to group 0 i get rubbish.
Will try to work out why.
Re: Problems with other sensors and emoncms. -RFM12Pi-
Shouldn't all RF frequencies match?? I mean, all your RF modules should be either 433Mhz or 868Mhz. Or am I wrong about this?
Re: Problems with other sensors and emoncms. -RFM12Pi-
Fluppie007 you are correct, all the RF modules should be the same type (either 433 or 868MHz) whilst you can set them to the alternate frequency, the module is not optimised for it and the range of a signal can be less than a metre.
Re: Problems with other sensors and emoncms. -RFM12Pi-
For what it's worth, I tried an 868 MHz module at 433 MHz. It worked, but with many errors, over a range of about 15 cm. I didn't bother trying over a longer range. (Ukmoose: I recognise a quote there!).
Re: Problems with other sensors and emoncms. -RFM12Pi-
The Frequencies did Match..
Iv have an Old Energymonitoring kit 433 version Set to 433. but this was being picked up by the 833 version set to 833 HOW i dont know.. Setting the frequency inside of cms system to 433 saving and setting it back to 833 and saving fixed the old system showing up..
The second problem setting the group to 0 completely messes up all the data in the feeds section..
Im guessing that its appending the Group id and node id to the feed or something but doing this wrong.. So showing rubbish..
Setting the Group to a group id of a known sensor allows the sensor to show up with correct values.. Changing it back to 0 shows the same sensor showing rubbish again..
This is not going to be a problem with normal operation as people will probably leave it on one group.
Hope this makes sence.