That was it!!!!! I tried 22uF, was still doggie, so I thought why not move up to 47uF wink and what do you know, that seems to be the winning value. I have some more testing, but looking pretty good so far.
This sounds to me that the issue is solved...
I can imagine that 1.4 requires a bigger cap while 1.3 doesn't. 1.4 uses auto acknowledge which can send burst packets. This could put a bigger load on your power supply.
That was it!!!!! I tried 22uF, was still doggie, so I thought why not move up to 47uF and what do you know, that seems to be the winning value. I have some more testing, but looking pretty good so far.
(Just to confuse things, some relays have double throw outputs, meaning that one pair of conductors is shorted when the relay is powered - "Normally Open/NO" - and one when it's not powered - "Normally Closed/NC" (with one of those contact being common to both).
So sometimes you might power a device with the NC connection of the relay output, meaning the device loses power when the relay is powered. One reason do so this would be if you want the device to be powered even if the microcontroller was disabled.
Anyway, take that into account too, and return 1 if after all the possible inversions, the hardware device is powered on.
For code, you could just return !digitalRead(...), where the NOT operator ! will convert 0 into 1, and 1 into 0 more simply than the ?: syntax (actually it will change any non-zero value to zero, not just 1).
I'm aware of the superiority of 1.4. Because I just started with building my custom controller I will go with the development branch for now. I really like the new protocol so far.
I'm using very basic arduino sketches at the moment. The only thing I'm worried about is my custom controller that I'm building in Node-Red. Hopefully the feature changes will not have to much impact on that part.
Anyway, the nRF24 seems to be very sensitive to location/orientation then?! It's true that I just 'throw' it on the table an the orientation will be different eveyday.
Is that the right conclusion? Really?
I know why it fails, the sensor is not installed.
But what I want, I am building my own Indigo plugin (in case you missed that part), is for the plugin to see that it goes wrong so that I can show that in the ui.
@therik I never really understood why the data was read this way in the pingpair sketch.
Is keeps reading and overwriting data just read until there's nothing left to read.
The pong sketch should just write 1 value for every value received, so there shouldn't be anything more to read anyway.
Maybe on some boundary condition more data could come in, but I would prefer to read the value and flush the rest. Too bad flush Rx is not exported to public in current rf24 implementation...
@hek And that is why I will never be a programmer... I must have looked at that code 4 times! Anyway, thanks! I'll change it tonight when I get home.
Do you think it would be worth updating the example here: http://www.mysensors.org/build/binary to add a child id? I'm wondering if there may be other people out there that may make the same mistake as me.