Posts made by tboha

Hi gad-ofir,

In addition to OH-Documentation you may find some hints in

https://forum.mysensors.org/topic/4415/my-final-setup-to-get-mysensors-and-openhab-communicating-via-mqtt

Part of this thread is dealing with "empty" payloads.

Hi gad-ofir,

1. Warnings may be ignored (for a short time).

2. 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.

3. 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.

@flopp :
No, it isn't that easy.
To improve your NRF, please have a look at https://forum.mysensors.org/topic/1851/extending-range-of-regular-nrf24l01.

I tried solution Nr. 2. It is easy to do and cheap. Improvements are noticeable but not dramatically.

In regard to effort it is worth trying.

If you aimed at changing NRF's frequency - no this is not possible at all. Base frequencies are selected within the chip itself and antenna resonant frequency has to match oscillator frequency.

@HogBil
Did you check your "boards.txt"?
Please have a look at
https://forum.mysensors.org/topic/5786/ethernet-gateway-no-lan-traffic-after-initial-controller-setup/2
respectively
https://forum.mysensors.org/topic/5716/solved-w5100-ethernet-gateway-with-nrf24-stable-mysensors-2-1-0-problem/3

@abrasha
Sorry about the delay - I ran out of ideas, and your new measurements are confusing to me.
About Vin:
Could it be possible we talk at cross-purposes?
From the MySensors wiring advice I conclude to connect Arduino-5V to Adafruit-Vin (just the way NRF24L01 with power adapter board).

From your picture (which I misinterpreted firstly due to bad sight) you said

Well, no, the Vin on the adafruit (brown wire) is connected to the vin pin on the uno. I've tried also connecting it to the 5v pin with no success. Also tried switching gnd sockets on the uno.
Im close to sign this issue with recall to adafruit - i ordered 4 boards and they're all with the same behavior. Or maybe i shorted out the ground when i soldered the antenna?

Connecting Arduino-Vin to Adafruit-Vin would not exactly be according to the rules - but it might work - more likely it would result in unforced errors due to insufficient stabilisation of 5V.
From your measurement 4.99V on Adafruit-Vin I conclude you switched to a 5V Arduino socket - have you?

D13 at 0.2V (or 0.3V) shouldn't light up the LED at all unless its really continuous SCK with predominantly low phases.

To solve this you would need an oscilloscope - and this would be inappropriate in my opinion.

No, I don't think it is a library malfunction. I experienced MySensors library as stable and library malfunctions are mostly detected by community at once. For special cases there maybe a lack of functionality but I don't think your setup is very special (besides the breakout-board). And 5 defective boards in a row - not very likely (and Adafruit has a good reputation for engeneering as well as for production).

I am not familiar with RFM69 (altough I was thinking of adding some RFM69 to my setup, but level converters scared me, so I was interested in your type of setup). So far I read about RFM69 you did the approriate #defines. Maybe someone who is working often with RFM69 could check the above sketch?

None of the above explains why your sketch works without GND connection. It's still a miracle.

And as I said before - I ran out of practicable ideas. Next I would try to get a functional two Arduino system according to Adafruit instructions (as well hardware as software). Ok - it's a little like giving up (only a little) - but maybe a practical approach.

@abrasha
I tested Vin behavior under load on my "original" UNO which displays 4.5V at Vin when powered through USB.
No Load = 4.5V, load 10mA results in 4.2V, load 150mA (which is required by RFM69HCW-breakout board so far I remember) results in 3.8V. Maybe transient load response is much worse than this, but my Multimeter does only 2 measurements per second.
I think it is safe to stay away from Vin on your Arduino (which you apparently are doing already).

According to schematics, "EN" is tied to Vin via 100k. Supplying Vin with 4.99V and measuring 4.4V on Pin "EN" could indicate your multimeter having a relatively low input impedance (about 1M ?). But either way - EN shuts off only below 0.4V, and 4V seem to be a reasonable margin (transients excluded). So this is not the reason for strange behavior.

D13 may be a good point. D13 is tied to Pin 13 (SCK) and via 1k and a (blue?) LED to GND. In my setup (NRF24L01+) there is only a dim flashing when data transmissions occur. So "bright" light on D13 could indicate a permanent data transmission (which your measurements on MISO/MOSI don't support) or there is a noticeable DC component -- which shouldn't be there. Measuring DC on Pin 13 may give a hint.
It is not likely that Pin 13 is our "lost" GND - in theory impedance (especially with a blue LED) is way to high.

To save some time - you got a spare Arduino? Consider building a second sensor (you wrote you got some more Adafruit breakout boards). Take the Adafruit wiring instructions mentioned above and do a close copy of that setup.

Another option would be to exchange the RFM69 module from your GW with the Adafruit breakout boards. If this would be functional - the board(s) are ok.

If you could afford, keep your current setup for further examinations. Although your basic question is quite interesting and unique (my setup works - but it shouldn't) don't get distracted from your way which is probably doing some measurements of your home environment and not of some hardware ( though it is still interesting anyway).

@abrasha
PS: Just found schematics of adafruit breakout board. There is already a capacitor (10µF) across Vin - maybe your additional capacitor has some unwanted side effects?
MySensors building instructions advise a capacitor for 3.3V with range problems - not for 5V.

Adafruits wiring instructions (very nice and instructive picture) don't mention a capacitor either.

Maybe stripping this capacitor will reduce trouble?

@abrasha
Last first: no, I wasn't aiming on current measurement, but it is a really good idea. It would be interesting where does the current come from, and much more interesting where does it go to when you disconnect ground (assuming your circuit is still working without ground connection...)?

Yes, your multimeter should go in series with either VCC or GND.

In the photos above the RFM module doesn't match the module on the breakout board. Please have a look at https://www.sparkfun.com/products/13910 here especially photo 4 (and have photo 3 in mind - it has to be flipped over and it is top down).
I tried to label the photo of the RFM69HCW, but I was kind of dazzled by transposition. Please crosscheck this.
.

But either way - your measurements give already some hints. Assuming you are powering your Arduino from USB - where do 4.55v come from? Backward current through your power regulator? Although 4.55v would be OK for the adafruit board (because power regulator needs only 3.5 V to start operation).

Did you measure Vin (from Arduino) under load? Is it capable of driving this load (i.e. does voltage drop down significantly under load)?

Next hint: why ever - 3.2V are generated on your board. So your power regulator (probably AP2112-3.3) is oK. But measuring at RFM- 3.3V connector (under load) won't hurt.

If labeling is correct, NSS = 1.54v doesn't make much sense - it would indicate a high frequent switching action (to be expected on SCK or MISO/MOSI during data transfer). NSS (CS) shouldn't probably switch at this high rate.

miso shows 0v all the time.

There should be at least a little data on miso , so it should not be 0 all the time.

And just for completeness - please measure voltage at "EN" at your adafruit board. Voltage should be constant 4.XX Volts (should be Vin), if not - module is disabled.

@abrasha
Well, I was short of sight (and offset the holes by one...). Sorry.

According to https://www.arduino.cc/en/Main/arduinoBoardUno

The power pins are as follows:

• Vin. The input voltage to the Arduino/Genuino board when it's using an external power source (as opposed to 5 volts from the USB connection or other regulated power source). You can supply voltage through this pin, or, if supplying voltage via the power jack, access it through this pin.
• 5V.This pin outputs a regulated 5V from the regulator on the board. The board can be supplied with power either from the DC power jack (7 - 12V), the USB connector (5V), or the VIN pin of the board (7-12V). Supplying voltage via the 5V or 3.3V pins bypasses the regulator, and can damage your board. We don't advise it.

Vin is used to access power from powerjack - before 5V regulators so it may be up to 12V (minus Diode). Supplying your Arduino from USB this pin should be without any voltage (in theory). So Vin (on Arduino) may not be a good choice to supply power to your extension boards.

Before sending back the modules - you got a multimeter and a steady hand?
Just checking power supply on Arduino Vin, breakout board and RFM module?

@abrasha
Please don´t mind if I am only short of sight, but....
If the pictures show your actual wiring, it seems to me your (brown) GND-wire is connected to the outermost pinhole from your adafruit board. In the photo below this pinhole is labeled with Vin so this should be connected with your orange wire. Your capacitor seems to be mounted accordingly to board labeling. Maybe it is worth checking this.

@mfalkvidd
I am quite happy that this little trick has no hidden side effects.

Would it be a good idea to give a crosslink to @Matt from https://forum.mysensors.org/topic/5426/cant-compile-2-01-for-atmega168/5 ?
I could not figure out how to do this, and cross posting is bad behavior I think.

@xelnaha
Lazy sunday afternoon -got time to "fix" some problems.
Not being capable of reading EBAY item descriptions properly, I got some Pro Mini 168 waiting for some work to do.

Please be aware what the boss says:

The atmega168 is not officially supported, due to the low flash / ram size, compared to atmega328 (tbowmo, ADMIN, 2 months ago)

So far I remember are the Pro mini 168 essentially clones based upon Arduino Duemilanove just without power supply and USB.

Within file "digitalWriteFast.h" in "<whatever>/Mysensors/drivers/avr/DigitalWriteFast/" at line 69

#elif defined(ARDUINO_AVR_UNO) || defined(ARDUINO_AVR_DUEMILANOVE) || defined(__AVR_ATmega328__) || defined(__AVR_ATmega328P__) || defined(__AVR_ATmega328PB__)

I added

#elif defined(ARDUINO_AVR_UNO) || defined(ARDUINO_AVR_DUEMILANOVE) || defined(__AVR_ATmega328__) || defined(__AVR_ATmega328P__) || defined(__AVR_ATmega328PB__) || defined (__AVR_ATmega168__)

because it is not fair to mention DUEMILANOVE and not to give credits to ATmega168.

With this modification compiling and uploading work well.

Please remember:

• Changes will be lost with every MySensors update
• I don´t know about side effects to other processor choices (e.g. Nano V2.3)

tbowmo was (is) right about memory capacity. The "BinarySwitchSensor" example sketch uses 14258 bytes from 14336 maximal Bytes. This is a really tight fit. Stripping debug information results in 7604 bytes.

@Geert-Massa
Sorry for "double" posting - my browser doesn't update while writing.

@Geert-Massa :
I got identical error messages when I tried to compile for my Pro-mini 168.

So far I understand there is no support for ATMega 168 with Mysensors (sadly).

As a legacy (I think) you can choose in the "TOOL"-menu, submenu "Processor" between ATMega328 and ATMega168 (which was used for Nanos until V2.3). Be sure to select "ATMega328".

If you got a V2.3 Nano - you are in trouble.

@ohuf
Learned something new. Until now I even didn't know that boards.txt was available at GITHUB.
I think replacing boards.txt twice might be redundant, but this is a pure guess.

Important for now is: have much fun with your new functional Gateway!

@ohuf :
Maybe it´s a simple thing. Please check your "boards.txt" file Version. Possibly in Version 1.8.1 the known failure of eternally rebooting W5100 (and probably ENC28J60 too) is propagated once more.

Change "board.txt" to a known working Version (e.g. 1.6.11) as described in https://forum.mysensors.org/topic/5716/solved-w5100-ethernet-gateway-with-nrf24-stable-mysensors-2-1-0-problem/4.

Good luck!

Maybe you should give

#define MY_RF24_PA_LEVEL RF24_PA_MIN

a try.
Being short of NRF modules, I ordered 10 pcs from my trusted EBAY-Seller for about 6.5€. What a disappointing experience - none of the modules did its work. All failed with

!TSM:FPAR:NO REPLY

10 defective modules in a row? Not likely. Clones? "Second source"? Fake? - maybe. So back to the roots, digging out maniacbug's library, uploading test sketches (pingpair_ack) - and ... no communication.
Regarding debug output the only difference between working and dysfunctional modules was PA_LEVEL (PA_LOW vs. PA_MAX). So switching to PA_MIN resulted in almost flawless communication arround 5-7m (inhouse with much armoured concrete, not noticeably different from "working" NRF modules).
Reducing PA_LEVEL is advised frequently in this forum, but I never thought of reducing to PA_MIN.
Interesting observation: increasing PA_LEVEL from PA_MIN to PA_LOW resulted in way much higher Round-Trip-Times (6000µs vs 650µs) and some failures (indicating bad transmissions), increasing to PA_LEVEL to PA_HIGH broke communication completely.

So recompiling Mysensors sketches with RF24_PA_MIN did the trick, the probably "fake" modules are doing their job.

@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.

@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.

@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:
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.

@Reza

Please look at the Check boxes on the right side and click accordingly.

@Reza
Sorry for missing part two:
Yes, connect GW with USB cable , and Node too. so you can monitor GW with arduino IDE and Node with putty -- or both with putty. Just as you like. For monitoring basic functions we don´t need a controller now.

@Reza "MockMySensors" is a Sketch from Mysensors Examples - it doesn´t need any hardware and simulates input for your GW and controller (e.g. giving random numbers as temperature or as humidity - you can chose within the sketch). So you get some Network traffic to check your components without any effort.

Yes change Channel to a private one - far away from channel 0. Maybe 72 is ok - I will look for it.

Hopefully your Nodes 2, 3 and 4 are ok (they communicated correctly according to your log).
So take two of them.
Make one a new serial GW and the other a "MockMySensors" Node.

Despite my old Message - please change RF-Channels to another Channel (i don´t know is 72 legal?) for both Arduinos,

Please connect both to your Windows 7 machine with some longer USB cables so you can space them a little apart.

I built meanwhile the same complex - one serial GW and one Mock-Node

@Reza

So let us start from scratch.

Before i want to know

• what type of computer are you using (laptop?)
• Operating system? (Windows?, which version)
• are you familiar with any kind of terminal? (Putty, Kermit?)
• does your OrangePi have wifi?

@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

@Reza I think we are getting close to solution.

but after start or reset , some time relay choose a node (10 m far) for parent, while gateway is near that ! why ?

This seems to be the crucial question.
I never dived into the core functions how MySensors decides about choosing parent.
Maybe it depends upon speed of answer?

a little excerpt from an earlier log (which i didn´t read close enough, I told you).

16 TSM:FPAR
52 TSF:MSG:SEND,4-4-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2059 !TSM:FPAR:NO REPLY
2061 TSM:FPAR
2097 TSF:MSG:SEND,4-4-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2165 TSF:MSG:READ,2-2-4,s=255,c=3,t=8,pt=1,l=1,sg=0:1
2170 TSF:MSG:FPAR OK,ID=2,D=2
2340 TSF:MSG:READ,3-3-4,s=255,c=3,t=8,pt=1,l=1,sg=0:3
4105 TSM:FPAR:OK
4106 TSM:ID

at 2097 Node 4 broadcasts for parent and gets accepted for parenting from Node 2.
at 2340 Node 3 offers parenting too - upon which request?

and why doesn`t GW offer parenting ?? GW shows up at 8240 with response to PING, so it is alive and connection was ok.

at least at the moment - unexpected behavior.

So reading logs give us some hints.
Could you provide a little more from the simultaneous logs? And don´t stick to the NACK logs - the other messages are interesting as well.

@Reza this is weird - i have to think about.
Just for clarification:

it seems you issued a command at your controller which results in sending

60;2;1;0;2;1

dissected:
60; = to node 60,
2; = sensor 2
1; = set value
0; = unacknowledged message (?)
2; = subtype is V_LIGHT
1; = payload is "1"

I think you hit button "Relais 2 ON" .

The weird thing is - you haven`t asked for acknowledge - but system is trying to get acknowledge ---- strange.

I just got your next question, I have to think about this too.

@Reza
Sometimes it is better to step back and have a look from the distance.

A receipe for a clean restart.

you need:

2 working Arduinos with radio (node 4 and node 3 from your log)

1 working Computer/Laptop with 2 free USB interfaces

preferably Windows with Arduino IDE installed. (Linux might work too.)
connect both arduinos to your USB ports.
if Arduinos are different - write down which Arduino is on which port (eg. com34: or similar)

1. start Arduino IDE
2. from examples/Mysensors load "Gateway serial"
   2a. choose one USB/COM-port.
3. don´t change anything and load it to the Arduino No.1
4. from examples/Mysensors load "MockMySensors"
   4a. choose the other USB/COM-Port
5. don`t change anything and load it to Arduino No.2

You are done. Watch Arduinos communicating via serial monitor.

Ok- you are right - it is not truely simultaneaus - but close enough.

If this is ok you should try to upload the relay-sketch and watch what is happening.

This should not take to long, and as a result you will hopefully know:

• my hardware is ok or not
• my software (MySensors) is ok or not
• my sketch is ok or not.

@Reza No.
Parallel may not be the exact description, I meant simultaneous recording of GW and node.

I don`t know about Domoticz - maybe there is a raw log function - then you are done.

Or if you installed arduino ide on your OrangePi just use the serial monitor.

Otherwise just hook up a terminal to your gateway.
I.e. on your OrangePi look for the device GW is bound to and start some terminal program linked hereto (e.g. putty, minicom, kermit).

@Reza No, an additional repeater was not intended (though it may be a solution).
From your "Node 4" log I conclude:

• you got at least 3 fully functional nodes (node 2,3,4). These nodes talk to each other in the environment of MySensors in an expected way.
• so hardware (radio and power) is ok. Software is ok too.
• GW functionality is partially ok - maybe hard- or software issues.

Now there is a decision to make: go on testing potentially defective hardware or start over with known intact hardware.

Go on testing means: are this failures reproducible? So I asked for logs of repeated boot sequences.
Until now we don´t know the exact failure. The parallel log from Gateway would show if there are really missing transmissions (and the extent of missing messages) or only missing ACKs.
I used ACKs last time in MySensors 1.4 and those days it made more trouble than profit. At last is showed up transmissions were ok (enough) the ACK system was not ok.
For my purposes MySensors keeps up with transmission difficulties so I have not to care about (15m Distance, in house, reinforced concrete). So I decided not to use ACKs anymore and this did not reduce performance.

If there are not to many missing transmissions (compare node messages vs. GW messages) I would skip the whole ACK thing.

I would test potentially defective hardware first because it is easy to get some logs an costs not much time.
Jan Gatzkes proposal is done quickly too.

An additional repeater would only obscure severe GW-problems. For the GW is the heart of MySensors system - you should not tolerate any problems (hard- or software) because it will come on top again in the very near future.

Starting over with known hardware takes more effort but should be doable in a manageable amount of time.

@Reza
I forgot - you are completely right. Why is there any need for a repeater node in between at 1m distance?

To get a clean solution you could isolate your GW and Node 4 by changing RF-channels and have a look at their private conversation without being disturbed by other (healthy) nodes.

@Reza
Based on your answer I have to confess I didn´t read your log carefully enough - being fixed to missing ACKs I didn´t pay attention to successful transmissions.

Difference between Node 160 log and Node 4 log is the complete absence of any messages from Node 0 (GW) in Node 160 log, whereas in Node 4 log there are answers from GW.

So my next question would be: are these failures consistent?

If you are not feed up already, would you please log some boot sequences from Node 4? And some button-presses too?

I think it would be interesting if failures are the exact identical or just almost identical.
(exact identical favors software problem, almost identical favors hardware problem).

A parallel log from the GW would be nice too. Maybe there is a problem in the ACK system.

If you don´t trust your OrangePi hardware - would a temporarily switch to Laptop/Windows/Linux make much effort? Just to prove integrity of GW-Arduino and radio.

@Reza I got your nodes behavior mostly reproduced (see protocol below).
Only difference:

2097 TSF:MSG:SEND,4-4-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2830 TSF:MSG:READ,2-2-4,s=255,c=3,t=8,pt=1,l=1,sg=0:1
2835 TSF:MSG:FPAR OK,ID=2,D=2
4105 TSM:FPAR:OK
4106 TSM:ID

In my network I got direct connections to my gateway.
so most messages in your logs document all nodes broadcasting all the time searching for your gateway and getting no response.
If there is no connection - there can be no ACK.

Would you please check your gateway sketch for the RF-channel in use?

Protocol with non matching RF-channel (#define MY_RF24_CHANNEL 0)

0 MCO:BGN:INIT REPEATER,CP=RNNRA--,VER=2.1.0
3 TSM:INIT
4 TSF:WUR:MS=0
11 TSM:INIT:TSP OK
13 TSM:INIT:STATID=5
15 TSF:SID:OK,ID=5
17 TSM:FPAR
53 TSF:MSG:SEND,5-5-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2060 !TSM:FPAR:NO REPLY
2062 TSM:FPAR
2098 TSF:MSG:SEND,5-5-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
4105 !TSM:FPAR:NO REPLY
4107 TSM:FPAR
4143 TSF:MSG:SEND,5-5-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6150 !TSM:FPAR:NO REPLY
6152 TSM:FPAR
6188 TSF:MSG:SEND,5-5-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
8195 !TSM:FPAR:FAIL
8196 TSM:FAIL:CNT=1
8198 TSM:FAIL:PDT
18201 TSM:FAIL:RE-INIT
18203 TSM:INIT
18210 TSM:INIT:TSP OK
18212 TSM:INIT:STATID=5
18214 TSF:SID:OK,ID=5
18216 TSM:FPAR
18253 TSF:MSG:SEND,5-5-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
20260 !TSM:FPAR:NO REPLY
20262 TSM:FPAR
20298 TSF:MSG:SEND,5-5-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
22306 !TSM:FPAR:NO REPLY
22308 TSM:FPAR
22344 TSF:MSG:SEND,5-5-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
24352 !TSM:FPAR:NO REPLY
24354 TSM:FPAR
24390 TSF:MSG:SEND,5-5-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
26398 !TSM:FPAR:FAIL
26399 TSM:FAIL:CNT=2
26401 TSM:FAIL:PDT

Protocol with matching RF-Channel (without #define MY_RF24_CHANNEL 0,i.e. using default channel)

0 MCO:BGN:INIT REPEATER,CP=RNNRA--,VER=2.1.0
3 TSM:INIT
4 TSF:WUR:MS=0
11 TSM:INIT:TSP OK
13 TSM:INIT:STATID=5
15 TSF:SID:OK,ID=5
17 TSM:FPAR
53 TSF:MSG:SEND,5-5-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2060 !TSM:FPAR:NO REPLY
2062 TSM:FPAR
2098 TSF:MSG:SEND,5-5-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2377 TSF:MSG:READ,14-14-5,s=255,c=3,t=8,pt=1,l=1,sg=0:1
2382 TSF:MSG:FPAR OK,ID=14,D=2
2811 TSF:MSG:READ,0-0-5,s=255,c=3,t=8,pt=1,l=1,sg=0:0
2817 TSF:MSG:FPAR OK,ID=0,D=1
3289 TSF:MSG:READ,7-7-5,s=255,c=3,t=8,pt=1,l=1,sg=0:2
3734 TSF:MSG:READ,4-4-5,s=255,c=3,t=8,pt=1,l=1,sg=0:1
4105 TSM:FPAR:OK
4106 TSM:ID
4107 TSM:ID:OK
4109 TSM:UPL
4112 TSF:MSG:SEND,5-5-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
4118 TSF:MSG:READ,0-0-5,s=255,c=3,t=25,pt=1,l=1,sg=0:1
4123 TSF:MSG:PONG RECV,HP=1
4126 TSM:UPL:OK
4127 TSM:READY:ID=5,PAR=0,DIS=1
4132 TSF:MSG:SEND,5-5-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
4139 TSF:MSG:READ,0-0-5,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
4146 TSF:MSG:SEND,5-5-0-0,s=255,c=0,t=18,pt=0,l=5,sg=0,ft=0,st=OK:2.1.0
4155 TSF:MSG:SEND,5-5-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
4584 TSF:MSG:READ,0-0-5,s=255,c=3,t=6,pt=0,l=6,sg=0:Metric
4590 TSF:MSG:ACK REQ
4594 TSF:MSG:SEND,5-5-0-0,s=255,c=3,t=6,pt=0,l=6,sg=0,ft=0,st=OK:Metric
4602 TSF:MSG:SEND,5-5-0-0,s=255,c=3,t=11,pt=0,l=6,sg=0,ft=0,st=OK:RELAY6
4611 TSF:MSG:SEND,5-5-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:0.1
4620 TSF:MSG:SEND,5-5-0-0,s=1,c=0,t=3,pt=0,l=8,sg=0,ft=0,st=OK:Relais A
4628 TSF:MSG:SEND,5-5-0-0,s=2,c=0,t=3,pt=0,l=8,sg=0,ft=0,st=OK:Relais B
4637 TSF:MSG:SEND,5-5-0-0,s=3,c=0,t=3,pt=0,l=8,sg=0,ft=0,st=OK:Relais C
4645 TSF:MSG:SEND,5-5-0-0,s=4,c=0,t=3,pt=0,l=8,sg=0,ft=0,st=OK:Relais D
4655 TSF:MSG:SEND,5-5-0-0,s=5,c=0,t=3,pt=0,l=8,sg=0,ft=0,st=OK:Relais E
4663 TSF:MSG:SEND,5-5-0-0,s=6,c=0,t=3,pt=0,l=8,sg=0,ft=0,st=OK:Relais F
4670 MCO:REG:REQ
4673 TSF:MSG:SEND,5-5-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
4679 TSF:MSG:READ,0-0-5,s=255,c=3,t=27,pt=1,l=1,sg=0:1
4684 MCO:PIM:NODE REG=1
4686 MCO:BGN:STP
4714 TSF:MSG:READ,0-0-5,s=255,c=3,t=6,pt=0,l=6,sg=0:Metric
5688 MCO:BGN:INIT OK,TSP=1
7503 TSF:MSG:READ,8-8-5,s=255,c=3,t=8,pt=1,l=1,sg=0:1
7508 !TSF:MSG:FPAR INACTIVE
loop_count: 36610
loop_count: 85099
loop_count: 85091
31153 TSF:MSG:SEND,5-5-0-0,s=1,c=1,t=2,pt=7,l=5,sg=0,ft=0,st=OK:0.0
Switch A pressed
34217 TSF:MSG:SEND,5-5-0-0,s=1,c=1,t=2,pt=7,l=5,sg=0,ft=0,st=OK:1.0
Switch A pressed
36277 TSF:MSG:SEND,5-5-0-0,s=1,c=1,t=2,pt=7,l=5,sg=0,ft=0,st=OK:0.0
Switch A pressed
loop_count: 84876

Which kind of Gateway are you using?

@reza:
I made some modifications to your sketch, trying to adhere to your style of programming. So it may be easier to adapt it to your needs.

#define MY_DEBUG
#define MY_RADIO_NRF24
#define MY_RF24_CHANNEL 0
#define MY_REPEATER_FEATURE
#define MY_NODE_ID 5

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


#define RELAY_ON 0
#define RELAY_OFF 1

#define A_ID 1
#define B_ID 2
#define C_ID 3
#define D_ID 4
#define E_ID 5
#define F_ID 6

#define DISPLAY_INTERVALL 10000

const int buttonPinA = 14;
const int buttonPinB = 15;
const int buttonPinC = 16;
const int buttonPinD = 17;
const int buttonPinE = 18;
const int buttonPinF = 19;

const int relayPinA = 3;
const int relayPinB = 4;
const int relayPinC = 5;
const int relayPinD = 6;
const int relayPinE = 7;
const int relayPinF = 8;

int oldValueA = 0;
int oldValueB = 0;
int oldValueC = 0;
int oldValueD = 0;
int oldValueE = 0;
int oldValueF = 0;

unsigned long loop_count = 0;           // counter for loop activity
unsigned long last_time;
bool toggleA = false, toggleB = false, toggleC = false, toggleD = false, toggleE = false, toggleF = false;

Bounce debouncerA = Bounce();
Bounce debouncerB = Bounce();
Bounce debouncerC = Bounce();
Bounce debouncerD = Bounce();
Bounce debouncerE = Bounce();
Bounce debouncerF = Bounce();

MyMessage msgA(A_ID, V_STATUS);
MyMessage msgB(B_ID, V_STATUS);
MyMessage msgC(C_ID, V_STATUS);
MyMessage msgD(D_ID, V_STATUS);
MyMessage msgE(E_ID, V_STATUS);
MyMessage msgF(F_ID, V_STATUS);

void setup()
{

  pinMode(buttonPinA, INPUT_PULLUP);
  pinMode(buttonPinB, INPUT_PULLUP);
  pinMode(buttonPinC, INPUT_PULLUP);
  pinMode(buttonPinD, INPUT_PULLUP);
  pinMode(buttonPinE, INPUT_PULLUP);
  pinMode(buttonPinF, INPUT_PULLUP);

  // After setting up the buttons, setup debouncer
  debouncerA.attach(buttonPinA);
  debouncerA.interval(5);
  debouncerB.attach(buttonPinB);
  debouncerB.interval(5);
  debouncerC.attach(buttonPinC);
  debouncerC.interval(5);
  debouncerD.attach(buttonPinD);
  debouncerD.interval(5);
  debouncerE.attach(buttonPinE);
  debouncerE.interval(5);
  debouncerF.attach(buttonPinF);
  debouncerF.interval(5);

  // Make sure relays are off when starting up
  digitalWrite(relayPinA, RELAY_OFF);
  digitalWrite(relayPinB, RELAY_OFF);
  digitalWrite(relayPinC, RELAY_OFF);
  digitalWrite(relayPinD, RELAY_OFF);
  digitalWrite(relayPinE, RELAY_OFF);
  digitalWrite(relayPinF, RELAY_OFF);
  // Then set relay pins in output mode
  pinMode(relayPinA, OUTPUT);
  pinMode(relayPinB, OUTPUT);
  pinMode(relayPinC, OUTPUT);
  pinMode(relayPinD, OUTPUT);
  pinMode(relayPinE, OUTPUT);
  pinMode(relayPinF, OUTPUT);

  wait(1000);                                    // testing LEDs. should be omitted for Relais.
  digitalWrite(relayPinA, RELAY_ON);
  digitalWrite(relayPinB, RELAY_ON);
  digitalWrite(relayPinC, RELAY_ON);
  digitalWrite(relayPinD, RELAY_ON);
  digitalWrite(relayPinE, RELAY_ON);
  digitalWrite(relayPinF, RELAY_ON);

  /*--------------------- Added these lines for toggle switch-------------------------*/
  oldValueA = digitalRead(buttonPinA);  // set oldValueA to the current status of the toggle switch
  oldValueB = digitalRead(buttonPinB);  // set oldValueB to the current status of the toggle switch
  oldValueC = digitalRead(buttonPinC);
  oldValueD = digitalRead(buttonPinD);
  oldValueE = digitalRead(buttonPinE);
  oldValueF = digitalRead(buttonPinF);

}

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

  // Register all sensors to gw (they will be created as child devices)
  present(A_ID, S_LIGHT, "Relais A");
  present(B_ID, S_LIGHT, "Relais B");
  present(C_ID, S_LIGHT, "Relais C");
  present(D_ID, S_LIGHT, "Relais D");
  present(E_ID, S_LIGHT, "Relais E");
  present(F_ID, S_LIGHT, "Relais F");

}

/*
   Example on how to asynchronously check for new messages from gw
*/
void loop()
{
    loop_count ++;                                        // increment loop count
  
    if ( millis() >= last_time + DISPLAY_INTERVALL ) {    // Display Loop-cycles every DISPLAY_INTERVALL milliseconds
      last_time = millis();                               // reset and start over again
      Serial.print("loop_count: ");
      Serial.println(loop_count);
      loop_count = 0;
    }

  debouncerA.update();
  // Get the update value
  int valueA = debouncerA.read();
  if (valueA != oldValueA && valueA == 0) {
    send(msgA.set(toggleA, true));                        // Send new state and request ack back
    digitalWrite(relayPinA, toggleA);                     // switch relais
    Serial.println("Switch A pressed");
    toggleA = !toggleA;                                   // this is the actual toggle switch
  }
  oldValueA = valueA;

  debouncerB.update();
  // Get the update value
  int valueB = debouncerB.read();
  if (valueB != oldValueB) {
    send(msgB.set(valueB ? false : true), true); // Send new state and request ack back
    Serial.println("Switch B pressed");
    oldValueB = valueB;
  }

  debouncerC.update();
  // Get the update value
  int valueC = debouncerC.read();
  if (valueC != oldValueC) {
    send(msgC.set(valueC ? false : true), true); // Send new state and request ack back
    Serial.println("Switch C pressed");
    oldValueC = valueC;
  }

  debouncerD.update();
  // Get the update value
  int valueD = debouncerD.read();
  if (valueD != oldValueD) {
    send(msgD.set(valueD ? false : true), true); // Send new state and request ack back
    Serial.println("Switch D pressed");
    oldValueD = valueD;
  }

  debouncerE.update();
  // Get the update value
  int valueE = debouncerE.read();
  if (valueE != oldValueE) {
    send(msgE.set(valueE ? false : true), true); // Send new state and request ack back
    Serial.println("Switch E pressed");
    oldValueE = valueE;
  }

  debouncerF.update();
  // Get the update value
  int valueF = debouncerF.read();
  if (valueF != oldValueF) {
    send(msgF.set(valueF ? false : true), true); // Send new state and request ack back
    Serial.println("Switch F pressed");
    oldValueF = valueF;
  }

}

void receive(const MyMessage &message) {
  // We only expect one type of message from controller. But we better check anyway.
  if (message.type == V_STATUS) {

    switch (message.sensor) {
      case 1:
        digitalWrite(message.sensor + 2, message.getBool() ? RELAY_ON : RELAY_OFF);
        break;

      case 2:
        digitalWrite(message.sensor + 2, message.getBool() ? RELAY_ON : RELAY_OFF);
        break;

      case 3:
        digitalWrite(message.sensor + 2, message.getBool() ? RELAY_ON : RELAY_OFF);
        break;

      case 4:
        digitalWrite(message.sensor + 2, message.getBool() ? RELAY_ON : RELAY_OFF);
        break;

      case 5:
        digitalWrite(message.sensor + 2, message.getBool() ? RELAY_ON : RELAY_OFF);
        break;

      case 6:
        digitalWrite(message.sensor + 2, message.getBool() ? RELAY_ON : RELAY_OFF);
        break;

      default:
        Serial.println("bad message (child_id >6)");
        break;
    }

    // Write some debug info
    Serial.print("Incoming change for sensor:");
    Serial.print(message.sensor);
    Serial.print("  from node:");
    Serial.print(message.sender);
    Serial.print(", New status: ");
    Serial.println(message.getBool());
  }
}

I haven`t copied the code for all push-buttons - I leave this to you if this sketch is functional for your needs.

Acting carefully, you may mingle some parts with blacey´s sketch successfully (by the way - impressing coding style).

Reenacting your sketch I found some strange behavior: no reaction to push-button-press - meaning the sketch didn´t even take notice of the push-button after it had been pressed once - or sometimes twice.

Adding an external pull-up resistor (4.7k) fixed this problem.

So maybe it has not been a sending problem but a hardware problem (internal pull-ups to weak?).

Please flood your sketch with print statements - like "button A pressed" "send command issued" etc. and watch your serial terminal carefully and/or post your logs.

Thinking about the modulo-driven time-statement - actually it is a cute idea. Something like

 time_m = millis();
    a = (time_m / 1000) % 3600;

should make it immune to uneven starting values an even loop-cycle duration. (loop-cycle-time of the above sketch: approximately 125 µs)

These are the lesser problems. I fear you have to do some boring English lecture.
Please read: https://en.wikipedia.org/wiki/Finite-state_machine
https://en.wikipedia.org/wiki/State_machine_replication

and first: https://en.wikipedia.org/wiki/Two_Generals'_Problem
https://en.wikipedia.org/wiki/Byzantine_fault_tolerance

as an excerpt :

The Two Generals Problem was the first computer communication problem to be proved to be unsolvable.

This is not "we don´t have a solution until now" but: "it is sure there can´t be a solution"

So you will have to live with a certain amount of uncertainty .....

Conclusion:

1. Check correct function of push-button with Serial.print(), with and without external pull-up resistor.

2. Please post your logs afterwards.

3. be prepared to make some decisions concerning tolerable fuzziness.

4. if necessary start learning about scripting capabilities of your controller.

@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 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.

.

@Reza said:

!TSM:READY:UPL FAIL,SNP

I had not got such errors due to power issues. Unstable/insufficient power supply mostly resulted in inconsistent functions - not in steady errors. Sometimes (depending on weather? phase of the moon?) functions were ok, sometimes not.
Changing power supply (either batteries or buck-device) healed this problems.

So far I understand your error-messages they could probably mean what they say:
UPLink control FAILed and your node is Searching New Parent - which is a logical consequence.

I think flopp and Jan Gatzke are right: 50 meters is quite a large distance - may be too much for stable connection.

If your device is mobile - lower the distance (just for testing purposes) and look for a stable connection. Depending on the result you may take further actions like described above or - if you like tinkering - you may have a look at

http://www.instructables.com/id/Enhanced-NRF24L01/ or Cheap DIY NRF24L01 Antenna Modification – 02:48
— Pete B

I have not done this until now - but it looks really cool.

@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.....

@SuperKris
you already solved the problem with Pin0 and 1 (did you?). Here is possibly another solution (from 2.0 API

MY_DISABLED_SERIAL 	Disabled 	Enable this in sketch if you want to use TX(1), RX(0) as normal I/O pin

so

#define MY_DISABLED_SERIAL

should free Pin 0 and Pin 1.

@SuperKris

Does sleep stop all code from running, or just the function that its in? In other words; My keypad code is in the loop function. The mysensor code for receiving messages is in another funtion outside the loop function (void receive). Does a sleep in the loop function also blocks void receive, or does it only block the loop part?

• sleep() stops all code. You should not use it in this environment.
• the receive() is declared outside loop() but runs inside loop(). This is done automatically by MySensors framework.

Disabling the sleep function (with just a // ) seems to work, but its flooding (debug still enabled off course) the serial monitor "with Failed reading temperature from DHT! Failed reading humidity from DHT

• you are right to disable sleep(), but .... the DHT Sensor is not as fast as your Arduino.

An excerpt of the DHT samplesketch:

// 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 MEASURING_INTERVAL = 30000;

// Force sending an update of the temperature after n sensor reads, so a controller showing the
// timestamp of the last update doesn't show something like 3 hours in the unlikely case, that
// the value didn't change since;
// i.e. the sensor would force sending an update every MEASURING_INTERVAL*FORCE_UPDATE_N_READS [ms]
static const uint8_t FORCE_UPDATE_N_READS = 10;

Thus your code must result in more than 1 reading per 2 seconds, so the DHT Sensor is not ready and fails.

So as you expected, it boils down to enclose the DHT code into an millis() controlled if-Statement.

Basically it looks like this

static const uint64_t UPDATE_INTERVAL = 60000;
static const uint64_t MEASURING_INTERVAL = 30000;

// before setup() aka global variables
unsigned long last_time = 0, actual_time = 0;
----------

// within loop()
  if ( (millis() - last_time) >= MEASURING_INTERVAL) {   
    last_time = millis();
    // Force reading sensor, so it works also after sleep()
    dht.readSensor(true);
// rest of your DHT Code here

}   // don´t forget closing parenthesis (after Humidity is done)

you will recognize the fragments, they originate form the DHT Example Sketch.

@SuperKris : You are welcome!

Yes, it is supposed to give a human readable name to your Sensor, which could be displayed by your controller.
strange - within my "testenvironment" it compiled (5 minutes ago) without complaints.
Would you please give the CompilerMessage?
It is not a vital point but it´s anoying.

some additional remarks:

Switching to Arduino-MEGA would solve your lack of IO-Pins dramatically (and provides you with huge amounts of Memory and RAM (=Variables)).

Another Option would be to split different functions to different Arduinos. E.g. one Arduino to serve the switches, one Arduino to control an Array of Relays.

Delegate dumb tasks to even dumber Hardware

• IOPort-Expander to control relais http://www.ebay.com/itm/PCF8574T-PCF8574-I2C-8-Bit-IO-GPIO-expander-module-for-Arduino-Raspberry-Pi-/311730563568?var=&hash=item8e2bb3695d
• multifunctional PCB´s for input and display[ http://stores.ebay.de/TxHang-Electronic/_i.html?_nkw=tm1638&submit=Finden&LH_TitleDesc=1&_sid=1103958046
• capacitive switches with i2c http://www.ebay.de/itm/CAP1188-8-Key-Capacitive-Touch-Sensor-Module-SPI-I2C-Captouch-LED-For-Arduino-/401148874426?hash=item5d66560eba]

Frequently read your included headerfiles (especially Mysensors.h) and read the APIs (https://www.mysensors.org/download/sensor_api_20), you will discover a bunch of additional functions.

One function you will discover is direct "internode" communication without gateway and so without controller.

This partially answers your question where to store your virtual items (or makes it more complicated with respect to maintenance). Deploying vital components to your peripherial Units gives great flexibility in choosing your controller. It also makes the integration "Third-Party" components easier. You mentioned your 433Mhz WallSwitch.

@SuperKris
From the first look: it could be a simple typo:

saveState(CHILD_ID_V1), state);
should be
saveState(CHILD_ID_V1, state);
it may be simply one parenthesis too much.

@SuperKris

I see you did not really use the manual created booleans ("VirtalSwitch1" for example). Do i need these manual created booleans for the function i want,

1.) Yes, you need these variables just the way you created them. At the moment they are used for logging (as you used them until now), so they reflect the current state as changed by the switches. More features have to be implemented.

of are these booleans automatically created by the mysensors library?

No, these booleans are not implemented by MySensors, at least not in the way you plan to use them.

"MyMessage msgV1(CHILD_ID_V1,S_LIGHT)" presents the existence of the switch to the gateway

Exact.

and "send(msgV1.set(1))" sends the status change to the gateway.
Where is the status (boolean?) actually stored? Is this a boolean provided by the mysensors code?

at last yes, but ... this statement performs two jobs:

• msgV1.set(1) sets the payload of the Message"Container" to "1"
• send(msgV1) performs the actual sending.
• send(msgV1.set(VirtalSwitch1) would probably do the trick - but I was too lazy typing. The current status is stored in the variables you created.

Again, if i understand right, the state of a (virtual) switch is always stored on the node. Not on the controller. Can you confirm?

Yes.

If so, how do i change the state of the (virtual) switch from the controller? For example. 1 keypad button will control the the outside lighting. Inside of the house i will place a 433mhz wallswitch that does the same thing. For this i need the 433mhz wallswitch to be able to change the state of the (virtual) button. The controller (Domoticz) will turn on the lights depending on the state of the virtual switch.
In other words, it seems to me the vitual switches should be controlled by the controller, but i dont see any receiving code.

Yes, there is much work left.

I am sorry, these answers are not very helpful at the moment. I´m in a hurry and I will try to explain later in the evening.

Until then I would propose you try to get the first fragment of the above sketch running. It will give you an impression of some possibilities - and also of some restrictions.

Until later.

@SuperKris : you should consider adding the "sending" routines for MySensors. Maybe dissecting the Binary Switch Example would be a better startingpoint than the RelaySketch.

I tried to integrate these routines into your template. Unfortunately I can´t test this sketch due to the lack of the Keypad. At least the sketch compiles without error.

// ##### SET PROJECT NAME AND VERSION #####
#define ProjectName "Schuur controller"
#define ProjectVersion "0,2"

// ##### SET MYSENSOR SETTINGS BEFORE INCLUDIGN LIBRARY #####
#define MY_DEBUG // Enable debug prints to serial monitor
#define MY_RADIO_NRF24 // Enable and select radio type attached
#define MY_REPEATER_FEATURE // Enabled repeater feature for this node

// ##### INCLUDE LIBRARYS #####
#include <SPI.h>
#include <MySensors.h>
#include <Bounce2.h>
#include <Keypad.h>

// ##### Child-IDs for "Virtual"Switches #####
#define CHILD_ID_V1 1
#define CHILD_ID_V2 2
#define CHILD_ID_V3 3
#define CHILD_ID_V4 4
#define CHILD_ID_V5 5

// ##### KEYPAD SETUP #####
const byte ROWS = 4; // Four rows
const byte COLS = 3; // Three columns
// Define the Keymap
char keys[ROWS][COLS] = {
  {'1', '2', '3'},
  {'4', '5', '6'},
  {'7', '8', '9'},
  {'A', 'B', 'C'}
};
// Connect keypad ROW0, ROW1, ROW2 and ROW3 to these Arduino pins.
byte rowPins[ROWS] = { A0, A1, A2, A3 };
// Connect keypad COL0, COL1 and COL2 to these Arduino pins.
byte colPins[COLS] = { A4, 1, 0 };                                        //if you got any spare pins - change 0 and 1 accordingly  e.g. { A4, 8, 9 }
                                                                          // or see below
// Create the Keypad
Keypad kpd = Keypad( makeKeymap(keys), rowPins, colPins, ROWS, COLS );

// ##### DEFINE I/O PINS #####
//#define IoPin1 4  // Arduino Digital I/O pin number for I/O 1
#define IoPin2 3  // Arduino Digital I/O pin number for I/O 2 
//#define IoPin3 6  // Arduino Digital I/O pin number for I/O 3    / Pin 6 seems to be unused
#define IoPin4 5  // Arduino Digital I/O pin number for I/O 4 
#define IoPin5 8  // Arduino Digital I/O pin number for I/O 5
#define IoPin6 7  // Arduino Digital I/O pin number for I/O 6
#define IoPin7 19 // Arduino Digital I/O pin number for I/O 7


// ##### BOOLEANS FOR VIRTUAL SWITCHES #####
bool VirtalSwitch1;  // Boolean (status) for virtual switch 1 (controlled by keypad)
bool VirtalSwitch2;  // Boolean (status) for virtual switch 2 (controlled by keypad)
bool VirtalSwitch3;  // Boolean (status) for virtual switch 3 (controlled by keypad)
bool VirtalSwitch4;  // Boolean (status) for virtual switch 4 (controlled by keypad)
bool VirtalSwitch5;  // Boolean (status) for virtual switch 5 (controlled by keypad)


// define Message"Containers" to communicate with Gateway
MyMessage msgV1(CHILD_ID_V1,S_LIGHT);
MyMessage msgV2(CHILD_ID_V2,S_LIGHT);
MyMessage msgV3(CHILD_ID_V3,S_LIGHT);
MyMessage msgV4(CHILD_ID_V4,S_LIGHT);
MyMessage msgV5(CHILD_ID_V5,S_LIGHT);


void setup()


{ // ##### PIN SETUP (FOR TESTING ONLY #####

  pinMode(IoPin4, OUTPUT);    // use I/O 4 as output for relay module
  digitalWrite(IoPin4, HIGH); // and set is HIGH so relay stays off


  // ###### VARIOUS SETTINGS ######
  Serial.begin(115200); // SERIAL PRINT MUST BE DEACTIVATED TO MAKE THE WHOLE KEYPAD WORK if Pin 0 and Pin1 are used for ColAdressing,
                        // maybe pin 8,9,10 would be preferable with respect to compact wiring (e.g. byte colPins[COLS] = { 8,9,10 }; )
                        // without pin 0 and one used, you can do some serial debugging, which is very helpful.
}

void loop()
{
  char key = kpd.getKey();     // Get key from keypad (if pressed)
  if (key)  {                  // compare key (defined in keypad setup)
    switch (key) {             // with multiple multiple options below

      case '1':                // If the pressed key compares with "1"
        VirtalSwitch1 = true;  // Change te state of boolean VirtalSwitch1 to true
        send(msgV1.set(1));    // sending virtual switch state to Gateway
        Serial.println("1");   // Debug code. Print "1" to show that button 1 was pressed
        break;                 // End of code for button 1

      case '4':                // If the pressed key compares with "4"
        VirtalSwitch1 = false; // Change te state of boolean VirtalSwitch1 to false
        send(msgV1.set(0));    // sending virtual switch state to Gateway
        Serial.println("4");   // Debug code. Print "4" to show that button 4 was pressed
        break;                 // End of code for button 4

      case '2':                // If the pressed key compares with "2"
        VirtalSwitch1 = true;  // Change te state of boolean VirtalSwitch1 to true
        send(msgV2.set(1));    // sending virtual switch state to Gateway
        Serial.println("2");   // Debug code. Print "2" to show that button 2 was pressed
        break;                 // End of code for button 2

      case '5':                // If the pressed key compares with "5"
        VirtalSwitch1 = false; // Change te state of boolean VirtalSwitch1 to false
        send(msgV2.set(0));    // sending virtual switch state to Gateway
        Serial.println("5");   // Debug code. Print "4" to show that button 5 was pressed
        break;                 // End of code for button 5

      case '3':                // If the pressed key compares with "3"
        VirtalSwitch1 = true;  // Change te state of boolean VirtalSwitch1 to true
        send(msgV3.set(1));    // sending virtual switch state to Gateway
        Serial.println("3");   // Debug code. Print "2" to show that button 2 was pressed
        break;                 // End of code for button 2

      case '6':                // If the pressed key compares with "6"
        VirtalSwitch1 = false; // This doesn´t really make sense here. Key "3" triggers Garden light for 5 Minutes
        send(msgV3.set(0));    // Reset this with a switch doesn´t meet the purpose of this switch (3), it (6) may be used for something else.
        Serial.println("6");   // 
        break;                 // End of code for button 6

                             // Other keys to be added here according to the same template
        
      default:                 // If the pressed key does not match the cases above
        Serial.println(key);   // Print the key that was pressed
        break;                 // End of function
    }
  }

  // ##### WRITE BOOLEAN TO PIN (FOR TESTING PURPOSES ONLY) #####
  digitalWrite(IoPin4, VirtalSwitch1);

}

void

 presentation() {
 
  present(CHILD_ID_V1, S_LIGHT, "Partylichtjes");  
  present(CHILD_ID_V2, S_LIGHT, "Verwarmingstoestel");
  present(CHILD_ID_V3, S_LIGHT, "Tuinverlichting gedurende 5 min");
  present(CHILD_ID_V4, S_LIGHT, "Bewegingsdetector");
  present(CHILD_ID_V5, S_LIGHT, "Muziek");
  
  
}```

@JimmyH : Yes, it is easy to swap bindings as well as controller. Easy - but it requires some labour. This labour is not complex, it just has to be done. In my specific setup it takes approximately 1-2 minutes per device.

If you are using the serial binding in OpenHab it is tempting to perform some processing within the nested case statements (like I did). Retrospectively this was a really bad idea.

I think it is a better idea to limit the use of these statements to dispatch the incoming data to the chosen Items - and nothing more.

I had a hard time to get used to the functions of OpenHab ".rules" but at last it was worth the effort. Transfer every processing step into separate rules - it will make things easy.

In an ideal scenario to switch between serial and MQTT (either serial or over Ethernet) you pull your USB-plug, activate your broker and you are done.

Due to laziness and little other reasons I'm stuck with an inhomogeneous system resulting in the work mentioned in the beginning - it is tedious but i leads to the desired results.

Hi!
I used an Arduino Nano (clone) as serial gateway to OpenHab, it worked without problems. Meanwhile I changed to an UNO-clone because the Nano fit better into its new task.

Power over USB was not an issue, it worked flawless.

The last question is a little bit ambiguous -
Scenario A - switching between serial binding or MQTT (over serial/USB) does not require much work (depending on your installation). You even don't have to change a plug. I did this several times and it is a little bit annoying -but it works.

Scenario B:
Serial binding and MQTT binding of the same gateway in parallel - I haven't tried this, but you will probably run into trouble.

Serial binding of the gateway and MQTT binding of a part of the messages of the MySensors network through a specialized node is not that difficult. It requires some strategy on programming the individual nodes (e.g. send this messages also to node xy which delivers these messages to a MQTT broker). The connection between this node and MQTT is serial/USB
It doesn't make much sense to use serial binding and MQTT binding from the same source to the same target, but it makes sense (at least for me) when the target is different. (e.g. switching and feedback via OpenHab, collecting sensor information via specialized programs).

If you see MQTT-binding as synonym for an Ethernet connection - I tried MQTT over Ethernet a long time ago and it didn't perform to my needs. There are new programs but i haven't tested until now. Switching between serial and Ethernet connection will probably cause the same amount of work mentioned above.

Connection refused means (in 99%) your broker is not up or you got the wrong address.
I supposed you to run mosquitto_sub/pub on the same machine your broker runs on.
On a different machine you have to add the host address like:

mosquitto_sub -h 192.168.1.10 -t /topic -m "message".

No - at last its not really complicated, but I think you had just a bad start. MySensors and OpenHab tend to start right out of the box - but you need the right box......

@Marcus: Sorry I'm in a hurry so...
But what to do now??? -> is your broker really ok?

1. open two terminal windows on your Raspberry.

2. one window:

   mosquitto_sub -t /test -v

3. second window:

   mosquitto_pub -t /test -m "test message"

If it's all fine, the test message should show up in the first window.

How do i connect mosquitto to Openhab?
OpenHab -> mosquitto
If your still got the OpenHab sitemap from above, the swtiches 1+3 should be functional like desribed, switch 2 will result in an errormessage in the log (as "intended").

Reverse direction (mosquitto -> Openhab).
You may populate your broker with some messages for the given topic.
e.g. mosquitto_pub -t MyMQTT/20/255/V_SKETCH_NAME -m "fake sketch name"

How do i connect mosquitto to Openhab?
I use the serial Gateway connected via USB to my Raspberry and a little Node.js script.
If you are interested - let me know.

Hi Marcus, I have to confess I mingled up the names and got a little lack of information. I referred to something I tried several months ago - i didn't fit my needs, so I changed back to the serial Interface - which performed reasonably good and i lost contact to the MySensors-MQTT side via Ethernet.

To my surprise i read there shall be some basic broker functionality in the Gateway sketch - which sounds really good. It will take a while to reactivate my Ethernetshield and give it a try. Sadly my holidays are over tomorrow and there will be not much spare time to test it.

Nevertheless trying Mosquitto would be interesting, e.g. to talk to the MySensors broker directly and to check the OpenHab->Broker connectivity.

This may be the fault. The MQTT Gateway is not a broker - it is just a special form of client, it "only" translates messages from the MySensors network into MQTT acceptable forms an supplies Ethernet access. It does not perform any broker function.
To install a broker you should spend a little time with Mosquitto (http://mosquitto.org/) or http://jpmens.net/2013/09/01/installing-mosquitto-on-a-raspberry-pi/
In a short way: To install MQTT on your raspberry:

sudo apt-get update
sudo apt-get upgrade

to be up to date.

sudo apt-get install mosquitto mosquitto-clients

this should be enough to get your broker up and running with default parameters.

Replace the IP-adress in OpenHab accordingly and you should be done.

It seems your broker does not response to OpenHab or the binding is not effective.

Your installation is different from mine - you are running OpenHab on your raspberry , I'm running OpenHab on my desktop.
We both use OpenHab 1.6.1.
Probably you are running your MQTT Broker (presumably mosquitto?) on your raspberry - so do I.
You are running MyMQTT on Android, so do I.
(by the way -- I am not able to publish something from MyMQTT despite MyMQTT says "Message published" - nothing arrives at the broker. You got similar experiences?)

For a basic debugging environment I use mosquitto_sub in an extra terminal on my Raspberry with

mosquitto_sub -t /#

which should show all messages arriving at the broker.
First test with mosquitto_pub in another terminal:

mosquitto_pub -t /testsw/1 -m "switch1"

If this Message shows up we got our topic instantiated (and the broker is working).

mosquitto_pub -t /testsw/1 -m "ON" -r

Now sending a retained message. If OpenHab connects to the broker, this message will be sent immediately

in the OpenHab log you should see this:

11:15:07.844 INFO  runtime.busevents[:26] - mqttsw1s state updated to switch1.
11:16:21.289 INFO  runtime.busevents[:26] - mqttsw1s state updated to ON

Toggling some switch should give the followin log:

12:00:03.976 DEBUG o.o.b.m.i.MqttItemBinding[:44] - Publishing command OFF to /testsw/1
12:00:03.991 DEBUG o.o.i.t.m.i.MqttBrokerConnection[:437] - Publishing message 6 to topic '/testsw/1'
12:00:03.994 INFO  runtime.busevents[:22] - mqttsw1 received command OFF
12:00:04.004 INFO  runtime.busevents[:26] - mqttsw1s state updated to Green

what does your log show?

A little update. I couldn't figure out the reasons of this strange behavior, bus at least there exist a kind of workaround.

File mqtt.sitemap

sitemap mqtt label="MQTT-Test"
{
 Frame label="MQTT" 
   {	
    Switch item=mqttsw1 label="MQTT Switch 1 (text)" 
    Text item=mqttsw1s   
    Switch item=mqttsw2 label="MQTT Switch 2 (raw)"
    Text item=mqttsw2s 
    Switch item=mqttsw3 label="MQTT Switch 3 (string)" 
    Text item=mqttsw3s
    Text item=sketch20
   }
}

File mqtt.items

Switch mqttsw1 "MQTT Switch 1" (all,mqtt) {mqtt=">[mysensor:/testsw/1:command:on:RED],>[mysensor:/testsw/1:command:off:Green]"}
Switch mqttsw2 "MQTT Switch 2" (all,mqtt) {mqtt=">[mysensor:/testsw/2:command:off:default],>[mysensor:/testsw/2:command:on:default]"}
 Switch mqttsw3 "MQTT Switch 3" (all,mqtt) {mqtt=">[mysensor:/testsw/3:command:*:Switch ${itemName} was turned ${command}]"}

String mqttsw1s "MQtt Switch 1 Status [%s]" (all,mqtt) {mqtt="<[mysensor:/testsw/1:state:default]"}
 String mqttsw2s "MQtt Switch 2 Status [%s]" (all,mqtt) {mqtt="<[mysensor:/testsw/2:state:default]"}
String mqttsw3s "MQtt Switch 3 Status [%s]" (all,mqtt) {mqtt="<[mysensor:/testsw/3:state:default]"}
                                   
 String sketch20 "Sketch name 20 [%s]"  (all,mqtt) {mqtt="<[mysensor:MyMQTT/20/255/V_SKETCH_NAME:state:default]"}

Switch 1 : default is replaced with RED/Green and this text is output to the topic /testsw/1.
Toggling this switch will result in RED/Green in the status field.

Switch 2: the original statement.
Toggling this switch will result in ON/OFF messages shown in the broker (e.g. MyMQTT)

Switch 3: copied from manual : https://github.com/openhab/openhab/wiki/MQTT-Binding
Toggling this switch will result in a well formed Message in status and broker.

This line resolves the secret of the 2 publishers : OpenHab counts every ">" as a separate publisher.

Furthermore the browser used seems to affect the results. It is mentioned somewhere in the documentation that browsers behave different. I'm using Opera 12.17 - for some items
manual refreshing is required. Chrome does this automatically.

However - the line "String sketch20....." should have been functional despite of all this. I can't see an obvious explanation for failure.

Maybe you can adapt the above skeleton files for your needs.

I stripped my Openhab Installation to the bones and tried to run the example - now I'm getting strange errors like "InstantiationException on org.openhab.core.library.types.StringType"

It will take a while to check out the reasons this behavior.

If I change the MQTT-Topics by hand (e.g. with mosquitto_pub from the raspberry) with some String, they show up correct, if it's a number it won't. Strange.

This is not the expected result. Where does the second publisher come from?

But this result tells us that your broker and your connection are working fine, at least for output (regarded from the OpenHab side).

Toggling the switch should now result in a message like shown above ( "Publishing command....). This message should show up in your MyMQTT on your Smartphone.

Maybe I misunderstood your intentions. I thought you wanted to control some appliance with a switch from within OpenHab. This should work with the given example.

If you want to control a switch (e.g. MySensors BinarySwitchSensor) things get a little more complex. You need an inbound channel from the broker. A code example for this purpose can be found in http://forum.mysensors.org/topic/303/mqtt-broker-gateway. The following line implements this.

Switch node2_sw2  "sw2 send + recieve example"  (node2,all)      {mqtt=">[mysensor:MyMQTT/21/2/V_LIGHT:command:ON:1],>[mysensor:MyMQTT/21/2/V_LIGHT:command:OFF:0],<[mysensor:MyMQTT/21/2/V_LIGHT:command:MAP(1on0off.map)]"}

( This will not fit for a switch - its only an example for inbound channels)
I tried this, but it was not successful. I got a Feed-back-loop blocking my OpenHab Server.

If you want to monitor your switch, the String Example some lines below could be an option.

 String sketch20 "Switch 20 [%s]"  (sketch,all) {mqtt="<[mysensor:MyMQTT/20/3/V_TRIPPED:state:default]"}

I forgot about the DEBUG part.

<logger name="org.openhab" level="INFO"/>
<logger name="org.openhab.binding.mqtt" level="DEBUG" />
<logger name="org.openhab.io.transport.mqtt" level="DEBUG" />

In File "logback.xml" look for the first line and insert the second and third line.
This will lead to some additional infos in Openhabs output.

I'm looking for some trace of successfully established connections between OpenHab and MQTT broker.

If there is no connection the switch will show like you described above.

@Marcus .. I have to think about this. Meanwhile I would be interested in your OpenHab output concernig lines like these:

15:19:49.599 DEBUG o.o.b.m.i.MqttItemBinding[:44] - Publishing command OFF to /tbtestm/1
15:19:49.599 DEBUG o.o.i.t.m.i.MqttBrokerConnection[:437] - Publishing message 325 to topic '/tbtestm/1'

You got some messages similar to this?

Add this to your openhab.cfg file:

mqtt:mysensor.url=tcp://xxx.xxx.xxx.xxx:1883
mqtt:mysensor.clientId=MyMQTT

Dont't forget to replace xxx with your broker's IP-Adress.
ClientID has to be unique for your broker, e.g. if there is another connection with the same ID, only the last established connection will be valid.

Add this to your *.items file:

Switch mqttsw1 "Switch 1" (all) {mqtt=">[mysensor:/testsw/1:command:on:default],>[mysensor:/testsw/1:command:off:default]"}
Switch mqttsw2 "Switch 2" (all) {mqtt=">[mysensor:/testsw/2:command:off:default],>[mysensor:/testsw/2:command:on:default]"}

Add this to your *.sitemap file:

Frame label="MQTT" {
Switch item=mqttsw1 label="MQTT Switch 1"	
Switch item=mqttsw2 label="MQTT Switch 2"
}

This should be enough for a dryfit run. It will be safe to restart OpenHab at this point. Using mosquitto_pub/mosquitto_sub or WMQTT-Utility or something similar you should be able to receive messages from OpenHab under topic "/testsw/#"

@C.r.a.z.y. Maybe the VERA controller is suitable for you. Have a look at http://forum.micasaverde.com/index.php, here especially http://forum.micasaverde.com/index.php/board,27.0.html. VERA has an inclusion mode and obviously supports Raspberry pi with Camera module (I didn't know before). Very probably you need additional additional hardware - I don'know if this is your intention.

@C.r.a.z.y. OpenHab doesn't offer such methods like "inclusion" or search for unknown devices at the moment. But this is not due to MySensors properties, this is common to all bindings.
Prerequisite for working with OpenHab seems to be the knowledge of your hardware to a very low level (e.g. programming the sensors yourself = MySensors). Accessing the configuration files results in great possibilities but also in much work.

There is another User-Interface to this functions - https://github.com/cdjackson/HABmin - you might give this a try to get rid of the Eclipse-part of the OpenHab designer. I haven't tried it, but the slideshows are really impressive. Habmin may result in easier working -- but probably not in less work.

You haven't told us what project you are aiming for - so it's a bit difficult to give a hint what may fit your needs.

Regarding your last question, consider the following example:

String HomeMaticS1 "Status1-1 [%s]"	<shield> (HomeMatic,kitchen, FirstFloor) {homematic="address=JEQ0459986, channel=1, parameter=LED_STATUS" }

It is a String definition for my Homematic controlling one of 16 dual-color LEDs
String denotes the type of this object
HomematicS1 ist the name of this object.
"Status1-1" ist the label displayed in the browser.,** [%s]** is a formating directive.
**<shield> **is the name of the icon (which has to reside in \OpenHab1.6.1\webapps\images\shield.png --with exact this name)
The round parenthesis **(Homematic, kitchen, FirstFloor) **tells Openhab to which group this object belongs --yes, one object may belong to many groups (= frames).

The rest of this declaration implements the homematic binding with parameters you should know before - as mentioned above.

The other 15 LEDControls are simply constructed by copy&paste and changing the numbers accordingly. Inconsistent numbering is a nice pitfall here and provides you with many happy hours.

With the following Frame in the current .sitemap

 Frame label="MyFrame" {
	Group item=HomeMatic icon="homematic"
	Group item=kitchen icon="kitchen"
	}

Item **HomematicS1 ** will show up in both subframes labeled as "Status1-1".

This applies to switches and other widgets in the same way, so you can operate your actors from within different frames.

@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.

@CARSTEN I'm running MySensors with OpenHab via Serial Gateway. You migth have a look at http://forum.mysensors.org/topic/301/the-best-way-to-connect-to-openhab/13. and/or http://forum.mysensors.org/topic/302/openhab-mqtt-tips-hints/6
Until now (20 Nodes) the functions are very reliable. The backdraw is - you have to manage all replies in the codesection by yourself. It's an noticeable amount of (repetitive) coding, but offers also great flexibility.

@kolaf : I´m not very experienced in Java, so the code reflects my missing knowledge and is much longer than it should be.

The purpose of "Split Message" is to split multilpe messages into single messages and afterward split this single messages into useful informations to set the OpenHAB items accordingly.

First part: common declarations

import org.openhab.core.library.types.*
import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*

var String[] buffer
var String[] linebuffer
var int SensorID
var int transmissions_old = 0
var int transmissions_new = 0  
var int transmissions_missed = 0 
var int RadioID

Second part: Splitting multiple Messages

rule SplitMessage
when 
	Item Arduino changed
 then
 /* Split messages separated with NEWLINE */
linebuffer=  Arduino.state.toString.split("\n")

Third part: Splitting messages according to the serial protocol
buffer(0) = NODE_ID
buffer(1) = CHILD_ID
buffer(2) = MESSAGE_TYPE
buffer(3) = SUB_TYPE
buffer(4) = Message

 for (String element : linebuffer) {
	buffer = element.split(";")
	RadioID = new Integer(buffer.get(0))
	
	switch (RadioID) {
	case 7: {
			SensorID = new Integer(buffer.get(1))
			switch (SensorID) {
				case 0 : postUpdate (MySensorsT0, buffer.get(4))
				case 1 : postUpdate (MySensorsT1, buffer.get(4))
				case 2 : postUpdate (MySensorsT2, buffer.get(4))
				case 3 : postUpdate (MySensorsT3, buffer.get(4))
				} /*switch (SensorID) */
				
			}  /* case 7 */
	case 6: {													 /* ExperimentalNode 6 - soll mal NODE 1 werden */
			if (buffer.get(1)== "10") {							 /* child 10 ist der Homematic Anschluss */
				postUpdate (HMSerialOut, buffer.get(4))	
			} /* if */
	} /* case 6 */
	case 9: {                                                      /* eigentlich war das mal NODE 6 */
			if (buffer.get(1) == "2") {                            /* Child 2 ist der Schrittmacher      */
				transmissions_new = new Integer(buffer.get(4))
				logInfo ("TRANS","Transmissions new " + transmissions_new.toString() )
				logInfo ("TRANS","Transmissions old " + transmissions_old.toString() )
				if (transmissions_old == 0) {transmissions_old = transmissions_new -1 } /* beim ersten mal passiert nichts */
				transmissions_missed = transmissions_missed + (transmissions_new - transmissions_old - 1)
				transmissions_old = transmissions_new 
				postUpdate (Missed_Transmissions, transmissions_missed.intValue.toString)
				postUpdate (Transmission_Count, transmissions_new.toString())
				}
			} /* case 9 */
	case 5: {
				if (buffer.get(1) == "0") { 						/* Child 0 ist die Luftfeuchte */
					postUpdate (MySensorsMobHum, buffer.get(4))
					}
				if (buffer.get(1) == "1") { 						/* Child 1 ist die Temperatur */
					postUpdate (MySensorsMobTemp, buffer.get(4))
					}
							
			} /*case 5: */
	default:	{
			postUpdate (MySensorsNode, buffer.get(0))
			postUpdate (MySensorsChild, buffer.get(1))
			postUpdate (MySensorsMtype, buffer.get(2))
			postUpdate (MySensorsStype, buffer.get(3))
			postUpdate (MySensorsMessage, buffer.get(4)) 
			}
			
	  }   /*switch(RadioID) */ 		   	
	} /*for (String element) */
	
end

So the drawback of the serial binding becomes obvious - every action has to be coded separately. On the other hand it offers enormous controlling possibilities (eg scene configurations),

Fourth part: some actions triggerd from OpenHAB GUI/Webinterface:

rule ArdSwon
when 
	Item ArduinoSwitch changed from OFF to ON
then
	sendCommand(Arduino, "4;2;1;0;2;1\n")
end

rule ArdSwoff
when 
	Item ArduinoSwitch changed from ON to OFF
then
	sendCommand(Arduino, "4;2;1;0;2;0\n")
end

rule HmArdon
when
 Item ArduinoHMSw1	changed from ON to OFF
then
	sendCommand(Arduino, "1;10;1;0;24;HD01004000000\n")
end

rule HmArdoff
when
 Item ArduinoHMSw1	changed from OFF to ON
then
	sendCommand(Arduino, "1;10;1;0;24;HD01004010000\n")
end

To send commands to the MySensors Network you have to use the same "Arduino"Item. In my oppinion another drawback. A separate way out would be nicer. Despite of my oppinion there is no interference between input and output - so i can live with this.

The above example illustrates controlling a LED connected to an Arduino-UNO with the original Relais-Sketch, the second part controls some of my Homematic devices via another MySensors node (connected to Homematic via USB) .

So at last I got a 2.4Ghz network to communicate with my Homematic and an ethernet connection via OpenHAB. In combination with direct interaction between certain MySensor nodes this results in a very redundant and stress-resistant home controlling network.

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.