I can absolutely confirm this with VS2015, Visual Micro and MySensors 2.1.1. This is clearly a kind of merging, that is done by Visual Micro.
All includes have to be made BEFORE the first line of code is executed. The initialization of your SENSOR_ANALOG_PINS array is such a line of code.
Just posting it to keep it visible and well-scored at search engines, as this is SOLVED and works fine. Thank you!
Oh, I didn't know they perform so "bad" in real-life applications. I would love to stay informed so it would be awesome if you could post your success-story here if you got it 
Very interesting topic indeed.
Good luck!
From my perspective it is an absolute must to have this handled by the library, because it is a core feature of nRF24L01+'s and would be relatively easy to implement.
My home automation system should not need to care about the transport layer stuff, but just make use of a reliable transport layer and be notified if sending and retransmission fail consecutively. Even TCP/IP Stack connections just notify the application layer if the timed out.
Can you put this higher on the list and help if possible?
Edit: This is the library where i got this from and it automagically just works https://github.com/TMRh20/RF24Network/tree/Development
Other libraries like the common RadioHead are doing this as well.
You can link multiple things (or thing channels) to the same item in openHAB. Simply create one single ColorItem and separate all channels with commas.
Working example:
Color aacc_color "Mysensors LED Lights" (lights) {channel="mysensors:rgbLight:bridge:drawer_lights:rgb,mysensors:rgbLight:bridge:desk_lights:rgb"}
I can confirm that the Arduino hangs at the init, if it cannot communicate with the nRF24L01+.
Often had that "issue" when I accidentally disconnected the MOSI cable and the communcation was broken. There seems to be no timeout though. If you enable the MySensors debugging, you will see radio init... on your serial line.
I now use this behaviour as a kind of self-test. In the setup() of my sketches, I turn on an LED, do the radio init and turn it off afterwards. If it stays on, I know there is something wrong with the radio. Without even connecting a single serial cable.
Maybe you can use it this way, too.
Just to clarify: The hang will not happen if you have a bad radio range. It will only happen if the local communcation through SPI fails.
Oh, I didn't know they perform so "bad" in real-life applications. I would love to stay informed so it would be awesome if you could post your success-story here if you got it Very interesting topic indeed.
Good luck!
I understand. There is also a relatively new infrared array sensor, that has a much higher resolution than the default PIR sensors and will be able to detect temperature differences over 64 separate fields and thus human presence.
Here is a link to a typically slightly more expensive but easy-to-prototype breakout board from Sparkfun with the Grid-Eye: https://www.sparkfun.com/products/14607
Might be worth a shot. I am planning to use this for detecting presence without the need for the occupants to be in motion regularly (office spaces, living rooms, etc).
Grid-eye information: https://www.mouser.de/new/panasonic/panasonic-grid-eye-infrared-array-sensors/
If you are going to try a z-wave multisensor, you should look into getting a Fibaro FGMS-001 (https://www.fibaro.com/en/products/motion-sensor/). I tried the Aeotec and the Fibaro and the settings of the Fibaro are way richer. There are 3 settings to tune the PIR detection so that might be interesting to you. Also I never had to change batteries in 2 years.
You can link multiple things (or thing channels) to the same item in openHAB. Simply create one single ColorItem and separate all channels with commas.
Working example:
Color aacc_color "Mysensors LED Lights" (lights) {channel="mysensors:rgbLight:bridge:drawer_lights:rgb,mysensors:rgbLight:bridge:desk_lights:rgb"}
I can absolutely confirm this with VS2015, Visual Micro and MySensors 2.1.1. This is clearly a kind of merging, that is done by Visual Micro.
All includes have to be made BEFORE the first line of code is executed. The initialization of your SENSOR_ANALOG_PINS array is such a line of code.
Just posting it to keep it visible and well-scored at search engines, as this is SOLVED and works fine. Thank you!
I can confirm that the Arduino hangs at the init, if it cannot communicate with the nRF24L01+.
Often had that "issue" when I accidentally disconnected the MOSI cable and the communcation was broken. There seems to be no timeout though. If you enable the MySensors debugging, you will see radio init... on your serial line.
I now use this behaviour as a kind of self-test. In the setup() of my sketches, I turn on an LED, do the radio init and turn it off afterwards. If it stays on, I know there is something wrong with the radio. Without even connecting a single serial cable.
Maybe you can use it this way, too.
Just to clarify: The hang will not happen if you have a bad radio range. It will only happen if the local communcation through SPI fails.
@Lemme said:
Wondering if it is still limited to 8 seconds. Or if I have to do some sort of loop/counting to make it sleep for several minutes or more
If you need longer intervals, you should use SLEEP_FOREVER and attach a Timer interrupt beforehand. Pseudocode would look like this:
loop(){
...
attachInterrupt(Timer1, 600000, dummy_function) // wake up every 10 minutes
gw.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF)
detachInterrupt(Timer1) // disable so we don't interrupt ourselves
.... do things, send data, and so on ......
}
void dummy_function(){
// this does nothing, but interrupt need something to call, so we make a dummy function
// this will return immediately to the loop() again
}
This is best-practise for things that are not real-time-based (like encoder wheels). Using the normal loop makes it possible to use all the millis() and other time-based functions you wouldn't be able to use withing interrupt calls.
By the way - in YOUR case, when you don't want to receive anything on the sensor node while sleeping, using the MySensors Sleep function is perfectly fine. This thread focuses on using it with other interrupts than Timers.
@TimO said:
Something I plan to do, is adding the ACK functionality to the binding, so if no ACK is received the command is repeated for 5 times or so.
+1 for the ack functionality. In my opinion this is a Transport-Layer functionality and should be built into the gateway (Arduino or whatever) itself. But the main developer doesn't like the idea because he is fearful that the serial buffer (or even an arduino queue system) will be unable queue enough messages while resends happen.
On the other hand: we have plenty of RAM on our openhab hosts, so your idea seems like it will solve the problem completely, because we could even react on continous fails with putting the device offline (or whatever the openhab2 terms are for this) 
@nikos1671 In case of unhandled messages (when there is no openhab item assigned to this nodeID;childID;-combination in your sensorToItemsMap), they will just be ignored (and print the data field).
This happens here in the code: https://gist.github.com/gersilex/13f39b3419427b35636a#file-default-rules-L211
This will look like this:
3;255;4;0;0;FFFFFFFFFFFFFFFF0300
No item matches nodeId=3, childId=255. Data received: FFFFFFFFFFFFFFFF0300
However, this was never tested with debugging enabled on the Gateway. This is why I asked you to disable debugging and recompile/reupload the code to your gateway arduino without the DEBUG flag inside MyConfig.h.
There is a know problem which is not catched currently:
Please go and try to disable the DEBUG on your gateway arduino.
Hey guys, on my Raspberry Pi 2 the first rule execution takes about 15 seconds. If you have changed the rules file, the xtent logic has to be re-compiled to java code again. But after the first rule execution it takes only about 10-50ms for execution.
Also, @nikos1671 I would turn off the DEBUG mode on your gateway. Receiving data works and this is what you would debug. You see incoming data without debug, too so you can securely get rid of it