Sorry, that was my blunder. Forgot to compile.
Why did you remove rht.update() from your code? You need that right before updating the variables inside the millis timer.
Because I screwed up!
I added that back in but there are no differences in output.
0000002516 [app] TRACE: Setup Readings:Ts = 0;Hs = 0
0000002517 [app] INFO: Setup complete.
0000003170 [comm.protocol] INFO: Sending 'S' describe message
0000003174 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 4
0000003369 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 3
0000003370 [comm.protocol] INFO: rcv'd message type=1
0000003385 [comm.protocol] INFO: Sending 'A' describe message
0000003387 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 4
0000003388 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 3
0000003389 [comm.protocol] INFO: rcv'd message type=1
0000005107 [app] TRACE: Pre-Filter Readings:Tp = 32;Hp = 0
0000005108 [app] TRACE: Delta Calcs:Td = 32;Hd = 0
0000005108 [app] ERROR: Delta calcs out of spec... cannot publish.
0000005110 [app] TRACE: Last Readings Updated:Tl = 32;Hl = 0
0000010216 [app] TRACE: Pre-Filter Readings:Tp = 32;Hp = 0
0000010217 [app] TRACE: Delta Calcs:Td = 0;Hd = 0
0000010219 [app] TRACE: T = 32;H = 0
And so we have the current code:
// This #include statement was automatically added by the Particle IDE.
#include <SparkFunRHT03.h>
const int RHT03_DATA_PIN = D4;
RHT03 rht;
int tempF = 0;
int humidity = 0;
int lasttempF = 0; //I'll use these to get rid of spikes in the data
int tempFdelta;
int lasthumidity = 0;
int humiditydelta;
unsigned long lastPubMillis = 0;
unsigned long pubInterval = 5000;
//Global variables to store messages.
const char pubEvent[] = "Xenon1 Environment";
char msg[128];
const char prePend[] = "Published Data:";
SerialLogHandler logHandler(LOG_LEVEL_TRACE);
void setup()
{
//Start serial for console debugging.
Serial.begin(9600);
// variable name max length is 12 characters long
// Declare Particle.variables as soon as possible.
Particle.variable("tempF", tempF);
Particle.variable("humidity", humidity);
//Wait 10 seconds for the serial console to connect.
waitFor(Serial.isConnected, 10000);
//Initialize and update the sensor.
rht.begin(RHT03_DATA_PIN);
rht.update();
//Add debugging output.
snprintf(msg,arraySize(msg)-1,"Setup Readings:Ts = %d;Hs = %d",tempF,humidity);
Log.trace(msg);
Log.info("Setup complete.");
}
void loop()
{
//Use a millis timer for non-blocking code design.
if (millis() - lastPubMillis > pubInterval)
{
int update = rht.update();
humidity = rht.humidity();
tempF = rht.tempF();
//Add debugging output.
snprintf(msg,arraySize(msg)-1,"Pre-Filter Readings:Tp = %d;Hp = %d",tempF,humidity);
Log.trace(msg);
tempFdelta = tempF-lasttempF;
tempFdelta = abs(tempFdelta);
humiditydelta = humidity-lasthumidity;
humiditydelta = abs(humiditydelta);
//Add debugging output.
snprintf(msg,arraySize(msg)-1,"Delta Calcs:Td = %d;Hd = %d",tempFdelta,humiditydelta);
Log.trace(msg);
if(tempFdelta < 2 && humiditydelta < 2)
{
//Create your message to publish and load into the message buffer.
snprintf(msg,sizeof(msg),"T = %d;H = %d",tempF,humidity);
//Send your data.
Particle.publish(pubEvent,msg);
//Add debugging output.
strcat("Published Data:",msg);
Log.trace(msg);
} else {
Log.error("Delta calcs out of spec... cannot publish.");
}
//Update your pub millis timer.
lastPubMillis = millis();
lasttempF = tempF;
lasthumidity = humidity;
//Add debugging output.
snprintf(msg,arraySize(msg)-1,"Last Readings Updated:Tl = %d;Hl = %d",lasttempF,lasthumidity);
Log.trace(msg);
}
}
Try changing this:
int update = rht.update();
to this:
//Check if sensor reading was successful.
if (rht.update() < 0) {
Log.error("RHT update failed.");
lastPubMillis = millis();
return; //If reading failed, do not process the rest.
}
This will let you know if the sensor update failed.
Yes, it failed, @ninjatill . But I’m not sure what that means or, rather, what I need to do to fix it. All I know is I haven’t had a problem with this sensor for two (2) years with the Electron.
0000002632 [app] ERROR: RHT update failed.
0000003385 [comm.protocol] INFO: Sending 'S' describe message
0000003389 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 4
0000003583 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 3
0000003584 [comm.protocol] INFO: rcv'd message type=1
0000003602 [comm.protocol] INFO: Sending 'A' describe message
0000003605 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 4
0000003606 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 3
0000003607 [comm.protocol] INFO: rcv'd message type=1
0000007740 [app] TRACE: Pre-Filter Readings:Tp = 32;Hp = 0
0000007740 [app] TRACE: Delta Calcs:Td = 32;Hd = 0
0000007741 [app] ERROR: Delta calcs out of spec... cannot publish.
0000007742 [app] TRACE: Last Readings Updated:Tl = 32;Hl = 0
0000012849 [app] TRACE: Pre-Filter Readings:Tp = 32;Hp = 0
0000012850 [app] TRACE: Delta Calcs:Td = 0;Hd = 0
0000012852 [app] TRACE: T = 32;H = 0
Ok. Great. This tells me that the first time through loop, the sensor update failed. 5 seconds later, it updated successfully and the library functions returned 32/0. There looks to be an issue with the library or perhaps some incompatibility with the Argon firmware. Unfortunately I don’t have one of those sensors to test with. I’ll take another look at the library tomorrow but it didn’t look very complicated. Maybe @peekay123 or @ScruffR could take a peek as well. If nothing else, they might have suggestions where to look or how to diagnose further.
Shouldn't these be doubles?
In the snprintf's you can use %1.2f instead of %d
1 Like
I forgot about the incorrect type definitions. Maybe the Nordic chip doesn’t handle the implicit type-cast from float to int the same as the STM chip.
There is not implicit type casting with dynamic parameter lists (... parameters, aka va_arg) as used in printf() (and related functions).
The ... parameter list is only a list of pointers and the format string is used to explicitly cast these void* into the provided type. If the type is wrong the result will be.
But when assigning a floating point value to an integer variable the value will be converted into the target type (irrespective of controller type, that’s taken care of by the compiler).
I had a look in the library, and since it relies on micros() which did have some issues up till rc.26 I’d have to ask which device OS version are you running.
I’d rather rewrite the library to use interrupts instead of having that library disable interrupts in order to get the timing right.
I can imagine that noInterrupts() on Gen3 devices does not actually block all interrupts and thus the timing might get muddled up.
1 Like
@ScruffR, I'm running 0.8.0-rc.27. Thanks.
This function is only supposed to disable interrupts exposed to the user. On Mesh devices it disables the GPIOTE_IRQn interrupts. These are the "Task and Events Module" interrupts. So ANY GPIO events including reads, writes and events (rising edge, falling edget, etc.). The GPIOTE can be associated with individual GPIO pins.
This implementation for the Mesh devices may be overkill and most likely has a broader (ie unexpected) affect than expected that it did on the Photon and Electron.
2 Likes
I filed an issue on the Spark Fun github about this library not working right with the mesh boards. Maybe they can resolve it or at least chime in.
1 Like
Thanks for doing that, @ninjatill. Let’s see what happens.
Ran into this as well, switched to using DHT22Gen3_RK and it appears to be working.