Posts made by jjk

@gohan yes, have done that. Thanks for your time and support!

@TimO after installing a (simple) sketch on a new node with the mysensors 2.2 library, I noticed frequent exceptions in the openhab logfile. It took me a while to figure out why, but it seems the issue is linked to new messages the ne mysensors library is sending in relation to smartsleep (type 32 and 33). I was able to reproduce the exceptions with manually generated mqtt messages. Below is the openhab log filtered for MySensorsMQTT

2018-02-21 13:43:23.232 [TRACE] [rotocol.mqtt.MySensorsMqttConnection] - Bridge is connected, connection skipped
2018-02-21 13:43:23.478 [DEBUG] [rotocol.mqtt.MySensorsMqttConnection] - MQTT message received. Topic: mysgw-out/151/4/1/0/0, Message: 2.4
2018-02-21 13:43:23.480 [DEBUG] [rotocol.mqtt.MySensorsMqttConnection] - Message topic part: 151/4/1/0/0
2018-02-21 13:43:23.481 [DEBUG] [rotocol.mqtt.MySensorsMqttConnection] - Converted MQTT message to MySensors Serial format. Sending on to bridge: 151;4;1;0;0;2.4
2018-02-21 13:43:23.665 [DEBUG] [rotocol.mqtt.MySensorsMqttConnection] - MQTT message received. Topic: mysgw-out/151/3/1/0/4, Message: 1013
2018-02-21 13:43:23.666 [DEBUG] [rotocol.mqtt.MySensorsMqttConnection] - Message topic part: 151/3/1/0/4
2018-02-21 13:43:23.668 [DEBUG] [rotocol.mqtt.MySensorsMqttConnection] - Converted MQTT message to MySensors Serial format. Sending on to bridge: 151;3;1;0;4;1013
2018-02-21 13:43:28.499 [DEBUG] [rotocol.mqtt.MySensorsMqttConnection] - MQTT message received. Topic: mysgw-out/151/255/3/0/22, Message: 13830390
2018-02-21 13:43:28.501 [DEBUG] [rotocol.mqtt.MySensorsMqttConnection] - Message topic part: 151/255/3/0/22
2018-02-21 13:43:28.503 [DEBUG] [rotocol.mqtt.MySensorsMqttConnection] - Converted MQTT message to MySensors Serial format. Sending on to bridge: 151;255;3;0;22;13830390
2018-02-21 13:43:33.234 [TRACE] [rotocol.mqtt.MySensorsMqttConnection] - Bridge is connected, connection skipped
2018-02-21 13:43:43.236 [TRACE] [rotocol.mqtt.MySensorsMqttConnection] - Bridge is connected, connection skipped
2018-02-21 13:43:53.238 [TRACE] [rotocol.mqtt.MySensorsMqttConnection] - Bridge is connected, connection skipped
2018-02-21 13:44:03.240 [TRACE] [rotocol.mqtt.MySensorsMqttConnection] - Bridge is connected, connection skipped
2018-02-21 13:44:13.242 [TRACE] [rotocol.mqtt.MySensorsMqttConnection] - Bridge is connected, connection skipped
2018-02-21 13:44:23.244 [TRACE] [rotocol.mqtt.MySensorsMqttConnection] - Bridge is connected, connection skipped
2018-02-21 13:44:23.579 [DEBUG] [rotocol.mqtt.MySensorsMqttConnection] - MQTT message received. Topic: mysgw-out/43/255/3/0/33, Message: 300000
2018-02-21 13:44:23.581 [DEBUG] [rotocol.mqtt.MySensorsMqttConnection] - Message topic part: 43/255/3/0/33
2018-02-21 13:44:23.589 [ERROR] [rotocol.mqtt.MySensorsMqttConnection] - MQTT connection offline - {}
	at org.openhab.binding.mysensors.internal.protocol.mqtt.MySensorsMqttConnection$MySensorsMqttSubscriber.processMessage(MySensorsMqttConnection.java:140) ~[?:?]
2018-02-21 13:44:33.247 [TRACE] [rotocol.mqtt.MySensorsMqttConnection] - Bridge is connected, connection skipped

Currently, the only workaround seems to be to avoid smartsleep or compile the nodes with the 2.1.1 library.

yes, I am sure now: https://forum.mysensors.org/topic/8933/mysensors-2-2-0-released/27

Looks like the only way to eliminate the messages is to not use smartsleep

@anticimex said in MySensors 2.2.0 released:

@maghac Hi,
documentation is best found here: https://www.mysensors.org/apidocs/
It is always covering the latest release. Specifically, for message types: https://www.mysensors.org/apidocs/group__MyMessagegrp.html

Is there a way to disable these messages?

@gohan fair question, I don't need it, it's just still in the code and besides, the 5 min message from smartsleep seems to show up every two mins (the heartbeaat rate)
And yes, I did indeed update the library, so maybe that's why. Turns out, the bigger problem is that these message seem to cause an exception in the openhab mysensor binding, so at best I'd like to figure out how to stop the node from sending them... Will do some digging

o.k., fair enough, that's a great explanation! - I'm still struggling, though, with why this node is sending this (but no heartbeat), but none of the previous ones I did...

hm, you might be right on the 300000 as that#s indeed the smartsleep wait time I'm setting. Not sure about the 500, but certainly possible (is that documented somewhere?) I'm wondering, though, why this node is sending this info, but not the other ones?! I don't think I have changed anything t the sketch other than the node-id and node name...

yes, I do - like on every other DHT node as well, but never had that...?! Plus, I can't seem to figure out what the messages mean.

Hi there,
do you know that, you've built a node like a 100 times and I think it's all routine and then something that completely bluffs you? I happened to me with a simple Temp/Hum node (DHT22) that keeps sending me messages that I can't seem to figure out: 43;255;3;0;33;300000 and 43;255;3;0;32;500 - They seem to show up in the frequency that other nodes send a heartbeat signal, but no heartbeat is sent from this node. The regular DHT22 datapoints are sent as normal. Anyone knows what this means?

@timo, another effect I noticed is that the mysensor binding seems a bit sensitive to updates in the things and item files. I got new errors every time I added a thing to the things file or modified the items file. After rebooting OH those erros were gone and the things properly included. Stopping the mysensors binding (bundle:stop) before adding/changing things or items and restarting it afterwards works without a problem.

Hi @TimO ,

after doing clean install of OH and the ESH mqtt binding per the original post above, the mqqt service ran properly (no errors in the debug log). After installing the mysensors binding, I start seing mysensors topics come in, but then following exception is thrown

2018-02-06 20:01:10.676 [DEBUG] [o.client.mqttv3.internal.ClientState] - paho167001634703924: received key=1 message=PUBLISH qos:1 msgId:1 retained:true dup:false topic:"mysgw-out/1/0/1/0/97" payload:[hex:33392e38 utf8:"39.8" length:4]
2018-02-06 20:01:10.676 [DEBUG] [o.client.mqttv3.internal.ClientState] - paho167001634703924: received key=1 token=org.eclipse.paho.client.mqttv3.MqttToken@e71260 message=SUBACK msgId 1 granted Qos 1
2018-02-06 20:01:10.677 [DEBUG] [client.mqttv3.internal.CommsCallback] - paho167001634703924: new msg avail, notify workAvailable
2018-02-06 20:01:10.678 [DEBUG] [o.client.mqttv3.internal.ClientState] - paho167001634703924: wait for new work or for space in the inflight window
2018-02-06 20:01:10.679 [DEBUG] [client.mqttv3.internal.CommsReceiver] - paho167001634703924: network read message
2018-02-06 20:01:10.679 [DEBUG] [client.mqttv3.internal.CommsCallback] - paho167001634703924: call messageArrived key=1 topic=mysgw-out/1/0/1/0/97
2018-02-06 20:01:10.680 [DEBUG] [o.client.mqttv3.internal.ClientState] - paho167001634703924: received bytes count=1
2018-02-06 20:01:10.681 [DEBUG] [o.client.mqttv3.internal.ClientState] - paho167001634703924: received bytes count=28
2018-02-06 20:01:10.681 [DEBUG] [client.mqttv3.internal.CommsCallback] - paho167001634703924: callback threw exception
        at org.openhab.binding.mysensors.internal.protocol.mqtt.MySensorsMqttConnection$MySensorsMqttSubscriber.processMessage(MySensorsMqttConnection.java:140) [233:org.openhab.binding.mysensors:2.2.0.201712141227]
        at org.eclipse.smarthome.io.transport.mqtt.MqttBrokerConnection$ClientCallbacks.messageArrived(MqttBrokerConnection.java:121) [232:org.eclipse.smarthome.io.transport.mqtt:0.10.0.b1]
        at org.eclipse.paho.client.mqttv3.internal.CommsCallback.handleMessage(CommsCallback.java:354) [231:org.eclipse.paho.client.mqttv3:1.0.2]
        at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:162) [231:org.eclipse.paho.client.mqttv3:1.0.2]
2018-02-06 20:01:10.683 [DEBUG] [o.client.mqttv3.internal.ClientComms] - paho167001634703924: state=DISCONNECTING

Any idea what I'm doing wrong?

UPDATE:
For what it's worth, I found the trigger for the error. In fact, the mqtt messages the binding received were (for whatever reason) retained messages of the mosquitto broker. After removing the mosquitto presistence file

sudo service mosquitto stop
sudo rm /var/lib/mosquitto/mosquitto.db
sudo service mosquitto start

it now seems to work o.k. - Hope this might help others who come across this thread.

@Newzwaver the wiring is pretty straight forward following the above links for the transistors and display. I will try to post a wiring scheme, but that like can't happen within the next two weeks for time constrains.

As for the parts list:

• Arduino nano
• I2C display, such as the 20x4 character display described here: https://www.mysensors.org/build/display
• 1 or 2 transistors, I have used the Maverick PR-022 which meanwhile I learned are made of Semiech's 105GT-2 (datasheet: https://www.rapidonline.com/pdf/61-0442.pdf)
• 1 or 2 resistors matching your thermistor's nominal resistance (for the above: 1 MOhm)

The wiring for each of the thermistors and the display is independent of each other following the above guidelines and you can use either one or two thermistors. The display is optional, too.

Hope this helps for now. I will post diagrams when I have a chance...

Not sure this is of use for anyone, but I thought I post a little project I implemented recently and that's pretty straight forward to implement.

When we were at our friends' place he showed off his cool new wifi-enabled BBQ-thermometer with the corresponding app. Nice gadget, that he got from his wife as a birthday present. When I looked it up online and saw the price tag of well above 150,- EUR I thought there must be a much cheaper way of getting this... And there is: a simple, mysensorized BBQ-node!

Next time they came over to our place we were standing in the kitchen and when it was time to check on the meat, all I did was ask Alexa - the effect was phenomenal

There are many good tutorials on the web on how to connect a thermistor and read the temperature, I've used this as the basis: https://learn.adafruit.com/thermistor/using-a-thermistor

Here's my simple setup:
I'm using a Nano powered with an external 5V supply, two Maverick temperature probes and 2 extra resistors for the voltage dividers. Turns out the two Mavericks are the biggest price items with around 20,- EUR each. There are much cheaper probes available, but I wanted to make sure they are durable and avoid having to re-calibrate the whole thing every time I have to get a new thermistor probe.

Please note, this project is not meant to actively control the smoker temperature! There are many projects to follow online that go down that road. I'm a bit of an old-fashioned BBQ-fan, I feel controlling the smoker temp and adjusting it when needed is part of the fun. So all this does is to read smoker and meat temperature...

Mainly to be able to check the temperature while developing the BBQ-node, I also added a 4-line LCD display (https://www.mysensors.org/build/display). It actually turned out to be quite handy, as it allows to check the temp while in the yard and without a handheld or Alexa.

Wiring everything up is pretty straight forward following the steps in the above two links for thermistor and display. It took me a bit to figure out the right settings for the thermistor as I didn't get data sheets or resistance curves. There's still some improvement potential to get the temperature readings more accurate, but for now precision is good enough.

(note: in ths pic, the smoker room temp probe was not attached, yielding a wrong value in the display!)

// -----------------------
// myBBQ-Node
// -----------------------

// Enable debug prints
#define MY_DEBUG
//#define MY_DEBUG_VERBOSE
#define MY_TRANSPORT_WAIT_READY_MS 1

// define node specific configuration
// ***********************************
// BBQ Thermometer
// ***********************************
#define MY_NODE_ID 13
char MY_BBQ_NODE_VERSION = "0.4";
char MY_BBQ_NODE_DATE    = "02.07.2017";

#define HEARTBEAT_INTERVAL 6000 // send heartbeat every 2 min

// which analog pin to connect
#define THERMISTORPIN_A A0
#define THERMISTORPIN_B A1
// temp. for nominal resistance (almost always 25 C)
#define TEMPERATURENOMINAL 25
// resistance at this nominal temperature
#define THERMISTORNOMINAL_A 1000000
#define THERMISTORNOMINAL_B 1000000
// the value of the 'other' resistor
#define SERIESRESISTOR_A 920000
#define SERIESRESISTOR_B 1000000
// how many samples to take and average, more takes longer
// but is more 'smooth'
#define NUMSAMPLES 20
// The beta coefficient of the thermistor (usually 3000-4000)
#define BCOEFFICIENT_A 3950
#define BCOEFFICIENT_B 3950

 
// Enable and select radio type attached 
#define MY_RADIO_NRF24
//#define MY_RF24_CHANNEL  77
//#define MY_RADIO_RFM69
//#define MY_RS485
 
#include <SPI.h>
// Enabled repeater feature for this node
//#define MY_REPEATER_FEATURE

#include <MySensors.h>  
#include <Wire.h>
#include <LiquidCrystal_I2C.h>

// Initialize display. Google the correct settings for your display. 
// The follwoing setting should work for the recommended display in the MySensors "shop".
//LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);
LiquidCrystal_I2C lcd(0x27, 20, 4);

// Sleep time between sensor updates (in milliseconds)
// Must be >1000ms for DHT22 and >2000ms for DHT11
//static const uint64_t UPDATE_INTERVAL = 60000;
static const uint64_t UPDATE_INTERVAL = 300000;


#define CHILD_ID_TEMP_SMOKER 0
#define CHILD_ID_TEMP_MEAT 1
bool metric = true;


MyMessage msgTempSmoker(CHILD_ID_TEMP_SMOKER, V_TEMP);
MyMessage msgTempMeat(CHILD_ID_TEMP_MEAT, V_TEMP);


void presentation()  
{ 
  // Send the sketch version information to the gateway
  sendSketchInfo("BBQ Temp", "0.2");
  
  // Register all sensors to gw (they will be created as child devices)
  present(CHILD_ID_TEMP_SMOKER, S_TEMP);
  present(CHILD_ID_TEMP_MEAT, S_TEMP);
  
  metric = getControllerConfig().isMetric;
}


void setup() {

  float temp_smoker;
  float temp_meat;

  // connect AREF to 3.3V and use that as VCC, less noisy!
  analogReference(EXTERNAL);

  temp_meat   = analogRead(THERMISTORPIN_A);
  temp_smoker = analogRead(THERMISTORPIN_B);
  float meat   = calc_steinhart(temp_meat, SERIESRESISTOR_A, THERMISTORNOMINAL_A, BCOEFFICIENT_A);
  float smoker = calc_steinhart(temp_smoker, SERIESRESISTOR_B, THERMISTORNOMINAL_B, BCOEFFICIENT_B);

  // initialize the lcd for 16 chars 2 lines and turn on backlight
  //lcd.begin(16,2); 
  lcd.init();
  lcd.clear();
  lcd.home();
  lcd.setCursor (0,0);
  lcd.backlight();
  lcd.print("myBBQ Thermometer");
  lcd.setCursor (10,2);
  lcd.print("Vers. " + MY_BBQ_NODE_VERSION);
  lcd.setCursor (10,3);
  lcd.print(MY_BBQ_NODE_DATE);
  delay(5000);
  lcd.clear();
  lcd_update(smoker,meat);
}


void loop(void) {
  uint8_t i;
  float av_smoker;
  float av_meat;
  
  // take NUMSAMPLES samples in a row, with a slight delay
  av_meat   = 0;
  av_smoker = 0;
  for (i=0; i< NUMSAMPLES; i++) {
   av_meat += analogRead(THERMISTORPIN_A);
   delay(50);
   av_smoker = analogRead(THERMISTORPIN_B);
   delay(50);
   lcd.setCursor (0+i,1);
   lcd.print("_");
  }
 
  // average all the samples out
  av_meat /= NUMSAMPLES;
  av_smoker /= NUMSAMPLES;
 
  Serial.print("Average analog reading 1: "); 
  Serial.println(av_meat);
  Serial.print("Average analog reading 2: "); 
  Serial.println(av_smoker);

  float temp_meat   = calc_steinhart(av_meat, SERIESRESISTOR_A, THERMISTORNOMINAL_A, BCOEFFICIENT_A);
  float temp_smoker = calc_steinhart(av_smoker, SERIESRESISTOR_B, THERMISTORNOMINAL_B, BCOEFFICIENT_B);
 
  Serial.print("Temp Meat "); 
  Serial.print(temp_meat);
  Serial.println(" *C");
  Serial.print("Temp Smoker "); 
  Serial.print(temp_smoker);
  Serial.println(" *C");

  lcd_update(temp_smoker,temp_meat);

  send(msgTempSmoker.set(temp_smoker, 1));
  send(msgTempMeat.set(temp_meat, 1));

  delay(1000);
}


float calc_steinhart(float reading, float RSER, float RNOM, float BCOEFF) {
  uint8_t i;
 
  // convert the value to resistance
  reading = 1023 / reading - 1;
  reading = RSER / reading;
  Serial.print("RSER "); 
  Serial.println(RSER);
  Serial.print("RNOM "); 
  Serial.println(RNOM);
  Serial.print("BCOEFF "); 
  Serial.println(BCOEFF);
  Serial.print("Thermistor resistance "); 
  Serial.println(reading);
 
  float steinhart;
  steinhart = reading / RNOM;                  // (R/Ro)
  steinhart = log(steinhart);                  // ln(R/Ro)
  steinhart /= BCOEFF;                         // 1/B * ln(R/Ro)
  steinhart += 1.0 / (TEMPERATURENOMINAL + 273.15); // + (1/To)
  steinhart = 1.0 / steinhart;                 // Invert
  steinhart -= 273.15;                         // convert to C
 
  Serial.print("cal_steinhart Temp: "); 
  Serial.print(steinhart);
  Serial.println(" *C");

  return steinhart;

}


void lcd_update(float smoker, float meat) {
  lcd.clear();
  lcd.home();
  // print information to lcd display
  lcd.setCursor (0,0);
  lcd.print("BBQ: ");
  lcd.print("Pulled Pork");

  lcd.setCursor (0,2);
  lcd.print("Smoker:");
  lcd.setCursor (0,3);
  if (smoker <= 0) {
    lcd.print("- n.a. -");
  } else if (smoker <= 10) {
    lcd.print("- low -");
  } else if (smoker > 200) {
    lcd.print("+ high +");
  } else {
    lcd.print(smoker);
    lcd.print(" *C");
  }

  lcd.setCursor (11,2);
  lcd.print("Fleisch:");
  lcd.setCursor (11,3);
  if (meat <= 0) {
    lcd.print("- n.a. -");
  } else if (meat <= 10) {
    lcd.print("- low -");
  } else if (meat > 120) {
    lcd.print("+ high +");
  } else {
    lcd.print(meat);
    lcd.print(" *C");
  }
}

btw. I'm using a pro mini 5V to power and trigger the DYP at the moment. Have played with an external 5V supply, but that didn't seem to make a noticeable difference.

@ben999 and @zboblamont thanks for the swift feedback and advice. I think you are right, the DYP seems to be VERY sensitive to alignment. The tests I did were "handheld" and readings jumped arbitrarily btw zeroes, accurate, and off values. I've done a few tests now with the sensor head fixed and more aligned to the target surface and that seems to work out much better now. I also found that readings get less accurate above 1m, though?!

update: we're getting there... after a bit a tweaking and trying different angles, I'm now getting readings. The good news: in one position, when readings come in, they are consistent. The bad news: as soon as I move the sensor head, it's a gamble, in some cases the readings are o.k., in other cases it drops to 0mm... Anybody has seen a similar effect?

hi folks, received my DYP-ME007Y finally, tried it and got the same inconsistent readings with the old sketch that @zboblamont and others reported. I was excited to see the code that @ben999 found and tested successfully - but I don't even get past the "start" print out in the serial monitor. the LED on the DYP board is flashing eagerly, but it doesn't look like it gets any readings... Have you guys changed anything else to get it t work?

@zboblamont, excellent idea, but unfortunately my previous tries with the JSN-SR04T were in a "previous life" of arduino experimenting quite a while ago and at the time, I dumped pretty much most of it (I hate to say, the JSN failures were one if the reasons...). That said, I have ordered some DYP and will give it another try. The tips you and @Boots33 have provided should get me much farer than last time The key information I guess I was missing at the time was the sensitivity to voltage.

On another note... has anyone played around with alternative ways to measure water level, like a pressure tube or so? I'd be interested to see if that's an easier way, maybe?!

@Boots33 o.k. that's good advice! I just ordered some DYP and they have a bit of a lead time, that gives me time to think about getting an extra and stable 5V to the sensor.

@Boots33 thanks for your detailed response! Is the DYP-ME007 the same as the JSN-SR04? As my experience with the latter is not too exciting... Anyways, I might as well give it another try! Also, thanks for the lead to your project and the median filtering in newping. I will definitely look into that and might just have to increase the number of readings the node takes and than filter for a transmission every 15 mins or so.

@gohan that's what I'm doing already, I even disregard the "zero" readings and am looking into algorithms to eliminate runaway values. But frankly, that's not how it's supposed to work and you never know when the readings start becoming random, so the trust level is pretty low...
@zboblamont I've tried a tube (one around the whole sensor for now) and that didn't change a thing, I'm afraid. I did notice, though, that there was quite a bit condesnsation on the box that I placed the sensor in, so maybe your thought about moisture build-up has a hang to it after all... Not sure, yet, how to deal with that, though...

@zboblamont thanks for the thoughts! I think I can rule out moisture build up as the effect started right after everything was installed. The confusing echos might be a lead?! I though I had made sure the sensor is over an area with no other objects around, but... I will see if I can test that by attaching some sort of tubing and report back when it's done

o.k. folks, here's another update. Thanks to a number of rainy days, I have worked on the setup in my lab environment, even got myself a fritzing pcb to make things a bit more stable. Indoors, with a new sensor, things worked out o.k., the readings were stable. With the sun back in our area, brought everything out to the tank. First finding: I proved the sensor that was still out there was faulty! Now everything is installed, readings are transmitted every 15 minutes. That's the good news. The bad news is, the readings are again not consistent! The following is a list of the last 20 or so readings:

120
86
82
84
85
67
0
82
85
80
84
126
84
85
0
85
84
60
85
51
82

I'd be happy with the "around 85cm" readings, but the other ones really bug me. Anyone has a clue what can cause that? Has anyone ever experienced something similar?

@zboblamont lol, yeah that can happen with all the wonderful acronyms we have to deal with
I had played with a JSN-SR04T (cable version) a while ago, but was very disappointed with accuracy and consistency, which also seems to be in line with most online ratings. So I switched to the HC-SR04 which worked well in another (indoor) setup. I'm not sure how that sensor will do in the water tank, but since it will always be at least 1m above the water level, I'm hoping it'll do o.k. - Will report once I got it working and then how it does over time...

@zboblamont the temperature issue I'm expecting is mainly wrt the electrical connections and the components sitting tightly (or not) in the pin headers. However, I guess only time will tell whether or not that becomes an issue The SR04 is labeled "HC-SR04" and I got it from Amazon. The accuracy is "ok", I'd say. I did some reference measurements with a tape measure and below 1m the sensor returned consistently correct readings. Beginning at about 1.5-2m the readings occasionally would fluctuate by +/- 1cm, but on average it is o.k. As I intend to use it as a "general level indicator" in my grey water tank that's good enough for me - if I get it to work properly.

o.k. here's an update for those who are interested...
I have completely take down the components and resembled the setup in a test environment with a newly created prototype pcb. It works as expected - kind of. What I found is that the SR04 seems to be very sensitive to weak electrical connections. At first, I had a similar effect of inconsistent readings in the test and was about to conclude that there must be a piece of hardware at fault. Then I found a cable poorly soldered to the pcb and after fixing that, voila, the readings were consistent over 50 or so samples.
Another source of headache is probably that I have used pin headers to easily connect/exchange the components and my observation is that there, too seems to be a certain sensitivity in "quality of craftsmanship". After about half day of running the test setup, I got unable to read errors from a DHT22 that is also attached to the node. I inspected everything and it looked good, but only after pushing firmly of the Nano (that looked like it was perfectly sitting in it's header), the readings came back o.k.
Now trying to figure out how to bring that into the outside world where eventually I will have to deal with temperature changes that I suspect might further contribute to the issue...

@zboblamont thanks and yes, that's exactly what I doing... I have take. everything down and will look into a detailed test setup over the weekend. Will post any findings

@zboblamont thanks for putting more thoughts into this for me!
As I'm just an motivated hobbyist (far from being expert in electronics), I've tried to switch the pro mini to a nano, in a hope that keeps me from dealing with the relay (new to me). My thought was that the 5V it provides should mitigate the issue - looks like it doesn't. So if the readings aren't getting more consistent with the 5V Nano, what else could be the issue?

thanks @ zboblamont, I will have a look

@mfalkvidd that's a fair question... I tested the sketch and connectivity with dupont cables and my spontaneous answer would be, "yes". However, to be honest, I never really calibrated the distance readings nor did I do a long-term test in the lab setup, so I think the true answer is, " I don't know"...

@zboblamont sounds like you figured it out?! Would you mind providing details on the relay you have used?

I have a setup with a HC-SR04 connected to an Arduino Pro Mini via a cable of about 5m length As I'm getting inconsistent readings from the sensor, I was wondering if cable length could be an issue - and if so, what a possible workaround could look like. Any thoughts from the experts?

@mfalkvidd thanks for the swift reply - sometimes the obvious is hard to see

I found this topic by chance and there might be new info - if so, I'm sorry.
However, I was thinking how the "forced" node-id 0 will work if more than one ESP8266 gateway is installed within possible radio range of the sensor nodes. Wouldn't that be leading to unpredictable behavior, like messages sent more than one?

o.k., quick update... contrary to what I reported yesterday, it now looks like my gateway is getting sensor readings from the node in question at irregular intervals. strangely enough, when I connect my Mac and launch the serial monitor, the sensor printout still stops after just the few lines above. Has anybody ever experienced something like this before?

Still need to do the hardware swapping to see if this is related to a malfunction of any of the components.

@gohan, hm not sure I get what you're suggesting...?! I had not changed anything before updating the sketch, so should that really make a difference? The ide and libraries are the same I have used a day or two ago to install the initial sketch - the one that worked?!

@gohan no, I have not et swapped hardware... That's on my to-do for the next days, but I was hoping that the problem is a known one with a more or less easy fix. If i's a bad piece of hardware, I guess I will have to got through the swapping exercise... It's just strange that the issue showed up after updating the sketch?!

@gohan yeah, it's all up to date - plus other node work as desired even after updating today...

@gohan: the reason I'm using MY_PARENT_NODE_ID is to ensure connection to the repeater. The sensor in question is outside in the yard and I won't get it to connect to the gateway otherwise.

Yes, I have checked, both the repeater node and the gateway and both are talking to each other (gw and repeater), but neither is getting any signals from the node in question. Strangely enough, this setup had worked before I updated the sketch in this particular node...

Hi there,
I've been encountering a strange issue with one my nodes and can't seem to figure out how to fix it. The node is built with an arduino nano, nrf24, and a HC-SR04 distance sensor. Things worked out o.k. for a while, then I updated the sketch so the sensor would only send a measurement every 5 minutes. Now, every time I restart the node and check via serial monitor, I only get a few lines, then the whole thing stalls.

3 TSM:INIT
4 TSF:WUR:MS=1
11 TSM:INIT:TSP OK
12 TSM:INIT:STATID=151
15 TSF:SID:OK,ID=15

I've tried to clear the eeprom, and uploaded the sketch again, but that won't change a thing. My sketch is included below.

Any idea is welcome at this point...

Thanks,
JJK

// Enable debug prints
#define MY_DEBUG
#define MY_DEBUG_VERBOSE
#define MY_TRANSPORT_WAIT_READY_MS 1

// define node specific configuration
#define MY_NODE_ID 151
#define MY_PARENT_NODE_ID 21
//#define MY_PARENT_NODE_IS_STATIC

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

#include <SPI.h>
#include <MySensors.h>  
#include <NewPing.h>

#define CHILD_ID 1
#define TRIGGER_PIN  6  // Arduino pin tied to trigger pin on the ultrasonic sensor.
#define ECHO_PIN     5  // 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.
unsigned long SLEEP_TIME = 300000; // Sleep time between reads (in milliseconds)

NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE); // NewPing setup of pins and maximum distance.
MyMessage msg(CHILD_ID, V_DISTANCE);
int lastDist;
bool metric = true;

void setup()  
{ 
  metric = getControllerConfig().isMetric;
}

void presentation() {
  // Send the sketch version information to the gateway and Controller
  sendSketchInfo("Distance Sensor", "1.0");

  // Register all sensors to gw (they will be created as child devices)
  present(CHILD_ID, S_DISTANCE);
}

void loop()      
{     
  int dist = metric?sonar.ping_cm():sonar.ping_in();
  Serial.print("Ping: ");
  Serial.print(dist); // Convert ping time to distance in cm and print result (0 = outside set distance range)
  Serial.println(metric?" cm":" in");

  if (dist != lastDist) {
      send(msg.set(dist));
      lastDist = dist;
  }

  wait(5000);
  smartSleep(SLEEP_TIME);

thanks, it works - in principle! I'm using smartSleep in my sketches and that causes the nodes to send heartbeat signals, which is o.k. But can it be, that the request for presentation is only received and responded to by the nodes when the node has sent a heartbeat? When I receive a regular sensor reading and fire back a presentation request, the node doesn't seem to care...?!

o.k., thanks! - and is there a way to broadcast this to all nodes or would I have to send it individually to every node?

@hek thanks for the quick reply - would that be the internal command id 19 that controller/gateway needs to send to the node?

Hi everyone,
apologies if this has been discussed before (I'm almost certain it must have), but I can't seem to find the answer in the forum...
I have a mqtt-gateway setup and would like to send a command via mqtt to a node (ideally a broadcast to all nodes) to re-issue it's startup-presentation info (incl. child-sensor-id's and types).
Thanks!

I have not, but will now thanks!

no intention to reinvent anything that is proven and works If you could kindly point me in the right direction for an example, I am more than happy to rely on what's available!

I don't mind at all
The idea is to post the sensor data to an uninformed controller/service, possibly web-based. Currently, the service would need to know what sensors are available and subscribe to the corresponding mqtt topics to get the sensor value as the message. I'd like it to simply subscribe to the top-level mystt topic and get all necessary information (like sensor id etc. ) in the actual message. There might be other ways to do this, I'm just experimenting and using a json container seems like a clean solution.

thanks for the lead, I will check into that!

Hi there, hope someone can point e in the right direction with this. I'd like to modify the mqtt client in a way that it posts json payloads containing the sensor id and possibly other information in the message. Where and how would I go for this?
Thanks, jjk

thanks, sounds good, I will give it a trg

hi folks, has anyone ever tried/considered to run this sensor on a battery powered node? Does it make sense, what would be a good setup? I want to monitor a remote watertank where it's hard to get power to... Thanks for your expert thoughts on this!