Posts made by jwosnick

@mfalkvidd

Thank you. I didn't realize the differences were so stark.

I have some Pro Mini 3.3V units on order and hope to convert my sensors to that platform, when they arrive.

@Digdogger
Out of curiosity, do you expect there to be a big savings in power consumption by removing the regulator and power LED? I've never used the Mini Pro (the smallest I get to is the Nano) but I understand it already is very efficient with power usage.

@avgays Confirmed that even with dht.begin(); the script still sends the same temp and humidity info, over and over again, as long as the sleep() function is in there. As soon as sleep() is replaced by delay() it all works properly.

So I conclude from this that the MySensors-customized version of the DHT library must have something in it to make sleep() play nicely with the DHT unit. I wish I knew what that was. It would be ideal if this sensor (and the Dallas Semiconductor one) could be used with the MySensors system with their standard libraries.

@avgays
Good catch -- thanks. Yes, that is the library I am using.

Despite omitting that line, the script above works fine as long as the last line is a delay() function and not sleep(). If I use sleep(), it in fact appears to work, but sends the same temperature and humidity over and over again. So it is something about the sleep() function.

I will add in the dht.begin() and then put sleep() back in and see what happens.

@mfalkvidd said in Air Humidity Sensor:

@jwosnick seems like the most recent version of the original library calls readSensor when getTemperature is called.

Yes, it does... but somehow that function is not "exposed" to the outside world. With a standard DHT test sketch (nothing to do with MySensors) calling readSensor throws an error.

@mfalkvidd

Yes, absolutely. But it appears that the dht.readSensor() function is not actually part of the standard DHT library, but rather something that only appears in the MySensors-customized version of it. I'm trying to get a handle on why there is a need for a customized library.

I've made a bit of an unusual observation in relationship to this script. I am running a fairly stripped-down version of it, but with the "standard" (not MySensors-customized) DHT library and its associated functions.

Here is the code:

// Enable debug prints
#define MY_DEBUG

// Enable and select radio type attached 
#define MY_RADIO_NRF24
//#define MY_RADIO_RFM69
//#define MY_RS485

#define MY_NODE_ID 47

#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 5

// Set this offset if the sensor has a permanent small offset to the real temperatures
#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 = 10000;

#define CHILD_ID_HUM 0
#define CHILD_ID_TEMP 1

bool metric = true;

MyMessage msgHum(CHILD_ID_HUM, V_HUM);
MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP);
DHT dht(DHT_DATA_PIN, DHT22);
float temperature;
float humidity;

void presentation()  
{ 
  // Send the sketch version information to the gateway
  sendSketchInfo("TemperatureAndHumidity", "1.1");

  // Register all sensors to gw (they will be created as child devices)
  present(CHILD_ID_HUM, S_HUM);
  present(CHILD_ID_TEMP, S_TEMP);

  metric = getControllerConfig().isMetric;
}


void setup()
{
  delay(100);
}


void loop()      
{  
  
  // Get temperature from DHT library
  temperature = dht.readTemperature();
  if (isnan(temperature))
  {
    Serial.println("Failed reading temperature from DHT!");
  }
    
  else
  {
    send(msgTemp.set(temperature,0));
    #ifdef MY_DEBUG
    Serial.print("T: ");
    Serial.println(temperature);
    #endif
  }  

  // Get humidity from DHT library
  
  humidity = dht.readHumidity();
  if (isnan(humidity))
  {
    Serial.println("Failed reading humidity from DHT!");
  }
    
  else 
  {
    send(msgHum.set(humidity,1));
    #ifdef MY_DEBUG
    Serial.print("H: ");
    Serial.println(humidity);
    #endif
  }

  // Sleep for a while to save energy
  sleep(UPDATE_INTERVAL); 
}

I find that if I leave the last line as
sleep(UPDATE_INTERVAL);
then the sensor node ends up sending the same temperature and humidity values, over and over again, even if the actual humidity and temperature change.

However, if I change the last line to
delay(UPDATE_INTERVAL);
then everything works as expected.

This is with known good DHT22 units, so I suspect there is something funny about the sleep() function and the operation of the standard (not customized) DHT library.

It took a lot of poking around to discover this, but is this in fact the reason why the MySensors customized DHT library is required for this script? Is that library necessary to make sleep() and DHT temperature measurements play nicely together?

@mfalkvidd said in Troubleshoot Nano temp/humidity to ESP8266-MQTT gateway issue:

I don't think handing out dynamic IDs works with mqtt. Define a node ID manually by adding

#define MY_NODE_ID 123

before including MySensors.h

It worked. Data is coming through now. Thanks again!

Thanks for the tip, I'll give it a try. It occurs to me that I have no "controller" here and so that may be why I'm getting errors.

Thanks for the tip. I changed to a new ESP8266 unit (now a NodeMCU board) and may be getting somewhere.

I can see what looks like the node and the gateway talking to each other, but the node never gets to the part where it actually reads a temperature! It seems to be stuck at some kind of "handshake" stage.

The log on the sensor node side reads as follows:

2503067 TSM:FAIL:RE-INIT
2503069 TSM:INIT
2503076 TSM:INIT:TSP OK
2503078 TSM:FPAR
2503081 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2503468 TSF:MSG:READ,0-0-255,s=255,c=3,t=8,pt=1,l=1,sg=0:0
2503473 TSF:MSG:FPAR OK,ID=0,D=1
2505090 TSM:FPAR:OK
2505091 TSM:ID
2505093 TSM:ID:REQ
2505096 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
2507103 TSM:ID
2507104 TSM:ID:REQ
2507107 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
2509115 TSM:ID
2509116 TSM:ID:REQ
2509119 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
2511127 TSM:ID
2511128 TSM:ID:REQ
2511131 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
2513139 !TSM:ID:FAIL
2513141 TSM:FAIL:CNT=7
2513143 TSM:FAIL:PDT

On the gateway side, I see publish events to my MQTT broker on the topic mygateway1-out/255/255/3/0/3 with no content in the message (timed corresponding to the TSF:MSG:SEND events in the sensor node log) so I assume the radios are actually talking to one another. I just don't know why the temperature isn't being read.

Any ideas from the crowd? I tried swapping in a NRF24L01 on the gateway side, which had no effect.

Everyone,

I am new to MySensors but have experience with Arduino, ESP8266, and MQTT. Trying to debug my "starter" MySensors setup and am having a hard time.

My set up is as follows:

• Sensor node: Arduino Nano clone with a DHT22 attached (DHT22 and Nano clone tested and working fine in non-MySensors applications). An NRF24L01 is attached, with a 10-uF cap across VCC-GND. It is running a variant of the humidity / temperature script described at https://www.mysensors.org/build/humidity. I made changes to make the script compatible with the standard DHT library.
• Gateway: A Wemos D1 Mini with an NRF24L01 attached (also with a 10-uF cap). It is running the ESP8266 variant of the MQTT gateway script described at https://www.mysensors.org/build/mqtt_gateway#mqttgateway-example

When I run the gateway script, the following appears in the serial monitor:

0;255;3;0;9;MCO:BGN:INIT GW,CP=RNNGE--,VER=2.1.1
0;255;3;0;9;TSF:LRT:OK
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSF:WUR:MS=0
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 4
cnt 

connected with Frog Station Alpha, channel 4
dhcp client start...
0;255;3;0;9;TSM:INIT:TSP OK
0;255;3;0;9;TSM:INIT:GW MODE
0;255;3;0;9;TSM:READY:ID=0,PAR=0,DIS=0
0;255;3;0;9;MCO:REG:NOT NEEDED
f r0, scandone
ip:192.168.1.189,mask:255.255.255.0,gw:192.168.1.1
.IP: 192.168.1.189
0;255;3;0;9;MCO:BGN:STP
0;255;3;0;9;MCO:BGN:INIT OK,TSP=1
IP: 192.168.1.189
0;255;3;0;9;Attempting MQTT connection...
0;255;3;0;9;MQTT connected
0;255;3;0;9;Sending message on topic: mygateway1-out/0/255/0/0/18
pm open,type:2 0

I see nothing after this, though my MQTT broker does indeed successfully receive the message "2.1.1" on topic mygateway1-out/0/255/0/0/18.

On the sensor node side, the serial output looks like this:

0 MCO:BGN:INIT NODE,CP=RNNNA--,VER=2.1.1
3 TSM:INIT
4 TSF:WUR:MS=0
11 TSM:INIT:TSP OK
13 TSM:FPAR
15 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2022 !TSM:FPAR:NO REPLY
2024 TSM:FPAR
2026 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
4034 !TSM:FPAR:NO REPLY
4036 TSM:FPAR
4038 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6046 !TSM:FPAR:NO REPLY
6048 TSM:FPAR
6050 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
8058 !TSM:FPAR:FAIL
8059 TSM:FAIL:CNT=1
8061 TSM:FAIL:PDT

This type of output continues on and on.

Obviously there is a "failure" but is it possible to diagnose where the problem lies, based on this output?

Many thanks! I'm hoping I can get this working.