@macieiks I got an identical Error last week after upgrading to Arduino 1.8.0. Solution is:
https://forum.mysensors.org/topic/4680/mysensors-2-0-ethernet-gateway-atmega-w5100-restart-all-time/4
simple: If you are running AVR board defs > 1.6.11, downgrade to 1.6.11 and the issue should be solved. (from @tekka).
If someone is interested: same Error for ENC28J60 Ethernet module, resolved with downgrading board definitions to 1.6.11.
@Reza Your code isn´t easy to understand. More Comments within your code would be very helpful.
So I will try a little mind reading.....
Basic concept seems to be decoupling switches/pushbuttons from the relais part and to control the relais action through your controller.
Management of switches/pushbuttons is done in loop().
"Master of states" is your controller (software).
Actions are performed by receive().
At last a clean soloution - but some parts aren´t that clean.
The only reference to stateX is within receive() directly before digital_write(X). So any change to stateX from within the sketch will not have any effekt. So the introduction of the stateX variable isn´t actually necessary.
digitalWrite(message.sensor + 2, message.getBool() ? RELAY_ON : RELAY_OFF);
should work to. This eliminates thes risk of double originals which can get very tricky if things go wrong. (i.e. there should be only one set of stateX variables in your system because keeping copied sets tidy is a huge amount of work and prone to errors).
In the first part of loop() you try to instantiate some basic mechanisms to accomplish this mission but I fear it will not succeed.
Within loop you begin with a chain of modulo-operations which might be intended to send the state variable to your controller once every hour (?) with 1 second interval. This will fail eternally if your loop starts accidentally with millis() at xxxxxx1 and loop duration is xxxxxx2. The remainder of % operation will always be 1 (or more) but never zero. Precise timing down to 1 millisecond would be too critical to little errors and is not necessary.
Spacing send() to one second should not be necessary either - MySensors framework can deal with lot of send() in a row.
So maybe a statement like
if (millis() >= lasttime+INTERVALL) {.....}
could fit your needs. It isn´t that precise - but precise enough and robust.
if (trigger == 0) {...;trigger=1;}
This part is executed only once because you never reset trigger to zero. If you intend to reset your controller variables you might move this part to setup() - or better leave it to your controller.
But if you omit stateX copying this whole section could be skipped.
The rest of loop() consists of switch management which seems ok to me. Nevertheless a little proposal for optimisation:
send(msgA.set(stateA ? true : false), true);
There is no really need for the trinary operator ? because stateA is bool, it may be send directly like
send(msgA.set(stateA ), true);
debouncerA.update();
I am not very familiar with debounce(). But omitting "&&valueA==0" will cause your statement to react to pressing your button as well as to releasing your button. So this statement will act twice on one keystroke -- so far I remember the debounce() function.
Because stateA is not likely to be changed in this short amount of time, this statement will send stateA twice - which causes unnecessary traffic.
These are surely no crucial points but I think the sketch woud be more robust.
wdt_enable(WDTO_4S);
Please don´t do this - it may have terrible side effects and may make you mad while searching for errors.
So over all your sketch isn´t that bad for a first proof of concept and should be functional for your basic needs.
So missing send should be due to the qualitiy of your connection. Maybe a longer log of debug messages (both sides?) would be helpful.
.
@tekka This is very interesting. I think i will review my own system - just for curiosity. Thank you for this explanation.
@Reza: don´t get desperate. I think you are not a beginner - but if you are - your learning curve is fairly steep.
As mentioned before, sometimes it is better to step backwards and look from the distance.
If you aren´t too annoyed, I would offer to guide you to a working two-arduino system. (and I am sure @tekka will give advice if necessary) From there you will probably manage it on your own.
Started correctly MySensors will supply you with a lot of fun -- but today it is not funny for you.
So put away this stuff for today, go fishing and have a cold one.
Tomorrow (or Wednesday, because I don´t know my schedule for tomorrow now) we will build up things in an ordered way. (and please don´t scavenge your current gateway, I think it is the source of all evil and I am too curious about the reason).
footnote: if you are worried about your English (I am not) - give google translate a try - if available for your language
@Jan-Gatzke You are welcome.
@Reza : don´t worry, there will be a simple solution.
I´m in a hurry at the moment, I was ordered to do some party tonight. If my supreme command detects my current activities I will have very bad Karma for the next days.
To whom it may already apply: Happy new Year!! 
if (applies == 0) {
wait.some(hours);
read.again();
}
@Reza:
I tried to reproduce the errors shown by your log.
Part of the errors could be reproduced.
So if you are leaving range of stable connections, node will try to get an new parent (within range). So broadcasting for new parent is "normal". As long as there is no valid connection node will reject sending messages because "Transport Not Ready". So this is "normal", too.
Leaving range resulted in one or two NACK, then connection died quietly. I never got this amount of NACK you got.
I could not reproduce !TSF:MSG:LEN:0!=8 or something similar. This means the message has been crippled (possibly).
Reviewing logs and testing on my configuration revealed no clue to defective Chips (in regard to NRF24L01). Chips could be fake though, but at least software functions seem to be ok.
Fake NRF modules are reported to have very varying (worse) connection distances, sometimes down to a few (possibly only one) meter(s). Maybe -- may be not.
There are two major differences between our setups. I am currently not working with ACKs, I will test this tomorrow.
Second - I got no actual relays connected (only LEDs). You reported transmission break down simultaneously to pressing switches at higher rate. Are you supplying DC for relays from Arduino or from separate DC-supply? Have you made any arrangement preventing inductive spikes (ferrite rings, self-induction recuperation diode etc) ?
If you simply unhook your relays and try again - you get better results? (since your non-inductive sensors work well).
If this will turnout true - you may give Solid-State-Relais a try.
@macieiks
for the sake of completeness - you do not have to downgrade your complete Arduino IDE, just "tweak" boards definitions. Board versions are not necessarily numbered according to Arduino version.
Sorry - I couldn´t get Enlish version at speed.
I probably reads "Tools"->"Board"->"Boardmanager"
I got 1.6.11 installed- so it is not available in drop down list.
Choose your desired version, hit "Install", wait a fairly long time and you are done.
For testing basic functions there exists another (rather crude) way - the serial binding offerd by OpenHAB. Adding :
String Arduino "Arduino [%s]" {serial="COM6"}
to an "items" file will do the trick. Accordingly a "rules" file should be expanded by something like :
rule SplitMessage
when
Item Arduino changed
then
<do some relevant processing>
Using MySensors 1.4b (proMini, Uno, Mega.Leonardo) and OpenHab 1.5 (Windows 7 Notebook) produced very reliable results with SerialGateway connected via USB.
You have to compile the sketches with Baudrate set to 9600 because OpenHAB deals only with this Baudrate (mentioned somewhere in the OpenHAB Documentation).
So in Mysensors.h replace :
#define BAUD_RATE 115200
with
#define BAUD_RATE 9600
Because OpenHAB is not prepared to distribute NODE_IDs, you should hardcode this NODE-IDs. This decreases flexibility, but it is acceptable to some degree.
This approach works well for reading sensordata as for writing to actuators. Currently I am using eigth Nodes (including Repeater) with serveral children (e.g. multiple DS18B20, multiple Door contacts, Motionsensor, DHT22 etc). Until now I haven´t enconterd serious problems.
@Joakim-Johansson
I got a bunch of CH340G UNOs, some CH340G Nanos and some CH340G USB-serial converters (for use with Arduino Pro Mini ). Since i bought them (maybe 2015) until today they worked flawless under Windows 7, Windows 10 and Ubuntu (various versions). No trouble with drivers or similar.
@flopp I got kind of similar errors due to insufficient supply voltage stability (e.g. drive NRF24L01 from nano´s 3.3V source which is not robust enough - most of the time).
So far your problem resembles mine - it is "read 0-0-0 ...". A message from Node 0, last forwarded by Node 0 is ok, but this message addressed to Node 0 is certainly not ok. So probably the NRF made rubbish from received messages. At this time I got some missing "FIND PARENT" and inconsistent "Version mismatch" -- which are receiving problems - I think. It seems the receive capabilities of NRF are very sensitive to voltage drops. Similar to your problem sending was not compromised.
So adding a little buck converter for 3.3 V (http://www.ebay.de/itm/201280523226?_trksid=p2060353.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT or http://www.ebay.de/itm/201662468680?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT ) and supplying it from nano´s 5V (=USB, 500mA) made the errors vanish.
Another solution could be adding a capacitor - I haven´t tried it yet.
A quick hack for Christmas may be to hook up the NRF to two fresh AA-cells (don´t forget common ground). They will drain relative quickly, but they will last long enough to identify the problem.
Merry Christmas and good luck.....
@C.r.a.z.y. , maybe the Node-Id Delaration might be ineffektive. The output of OpenHab says your node identifies itself as Node 0 (Node 0 should be the Gateway itself). You should consider to give Static ID´s like:
#define NODE_ID 100
gw.begin(incomingMessage, NODE_ID, true);
So far I understand your sketch, yout try to assign a Node-id in the declaration statement
MySensor gw(100);
I´m not sure if this works. It will be safe to change it to
MySensor gw();
unless you got some very special hardware.
If the Node-Id is assigned properly, your code example should work fine.
Hi gad-ofir,
In addition to OH-Documentation you may find some hints in
Part of this thread is dealing with "empty" payloads.
Hi gad-ofir,
Warnings may be ignored (for a short time).
What are you doing with UIPEthernet1? Any ENC28J60 chip in Your environment? If so - may be you should use UIPEthernet instead (current version 2.0.6). Beside this - this message is a warning, too.
Check the usual suspects (wrong board? -> if Arduino Nano try "old bootloader", wrong COM port? check Hardwaremanager),
Both Messages give a hint to an improvable IDE. Maybe an update to the actual version could help.
Good luck 
Hi Gad Ofir ,
You are correct. So far I remember OpenHab assigns IDs. (but if you got a spare Arduino or STM it will not hurt to have one Node with a fixed, known ID -- just for testing purposes).
Your list 1.-3. is correct.
I don't know exactly but from my point of view the logic behind this behavior could be pretty simple: somewhere a list of Nodes has to be kept and the usual Arduino gateways are busy with managing traffic as well as chronically short of RAM and EEPROM. For small networks capacity may be sufficient, but believe me -- MySensors networks tend to grow rapidly. So at last you need an administration Software (aka controller (like OpenHab)) and this may administer the IDs according to its needs instead of keeping and synchronizing double lists.
Hi Gad Ofir,
The Node ID is supplied in the Node Sketch, so you have to modify your PIR sketch (slightly) as shown above.
The drawback of "hard" coded IDs is - you have to compile every sketch for every node individually and you have to keep track of the used IDs to avoid conflicts. For me (about 20 Sensors) it is manageable.
About a year ago i tried OpenHab (2.2 I think). There was a kind of plugin for MySensors and it worked very well. So there is a nice way to bypass MQTT.
I didn't continue OpenHab because it was a slight overkill for my purpose in comparison to MyController which does the trick completely. By the way - MyController seems to work with MQTT too, but I haven't tried it (yet).
Hi @Gad Ofir,
Though I'm not familiar with MySensors and MQTT, this protocol reminds me of my first steps with MySensors when I forgot to assign static IDs for my Nodes and the Controller (e.g. MyController https://www.mycontroller.org/#/home) wasn't up and running. You didn't mention which controller you are using - it should be capable of assigning IDs to nodes.
Copying your sensorlog to the logparser (https://www.mysensors.org/build/parser) shows the lack of an answer to a Request for ID.
I short circuited the whole ID-process by assigning "hard" IDs in the sketch (e.g.
#define MY_NODE_ID 100
This should bypass ID-Requests.
I am not familiar with the exact protocol in the newer MySensors versions so I can't explain the origin of the mentioned ID 237 (???).
In my environment a Node startup looks like:
__ __ ____
| \/ |_ _/ ___| ___ _ __ ___ ___ _ __ ___
| |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __|
| | | | |_| |___| | __/ | | \__ \ _ | | \__ \
|_| |_|\__, |____/ \___|_| |_|___/\___/|_| |___/
|___/ 2.3.0
16 MCO:BGN:INIT REPEATER,CP=RNNRA---,VER=2.3.0
26 MCO:BGN:BFR
27 TSM:INIT
28 TSF:WUR:MS=0
35 TSM:INIT:TSP OK
37 TSM:INIT:STATID=4
39 TSF:SID:OK,ID=4
40 TSM:FPAR
77 TSF:MSG:SEND,4-4-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
796 TSF:MSG:READ,0-0-4,s=255,c=3,t=8,pt=1,l=1,sg=0:0
801 TSF:MSG:FPAR OK,ID=0,D=1
871 TSF:MSG:READ,7-7-4,s=255,c=3,t=8,pt=1,l=1,sg=0:1
2084 TSM:FPAR:OK
2085 TSM:ID
2086 TSM:ID:OK
2088 TSM:UPL
2094 TSF:MSG:SEND,4-4-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
2110 TSF:MSG:READ,0-0-4,s=255,c=3,t=25,pt=1,l=1,sg=0:1
2115 TSF:MSG:PONG RECV,HP=1
2117 TSM:UPL:OK
2119 TSM:READY:ID=4,PAR=0,DIS=1
so there is no request for ID.
@hausinger
Yes, there is somebody - me.
Just like magic - I switched back from my W5100 GW to ENC28J60 GW for testing purposes --- and it is working 
.
Maybe because the node entries in the database were populated by the W5100 GW? I don't know.
I have not changed anything within the GW software or hardware.
So I still think it's a MysController setup issue. Maybe you will succeed using a serial GW for a short time to "initiate" MysController database and then switch to ENC28J60 GW ?? (I haven't tested adding new nodes...)
@hausinger
Bad guess in above posting.
I downloaded MysController (1.0.0beta:b3314:) - just for curiosity.
Yes - I got the same error - connection refused with my ENC28J60GW, which was working fine with MyController just a few seconds ago.
MysController is working fine with W5100 GW - without any configuration change (beside IP address).
I will try some fiddling with MysController - but I am using this program for the first time today.
Is there anybody out there successfully using MysController with ENC28J60 ?
@hausinger
This does not resemble a MySensors message.
I usually get this message when I'm stuck with my SSH connections on Raspberry Pi (lost SSH keys or such things) or due to bad setup - so denial of communication is correct but was not intended.
I don't know if MySensors provides any security functions at this level, but if it does - switch 'em off.
Perhaps you should try to ping your gateway. If there is an answer - i think the GW should be accessible. So it might be a configuration issue at MysController. But this is just a guess.
I am using MyController (without "s"). Actually a ENC28J60 is connected, standard GW software from examples expanded by DHT11 and DS18B20.
This configuration works well since about three months.
@hausinger
Maybe you are using an inappropriate "boards.txt" (i.e. Version > 1.6.11).
Please check posts https://forum.mysensors.org/topic/5786/ethernet-gateway-no-lan-traffic-after-initial-controller-setup/2
and/or
https://forum.mysensors.org/topic/5716/solved-w5100-ethernet-gateway-with-nrf24-stable-mysensors-2-1-0-problem/4
for "repair" instructions.
A "wrong" boards.txt (from Arduino 1.8.0) caused exactly the behavior mentioned above, so this incompatibility (it' probably not a real error) can be fixed with a boards.txt version prior to 1.6.11.
Please keep in mind, every time you update your Arduino IDE, this fix will be reverted.
@HogBil
Seems to be a tricky problem. To get some debug messages you have to hook it to the computer ... and there you won't get any because it's working.
Maybe it is worth to look at debug output from some node. Does it get parent (especially Parent 0)?, will TSM:UPL be ok? At least it would prove your node is working, regardless of network connection.
Maybe you try supplying power via power jack (i.e. 9V).
But this still doesn't solve the problem to get a message without connecting to a computer ..... At the moment - no practical idea leading to any benefit.