Posts made by Strixx

@Flyer Sorry, but I can't remember if I had any more problems after I manually fixed the database.

And just a couple months after I had this problem I switched to Home Assistant instead.

So I have been reading up alot. And yesterday I finally managed to upload a new bootloader to this ProMini. It was the optiboot that @bjacobse linked to. All worked fine without any errors.

But I must have been doing something wrong, because I am not able to upload any sketch to the Arduino after that. I only get not in sync errors.

Unfortunately I don't have time to continue on this until late next week...

Well. It was the radio that caused this false triggers. The final placement of the node must be in a radio shaddow.

I really "funny" thing is that I solved this problem by changing the radio. I had a NRF24L01+PA+LNA for better range. This was for future project (node in my greenhouse) which would need this node as a repeater for shore.
But by replacing the radio to a "normal" NRF24L01+ made the problem go away. I did not change the location!

@pjr I am still a noob when it comes to C. And I have not had the time to examine the Domoticz source code. But at first glance those lines seems as V_PERCENTAGE, V_SCENE_OFF, V_STOP and V_RGBW that updates the last seen on heartbeat.

I have had my node running now for 2 days just checking this heartbeat. And I can for shore sasy that is only working for the door sensor. Which presents it self as S_DOOR and sends V_TRIPPED messages.
It is not working for the motion sensor presenting it self as S_MOTION and also sends V_TRIPPED messages.

And one more really strange thing is that it is only working on the door sensor when the door is open. Not closed!

Update: It seems as heartbeat works in 4.9701 for S_DOOR, but not for S_MOTION or S_BINARY.

This is strange...

Last 24 hours I have had the node standing almost next to the gateway, and no false motion has been detected. So:

• Close to the gateway there is no false indication.
• Testing area in garage is no false indication.
• Final place in garage there is false indication.

PIR sensor is driven from 5V USB charger. All sensors are connected to the 5V charger as well as the Pro Mini. The radio is NRF24L01+PA+LNA connected to a AMS1117 5V-3.3V converter.
USB charger is capable to deliver 700mA. And if I calculate correct the node has a maximum of about 270 mA consumption.
So there should be more than enough power.

And why is it different due to location of the node? Does power consumption differs from radio depending on the quality of the radio connection to the gateway?

@yveaux Yes. I have understood that by reading up. But what I can't understand is that it not happens every time I use the radio. As it seems now it is only when the gateway is sending the discovery broadcast. Not when the node is sending data from the other sensors on the node, or when I send data to the node for operating the relays. Strange...

@electrik I disconnected the extender wires for reed. And it has been running all night like this. But no difference. So it can not be due to the extender wires.

@ahmedadelhosni Yes. This is a 5V sensor powered from a phone charger.

Hello,

I have been testing my latest node for a couple weeks. It's a node with a double relay, a DHT22, one reed switch and one motion sensor (HC-SR501), with repeater function. It is intended for maneuvering my garage door. And should be situated in my garage (of course) and the reason for repeater function is that I also have a temp node at my fridge in the garage that some times is not reaching my gateway. This new node is placed halfway between the gateway and fridge node.

It has been standing in the garage at the same distance as final mounting place and I have been logging the function. And all have been working perfectly.
But yesterday I mounted it and connected the garage door to the relay and extended the reed wires (4 meters), and now the motion sensor (not changed at all) is reporting motion every 20 minutes.

So last night I found this thread:
New nodes, new problems Motion sensor [Solved]
wich reports the exact same behavior.

But @xydix solved the problem with replacing the PIR from another model to the one I am using. Others suggest it is a power problem.
So I thought it was due to the reed switch. That was not tested at "closed" for a longer period under testing. Drawing current when the switch was closed.
But I disconnected it again, and no change. Still reporting motion every 20 minutes.

So:
Any one having any ideas what I should do next?
The only remaining differences from testing period is location. I was standing on a shelf before, and now it is placed in the sealing, with the same distance to the gateway (about 7 meters)

And if it is power issue due to radio radio transmissions (as suggested in the earlier mentioned thread) why is it only on discover request broadcast, and not when the node is sending data from DHT22 or reed, or when I send data to the node for maneuvering the relays?

@mfalkvidd Thanks! Don't think I found that page before. Found a lot of pages about this subject but not this page. But if I understand it correct I still need to buy a new Arduino. I only have a big supply of Pro Minis. No other models.

@bjacobse So it's time for a new raid with this project. I have been trying to read up on how to change bootloader. And if I understand it correct I need a programmer. And I only have a FTDI for uploading my code to my arduinos.
But somewhere I found that I can use a Arduino Uno instead.

So is this correct? If I buy a Uno will I be able to change to the new bootloader?

Answering my self for info to others that finds this thread.

I finally did the upgrade anyway and:
It is NOT working in v4.970.

@sglue Thanks for replying but that does not work in Domoticz. Just as mentioned in the thread. Domoticz only acknowledge that a sensor is alive if it sends new data. Not by sending a status that it has received earlier.

For now I have solved it by a dummy switch in my sketch that alternates on and off at every heartbeat, but I don't think that is a very nice solution. And I have to have two different script checking my sensors in Domoticz. One for the ones that heart beats is working in (ie X10) and one for my MySensors nodes.

Did some more research. And it seems to me now that it was Domoticz that somehow messed up the ID. Even after clearing the EEPROM and flashed the node with a new sketch specifying what ID to use, it did not show up in Domoticz. So I had a look in Domoticz database. And in the table "MySenors" everything looked as it should, but in table "MySensorsChilds" there was children to nodes not existing in the first table or in reality.
By removing those lines in the database, it started working again.

Can be that I have been adding children to this new node between tests?

Anyway; my conclusion is that it is safer to manually assign ID myself, when building and testing new nodes.

@gohan Ok. Then I will try your suggestion. I will first have to learn how to replace the bootloader..

Hello!

Anyone here using sendHeartbeat() and can confirm it works with Domoticz?
I have just build my first motion and door sensor, and I can not get Domoticz to update the "last seen" for them.

If I read on Domoticz forum @sundberg84 asked for this feature in january 2016, and as I understand it it was implemented in february.
But in another thread someone else is asking again for it. And this is in september 2017.

I am running version 3.8153 dated 2017-07-30.

If someone can confirm that it is working in latest stable 4.9700 I will update my server, otherwise not. I have always had allot of troubles on my previous updates. And now it has been working perfect for a year.

@mfalkvidd That is perfect. Thank you!
I will start with adding this to my nodes to prevent this from happening again, and messing up my controller (Domoticz).

When I think back to what happened was that at the time of when the old node changed ID, I was removing the battery from this this node, to reset it. Until now I thought it changed ID before this. The reason for restarting the node was that my controller had not got an status for several hours from the node. But of course it could be for some other reason. Radio interference or something else.
And then as I understand it, when I restarted the old sensor, some how Domoticz (if I have read up correctly it is the controller not the GW) assigned the ID of the new node I was playing with.

@gohan Well. I could try that. But it sounds strange to me that it will all the sudden change behavior. It was running fine without battery drain for a couple of weeks, and then all the sudden started draining the batteries.

@bjacobse
Changed the whole board. I have it laying here in my workshop, but haven't got the time yet to investigate more.
It's shore sounds like @sundberg84 was right about a leaking capacitor.

The node that changed ID all by it self yesterday was a battery powered node, with about 3 week old batteries. Reporting 100% battery.

And if I understand your answer correct this is just a coincidence that the change of ID on the old node was at time I was messing with my new node. And also that it got the same ID as the new one.

I don't have a programmer. So I will reprogam the old one.

New question:
If I define a manual ID (MY_NODE_ID), will this ID be rewritten to EEPROM every time the node starts? Or is it a one time operation, at first start.
By other words; will this prevent this that just happened to me from happening again?
Meaning: If I define MY_NODE_ID and the node corrupts the EEPROM in the future, all I have to do then is restart/reset the node.

Background:
I have 3 nodes running for a couple of month now.
Yesterday I built my 4th node. And when trying to load my sketch to it I had some strange errors output. I searched the internet without any luck. The node seemed to be working (except one sensor on the node), and I could see it in my controller. It had node id 4. I have not manually assigned any ID in my sketch.
To day I tried again with an updated code. With new errors. But the node still worked and the sensor still didn't work. Now it had node id 5.
I found out that the thing that caused the errors while downloading the sketch to the Arduino was because I was feeding power from a seperate source than the FTDI interface.
And tried again with new code for the sensor that did not work. Still node id 5.

Problem:
Sometime today when I was trying different codes on my new node (after or before I realized the problem with the errors when uploading the code) that one of my running node had changed id from 2 to 5. The same ID that this new node has. The new node and the old node both has a sensor on child id 0 that is a temperature sensor.
So this is all messed up.

Questions:

1. How can a node change id when running just out of the blue?
2. Is there a way to change it back, without clearing the EEPROM and reprogram it?

So. Forgot to get back.
But it was the Arduino it self that had gone bad. I switched the Arduino to a new, and everything was back to normal.

@sundberg84 Yes. I think I will have to do that.
I changed the test code above a little bit and added a delay for 5 seconds before sleep. And now I got better readings from my meter. It is about 48 mA when not sleeping and 28 mA when sleeping. So it does go to sleep but it is leaking somewhere.

To bad I don't have time this week for changing the arduino. I will have to get back next week about the progress.

@gohan Nope. But I tried that now, and then the sketch above again. Still the same.

So now I have been investigating some more. I tried to upload my own sketch again, but that made no difference. The constant power consumption was still there. So I then took the example code from the homepage and did some small adjustments and tried again.
It still consume power even when sleep. But now my meter only shows a constant 26-28 mA.

Here is the code that I use now:

#define MY_DEBUG  // Enable debug prints to serial monitor
#define MY_SPLASH_SCREEN_DISABLED  // Save memory
#define MY_SECURITY_SIMPLE_PASSWD "secret"  //Simpel soft signing with password
#define MY_SIGNING_SOFT_RANDOMSEED_PIN A3  // Unconnected analog pin for random seed
#define MY_RADIO_NRF24
#define MY_RF24_CHANNEL 110  // Set the frequency to channel 110 (2,510MHz), to prevent interference with all available WiFi channels (ch 14 -> 2,495MHz)


#include <SPI.h>
#include <MySensors.h>  
#include <DallasTemperature.h>
#include <OneWire.h>

#define ONE_WIRE_BUS 3 // Pin where dallase sensor is connected 
#define MAX_ATTACHED_DS18B20 1
unsigned long SLEEP_TIME = 30000; // Sleep time between reads (in milliseconds)
OneWire oneWire(ONE_WIRE_BUS); // Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
DallasTemperature sensors(&oneWire); // Pass the oneWire reference to Dallas Temperature. 
int numSensors=0;
bool receivedConfig = false;
bool metric = true;
// Initialize temperature message
MyMessage msg(0,V_TEMP);

void before()
{
  // Startup up the OneWire library
  sensors.begin();
}

void setup()  
{ 
  // requestTemperatures() will not block current thread
  sensors.setWaitForConversion(false);
}

void presentation() {
  // Send the sketch version information to the gateway and Controller
  sendSketchInfo("pool", "2.2");

  // Fetch the number of attached temperature sensors  
  numSensors = sensors.getDeviceCount();

  // Present all sensors to controller
  for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {   
     present(i, S_TEMP);
  }
}

void loop()     
{     
  // Fetch temperatures from Dallas sensors
  sensors.requestTemperatures();

  // query conversion time and sleep until conversion completed
  int16_t conversionTime = sensors.millisToWaitForConversion(sensors.getResolution());
  // sleep() call can be replaced by wait() call if node need to process incoming messages (or if node is repeater)
  sleep(conversionTime);

  // Read temperatures and send them to controller 
  for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {

    // Fetch and round temperature to one decimal
    float temperature = static_cast<float>(static_cast<int>((getControllerConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.;

    if (temperature != -127.00 && temperature != 85.00) {

      // Send in the new temperature
	  send(msg.setSensor(i).set(temperature,1));
	  Serial.print("Temperature sent: ");
      Serial.println(temperature);
    }
  }
  Serial.println("Sleep");
  sleep(SLEEP_TIME);
  Serial.println("Back from sleep");
}

And this is the serial output:

0 MCO:BGN:INIT NODE,CP=RNNNA---,VER=2.2.0
4 MCO:BGN:BFR
65 TSM:INIT
65 TSF:WUR:MS=0
73 TSM:INIT:TSP OK
75 TSF:SID:OK,ID=2
77 TSM:FPAR
114 TSF:MSG:SEND,2-2-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
413 TSF:MSG:READ,0-0-2,s=255,c=3,t=8,pt=1,l=1,sg=0:0
417 TSF:MSG:FPAR OK,ID=0,D=1
2121 TSM:FPAR:OK
2121 TSM:ID
2123 TSM:ID:OK
2125 TSM:UPL
2129 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
2136 TSF:MSG:READ,0-0-2,s=255,c=3,t=25,pt=1,l=1,sg=0:1
2142 TSF:MSG:PONG RECV,HP=1
2146 TSM:UPL:OK
2148 TSM:READY:ID=2,PAR=0,DIS=1
2152 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
2160 TSF:MSG:READ,0-0-2,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
2168 TSF:MSG:SEND,2-2-0-0,s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=OK:2.2.0
2179 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
3131 TSF:MSG:READ,0-0-2,s=255,c=3,t=6,pt=0,l=1,sg=0:M
3139 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=11,pt=0,l=8,sg=0,ft=0,st=OK:pool
3149 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:2.2
3158 TSF:MSG:SEND,2-2-0-0,s=0,c=0,t=6,pt=0,l=0,sg=0,ft=0,st=OK:
3164 MCO:REG:REQ
3168 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
3176 TSF:MSG:READ,0-0-2,s=255,c=3,t=27,pt=1,l=1,sg=0:1
3182 MCO:PIM:NODE REG=1
3184 MCO:BGN:STP
3186 MCO:BGN:INIT OK,TSP=1
3192 MCO:SLP:MS=750,SMS=0,I1=255,M1=255,I2=255,M2=255
3196 TSF:TDI:TSL
3201 MCO:SLP:WUP=-1
3203 TSF:TRI:TSB
3233 TSF:MSG:SEND,2-2-0-0,s=0,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:25.2
Temperature sent: 25.20
Sleep
3241 MCO:SLP:MS=30000,SMS=0,I1=255,M1=255,I2=255,M2=255
3250 TSF:TDI:TSL
3252 MCO:SLP:WUP=-1
3254 TSF:TRI:TSB
Back from sleep
3260 MCO:SLP:MS=750,SMS=0,I1=255,M1=255,I2=255,M2=255
3264 TSF:TDI:TSL
3268 MCO:SLP:WUP=-1
3270 TSF:TRI:TSB
3336 !TSF:MSG:SEND,2-2-0-0,s=0,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=NACK:25.2
Temperature sent: 25.20
Sleep
3346 MCO:SLP:MS=30000,SMS=0,I1=255,M1=255,I2=255,M2=255
3352 TSF:TDI:TSL
3356 MCO:SLP:WUP=-1
3358 TSF:TRI:TSB
Back from sleep

@gohan Well. I see that I was not clear about my misstake. I don't know which sketch I have uploaded to the node. I have several version of the sketch on my computer and I am not sure which I have uploaded.
What I do know is that none of them has enabled debug for serial output. I disabled that when I got them working.
So the only thing I can (at least that I know of) is checking the gateway log with MYS Controller. And i will try that tomorrow evening when I am back home from work.

And just to be cleare. I am asking for your help beacuse I want to help find an eventual bug in the library code.
I am happy with trying to upload a new sketch to see if that helps. But before that I want to know if there is any possible ways to find out why it doesn't go to sleep any more.

I have checked the code in the sketch. And I think that I have been mixing some code in all my sketches.
And it looks like the node is requesting acknowledgement from gateway, but I am not shore.

Is there a way to check this? To see if I have uploaded the wrong sketch?

And if that is the case. Can that be the cause for the battery drain?
The strange thing is as I wrote above, that the node doesn't seem to go to sleep even after I moved it to the same room as the gateway. It should be receiving ack from the gateway now. And the gateway is receiving the messages.
And the node has been working just fine until I moved the gateway, but now it is not. Not even after moving the node to the same room.

So, as you see I have tried all of the suggestions. The node is working. Reporting to the gateway. The sensor connected to the arduino is working, and nothing wrong with the radio.

So can it be that some how the node doesn't sleep any more, and could this be because it had trouble to connecting to the gateway, and that something got stored in EEPROM that now prevents it from sleeping, even though it now can communicate with the gateway?
IS there someway I can find this out without uploading a new sketch to the node?

I am asking because I would like to help finding eventual buggs. It would be a missed opportunity if I upload a new sketch and that fixes the problem. Then we would not be able afterwards to find what was causing this.

@bjacobse Changed the radio to a new, but it is still the same.

@yveaux I use version 2.2.0 of the library. And it does not help to move the node next to the gateway, it still drains the battery.

@gohan Done that now. The current doesn't change when unplugging the radio or the sensor. My very simple meter shows 67 mA when the node power up, and then it drops to 47-48 mA and stays there.
The node works, and sends data to the gateway.

Hello!

I have a problem with extreme battery drain on one of my nodes. It's a temperature sensor with a DS18B20 and (NRF24 radio). It sleeps for 15 minutes and only reports temperature if changed more than 0.5 degrees. But at least one time per hour.
Have have two identical nodes with same sketch (except the name).
But one of them started to drain the battery. A pair of new batteries is drained in only 12-14 hours.

It was working fine for a couple of weeks. But about 2 weeks ago one of them stopped sending. I noticed this a day of two after I changed the location of the gateway. So I thought it was because of radio shadow.
But then a couple of days ago I went for changing the location of the node. And noticed that it was the battery that was dead. So I changed batteries and moved the sensor at the same time.
The next morning I noticed it was offline again.

So today I took it apart and start checking. Battery dead again. I have been checking cables now I can't find anything that should be causing this.

So before I upload the sketch again to the code I would like to here what you guys think.
Can it be a bug that I should try to find before doing that?

@yveaux said in Radio Traffic LEDs - Lights up on heart beat...:

@strixx yes, you have to supply your own implementation of the indication function once you define that.
It needs to be defined before the mySensors include statement.

I have learned that much that I need to define before including the library. But can I put the function (the code) anywhere? For example at the end of my sketch?

I haven't had time to read up on your suggestions. But hopefully I will have some spare time this weekend. But thank you for your help so far.

Do I understand it right:
By defining MY_INDICATION_HANDLER before the I include the MySensors library, that part of the library will not be included in the sketch?
And then I wright my own handler for blinking the leds in my own sketch?

Can I put it at the end or must it be in the beginning?

@yveaux But what I would like is that the led's only show status of communication between nodes and gateway. Not between gateway and controller to. So not to change or add things to led, only remove the part where it lights up on communication between gateway and controller.

Is this really the easiest way to do just that?

@anticimex Thank you! I have been reading that doc, but missed the part that says: "This flag will enable signing, signature requests and encryption."

@yveaux I'm a newbie when it comes to C++, but I have been coding for a long time in Python. I can't really see how I can change that code you are referring to to get the changes I am looking for.

But I found something in https://github.com/mysensors/MySensors/blob/development/core/MyGatewayTransportEthernet.cpp which I think is the code @mfalkvidd is reffering to.

So I think I someway need to change INDICATION_GW_TX and INDICATION_GW_RX in my sketch for my gateway.

Is that the way I should go if I don't change directly in the library code?

@mfalkvidd

Thank you!

Would you like to tell where in the code you found this?
I would like to change that, so that the led's only show the radio traffic for the node communication, and not between GW and controller.

So i have looked at the API dokumentation and in MyConfig.h and can't seem to find the default value of MY_SIGNING_WEAK_SECURITY.
I still feel unsure how it works.

My code looks like this (in both GW and node), and I don't set anything else, and doesn't include MyConfig.h in my sketch:

#define MY_SECURITY_SIMPLE_PASSWD "123456789"
#define MY_SIGNING_SOFT_RANDOMSEED_PIN A3

• As I understand the documentation the communication will be encrypted in both ways, and all messages will be signed. Is that correct?
• What if I build another sensor node without these lines of code. Will the gateway accept it?
• What if I build another actuator node without these lines of code. Will the node accept messages from the GW?

Or do I need to set the "MY_SIGNING_REQUEST_SIGNATURES" in both GW and node to force signing?

I have been trying to read up on the signing and encryption part. But some questions I am not able to find a simple answere to.

If I define "MY_SECURITY_SIMPLE_PASSWD" with a password:

• Do I need to asign a anlog pin for random seed?
• If I define it in the gateway, can nodes without "MY_SECURITY_SIMPLE_PASSWD" defined send messages to the gateway, and vice versa?
• If I don't define it in the gateway, can nodes with it defined send messages to the gateway?

So I have my gateway up and running and connected to my controller which is Domoticz.

And I notice that every time Domoticz is sending a heart beat both TX and RX LED lights up on the gateway.
So I wonder why the RX lights up. I only have battery powered sensors, and they dont reply on the heart beats.
When I use MYSController to check. There is no answere to the heart beats.

I use MySensors 2.2.0. The gateway is a ESP8266 (NodeMCU 0.9).

@mntlvr

Strixx
You have a WiFi gw up and working , right? What version of the MYSensors are you using? Also what type of Vera are you using. I am using a Vera3 and a Vera Plus? Also which plugin are you using for your Vera. I have built both WiFi and Ethernet and the sensors talk wonderfully to the gw's no matter which I power up but neither of my Vera's will configure and use the plugin that are the latest available from git-hub.

I don't use Vera. I use Domoticz.

@mntlvr I use Domoticz, not Vera. So I can't answer any questions about that controller.

But here is my code for the ESP8266 Gateway. I am using 2.2.0 library.

// Use a bit lower baudrate for serial prints on ESP8266 than default in MyConfig.h
#define MY_BAUD_RATE 9600

// Enables and select radio type (if attached)
#define MY_RADIO_NRF24
// Set the frequency to channel 110 (2,510MHz), to prevent interference of WiFi channel 14 (-2,495MHz)
#define MY_RF24_CHANNEL 110

// ESP8266 Gateway
#define MY_GATEWAY_ESP8266

// WiFi settings
#define MY_ESP8266_SSID "wifi"
#define MY_ESP8266_PASSWORD "password"

// Set the hostname for the WiFi Client. This is the hostname
// it will pass to the DHCP server if not static.
#define MY_ESP8266_HOSTNAME "MySensor_GW"

// The port to keep open on node server mode
#define MY_PORT 5003

// How many clients should be able to connect to this gateway (default 1)
#define MY_GATEWAY_MAX_CLIENTS 2

// Enable inclusion mode
#define MY_INCLUSION_MODE_FEATURE
// Enable Inclusion mode button on gateway
#define MY_INCLUSION_BUTTON_FEATURE
// Set inclusion mode duration (in seconds)
#define MY_INCLUSION_MODE_DURATION 60
// Digital pin used for inclusion mode button
#define MY_INCLUSION_MODE_BUTTON_PIN  D4

// Set blinking period (in milliseconds)
#define MY_DEFAULT_LED_BLINK_PERIOD 300

// Flash leds on rx/tx/err
// Led pins used if blinking feature is enabled above
// Internal onboard LED is PIN 16 
#define MY_DEFAULT_ERR_LED_PIN D10  // Error led pin (Red)
#define MY_DEFAULT_RX_LED_PIN  D9  // Receive led pin (Yellow)
#define MY_DEFAULT_TX_LED_PIN  D1  // Transmit led pin (Green)

#include <ESP8266WiFi.h>

#include <MySensors.h>

void setup()
{
}

void presentation()
{
	// Present locally attached sensors here
}


void loop()
{
	// Send locally attached sensors data here
}

Be aware that if you use D4 for inclusion button the button can not be pushed at start of gateway. Then the gateway will not boot correct.

@mntlvr
I have the NodeMCU 0.9. This is the PIN layout and what I am using:

//LEDs
D1    GPIO 5
D9    GPIO 3
D10   GPIO 1

//Inclusion button
D4    GPIO 2

//Radio
D2    GPIO 4
D5    GPIO 14
D6    GPIO 12
D7    GPIO 13
D8    GPIO 15

@mntlvr said in Advanced Gateway Options:

Thanks Strixx
I am using D4 D5 D9 D10
and as soon as I can get the unit to work with either of my Vera's I will know if mine works. It seems sinceI have gone over to the newest Library none of the gateways I build works.

Don't know what radio you are using, but for the NRF24L01+ D5 is used for the radio.

And D4 is not possible to use for LED. It can not be high or low on boot. That has some special purpose.

The only pins available for LED is the ones I use. D1, D9 and D10.

I use D4 for inclusion button. That works as long as I don't press the button at startup of gateway. Then it will not start.

@mntlvr said in Advanced Gateway Options:

So what is the finial solution to using the Led's on a ESP 8266-E gateway are they of any use if using a Vera Controller?

I have had a lot of help with the leds. I have noticed that you get a lot of errors (in some positions it is impossible to communicate with the nodes at all) if not the radio is positioned to close to the ESP. It seems to me that the radio on the NodeMCU interferes with the NRF24L01+PA+LNA that i am using on my gateway. I found I thread on this forum about it but can't find it again.

So thanks to the leds I have been able to build a box where i have no transmission errors due to interference.

@mntlvr I am using D1, D9 and D10. And it works perfectly on NodeMCU 0.9. Without the need of "MY_WITH_LEDS_BLINKING_INVERSE".

Here is the code:

// Set blinking period (in milliseconds)
#define MY_DEFAULT_LED_BLINK_PERIOD 300

// Flash leds on rx/tx/err
// Led pins used if blinking feature is enabled above
// Internal onboard LED is PIN 16 
#define MY_DEFAULT_ERR_LED_PIN D10  // Error led pin (Red)
#define MY_DEFAULT_RX_LED_PIN  D9  // Receive led pin (Yellow)
#define MY_DEFAULT_TX_LED_PIN  D1  // Transmit led pin (Green)

Ok. Will do some more testing to be sure it works as expected, and then create an issue.

@mfalkvidd said in NodeMCU PIN reference:

See here for the NodeMCU Dn pins and BUILTIN_LED

I shows that numbers the Dn aliases are mapped to.

Yes I did. I don't know why I have been trying with only digits without the D in front. I have been reading up on this project a lot, and I think I have seen somewhere that both Dx and x have mappings to GPIO. But maybe I have been reading in some old source or maybe that is only for Arduino. Or maybe I am only dreaming. But I do feel a bit stupid now...
(But in my defense, in the example code for the gateway the LED pins are only referenced by a single digit)

As for the pull request. I consider myself to much of a newbee to be doing that. Even suggesting to the professional here in the forum is a bit scary..

@mfalkvidd That is perfect.
I have been buisy with another projects. But I did quite a lot of trials, and could not get it to work for me no mater what i tried.
But now I see what was the problem. I was assigning the pin with only a digit. IE 1, 3, 4. But with D1, D3 and D4 it works. I was under the impression that 1 = D1, but it's not.

Now that I got it working I have noticed a strange thing. When using MYSController for debugging I can only sometimes se the inclusion message sometimes in the "log". But always when logging with netcat. I have not been able to see any pattern for when MYSController is not showing the message.

May I suggest another PIN for the inclusion button?

As I understand it. With the NodeMCU 0.9 that I'm using there is only a limited number of pins left to use after connecting the radio. D0, D1, D3, D4, D9 and D10. And some of them have special purpose. And if you want to use external leds for rx/tx/err (instead of the internal led as used by the example) there are (as I understand it) only three pins left, and that is D1, D9 and D10. But D3 and D4 should be safe to use for inclusion button, since they only have special use at boot. So as long as you don't press the inclution button at startup of the gateway they are safe to use as input.

My suggestion, which I have been trying with out problems the last couple of hours, is that:

#define MY_INCLUSION_MODE_BUTTON_PIN  D4

#define MY_DEFAULT_ERR_LED_PIN D10  // Error led pin (Red)
#define MY_DEFAULT_RX_LED_PIN  D9  // Receive led pin (Yellow)
#define MY_DEFAULT_TX_LED_PIN  D1  // Transmit led pin (Green)

Ok. So my strange error was due to connecting GND to the wrong PIN.

I was connecting GND next to VCC on the side of the Pro Mini.
Accordning to pics on the MySensors homepage and to the marking of my Arduino that pin is GND.

But when connecting the FTDI with jumper cables I notice that PIN was marked with CTS.
So instead I connected GND to the pin one step out.
This PIN is also marked GND on my Arduino, and on the FTDI. But marked BLK on the pictures on MySensors home page.

So it seems that both these pins are GND on my board, because everything else was working fine except the reference for analogue pins.

So topic solved. Thanks for all input. And specally @gohan that made me use the jumper cables and therfore found the error.

@zboblamont Yes. It looks like bad wiring. I am testing right now. And it looks like my Arduino clone has some bad markings of the pins.... I am documenting and posting the solution (if it is what I am suspecting right now) later today. Right now I am doing test cycles while doing some paid work..

@gohan Well. I think I have found the problem. Investigating now. I will get back during the day when I have tested some more times.

@gohan No regulator except the built in on the card. I also tried with two new AA and when not reporting crazy values it is reporting 74% correlating to calculated vBat of 3,14 and the actual voltage 3,24.
So again; working just fine.

Ok. So connecting the node to serial interface, but without power from it. And power from same batteries.
The calculations is correct and multimeter is not measuring correct.

This is debug out put:
First loop:

Sensor value: 1023
Battery Voltage: 3.30 V
Battery percent: 100 %

Second and the following loops:

Sensor value: 877
Battery Voltage: 2.83 V
Battery percent: 21 %

So back to square one. When serial output is connected it works perfect.
When disconnected it starts reporting all messed up readings!

@gohan Thinking outside the box... will do..

@gohan Cant unplug the Vcc from FTDI. Not without cutting the pin on my Mini.
And it will not help do average from 4 or even 10 readings. It will still show a messed up percentage. Non of the readings is below 100%

@zboblamont
The voltage at A0 is at steady 0,8V with batteries.
Which should give sensor value 744.
The voltage of the two batteries is 2,88V.

But as I wrote earlier it must be so that my multimeters internal resistance is not high enough. And is messing up the divider when measuring.
The calculated voltage at A0 should be 0,89V
Which should give sensorValue 828

My sensors right now is reporting 100% then 253% and now 236%.

@zboblamont Nothing strange. sensorValues between 800 and 1023, and correct corresponding vBat and batteryPcnt according to my formulas. But that's when I have the serial programmer connected.
I don't know how to get the serial output from debug without having it connected.
The strange values only appear when on battery.

@zboblamont Yes. 3V Mini Pro
@gohan Yes. 0.1uF capacitor.
@rozpruwacz Internal reference 1.1V. Have a external divider exactly as the example schematics on the home page, to get maximal 1.1 V with two AA batteries.

As a first step I am trying to understand how the batteryPcnt can ever be higher than 100. With my code that should be impossible. Even if i put 5V on A0.

vBat should never be able to be higher than v_MAX
and therefore batteryPcnt should never be able to be higher than 100.

@sundberg84 Short reply:
Doesn't matter what the actual reading is.

#define V_MIN 2.7  // 0% Battery voltage
#define V_MAX 3.3  // 100% Battery voltage

  // read analog pin
  int sensorValue = analogRead(BATTERY_SENSE_PIN);
  // calculate battery voltage
  float vBat  = static_cast<float>(sensorValue * (V_MAX/1023));
  // calculate % left of defined interval
  int batteryPcnt = static_cast<int>(((vBat-V_MIN)/(V_MAX-V_MIN))*100.);

In my head this code should never be able to set batteryPcnt higher than 100. Unless sensorValue can be greater than 1023.

Long reply:
Yesterday I was measuring the voltage with a multimeter and ended up recalculating the divider over and over again. With the same result over and over again. The voltage at the tap point was not the same as the math told me it should be.
But then last night it hit me. The internal resistance in my multimeter is not high enough to give me an accurate reading with such high resistors in the divider. (I studied electronics 25 years ago. The knowledge is there but buried deep in my mind)

In one of all these recalculations I came up with the code snippet in this reply. Simply to make shore that what ever reading you get you will never present a value over 100%.

And as I wrote in the original post. The strange thing is that when the sensor is connected to the serial programmer the sensorValue never exceeds 1023, and therefore the batteryPcnt never exceeds 100. But as soon as i disconnect the serial programmer and put the sensor on battery power, it starts reporting reading of above 100% and all the way up to 300%.
And it makes it every time. I have tried switching at least ten times with the same result every time.

Hello,

I'm building my first battery powered sensor. A simple temperature sensor using a Pro Mini with a DS18b20.
The temperature reading works just fine, but the battery reading is all crazy.
I have wired it just like the example.

When connected to the serial programmer the reading seems fine. The reading jumps up and down but never goes above 100%. I guess fluctuation is due to the powering from the FTDI, and the battery only connected to radio and tap point to A0.

But when on battery power I got readings every sleep cycle of 120-300%. This is my code:

// ------------------ MYSENSORS ------------------
// Enable debug prints to serial monitor
#define MY_DEBUG

// Enable and select radio type attached
#define MY_RADIO_NRF24
// Set the frequency to channel 110 (2,510MHz), to prevent interference of WiFi channel 14 (-2,495MHz)
#define MY_RF24_CHANNEL 110

#include <SPI.h>
#include <MySensors.h>  
#include <DallasTemperature.h>
#include <OneWire.h>

unsigned long SLEEP_TIME =  5 * 60000; // Sleep time between reads (in milliseconds), 60000 ms = 1 minute

// ------------------ TEMPERATURE ------------------
#define COMPARE_TEMP 1 // Send temperature only if changed? 1 = Yes 0 = No
#define ONE_WIRE_BUS 3 // Pin where dallase sensor is connected 
#define MAX_ATTACHED_DS18B20 1
OneWire oneWire(ONE_WIRE_BUS); // Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
DallasTemperature sensors(&oneWire); // Pass the oneWire reference to Dallas Temperature. 
float lastTemperature[MAX_ATTACHED_DS18B20];
int numSensors=0;
bool receivedConfig = false;
bool metric = true;
// Initialize temperature message
MyMessage msg(0,V_TEMP);

// ------------------ BATTERY ------------------
int BATTERY_SENSE_PIN = A0;  // select the input pin for the battery sense point
int oldBatteryPcnt = 0;  // remember last measured percentage
#define V_MIN 2.7  // 0% Battery voltage
#define V_MAX 3.3  // 100% Battery voltage

void before()
{
  sensors.begin();
}

void setup()
{
  // requestTemperatures() will not block current thread
  sensors.setWaitForConversion(false);

  // Setup 1.1 V internal reference for analoge GPIO
  analogReference(INTERNAL);
}

void presentation()
{
   // Send the sketch version information to the gateway and Controller
  sendSketchInfo("Hottub", "2.1");
  // Fetch the number of attached temperature sensors  
  numSensors = sensors.getDeviceCount();

  // Present all sensors to controller
  for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {   
     present(i, S_TEMP);
  }
}

void loop()
{
  // read analog pin
  int sensorValue = analogRead(BATTERY_SENSE_PIN);
  // calculate battery voltage
  float vBat  = static_cast<float>(sensorValue * (V_MAX/1023));
  // calculate % left of defined interval
  int batteryPcnt = static_cast<int>(((vBat-V_MIN)/(V_MAX-V_MIN))*100.);  
  // debugging
  #ifdef MY_DEBUG
    Serial.print("Sensor value: ");
    Serial.println(sensorValue);
    Serial.print("Battery Voltage: ");
    Serial.print(vBat);
    Serial.println(" V");
    Serial.print("Battery percent: ");
    Serial.print(batteryPcnt);
    Serial.println(" %");
  #endif
  // If battery % has change send to controller
  if (oldBatteryPcnt != batteryPcnt) {
    // Power up radio after sleep
    sendBatteryLevel(batteryPcnt);
    oldBatteryPcnt = batteryPcnt;
  }

  // Fetch temperatures from Dallas sensors
  sensors.requestTemperatures();

  // query conversion time and sleep until conversion completed
  int16_t conversionTime = sensors.millisToWaitForConversion(sensors.getResolution());
  // sleep() call can be replaced by wait() call if node need to process incoming messages (or if node is repeater)
  sleep(conversionTime);

  // Read temperatures and send them to controller 
  for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {

    // Fetch and round temperature to one decimal
    float temperature = static_cast<float>(static_cast<int>((getControllerConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.;

    // Only send data if temperature has changed and no error
    #if COMPARE_TEMP == 1
      if (lastTemperature[i] != temperature && temperature != -127.00 && temperature != 85.00) {
    #else
      if (temperature != -127.00 && temperature != 85.00) {
    #endif

      // Send in the new temperature
      send(msg.setSensor(i).set(temperature,1));
      // Save new temperatures for next compare
      lastTemperature[i]=temperature;
    }
  }
  sleep(SLEEP_TIME);
}

How can the value ever be greater than 100% and only when powered with battery and not with the serial programmer?

What am I missing? I have been struggling with this for 2 days now, and can't come up with any more ideas to try!

I believed that adding this button to the gateway would set Domoticz to accept new hardware, when the button was pushed. But now that I have investigated some more it seems that this button is only used in Vera? Maybe there is a way to add this function in Domoticz, but that's for later.

Anyway; since I started this "issue" I want to finish it, even if I have no use of the button.

Is there any way to see if the gateway sends anything to the controller when I push the button?
I cant see anything on the serial output.

Back to testing the inclusion button, now that the gateway is up and running.

I am trying to see in serial monitor, MYS Controller and Domoticz to see if it works, but nothing.
What would be the easiest way to see if the function actually is working?

It for shore is. And what is even more strange is that adding a new manually assigned IP now is working.
Can't explain it. The router is a Asus RT-AC66U.

Ok... Sorry for bothering you... I have been testing several things now for an hour. And I found what was causing the errors, and it was my Asus router. A year ago when started this project apparently set up an dhcp rule for the gateway binding it to a certain ip when connecting. Some how this is the cause for not getting any IP at all.

Because now, when removing this rule, I am able to connect and receive IP adress in dynamic mode on.

It is strange because I have allot of other things that is getting manually assigned IP from the DHCP in the router, and they all works. But I guess this is to hard for me to find why the gateway is not working with this settings in the router..

Now I will get back to testing inclusion mode and traffic leds on the NodeMCU wifi gateway.

Well off course you are right about not posting output when it works. But then again Google wont find many answers on that phrase.

Any way. Last night I updated uupdated to MySensors library 2.1.1, and tried again, without any luck. I did notice that I got some errors about invalid library in the IDE after switching to 2.1.1. But there was no luck, still no assigned IP. Tried to change to a different AP. Nothing

So this morning I gave it a new go and change the code back to static IP, and now it is working.

connected with wifi_2@home, channel 11
ip:192.168.2.50,mask:255.255.255.0,gw:192.168.2.1
.IP: 192.168.2.50
0;255;3;0;9;MCO:BGN:STP
0;255;3;0;9;MCO:REG:NOT NEEDED
0;255;3;0;9;MCO:BGN:INIT OK,TSP=NA
pm open,type:2 0
0;255;3;0;9;Client 0 connected
0;255;3;0;9;Client 0: 0;0;3;0;2

So I cant find any pattern in this. I will do some more testing during the day to see if I can find what went wrong before..

@mfalkvidd I've tried disconnected the radio and comment out the radio. Still the same.

I googled the phrase "pm open,type:2 0" and all hits seemed to refer to problems. So I assumed it was some kind of error message. Since I can't find any documentation of the initial output in the serial interface, and I haven't got the time to go through all the source code.

I started building the gw a year a go, and then it worked. Then I put it on a shelf waiting to get the time to build some sensors. Two weeks ago I started with this project again. And the only thing changed is I now have a new computer. Same router (but uodated firmware), same server, same gateway (Domoticz).

So I thought it was the usb port not being able to power the Node MCU. To day I plugged in a powered usb hub, but that made no difference. Then tried recompiling with the latest MySensors library, then "down grading". Still the same.

I don't know what I except to see. Don't remember how it looked a year ago. But at least an assigned IP (I have seen this output in the forum searching this)

I can't ping it. I can't telnet. I can't see it in my router. And my controller can't find it.

Tried as I wrote with both static and dynamic IP.

Hello,

Help needed. I am trying to build a WiFi gateway using NodeMCU. Actually I built it a year ago and it was working fine. But then this hole projekt was suspended, and brought to life again now. But I am not able to get the GW wroking.
I am using Arduino IDE 1.8.5 and have tried with both MySensors library 2.0.0 and 2.1.1. Without any differens.

This is my code:

// Enable debug prints to serial monitor
#define MY_DEBUG

// Use a bit lower baudrate for serial prints on ESP8266 than default in MyConfig.h
#define MY_BAUD_RATE 9600

// Enables and select radio type (if attached)
#define MY_RADIO_NRF24
//#define MY_RADIO_RFM69

#define MY_GATEWAY_ESP8266

#define MY_ESP8266_SSID "wifi_n2@home"
#define MY_ESP8266_PASSWORD "XXXXXXX"

// Enable UDP communication
//#define MY_USE_UDP

// Set the hostname for the WiFi Client. This is the hostname
// it will pass to the DHCP server if not static.
#define MY_ESP8266_HOSTNAME "MySensor_GW"

// Enable MY_IP_ADDRESS here if you want a static ip address (no DHCP)
//#define MY_IP_ADDRESS 192,168,2,50

// If using static ip you need to define Gateway and Subnet address as well
//#define MY_IP_GATEWAY_ADDRESS 192,168,2,1
//#define MY_IP_SUBNET_ADDRESS 255,255,255,0

// The port to keep open on node server mode
#define MY_PORT 5003

// How many clients should be able to connect to this gateway (default 1)
#define MY_GATEWAY_MAX_CLIENTS 2

// Controller ip address. Enables client mode (default is "server" mode).
// Also enable this if MY_USE_UDP is used and you want sensor data sent somewhere.
//#define MY_CONTROLLER_IP_ADDRESS 192, 168, 178, 68

// Enable Inclusion mode button on gateway
//#define MY_INCLUSION_BUTTON_FEATURE
// Set inclusion mode duration (in seconds)
//#define MY_INCLUSION_MODE_DURATION 60
// Digital pin used for inclusion mode button
//#define MY_INCLUSION_MODE_BUTTON_PIN  3

// Set blinking period
//#define MY_DEFAULT_LED_BLINK_PERIOD 10

// Flash leds on rx/tx/err
// Led pins used if blinking feature is enabled above
// Internal LED is PIN 16
//#define MY_DEFAULT_ERR_LED_PIN 16  // Error led pin
//#define MY_DEFAULT_RX_LED_PIN  16  // Receive led pin
//#define MY_DEFAULT_TX_LED_PIN  16  // the PCB, on board LED = 16

#if defined(MY_USE_UDP)
#include <WiFiUdp.h>
#endif

#include <ESP8266WiFi.h>

#include <MySensors.h>

void setup()
{
}

void presentation()
{
	// Present locally attached sensors here
}


void loop()
{
	// Send locally attached sensors data here
}

And here is the serial output:

0;255;3;0;9;Starting gateway (RNNGE-, 2.0.0)
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSM:RADIO:OK
0;255;3;0;9;TSM:GW MODE
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 4
cnt 

connected with wifi_n2@home, channel 6
dhcp client start...
chg_B1:-40
0;255;3;0;9;TSM:READY
f r-40, scandone
...................pm open,type:2 0
...................................................................

No matter what I tries in the code (static/non static IP) it is the same output.
Any ideas about what is wrong?

@mfalkvidd I have not started building it yet. Hopefully I will have some spare time tomorrow, otherwise it will be in a week or two. I will get back as soon as I have got it all up and running (with external radio traffic LED as well).

@dbemowsk Thank you! This is what I was looking for. Especially the code in your thread.

@mfalkvidd Thank you!

Then I had it all figured out any way and the code for the ESP8266 WiFi Gateway (https://github.com/mysensors/MySensors/blob/master/examples/GatewayESP8266/GatewayESP8266.ino) is not correct when it comes to the inclusion button. Either the comments on which GPIO the button should be connected to or the PIN assignment should be changed.

Once more: Thank you for your help!

@sundberg84 But how will that code handle a push button in the controller, and not a switch?
I don't have access to either my controller or MySensors hardware at the moment therefore I can not try it my self. Will the controller send on, and then off? What happens if the off doesn't reach the node?

It is very important that the relay never stays at "on". Because I am about to attach a bell/siren /sound device to the relay. And use it give me audio notice when something is "bad" in my house. For example when the freezer has to high temperature. So the relay should only switch on, and then off again.

Hi,

I am wondering what the best sensor type would be for a relay actuator which I want to control from my controller (Domoticz) with a push button.

What I am about to build is a sensor with only a relay. No buttons on the sensor. And in the controller I want to control that relay with a push button. So when I activate the push button in my controller the relay switch on and then off again after lets say 1 second.

The only way I have found is to present it as S_BINARY, and then put the logic in the code on both sides (sensor and controller). But is there a more native way to do this in the library that I not yet have found? So that the sensor shows up as a push button in the controller by it self without the need for extra code on any side?

Hello!

I am struggling with how I should refer to the different GPIOs vs PINs in my code. I have been looking at the library source code and different example code, as well as the complete pin mappings of the NodeMCU, and i find disparities.

For example in the code for the ESP8266 WiFi Gateway (https://github.com/mysensors/MySensors/blob/master/examples/GatewayESP8266/GatewayESP8266.ino) all comments about which GPIO to connect the radio correlates correct to the PIN layout.
Then it says to connect the inclusion button to GPIO5 which is PIN D1. Later in the code it defines inclusion button to PIN 3, which is GPIO0.
To confuse it even more, the same example code later uses PIN 16 which is the internal LED on the board...

And the next confusing thing is how I refer to the analog PIN on the board? On the board there is only one analoug PIN, named A0. How do I put that one in the code for soft signing? I have seen example of both "0" and "A0". Which is the correct?

Is there any where I could find a complete reference for the PIN vs GPIO for the ESP8266 in the MySensors library?

@maghac Well... I guess you are right about how useful the LEDs are. But I still would like to learn how to use the NodeMCU. And then there is also this, shall we call it OCD...

@maghac What pins are you using for the LEDs? I have been investigating the GPIO vs PIN layout for the NodeMCU now for several hours. And I am still not shore which I shall use.
I have found complete maps for the GPIO and thought I had it all figured out. But then I saw in the example code for the gateway (GatewayESP8266.ino) the following:

/*
 * Inclusion mode button:
 * - Connect GPIO5 via switch to GND ('inclusion switch')
*/
....
// Digital pin used for inclusion mode button
//#define MY_INCLUSION_MODE_BUTTON_PIN  3

But on NodeMCU GPIO5 is PIN D1 and not D3 (which is GPIO0)

So please... Anyone... What pins on the NodeMCU is usable for connecting radio traffic LEDs, and how do I name them in the code?