I found the problem. In an unrelated part of the sketch I was doing an analogue read from an input set up as a digital output. This apeared to generate some sort of error state that fouled up the interface between teh Arduino and the RFM69. After removing the offending statements everything works fine.
@nelsonov Great! There is no need to create an issue. If there is anything to discuss, we can discuss in the pull request thread.
Maybe call it something like "Add MY_DEBUGDEVICE to redirect debug output"
@Stefan_NE Good to hear you finally succeded in having a reliable network.
News from my side:
After 5 days of operation it seems Node_2 is back in a mode of relaible communication, no more issues also with Node_1. These both are the ones sending a lot of data and use HW-serial + "triple-headed" message initialisation.
BUT: Node_3 (BME280) is no longer continously present now, and also Node_4 (sw-serial + "single-headed") seems to have communication problems (didn't yet investigate in depth). So next step will be to first change these sketches also for the use of the triple initialisation. If that works, I'll report - it then may be a good idea to change the defaults in the MySensors-lib (to be discussed).
BAD news, it is not solved...
It had been working fine on batteries when CH1P was connected instead of CH2P originally, but it is now echoing random false positives as before, despite running first on battery smoothly for over a day, but now with the USB power supply connected, cue Ghostbusters...
When CH2P was previously connected and the USB was connected, whether powered up or down, the false positives continued, whether the Node was on the wall next to the power outlet or parked on top of the washing machine spreadeagled.
I even changed the USB PSU for a Nokia spare, but I have now powered it down to follow this through. I cannot believe the physical proximity of a dead USB cable should have any effect on a FET drain line, or an Interrupt Line on an Arduino, but that is what I am staring at as possible cause...
Here is an example of two consecutive false positive reports to Domoticz, but note the time separation:
2017-11-22 17:00:01.854 (WN Gateway) RFXMeter (Water Meter Cumulative)
2017-11-22 17:00:01.863 (WN Gateway) RFXMeter (Water Meter Cumulative)
BUT, to add fuel to the puzzle...
1 - At max flow rates the pulses from the sensor as checked are 8-9 seconds apart on a 1 litre pulse.
2 - The minimum 'sleep' cycle in any condition on the sketch is 50ms.
Reports 9 milliseconds apart is impossible on a sensor in the circumstances, 80ms pulse width, so logically the origin can only be the node itself (Pro-Mini 16MHz , 3v). So it can is EMI, an effect of the cable, the cable from the PSU or the board itself? I checked the transmit periods so no coincidence there...
I detached the sensor for sags, and zero response, as expected.
I re-attached the sensor but detached the signal line from the sink FET on the sensor, zero response, as expected.
Only when everything is in combination do these curious triggers arise so any thoughts on suppression ?
What makes no sense in this is that although it is an inductive sensor, the sinking of the interrupt should be the only trigger to the FET in te sensor, there should not be any other influence...
I will experiment a little more to try to get to the bottom of this as it seems likely this is interference issues over the Pro-Mini or sensor cable proximity to 'something' such as the nearby power outlet or a buried power cable in the wall rather than the sensor, unless the sensor cable. It is also possible that since the USB power supply cross over the GND and Signal cores from the sensor, this may c
@burningstone Check connections with a continuity tester and measure your voltages coming to the arduino and PIR. When checking continuity, check directly from the jack on the PIR and/or temp sensor to the pro mini terminals, and also check pins near the connections for any possible shorts.
In most home automation scenarios you usually have a (locally installed) controller software where you act on incoming data from the sensors deployed in your home.
With "act" I mean everything from logging data (for graphing) to automatically send out commands to actors.
I.e. If movement is detected (by a motion sensor) in a room after sunset then turn on ceiling light for two minutes.
So... the controller holds all the "rules" in your building automation setup.
You can have a very small MySensors setup where sensors/actors send messages between each other and the "rules" is hardcoded in the nodes. But this will soon get very messy to maintain. You'd need at least one Relay node to get this working (with hard-coded id's in the nodes).
The controllers can often run headless on simple hardware like Raspberry. Check out our list of supported controllers.
I finally had some time to do some further testing.
Switching to the development branch of MySensors solved my problem.
I have the feeling that the link is not really stable, but at least I can see data coming in.
Finally I got it, as I have used same hw configuration for ver1.5.4 as for ver 2.1.1 I did not expect any power issues...
a hint for debugging in consol mode linux then use screen
apt-get install screen
then use like this, note that I use udev to always get Domoticz to use correct ttyUSBx, as I have several USB devices attached attached
sudo screen /dev/ttyUSB-mysensor 115200
to kill screen CTRL-a then k and y for confirm
Then I realised that if I use gateway sketch un-modified it is working, and Domoticz is providing node id, (If Domotics is set to allow new sensors, in settings)
So when I change on the PA_LEVEL_HIGH or PA_LEVEL_MAX and use more power consumption, apparently the gateway isn't working. I do have a amplified PA RF24L01 moduleboard.
It's working when set as default PA_LEVEL_LOW
// Set LOW transmit power level as default, if you have an amplified NRF-module and
// power your radio separately with a good regulator you can turn up PA level.
// RF24_PA_MIN RF24_PA_LOW RF24_PA_HIGH RF24_PA_MAX
#define MY_RF24_PA_LEVEL RF24_PA_LOW
//#define MY_RF24_PA_LEVEL RF24_PA_HIGH
//#define MY_RF24_PA_LEVEL RF24_PA_MAX
I might have to look into a power USB hub
Thank you guys for providing input to solve my issue
Thanks for the info and confirmation! I will then move my testing setup to different frequency and the problems with coverage will resolve with repeaters.
(I do also have some RFM69 units laying around, but I do not want to use them for the time being due to their bigger footprint)