Posts made by mihai.aldea

@tango156157, I sometimes get similar errors while compiling the sketches. Mostly because I am still using the MySensors 1.5 library for my legacy network, 2.1.0b for the RFM69 network (working RSSI report) and 2.1.1 for the LoRa network.
Mostly when dealing with MySensors 1.5 and/or older sensors libraries, I find the newer Arduino version to pop all sort of errors. But then I fire up one of the older Arduino IDE versions I have, 1.6.5, 1.6.9 and so on. Eventually one of them compiles the sketch without errors while the newer version don't work. This is far from being a solid solution for these errors, but it gets the job done.
You should try that too, especially if you're using older libraries for your sensors.
You can find them here: https://www.arduino.cc/en/Main/OldSoftwareReleases#previous

@mfalkvidd said in Transport overhead optimization:

Could you describe the advantages of using a rfm96 instead of rfm69, when not using LoRa mode?

Then I don't understand your statement.

OK, trying to make a sense of those tables now, but my main question remains: Is RFM95_BW31_25CR48SF512 a LoRa mode or not? Because this is what I'm currently using.

So what you're telling me is that I'm not using the RFM96 in LoRa mode? I now seem really dumb, but in all fairness, after a lot of digging, I only found these modem configrations available:

* | CONFIG                    | BW    | CR  | SF   | Comment
* |---------------------------|-------|-----|------|-----------------------------
* | RFM95_BW125CR45SF128      | 125   | 4/5 | 128  | Default, medium range
* | RFM95_BW500CR45SF128      | 500   | 4/5 | 128  | Fast, short range
* | RFM95_BW31_25CR48SF512    | 31.25 | 4/8 | 512  | Slow, long range
* | RFM95_BW125CR48SF4096     | 125   | 4/8 | 4096 | Slow, long range

I chose RFM95_BW31_25CR48SF512 after some extensive trial and error range tests.

If I'm not currently using LoRa, how can I actually switch to that?

I couldn't not notice the large overhead associated with the MySensors transport protocol. You see, as discussed before, the issue at hand is not using a coin cell for 3 years instead of 2, but it's about the RFM69 and RFM95/RFM96 modules which are capable of using really low bitrates or special modulations.
Eg. I had a 14250 battery that drained within a month with an RFM96 sending data every 5 minutes using RFM95_BW31_25CR48SF512 which was sending only one sensor value. This happened because unlike RF24 which can have a total awake cycle of 100-150ms, the RFM96 had an awake cycle of about 5000ms. It took it 5 seconds to send the single sensor value.
RFM69 is another case in which a lower bitrate -> longer range -> longer TX time. I went as low as 300bps only to see that a single packet is sent in about 1500ms. That's way too much for a battery powered node.

Some of us need long range sensors and we don't want a constant power messy setup, or the complex circuitry and increased cost associated with adding "UPS" like features to our boards.

My RFM96 node now sends a ping every 3h and the RFM96 nodes run in 9600bps so that I wouldn't have to replace those 14250 batteries monthly and actually use them for the intended life-cycle, that's more than 3 years.

The alternative is to give up MySensors altogether and use third party libraries, concatenate the messages as raw data then parse them on the remote gateway based on predefined rule set. But although this gets the job done, it's not a really good idea to mix various libraries and properly maintain the whole system in the long run.

Well, I'm glad that the posting got some traction and some very interesting ideas were shared. While the bits and pieces of information were all out there, your argument helped drawing some conclusions.

1. LoRa is NOT an option for HA. alexsh1 explained one scenario and I'm actually using LoRa (not LoRaWAN) in my building, but both cases make use of LoRa only because it's a new cool technology. @alexsh1 your friend could properly cover his home with 2G/3G signal either for free, by asking the provider to improve the coverage in that area, or by buying a GSM repeater. And I could ask a neighbor to share his WiFi connection so an ESP8266 module could do the job.
2. The protocol addresses very specific segments where a great urban coverage is required and for that to happen no node should exceed a radio power of over 100mW.
   There is another case where everything was traded off for the sake of range, the ham radio JT65 protocol. I was able to successfully transmit a signal from Romania to Brazil using 5W RF power and a 1m diameter magnetic loop antenna. It's great for long distance, narrow bandwidth (200Hz wide channel), low power but it sends data at a "whooping" speed of 13 characters per 50 sec, during which it draws about 1.8A from a 12V battery (21.6Wh).
3. My original idea of LoRa <-> RFM69/RF24 is not feasible unless, some serious downsampling is involved, as buffering the raw data before sending it out is really useless because LoRa doesn't have a serious overhead that would be addressed by concatenating larger chunks of data in a single packets.

So at the end of the day, it really leaves us with a couple of applicable scenarios when taking public LoRaWAN meshes into consideration. Smart meters and perhaps security devices which only have to send a daily keepalive ping and if ever needed, tripped sensor alerts, provided that they would be immune to jammers. I'm not taking into consideration the close range stations where a daily 30s air time would suffice, because this defeats the purpose of LongRange. Other than that I see no real use of LoRaWAN, but feel free to share your ideas, perhaps I'm missing something.

And after apparently trashing both LoRa and LoRaWAN I will only say that I can barely wait to get myself a LoRaWAN gateway and set it up in my area

@alexsh1 said in Any RFM95 user reports?:

@gohan in a highly populated area Lora is better from my perspective. However, as already mentioned the cost is high (GW - €300, node - €55+ etc). Plus one is expected to develop

And why is that? Dense population = likely more users = frequent gw congestions.

Indeed, I see LoRa as an option for either experimenting, or as a solid alternative where there's no other option. Because at the end of the day, those who'll require a reliable transport layer will not resort to the open bands but use 2G/3G modems or even radio modems or satellite uplinks. While the LoRaWAN users will have to cope with the drastic FAP limitations, or use point-to-point systems for setups that allows no alternative, like I do.

I see, but the end nodes shouldn't necessary route their data in an a synchronous manner. The gateway can buffer the data and commit the reading asynchronously over to the LoRaWAN network once every 5 minutes. Sensor data downsampling could be performed by the gateway in order to shorten the TX window to the utmost minimum. Downsampling and/or a heavy compression algorithm could help.
On the other hand, I do realize that all these feature could lead to a fairly complex solution that's going to be so complicated to use that's never gonna get any traction.

I'm planning to get myself one of those and set it up in my neighborhood, however at least for the time being I find it a bit useless since I don't know of any Home <-> LoRaWAN gateway that would effectively push the end nodes data over the LoRa network and up to a hub. Moreover, if that gateway would exist, then there should be some considerations regarding the way the LoRaWAN gateway handles packets, eg. authentication, message signing, encryption, ACL or rate limiting. This would enforce a private communication channel, free of any abuser that would hammer down the gateway by sending readings every 5 sec. from a set of couple of dozen sensors, congesting the gateway.
It may be that some manufactures such as Cisco have already considered these but I'm not aware of that, and testing their solutions is rather cost prohibitive.

It would though be very nice to have RFM9x <-> RFM69 or RFM9x <-> RF24 home gateway. The end nodes would use an appropriate protocol for the required range and cost (RFM69 or RF24) to send data to the gateway, and then the gateway would forward the packets over the LoRaWAN network to "the cloud".

Yes, I am very much aware of that, it's just that I wasn't expecting such a long TX time. And my conclusion is that they have no use with battery powered sensors, unless maybe BW500CR45SF128 is used, but then it will defeat the "LoRa" purpose.

Well, let's not get overhyped here, there's the story of the guy reaching 160km with an RFM69, not RFM95, but to talk about hundreds of km away with line-of-sight is almost impossible due to geographical restraints. And if we were to talk about ionosphere propagation, I'm sure it may work under ideal conditions, but propagation is very iffy, relies a great deal on the solar conditions and is totally unreliable throughout the 24h cycle. So except from a range success story, there's really nothing to it.
The real thing is the urban propagation with vanilla RFM95/RFM96 along with omnidirectional antennas if a city-wide mesh would be deployed. Yagi's will only help with point-to-point directional setups and perhaps a magnetic loop could prove an awesome option but they require extremely fine tuning due to their very narrow bandwidth, sometimes in the range of +/- 10kHz. I'm considering ordering two custom built magloops but the issue at hand is that for them time being I don't have a VSWR meter for UHF bands. And with entry level UHF antenna analyzer models starting at about $700, it seems a bit too much for current hobby level requirements.

@alexsh1, I know that, the problem is that LoRa has a very long TX time, unlike RFM69 or RF24. The latter can send their data within 100ms incluiding the sensors conversion time. LoRa takes about 5000ms. And not to mention that it uses about 100mA instead of 20mA. Switching to 3h duty cycle seems to work fine, but only because I'm using the sensors as a tripping security device, however, plotting temperatures won't be very nice at a 3h resolution.

Very nice log parser, I didn't knew it. Thanks @gohan for letting me know and @hek and @tekka for maintaining it.
Yes, regarding the battery power, I measured reporting cycle. It's about 5000ms give or take 1000ms which is a huge TX time for a battery powered sensor. But since I only need to know that it's live and kicking and only get the door trigger message, I'm fine with a ping every 3h. If I were to use this as a temperature sensor, even with a 300ms resolution, it would've been a battery killer.

I'm using RFM96 but used RFM95 in the article as for some reason the 868MHz is way more popular and thus more likely to get some feedback.

Sort of yes. My problem is with the battery. I initially set it to wake every 300s and whenever the sensor door triggers. The battery drained within a few weeks. Then I changed the wake cycle to 10800s (3h) and the battery holds up pretty well.
The battery problem is cause by the mode that I have to use:
RFM95_BW125CR48SF4096. Moreover, it seems that the transport is not really reliable. Here's last 24h log

Wed Mar 15 12:45:34 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 12:45:34 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 12:50:36 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 13:05:37 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 13:05:38 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 13:05:38 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 13:10:34 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 13:10:34 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=255,c=3,t=0,pt=1,l=1,sg=0:59
Wed Mar 15 13:10:36 EET 2017 | 1;255;3;0;0;59
Wed Mar 15 13:10:36 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=2,c=1,t=28,pt=0,l=9,sg=0:rssi: -5%
Wed Mar 15 13:10:38 EET 2017 | 1;2;1;0;28;rssi: -5%
Wed Mar 15 13:10:38 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=1,c=1,t=16,pt=1,l=1,sg=0:0
Wed Mar 15 13:10:41 EET 2017 | 1;1;1;0;16;0
Wed Mar 15 13:10:41 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
Wed Mar 15 13:10:41 EET 2017 | 0;255;3;0;9;TSF:MSG:BC
Wed Mar 15 13:10:42 EET 2017 | 0;255;3;0;9;TSF:MSG:FPAR REQ,ID=1
Wed Mar 15 13:10:42 EET 2017 | 0;255;3;0;9;TSF:PNG:SEND,TO=0
Wed Mar 15 13:10:42 EET 2017 | 0;255;3;0;9;TSF:CKU:OK
Wed Mar 15 13:10:42 EET 2017 | 0;255;3;0;9;TSF:MSG:GWL OK
Wed Mar 15 13:10:43 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
Wed Mar 15 13:10:43 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
Wed Mar 15 13:10:46 EET 2017 | 0;255;3;0;9;TSF:MSG:PINGED,ID=1,HP=1
Wed Mar 15 13:20:41 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=OK:1
Wed Mar 15 13:24:40 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 13:24:40 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=255,c=3,t=0,pt=1,l=1,sg=0:60
Wed Mar 15 13:24:42 EET 2017 | 1;255;3;0;0;60
Wed Mar 15 13:24:42 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=2,c=1,t=28,pt=0,l=8,sg=0:rssi: 1%
Wed Mar 15 13:24:44 EET 2017 | 1;2;1;0;28;rssi: 1%
Wed Mar 15 13:24:44 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=1,c=1,t=16,pt=1,l=1,sg=0:1
Wed Mar 15 13:24:47 EET 2017 | 1;1;1;0;16;1
Wed Mar 15 13:24:47 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=255,c=3,t=0,pt=1,l=1,sg=0:54
Wed Mar 15 13:24:48 EET 2017 | 1;255;3;0;0;54
Wed Mar 15 13:24:48 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=2,c=1,t=28,pt=0,l=8,sg=0:rssi: 1%
Wed Mar 15 13:24:50 EET 2017 | 1;2;1;0;28;rssi: 1%
Wed Mar 15 13:24:50 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=1,c=1,t=16,pt=1,l=1,sg=0:1
Wed Mar 15 13:25:40 EET 2017 | 1;1;1;0;16;1
Wed Mar 15 13:25:41 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 13:35:43 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 13:45:43 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 13:45:44 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 13:50:45 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 14:05:46 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 14:05:47 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 14:05:48 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 14:20:50 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 14:25:49 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 14:25:50 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 14:35:53 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 14:45:53 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 14:45:54 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 14:50:55 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 15:05:56 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 15:05:57 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 15:05:57 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 15:21:00 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 15:25:59 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 15:26:00 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 15:36:02 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 15:46:02 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 15:46:03 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 15:51:04 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 16:06:05 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 16:06:06 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 16:06:07 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 16:21:09 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 16:26:08 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 16:26:09 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 16:30:57 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 16:30:58 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
Wed Mar 15 16:30:58 EET 2017 | 0;255;3;0;9;TSF:MSG:BC
Wed Mar 15 16:30:58 EET 2017 | 0;255;3;0;9;TSF:MSG:FPAR REQ,ID=1
Wed Mar 15 16:30:58 EET 2017 | 0;255;3;0;9;TSF:PNG:SEND,TO=0
Wed Mar 15 16:30:58 EET 2017 | 0;255;3;0;9;TSF:CKU:OK
Wed Mar 15 16:30:59 EET 2017 | 0;255;3;0;9;TSF:MSG:GWL OK
Wed Mar 15 16:31:00 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
Wed Mar 15 16:31:01 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
Wed Mar 15 16:31:06 EET 2017 | 0;255;3;0;9;TSF:MSG:PINGED,ID=1,HP=1
Wed Mar 15 16:31:06 EET 2017 | 0;255;3;0;9;!TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=NACK:1
Wed Mar 15 16:31:06 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
Wed Mar 15 16:31:13 EET 2017 | 0;255;3;0;9;TSF:MSG:PINGED,ID=1,HP=1
Wed Mar 15 16:36:12 EET 2017 | 0;255;3;0;9;!TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=NACK:1
Wed Mar 15 16:46:12 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 16:46:12 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 16:51:14 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 17:06:15 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 17:06:16 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 17:06:16 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 17:21:19 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 17:26:18 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 17:26:19 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 17:36:21 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 17:46:21 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 17:46:22 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 17:51:23 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 18:06:24 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 18:06:25 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 18:06:26 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 18:21:28 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 18:26:27 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 18:26:28 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 18:36:31 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 18:46:31 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 18:46:32 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 18:51:33 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 19:06:34 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 19:06:35 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 19:06:35 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 19:21:38 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 19:26:37 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 19:26:38 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 19:36:40 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 19:37:04 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 19:37:04 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
Wed Mar 15 19:37:06 EET 2017 | 0;255;3;0;9;TSF:MSG:PINGED,ID=1,HP=1
Wed Mar 15 19:46:40 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=OK:1
Wed Mar 15 19:46:41 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 19:51:42 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 20:06:43 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 20:06:44 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 20:06:45 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 20:21:47 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 20:26:46 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 20:26:47 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 20:36:50 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 20:46:50 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 20:46:51 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 20:51:52 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 21:06:53 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 21:06:54 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 21:06:54 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 21:21:57 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 21:26:56 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 21:26:57 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 21:36:59 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 21:46:59 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 21:47:00 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 21:52:01 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 22:07:02 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 22:07:03 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 22:07:04 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 22:22:06 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 22:27:05 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 22:27:06 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 22:37:09 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 22:43:01 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 22:43:01 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=255,c=3,t=0,pt=1,l=1,sg=0:59
Wed Mar 15 22:43:03 EET 2017 | 1;255;3;0;0;59
Wed Mar 15 22:43:03 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=2,c=1,t=28,pt=0,l=9,sg=0:rssi: 17%
Wed Mar 15 22:43:05 EET 2017 | 1;2;1;0;28;rssi: 17%
Wed Mar 15 22:43:05 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=1,c=1,t=16,pt=1,l=1,sg=0:1
Wed Mar 15 22:47:09 EET 2017 | 1;1;1;0;16;1
Wed Mar 15 22:47:09 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 22:52:11 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 23:07:12 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 23:07:13 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 23:07:13 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 23:22:16 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 23:27:15 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 23:27:16 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 23:37:18 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Wed Mar 15 23:47:18 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Wed Mar 15 23:47:19 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Wed Mar 15 23:52:20 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 00:07:21 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 00:07:22 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 00:07:23 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 00:22:25 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 00:27:24 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 00:27:25 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 00:37:28 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 00:47:28 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 00:47:29 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 00:52:30 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 01:07:31 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 01:07:32 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 01:07:32 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 01:22:35 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 01:27:34 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 01:27:35 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 01:37:37 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 01:47:37 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 01:47:38 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 01:49:12 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 01:49:12 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=255,c=3,t=0,pt=1,l=1,sg=0:59
Thu Mar 16 01:49:14 EET 2017 | 1;255;3;0;0;59
Thu Mar 16 01:49:14 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=2,c=1,t=28,pt=0,l=9,sg=0:rssi: 17%
Thu Mar 16 01:49:16 EET 2017 | 1;2;1;0;28;rssi: 17%
Thu Mar 16 01:49:16 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=1,c=1,t=16,pt=1,l=1,sg=0:1
Thu Mar 16 01:52:39 EET 2017 | 1;1;1;0;16;1
Thu Mar 16 02:07:40 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 02:07:41 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 02:07:42 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 02:22:44 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 02:27:43 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 02:27:44 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 02:37:47 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 02:47:47 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 02:47:48 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 02:52:49 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 03:07:50 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 03:07:51 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 03:07:51 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 03:22:54 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 03:27:53 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 03:27:54 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 03:37:56 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 03:47:56 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 03:47:57 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 03:52:58 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 04:07:59 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 04:08:00 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 04:08:01 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 04:23:03 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 04:28:02 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 04:28:03 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 04:38:06 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 04:48:06 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 04:48:07 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 04:53:08 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 04:55:23 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 04:55:23 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
Thu Mar 16 04:55:23 EET 2017 | 0;255;3;0;9;TSF:MSG:BC
Thu Mar 16 04:55:23 EET 2017 | 0;255;3;0;9;TSF:MSG:FPAR REQ,ID=1
Thu Mar 16 04:55:23 EET 2017 | 0;255;3;0;9;TSF:PNG:SEND,TO=0
Thu Mar 16 04:55:23 EET 2017 | 0;255;3;0;9;TSF:CKU:OK
Thu Mar 16 04:55:25 EET 2017 | 0;255;3;0;9;TSF:MSG:GWL OK
Thu Mar 16 04:55:26 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
Thu Mar 16 04:55:26 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
Thu Mar 16 04:55:29 EET 2017 | 0;255;3;0;9;TSF:MSG:PINGED,ID=1,HP=1
Thu Mar 16 05:08:09 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=OK:1
Thu Mar 16 05:08:10 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 05:08:10 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 05:23:13 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 05:28:12 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 05:28:13 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 05:38:15 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 05:48:15 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 05:48:16 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 05:53:18 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 06:08:18 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 06:08:19 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 06:08:20 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 06:23:22 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 06:28:21 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 06:28:22 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 06:38:25 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 06:48:25 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 06:48:26 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 06:53:27 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 07:08:28 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 07:08:29 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 07:08:29 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 07:23:32 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 07:28:31 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 07:28:32 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 07:38:34 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 07:48:34 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 07:48:35 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 07:53:37 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 08:01:21 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 08:01:21 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=255,c=3,t=0,pt=1,l=1,sg=0:58
Thu Mar 16 08:01:23 EET 2017 | 1;255;3;0;0;58
Thu Mar 16 08:01:23 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=2,c=1,t=28,pt=0,l=8,sg=0:rssi: 6%
Thu Mar 16 08:01:25 EET 2017 | 1;2;1;0;28;rssi: 6%
Thu Mar 16 08:01:25 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=1,c=1,t=16,pt=1,l=1,sg=0:1
Thu Mar 16 08:08:37 EET 2017 | 1;1;1;0;16;1
Thu Mar 16 08:08:38 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 08:08:39 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 08:23:41 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 08:28:40 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 08:28:41 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 08:38:44 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 08:48:44 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 08:48:45 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 08:53:46 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 09:08:47 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 09:08:48 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 09:08:48 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 09:23:51 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 09:28:50 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 09:28:51 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 09:38:53 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 09:48:53 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 09:48:54 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 09:53:55 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 10:08:56 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 10:08:57 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 10:08:58 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 10:24:00 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 10:28:59 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 10:29:00 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 10:39:03 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 10:49:03 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 10:49:03 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 10:54:05 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 11:07:32 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 11:07:32 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=255,c=3,t=0,pt=1,l=1,sg=0:59
Thu Mar 16 11:07:34 EET 2017 | 1;255;3;0;0;59
Thu Mar 16 11:07:34 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=2,c=1,t=28,pt=0,l=8,sg=0:rssi: 6%
Thu Mar 16 11:07:36 EET 2017 | 1;2;1;0;28;rssi: 6%
Thu Mar 16 11:07:36 EET 2017 | 0;255;3;0;9;TSF:MSG:READ,1-1-0,s=1,c=1,t=16,pt=1,l=1,sg=0:1
Thu Mar 16 11:09:06 EET 2017 | 1;1;1;0;16;1
Thu Mar 16 11:09:07 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 11:09:07 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 11:24:10 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 11:29:09 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 11:29:10 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 11:39:12 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 11:49:12 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 11:49:13 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 11:54:14 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 12:09:15 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 12:09:16 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 12:09:17 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Thu Mar 16 12:24:19 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 12:29:18 EET 2017 | 0;255;3;0;9;TSF:SAN:OK
Thu Mar 16 12:29:19 EET 2017 | 0;255;3;0;9;TSM:READY:NWD REQ
Thu Mar 16 12:39:22 EET 2017 | 0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:

You'll notice there that there were three pairing events in the last 24h, which is not OK. Not sure exactly what "NWD REQ" means but there are also many such occurences. And judging from the battery percent graph, which puts a red dot on the graph every 3h, it's clear that many messages get lost.
Anyway, it may have to do with the gateway power supply but I'm still waiting for the 433MHz antennas and SMA connectors so that I can replace the current vanilla RFM96 module with the Adafruit RFM96 module.

They're an interesting option in special use cases. Eg. I mounted a sensor on my flat building janitor's storage room. I wanted to know if she comes daily as agreed and if so, how long does it take for her to clean the staircase. The RFM69 modules didn't worked so I switched to RFM96 which struggles to get the signal through 2 floors and on the other side of the building where I placed my gateway. And this while using RFM95_BW31_25CR48SF512. It works, but if I were at the 3rd floor, I'm sure it wouldn't have worked.
Next thing I want to monitor the status of the water pumps that are in a special room beneath ground and also on the opposite side of the building. And I'm pretty sure that the RFM95 will not make it there unless directional antennas or repeaters are involved.

Has anyone seen these modems in action?
Besides the known 433MHz and 868MHz, now the 169MHz band is accessible. This band is regulated in Europe at a maximum of 500mW and <=10% duty cycle beacons used generally for gas meters and similar quipments.
It can output 30dBm in 433MHz and 868MHz and 27dBm in 169MHz. This allows for even greater range but it uses up to 650mA during TX.

This is a very interesting module that comes in a larger footprint than the RFM9x but has a way greater TX power and makes the 169MHz band accessible and I think that once it hits the market and the RF engineers start to tinker and build Arduino libraries for it, it will become farily popular.

Well, this makes sense. And after all, if you're smart enough to tweak the lib and bypass the restrictions, chances are you know what you're doing both with the coding and with the radio spectrum.

I am ham radio licensed operator so I'm very much aware of the regulations. However we should not forget that this is an open band and as such no mission critical devices will run on these frequencies. FCC drafted these regulations to prevent some donkey to keep the channel closed by using 80-90% duty cycle and prevent all others from using it. However juding strictly from the MyS perspective, this is used by hobbyists and while many would put a dumb grim on their faces when using RFM95_BW125CR48SF4096 we should not forget that most of them work indoors, behind rebared walls and use poor antennas, so in real life there's really no impact on the band as their signal will not take off pretty far. And we can all agree that a when a Yagi is involved, those are most likely responsible experienced engineers who will know better than to block the band with their temperature sensors
I'm not condoning in any way the abuse on these bands, but all I'm saying that I see no reason for MyS to enforce these limits.

I don't think the library is FCC compliant
Now seriously, there's no reason for MySensors to enforce such limit as the user has full control over the duty cycles of his sensors and RFM network, it's up to the user to abide to these regulations. In fact, for the battery sensors nodes it's actually recommended to stick to that rule. With ** RFM95_BW31_25CR48SF512** taking about 1000ms for a TX and ** RFM95_BW125CR48SF4096** taking about 3000ms, you'll kill the battery pretty fast if you'll use short duty cycles. All my sensors nodes at home send their readings minutely, but the RFM95 node sends a beacon every 300s and whenever an interrupt fires it.

@Al85 For me it worked only by changing:

#define RFM95_RETRY_TIMEOUT_MS	(500ul)

to

#define RFM95_RETRY_TIMEOUT_MS	(2000ul)

in drivers/RFM95/RFM95.h. And then both RFM95_BW31_25CR48SF512 and RFM95_BW125CR48SF4096 worked just fine, although RFM95_BW125CR48SF4096 has a whooping ~3000ms TX time per packet so not very feasible for battery powered sensors, unless the poll cycle is set to a an absolute minimum or even better is based on interrupts, like a door sensor.

I just found this out yesterday but I can't recall exactly what value I changed. The only thing I do remember is that I change only one value, not two and then everything was fine.

I know it's a bit late but I just set up my RFM95 nodes and started playing. I did noticed something interesting when using RFM95_BW31_25CR48SF512 and RFM95_BW125CR48SF4096. The TX times are very long, about 6000ms long. Yet I think it's got something to do with packet retries.
The node reports an NACK status for each packet, however the gateway receives them just fine.

Hey there, with the 2.1.0 out now supporting LoRa I was wondering if anyone had the chance to test the modules. If so, I'd apreciate if you could share some quick facts on how did you got it up and running. Is it the same wiring as on RFM69? Could you please post example GatewaySerial and a sample node sketch so we can kickoff this?
I'll solder my RFM95's tomorrow and start tinker but with the recent experience with the RFM69 that took me a couple of days to figure out, I'd love to get a head start if anyone used them before.
Also, what range did you got out of them and under what conditions?

There are few who know that lots of asian compaines were producing SBC's long before RPi ever existed. RPi has to take credit for the SBC boom, but the connaisseurs will always prefer a top notch SBC that costs less than half of an RPi and is piled with features. Take the OPi Zero for instance, it's way smaller than RPi 3, has half the RAM and doesn't have Bluetooth. But you can buy 4 OPi Zeros with the money you'd spend on an RPi 3.
Anyway it's an endless debate here, I'm just glad I could help a bit bringing this to life, even though you and @marceloaqno did the heavy lifting.

Excellent work !!! It finally works, I believe the slight mistake was with the damn SPI device ID. Now that I've enabled /dev/spidev1.0 everything works perfect. Really nice job and awesome commitment to showing people that it's time for them to pull their heads out of their a.... and spend less for way more awesome boards because let's face it, RPi has the greatest community support but it's a nothing more than an expensive closed source crappy board.

I confirm it's not working on the OPi PC where TMRh20 works.

That I can not say.

@Reza I wouldn't even dream of not using Armbian on OrangePi and NanoPi. Compared to Raspbian it's years ahead in terms of optimization and tidyness. Armbian is the reason I'm avoiding RPi when possible. So go ahead and install a proper OS for your OPi. Not sure if Xenial or Debian, maybe we should wait for @marceloaqno to respond to my comment with the running OS.

@Reza Is it too complicated to switch to Debian?

@marceloaqno It still doesn't work on my OPi Zero

root@opi-zero-1:~/orangepi# bin/mysgw -d
mysgw: Starting gateway...
mysgw: Protocol version - 2.2.0-beta
mysgw: MCO:BGN:INIT GW,CP=RNNG---,VER=2.2.0-beta
mysgw: TSM:INIT
mysgw: TSF:WUR:MS=0
mysgw: !TSM:INIT:TSP FAIL
mysgw: TSM:FAIL:CNT=1
mysgw: TSM:FAIL:PDT
mysgw: Received SIGINT

I do have the /sys/class/gpio/export and I ran for A in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16; do echo "$A" > /sys/class/gpio/export ; done

For the record, here's my OS:

BOARD=orangepizero
BOARD_NAME="Orange Pi Zero"
VERSION=5.24
LINUXFAMILY=sun8i
BRANCH=default
ARCH=arm
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

@marceloaqno You were right, I wasn't using the correct branch. Your instructions though did not work for me

root@opi-pc-1:~# git clone https://github.com/marceloaqno/MySensors/tree/spidev marceloaqno-spidev
Cloning into 'marceloaqno-spidev'...
fatal: repository 'https://github.com/marceloaqno/MySensors/tree/spidev/' not found

Anyway, I found another way:

git clone https://github.com/marceloaqno/MySensors.git marceloaqno-spidev
cd marceloaqno-spidev/
git pull origin spidev
./configure
make

This time it compiled successfuly, but when I fired up mysgw all I got was:

mysgw: Starting gateway...
mysgw: Protocol version - 2.2.0-beta

with no other output.
Just to be sure we're on the same note, what is the wiring schematic I should use? When I first started to tinker with RF24 on OPi I found at least two wiring schematics.
For reference here's the gpio readall on my OPi PC:

 +-----+-----+----------+------+---+-Orange Pi+---+---+------+---------+-----+--+
 | BCM | wPi |   Name   | Mode | V | Physical | V | Mode | Name     | wPi | BCM |
 +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+
 |     |     |     3.3v |      |   |  1 || 2  |   |      | 5v       |     |     |
 |  12 |   8 |    SDA.0 | ALT5 | 0 |  3 || 4  |   |      | 5V       |     |     |
 |  11 |   9 |    SCL.0 | ALT5 | 0 |  5 || 6  |   |      | 0v       |     |     |
 |   6 |   7 |   GPIO.7 | ALT3 | 0 |  7 || 8  | 0 | ALT4 | TxD3     | 15  | 13  |
 |     |     |       0v |      |   |  9 || 10 | 0 | ALT4 | RxD3     | 16  | 14  |
 |   1 |   0 |     RxD2 | ALT5 | 0 | 11 || 12 | 0 | ALT3 | GPIO.1   | 1   | 110 |
 |   0 |   2 |     TxD2 | ALT5 | 1 | 13 || 14 |   |      | 0v       |     |     |
 |   3 |   3 |     CTS2 | ALT5 | 0 | 15 || 16 | 0 | ALT3 | GPIO.4   | 4   | 68  |
 |     |     |     3.3v |      |   | 17 || 18 | 0 | ALT3 | GPIO.5   | 5   | 71  |
 |  64 |  12 |     MOSI | ALT4 | 0 | 19 || 20 |   |      | 0v       |     |     |
 |  65 |  13 |     MISO | ALT4 | 0 | 21 || 22 | 0 | ALT5 | RTS2     | 6   | 2   |
 |  66 |  14 |     SCLK | ALT4 | 0 | 23 || 24 | 0 | ALT4 | CE0      | 10  | 67  |
 |     |     |       0v |      |   | 25 || 26 | 0 | ALT3 | GPIO.11  | 11  | 21  |
 |  19 |  30 |    SDA.1 | ALT4 | 0 | 27 || 28 | 0 | ALT4 | SCL.1    | 31  | 18  |
 |   7 |  21 |  GPIO.21 | ALT3 | 0 | 29 || 30 |   |      | 0v       |     |     |
 |   8 |  22 |  GPIO.22 | ALT3 | 0 | 31 || 32 | 0 | ALT5 | RTS1     | 26  | 200 |
 |   9 |  23 |  GPIO.23 |  OUT | 0 | 33 || 34 |   |      | 0v       |     |     |
 |  10 |  24 |  GPIO.24 |  OUT | 1 | 35 || 36 | 0 | ALT5 | CTS1     | 27  | 201 |
 |  20 |  25 |  GPIO.25 | ALT3 | 0 | 37 || 38 | 0 | ALT5 | TxD1     | 28  | 198 |
 |     |     |       0v |      |   | 39 || 40 | 0 | ALT5 | RxD1     | 29  | 199 |
 +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+
 | BCM | wPi |   Name   | Mode | V | Physical | V | Mode | Name     | wPi | BCM |
 +-----+-----+----------+------+---+-Orange Pi+---+------+----------+-----+-----+

@marceloaqno said:

@mihai-aldea Could you send the complete make and configure output so I can check if your system is correctly detected?

Here it is

root@opi-pc-1:~/rf24opi/MySensors# ./configure --soc=H3
[OK] init system detected: systemd
[SECTION] Saving configuration.
[SECTION] Cleaning previous builds.
[OK] Finished.
root@opi-pc-1:~/rf24opi/MySensors# make
gcc -MT build/drivers/Linux/log.o -MMD -MP -march=armv8-a -mtune=cortex-a53 -mfpu=neon-vfpv4 -mfloat-abi=hard -DMY_RADIO_NRF24 -DMY_GATEWAY_LINUX -DMY_DEBUG  -Ofast -g -Wall -Wextra  -I. -I./core -I./drivers/Linux -c drivers/Linux/log.c -o build/drivers/Linux/log.o
g++ -MT build/drivers/Linux/IPAddress.o -MMD -MP -march=armv8-a -mtune=cortex-a53 -mfpu=neon-vfpv4 -mfloat-abi=hard -DMY_RADIO_NRF24 -DMY_GATEWAY_LINUX -DMY_DEBUG  -Ofast -g -Wall -Wextra  -I. -I./core -I./drivers/Linux -c drivers/Linux/IPAddress.cpp -o build/drivers/Linux/IPAddress.o
g++ -MT build/drivers/Linux/noniso.o -MMD -MP -march=armv8-a -mtune=cortex-a53 -mfpu=neon-vfpv4 -mfloat-abi=hard -DMY_RADIO_NRF24 -DMY_GATEWAY_LINUX -DMY_DEBUG  -Ofast -g -Wall -Wextra  -I. -I./core -I./drivers/Linux -c drivers/Linux/noniso.cpp -o build/drivers/Linux/noniso.o
g++ -MT build/drivers/Linux/Print.o -MMD -MP -march=armv8-a -mtune=cortex-a53 -mfpu=neon-vfpv4 -mfloat-abi=hard -DMY_RADIO_NRF24 -DMY_GATEWAY_LINUX -DMY_DEBUG  -Ofast -g -Wall -Wextra  -I. -I./core -I./drivers/Linux -c drivers/Linux/Print.cpp -o build/drivers/Linux/Print.o
g++ -MT build/drivers/Linux/EthernetClient.o -MMD -MP -march=armv8-a -mtune=cortex-a53 -mfpu=neon-vfpv4 -mfloat-abi=hard -DMY_RADIO_NRF24 -DMY_GATEWAY_LINUX -DMY_DEBUG  -Ofast -g -Wall -Wextra  -I. -I./core -I./drivers/Linux -c drivers/Linux/EthernetClient.cpp -o build/drivers/Linux/EthernetClient.o
g++ -MT build/drivers/Linux/compatibility.o -MMD -MP -march=armv8-a -mtune=cortex-a53 -mfpu=neon-vfpv4 -mfloat-abi=hard -DMY_RADIO_NRF24 -DMY_GATEWAY_LINUX -DMY_DEBUG  -Ofast -g -Wall -Wextra  -I. -I./core -I./drivers/Linux -c drivers/Linux/compatibility.cpp -o build/drivers/Linux/compatibility.o
g++ -MT build/drivers/Linux/SerialPort.o -MMD -MP -march=armv8-a -mtune=cortex-a53 -mfpu=neon-vfpv4 -mfloat-abi=hard -DMY_RADIO_NRF24 -DMY_GATEWAY_LINUX -DMY_DEBUG  -Ofast -g -Wall -Wextra  -I. -I./core -I./drivers/Linux -c drivers/Linux/SerialPort.cpp -o build/drivers/Linux/SerialPort.o
g++ -MT build/drivers/Linux/Stream.o -MMD -MP -march=armv8-a -mtune=cortex-a53 -mfpu=neon-vfpv4 -mfloat-abi=hard -DMY_RADIO_NRF24 -DMY_GATEWAY_LINUX -DMY_DEBUG  -Ofast -g -Wall -Wextra  -I. -I./core -I./drivers/Linux -c drivers/Linux/Stream.cpp -o build/drivers/Linux/Stream.o
g++ -MT build/drivers/Linux/SoftEeprom.o -MMD -MP -march=armv8-a -mtune=cortex-a53 -mfpu=neon-vfpv4 -mfloat-abi=hard -DMY_RADIO_NRF24 -DMY_GATEWAY_LINUX -DMY_DEBUG  -Ofast -g -Wall -Wextra  -I. -I./core -I./drivers/Linux -c drivers/Linux/SoftEeprom.cpp -o build/drivers/Linux/SoftEeprom.o
g++ -MT build/drivers/Linux/EthernetServer.o -MMD -MP -march=armv8-a -mtune=cortex-a53 -mfpu=neon-vfpv4 -mfloat-abi=hard -DMY_RADIO_NRF24 -DMY_GATEWAY_LINUX -DMY_DEBUG  -Ofast -g -Wall -Wextra  -I. -I./core -I./drivers/Linux -c drivers/Linux/EthernetServer.cpp -o build/drivers/Linux/EthernetServer.o
g++ -MT build/examples_linux/mysgw.o -MMD -MP -march=armv8-a -mtune=cortex-a53 -mfpu=neon-vfpv4 -mfloat-abi=hard -DMY_RADIO_NRF24 -DMY_GATEWAY_LINUX -DMY_DEBUG  -Ofast -g -Wall -Wextra  -I. -I./core -I./drivers/Linux -c examples_linux/mysgw.cpp -o build/examples_linux/mysgw.o
In file included from examples_linux/mysgw.cpp:77:0:
./MySensors.h:258:2: error: #error No support for nRF24 radio on this platform
 #error No support for nRF24 radio on this platform
  ^
In file included from ./drivers/RF24/RF24.cpp:23:0,
                 from ./MySensors.h:294,
                 from examples_linux/mysgw.cpp:77:
./drivers/RF24/RF24.h:52:17: fatal error: SPI.h: No such file or directory
 #include <SPI.h>
                 ^
compilation terminated.
Makefile:98: recipe for target 'build/examples_linux/mysgw.o' failed
make: *** [build/examples_linux/mysgw.o] Error 1

@Tag Use this info:
http://linux-sunxi.org/Sunxi-tools
To export /boot/script.bin, edit the output file and enable SPI1, then compile it back and reboot your OPi with the SPI1 active.

If you haven't done this before, it's quite simple.

apt-get install sunxi-tools
cd ~
bin2fex /boot/script.bin > script.fex

Edit the script.fex file, find the [spi1] section and change spi_used = 0 to spi_used = 1. Save the file and exit.
Then

fex2bin script.fex > /boot/script.bin

Reboot, then you should have the SPI1 active.

@marceloaqno Here's the output:

./MySensors.h:258:2: error: #error No support for nRF24 radio on this platform
 #error No support for nRF24 radio on this platform
  ^
In file included from ./drivers/RF24/RF24.cpp:23:0,
                 from ./MySensors.h:294,
                 from examples_linux/mysgw.cpp:77:
./drivers/RF24/RF24.h:52:17: fatal error: SPI.h: No such file or directory
 #include <SPI.h>
                 ^
compilation terminated.
Makefile:98: recipe for target 'build/examples_linux/mysgw.o' failed
make: *** [build/examples_linux/mysgw.o] Error 1

If you used this wiring scheme:

nRF24L01 | Orange Pi
_________|________________
VCC      | VCC3V3-EXT
GND      | GND
CSN      | SPI0_CS0 (SPI-CE0)
CE       | PA7 (IO-7)
MOSI     | SPI0_MOSI (SPI-MOSI)
SCK      | SPI0_CLK (SPI-CLK)
MISO     | SPI0_MISO (SPI-MISO)

Then you should initialize the radio with:

RF24 radio(7,0);

Worked for me:

root@opi-pc-1:~/RF24-master/examples_linux# ./gettingstarted
RF24/examples/GettingStarted/
STATUS		 = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1	 = 0x65646f4e32 0x65646f4e31
RX_ADDR_P2-5	 = 0xc3 0xc4 0xc5 0xc6
TX_ADDR		 = 0x65646f4e32
RX_PW_P0-6	 = 0x20 0x20 0x00 0x00 0x00 0x00
EN_AA		 = 0x3f
EN_RXADDR	 = 0x02
RF_CH		 = 0x4c
RF_SETUP	 = 0x07
CONFIG		 = 0x0e
DYNPD/FEATURE	 = 0x00 0x00
Data Rate	 = 1MBPS
Model		 = nRF24L01+
CRC Length	 = 16 bits
PA Power	 = PA_MAX

 ************ Role Setup ***********
Choose a role: Enter 0 for pong_back, 1 for ping_out (CTRL+C to exit)

@Tag said:

Made some progress. first I created this table based on this page: http://linux-sunxi.org/GPIO

Pin - Num - Name - Calculated value
CE / 22 / PA02 / 482
SCK / 23 / PA14 / 494
MISO / 21 / PA16 / 496
CSN / 24 / PA13 / 493
MOSI / 19 / PA15 / 495

Are you sure this is correct?
The formula is: (position of letter in alphabet - 1) * 32 + pin number
For PA02 for instance the correct value is:
PA02 = (1 - 1) * 32 + 02 = 2

Actually you don't need to use the formula at all with the PA ports, all you have to do is use the trailing number.

@Tag I made the test setup and retraced my steps from the previous experiment. While the TMRh20 is working, the problem indeed lies with the ** mysgw** compilation. I'm getting the same error.
After spending quite some time trying to mitigate the errors I hit a wall and I concluded that the problem is not the different pin numbering but the mysgw source code. I believe the problem is the lack of support for this architecture and with MySensors being so complex and my C++ skills so average, I'm afraid I can't help.
However, if someone can mitigate the source code to successfully compile, the radio should be initialized with:
RF24 radio(7, 0);
7 - CE pin
0 - CS pin
More details here: https://github.com/TMRh20/RF24/issues/257

Thank you, but right now everything's working as expected. My only concern is that the tweak you told me about should not be so obscure but way more visible and easy to toggle.
I'd like to have the input of a senior developer of MySensors because I may be mistaking but if not I don't know why no one considered this yet.

Hey, it turns out that the fix is:

return RFM69_send(to, data, len, 0, 0);

Now I have a steady TX time, but the strange thing is that I'm still getting the RSSI reports. Anyway, since the RSSI is really voodoo right now, I will let it rest.
Thanks for your hint, it did the trick

No joy, it pops this error

/Documents/Arduino/libraries/Mysensors/core/MyTransportRFM69.cpp: In function 'bool transportSend(uint8_t, const void*, uint8_t)':
/Documents/Arduino/libraries/Mysensors/core/MyTransportRFM69.cpp:51:33: error: too few arguments to function 'bool RFM69_send(uint8_t, uint8_t*, uint8_t, rfm69_controlFlags_t, bool)'
  return RFM69_send(to, data, len);

@Fabien said:

I'm not agree with you. It will be better to user proper power supply on you gateway (not only 230V power supply but Arduino board with good 3.3V IC regulator (not from ali, ebay ...)

I won't argue about the quality of the components. However, as I mentioned before, using a good quality power supply will still not address the fact that MySensors is stubborn at exchanging ACK's and while this may not be an issue for battery powered nodes well within the gateway's range, the ones installed at the edge of the gateway coverage area (however optimized that would be) will still exhibit long awake cycles.
It's like an old local joke I heard a couple of years ago:
An very old lady living in the rural areas all her life had to travel by train. As this was the first train ride for her she was quite frightened and worried for her safety. She asked the train steward what is the most unsafe carriage of all. The guy said that he doesn't know, but she insisted. Just to get rid of her he said: OK, OK, the last carriage is the most unsafe. And she said: They why don't you remove it?
That may be a stupid joke, especially in translation, but it illustrates my problem. No matter what hardware I use, what awesome power supplies and antennas I use and how many square miles I cover with the RFM69 modules, the edge nodes will die way faster.

I will try your suggestion. Looks very promising.

@Tag Just to make it clear, do you want to connect the RF24 radio directly on the OPi's GPIO pins? Or do you want to connect it first to an Arduino and then to the OPi?
I haven't used the mysgw because so far I only played with EasyIoT (directly attached RF24 to RPi GPIO - doesn't work on OPi) and MyController (using an Arduino connected to the OPi's serial port).
Since MySensors is open source you can definitely change the pin numbers to match the OPI's Sunxi pin numbering. I don't have a setup in place right now to point you in the exact direction but will cook one tomorrow and get back with the details.
Meanwhile you can burn the GatewaySerial sketch on your Arduino and either use /bin/mysgw or:

apt-get -y update
apt-get -y install minicom
minicom -D /dev/ttyUSB0

It's likely that the minicom will scramble the text on your screen but you can:

Ctrl+Z
O
Screen and Keyboard
T
Esc
Save setup as df1

Close the minicom window then open it again and all should be fine.

@scalz said:

in future rfm69 driver, you'll be able to get :

• rssi of a received packet, so on receiving node side.

Just to make it clear, the "receiving node" is the gateway, right?

• rssi of a response, at the sending side.

This is pretty much what happens now, the sensor node couldn't report the RSSI for anything else than the ACK that the gateway sends back to it.

There must be good reason for which MySensors relies on these ACK packets but in my opinion this feature should only be used when needed, eg.: arming a motion sensor, turning off the heating or a switch a relay. But let's face it, is it really necessary for a temperature sensor node to make sure that its message was properly received by the gateway? There are lots of frontends who report an offline node if a flat graph line isn't enough.

@Fabien said:

Wich gateway you use ?

I'm using the serial gateway, nothing special about it.

It seems like node doens't recieve harware ACK from gateway.

Hence the reason of opening this discussion. Is this ACK really needed? If not, can it be disabled?

You have hardware ACK if i remember and 5 tries. So it's longer because of retries.

That's something I never heard of so far. But if I didn't hear it, it doesn't mean you're right. Are you absolutely sure that the RFM69 has embedded ACK capabilities? I haven't found this info in the datasheet.

You loose 1 packet because all retries fails.
I suppose power supply on gateway radio is not sufficient. I have same problem with UNO and NodeMCU gateway with internal regulator.

I must admit that I'm not using the greatest power supply on the gateway radio, but if there weren't no ACK's requested from the sensor node and it would just send the data "blindly" into the open, the gateway's power supply wouldn't be an issue. And the sensor node power supply is defintely not the culprit since it's powered by a bulky 18650 fully charged Li-Ion battery.

This all behaviour only means that each sensor node report also requests an ACK from the gateway. And my question is: how do I disable this, if possible? Installing a better antenna or a better power supply on the gateway will not cut it. Because there will always be some sensor nodes at the edge of the coverage area and if they'll ask for an ACK each time they send a reading, they will drain their batteries a whole lot faster than the nodes closer to the gateway.

It doesn't appear to work. Here's what I did:

send(msgTemp.set(temp,2),false);
send(msgRh.set(rh,2),false);
send(msgRSSI.set(rssiStr),false);
send(msgTime.set(txTime/1000),false);
sendBatteryLevel(battPcnt,false);

Here's a regular cycle:

4141 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:27.58
4200 TSF:MSG:SEND,3-3-0-0,s=2,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=OK:44.00
4241 TSF:MSG:SEND,3-3-0-0,s=3,c=1,t=28,pt=0,l=9,sg=0,ft=0,st=OK:rssi: 52%
4280 TSF:MSG:SEND,3-3-0-0,s=3,c=1,t=48,pt=5,l=4,sg=0,ft=0,st=OK:244
4315 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=0,pt=1,l=1,sg=0,ft=0,st=OK:100
Time awake: 244ms

and here's one that's taking way too long

4419 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:27.58
4601 TSF:MSG:SEND,3-3-0-0,s=2,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=OK:43.98
5007 !TSF:MSG:SEND,3-3-0-0,s=3,c=1,t=28,pt=0,l=9,sg=0,ft=0,st=NACK:rssi: 52%
5044 TSF:MSG:SEND,3-3-0-0,s=3,c=1,t=48,pt=5,l=4,sg=0,ft=1,st=OK:760
5079 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=0,pt=1,l=1,sg=0,ft=0,st=OK:100
Time awake: 760ms

Notice the NACK?

EDIT: The result above is from after I applied the suggested mods.

@Tag The RF24 won't work on the OPi out of the box. Since the GPIO numbering is different it will work but only after some tweaks. I'm not sure if you're familiar with:
http://linux-sunxi.org/GPIO
Once you get the pin numbering figured out you can use the TMRh20 library. I confirm that it works on my OPi PC. Didn't unboxed my OPi Zero yet
However it's not very clear what sort of gateway you're trying to build. My project will have an OPi Zero running MyController, hooked up to an ATmega328 running the GatewaySerial sketch. The radio will be be connected to the ATmega328 chip. This way I wouldn't have to worry about GPIO pin numbering.

@fleinze said:

I put the arduino to sleep during the conversion time, so this is not a big issue. But I agree that the DS18B20 is not the best, but it is widely available. For newer nodes I try to use the Si7021 where possible.

It goes without saying that the nodes are in sleep mode between reports. However, the conversion time has a great impact in the cycle math. I won't say that pulling the readings 10 times faster will give you 10 times more time on battery but if you'll get 5 times more time then it's something. Not to mention that the Si7021 works down to 1.9V unlike the DS18B20+ which works down to only 3.0V.

I am using stoltz's fork it it looks that the references above are not availble. Anyway, the RSSI should be implemented at the gateway level. Else, a node may read this value but only in response to an incoming packet and that implies a longer duty cycle.

The DS18B20+ is not a great sensor for the battery powered nodes. It has a huge conversion time comparing to others.
9-bit resolution | 93.75 ms | 0.5°C
10-bit resolution | 187.5 ms | 0.25°C
11-bit resolution | 375 ms | 0.125°C
12-bit resolution | 750 ms | 0.0625°C
The last column is the sensor's precision. So unless you're OK with a 0.5°C steps, the simple usage of DS18B20+ will kill your battery a lot faster.
Don't use DHT22, that one is very slow too. BME280 does have a barometric pressure sensor but it's not very fast either.
The best sensor for battery powered nodes is the the Si7021 which is rather old, but is the fastest.

I'm currently testing some RFM69 sensors.
I added a few lines of codes to count the temperature conversion + TX time, just to see the impact of various settings over the awake cycle and to properly adjust them for battery usage.
One of the test nodes is a battery powered Adafruit Feather which I left in the same room with the gateway that I hooked up to an 18650 Li-Ion battery and used the Feather's internal charge controller and battery protection circuit for these experiments.
After a couple of days, the battery was at a constant 85%. Then I moved it to the other end of my apartment with 4 brick walls between the node and the gateway. I also added a visual "probe" to the sketch, that's keeping the board's led lit while performing the loop tasks. I noticed that in the distant corner of my apartment the led was lit for a lot more time than in the same room with the gateway.
Needless to say that with these very long duty cycles the battery drained within 2 days. It's taking the node about 250ms to send the data to the gateway when in the same room and 750-1000ms to send it while being in the distant room.
I haven't found any accurate information on whether the ACK can be enabled or disabled, if so then what's the default setting. And does it serve any special purpose like RSSI reporting which if used it automatically enables the ACK?
The thing is that RSSI = Received Signal Strength Indicator and if the sensor node can read this value, it's obvious that it's reporting a received signal strength. And what else can the sensor receive from the gateway on a regular basis if not an ACK?

The onboard temperature sensor is not a cool freebie. It's meant to be a way to check the approximate environmental temperature for the outdoor or industrial devices (not only sensor nodes) using RFM69.

This is perfectly understandable but I merely wanted to give a raw input on the feature status.
I consider the RSSI values to be paramount when testing MySensors along with new hardware (antennas, wall penetration, registry tweaks etc.) as the simple online/offline node status would not help very much with these scenarios. That's why for the time being I will stick to scalz's rfm69_update2.

@hek I confirm that the RSSI support works perfect in scalz's fork.

@hek Have you considered using the Seeedstudio PCB assembly service? I haven't tried this service as all my PCB's are using old school PTH. But will try them at some point. It says that "Assembly Fee Starts from $25" but there's no mention whether it's a flat fee or it includes some components assembly. The pricing information is rather fuzzy and I wasn't needing the service for time being anyway so I didn't ask.

@scalz Just to make it clear. The RFM69 RSSI value is not available in the official MySensors 2.1.0 release but it is available in your GitHub fork here: https://github.com/scalz/Mysensors/tree/rfm69_update2. Is that correct?

@scalz said:

But if i need more PIR only, or temp/hum only... it's also possible. So i don't need to have a dedicated pcb per use. I stencil only what i need

Yeah, makes sense, a modular sensor PCB, a more advanced version than my Si7021 / DS18B20+ or PIR / door-window PCBs.

@scalz Awesome board, really. However, I'm a bit worried about its practical use. You see, the motion sensors are commonly placed near the ceiling or sometimes on the ceiling. This may induce a serious drift in the reported temperature. Ideally, a temperature sensor should be placed in the middle of the wall.
Some people would have the impression that they're wasting energy on heating during winter while others would boost their A/C units during the summer just to read they temperature they feel confortable with. This effect would be mitigate by either concealing the motion sensor at a proper height for temperature reading, or use a reference sensor for calibration and compensate the reported value of an improperly placed sensor, and that's assuming that the seasonal variation is linear.
Anyway, excellent SMD work, I'm still in the PTH ice age

@rmtucker said:

Has Rssi been added to mysensors 2.1 ?

Yes. You can pull it using transportGetRSSI(). From there on, use it just as it is or shape it more nicely with a map() function, it's up to you. But please note that 2.1.0 brings some slight changes so if your sketch throws some errors, just read them and change your sketch accordingly. Eg. #define MY_RF69_FREQUENCY RFM69_433MHZ is replaced by #define MY_RFM69_FREQUENCY RFM69_433MHZ, notice the extra "M".

@Christoph-Blank said:

well - the blog post I used for the wiring missed the detail that the RFM69 does not seem to be 5V tolerant (inputs).

Can anyone tell me:

a) if it is damaged if the inputs had 5V
b) how I can adjust the levels, can I do this with resistors or do I need more?

I made the same mistake, while connecting the modules VIN pin to the Arduino's 3.3V rail, I failed to read that the RFM69's pins aren't 5V tolerant. After I figured out how to make another pair of RFM69 modules work together, this time at the correct voltage, I tried the first to if they were fried. They weren't. As soon as I connected them to a 3.3V Arduino they worked like a charm. So it's very likely that yours are fine to.
As for the correct wiring, some are using voltage dividers to lower the signal pins voltage down to 3.3V. Others are using logic level converters. Me, I was lucky engough to have a couple of chinese 3.3V Arduino Pro Mini boards ordered a long time ago and never used since. For minimal clutter, I'd suggest using the same setup. The cheapest 3.3V options are the Arduino Pro Mini (my model) but you'll also need some USB to TTL dongles (the ones having a DTR pin) to program them. Or you may use something like:
http://www.ebay.com/itm/Pro-Micro-3-3V-8M-5V-16M-atmega328-Replace-ATmega128-Arduino-Compatible-Nano-/172446438226
but notice that this one doesn't use the ATmega328 chip but ATmega32U4 and that will require these lines of code at the top of your sketches:
For MySensors 2.0

#define MY_RF69_SPI_CS 8
#define MY_RF69_IRQ_PIN 7
#define MY_RF69_IRQ_NUM 4

For MySensors 2.1.0beta (RSSI report added amongst a lot of other improvements)

#define MY_RFM69_SPI_CS 8
#define MY_RFM69_IRQ_PIN 7
#define MY_RFM69_IRQ_NUM 4

Note the slight difference between the two.

@mfalkvidd Thank you for pointing me to those resources, I finally got them working.
@scalz Absolutely awesome work

Here's a full sketch example using the Si7021 Temp/RH sensor:

#define MY_NODE_ID 2
#define MY_DEBUG
#define MY_RADIO_RFM69
#define MY_RFM69_FREQUENCY RFM69_433MHZ
#define MY_IS_RFM69HW 
#define MY_RFM69_NETWORKID 100

#include <MySensors.h>  
#include <SPI.h>
#include <Wire.h>
#include "Adafruit_Si7021.h"
unsigned long SLEEP_TIME = 1000;
Adafruit_Si7021 sensor = Adafruit_Si7021();
MyMessage msgTemp(1, V_TEMP);
MyMessage msgRh(2, V_HUM);
MyMessage msgRSSI(3,V_VAR5);
float temp;
float rh;
boolean requestACK = false;
int16_t rssiVal
char rssiStr[10];

void setup()  
{  
  delay(100);
  sendSketchInfo("Temperature/RH Sensor N2 RFM69", "1.1");
  sensor.begin();
  present(1, S_TEMP);
  present(2, S_HUM);
}

void loop() {
  rssiVal = transportGetRSSI();
  rh = sensor.readHumidity();
  temp = sensor.readTemperature();
  snprintf(rssiStr,10,"rssi: %d%",rssiVal);
  send(msgTemp.set(temp,2));
  send(msgRh.set(rh,2));
  send(msgRSSI.set(rssiStr));
  sleep(SLEEP_TIME);
}

However, please note that this only works on:
https://github.com/scalz/Mysensors/tree/rfm69_update2
and
http://forum.mycontroller.org/topic/58/download-snapshot-build
Just drop a reply here and I will happily assist you using the above versions until they will be fully commited.

Is there any way for a gateway to read the RSSI value of the remote RFM69 based sensors? RSSI reporting is already available in the driver library, however I can only see RSSI reports when using the libraries Struct_send/Struct_receive example sketches. I tried to trick the sketch to report it, yet unsuccessfull. There are some tweaks for the RF24 networks yet they're not actually RSSI reports but rather transport reliability metrics counting failed against sent packets. But since RFM69 natively supports RSSI and the functions are already there, I believe that it's very simple for someone who knows the arhitecture inside out to add some #define MY_RFM69_RSSI option available to the gateway sketch.
But meanwhile I wouldn't mind any suggestion as to how could I access the RFM69 library RFM69::readRSSI function and get the values in any form. It would help me a great deal to test various antennas, bitrates, range and penetration for the RFM69 modules.
RSSI reports of the ACK packets sent back from the gateway would be great too in order to have a clear picture of the two-way communication but let's take it one step at a time

@mfalkvidd I will definitely do that. I'll tinker with them for a while just to be confortable with stating the facts and I will compile such a guide. It'll take me no more than a couple of days.

I believe this one is on me. It wasn't clear to me that MySensors is actually wrapper of the original LowPowerLab's RFM69 lib and you can't mix #define's from MySensors and the embedded RFM69 driver.
MySensors is really plug&play if you're using the NRF24L01+ modules, follow the guides, upload the sketches and fire up the gateway, but if you want to use RFM69, I at least, needed some serious trial and error.
Maybe it's just my hectic style of trying new setups, or maybe because I found no concise guide on how to switch from RF24 to RFM69 or maybe something in between

No need to stick to the expensive Raspberry Pi board. MyCotroller runs perfect on my 1GB RAM quad core Orange Pi PC ($15) and I see no reason it wouldn't work on the 512MB RAM quad core, with ethernet and WLAN already on board Orange Pi Zero ($9), which can be purchased in quantities of more than one per household and, shockingly, is actually available...
Nano Pi also manufactures great boards but they tend cost double than OPi, actually getting close to the Raspberry Pi's price tag.
The only difficulty I had with deploying MyController on these boards was installing Java 1.8 which isn't currently available in the apt repos.
I'm in no way affiliated with any producer, only a happy user of Orange Pi & Nano Pi, powered by the super polished Armbian.

It seems that adding:

#define MY_PARENT_NODE_IS_STATIC

is of some help, however I did noticed a large increase in TX time even though i set

boolean requestACK = false;

So the whole protocol appears to resemble more with TCP rather than UDP. All things considered I believe the remote battery powered nodes should be able to successfully recover from a temporarily gateway failure without increasing their TX time substantially. The TNR state is excellent when it comes to TX time during gateway failure but it misses a mechanism to automatically recover from this state once the gateway is back. ** MY_PARENT_NODE_IS_STATIC** allows for recovery but at the expense if doubling the TX time. So in production you either manually reset all sensor nodes after a gateway failure, or you take immediate action to minimize the impact on the sensors batteries.

For those of you having difficulties making the Feather work with MySensors, please note that Adafruit doesn't use the standard wiring.
In order to make it work, right at the top of your sketch, before loading the libraries, you should add this:

#define MY_RF69_SPI_CS 8
#define MY_RF69_IRQ_PIN 7
#define MY_RF69_IRQ_NUM 4

I have a test setup comprised of two 3.3V Arduino Pro Minis, each hooked to an RFM69HW 433MHz module.
I configured the Temp/RH node to send the readings every second to the gateway. All works fine until either I reset the gateway, or some hickup occurs and then the remote node stops sending messages even if I reset the gateway, or reinstall its sketch. Looks like if it can't reach the gateway it enters some fault mode and stays there until I reset it.

Here's the node's sketch

#define MY_NODE_ID 2
#define MY_DEBUG
#define MY_RADIO_RFM69
#define MY_RFM69_FREQUENCY   RF69_433MHZ
#define MY_IS_RFM69HW 
#define MY_RFM69_NETWORKID     100

#include <MySensors.h>  
#include <SPI.h>
#include <Wire.h>
#include "Adafruit_Si7021.h"

#define COMPARE_TEMP 0
unsigned long SLEEP_TIME = 1000;
Adafruit_Si7021 sensor = Adafruit_Si7021();
MyMessage msgTemp(1, V_TEMP);
MyMessage msgRh(2, V_HUM);
float lastTemp;
float lastRh;
boolean requestACK = false;

void setup()  
{  
  delay(100);
  sendSketchInfo("Temperature/RH Sensor N1 RFM69", "1.1");
  sensor.begin();
  present(1, S_TEMP);
  present(2, S_HUM);
}

void loop() {
  unsigned long startTime = micros();
  lastRh = sensor.readHumidity();
  lastTemp = sensor.readTemperature();
  send(msgTemp.set(lastTemp,2));
  send(msgRh.set(lastRh,2)); 
  unsigned long endTime = micros();
  unsigned long txTime = endTime - startTime;
  Serial.print("Time awake: "); Serial.print(txTime/1000); Serial.println("ms");
  sleep(SLEEP_TIME);
}

And here's the gateway sketch

  /**
 * The MySensors Arduino library handles the wireless radio link and protocol
 * between your home built sensors/actuators and HA controller of choice.
 * The sensors forms a self healing radio network with optional repeaters. Each
 * repeater and gateway builds a routing tables in EEPROM which keeps track of the
 * network topology allowing messages to be routed to nodes.
 *
 * Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
 * Copyright (C) 2013-2015 Sensnology AB
 * Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
 *
 * Documentation: http://www.mysensors.org
 * Support Forum: http://forum.mysensors.org
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * version 2 as published by the Free Software Foundation.
 *
 *******************************
 *
 * DESCRIPTION
 * The ArduinoGateway prints data received from sensors on the serial link. 
 * The gateway accepts input on seral which will be sent out on radio network.
 *
 * The GW code is designed for Arduino Nano 328p / 16MHz
 *
 * Wire connections (OPTIONAL):
 * - Inclusion button should be connected between digital pin 3 and GND  
 * - RX/TX/ERR leds need to be connected between +5V (anode) and digital pin 6/5/4 with resistor 270-330R in a series
 *
 * LEDs (OPTIONAL):
 * - To use the feature, uncomment MY_LEDS_BLINKING_FEATURE in MyConfig.h
 * - RX (green) - blink fast on radio message recieved. In inclusion mode will blink fast only on presentation recieved
 * - TX (yellow) - blink fast on radio message transmitted. In inclusion mode will blink slowly
 * - ERR (red) - fast blink on error during transmission error or recieve crc error 
 * 
 */

// Enable debug prints to serial monitor
#define MY_DEBUG 


// Enable and select radio type attached
//#define MY_RADIO_NRF24
#define MY_RADIO_RFM69
#define MY_RFM69_FREQUENCY   RF69_433MHZ
#define MY_IS_RFM69HW 
#define MY_RFM69_NETWORKID     100

// 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. 
#define MY_RF24_PA_LEVEL RF24_PA_LOW

// Enable serial gateway
#define MY_GATEWAY_SERIAL

// Define a lower baud rate for Arduino's running on 8 MHz (Arduino Pro Mini 3.3V & SenseBender)
#if F_CPU == 8000000L
#define MY_BAUD_RATE 38400
#endif

// Flash leds on rx/tx/err
#define MY_LEDS_BLINKING_FEATURE
// Set blinking period
#define MY_DEFAULT_LED_BLINK_PERIOD 300

// Inverses the behavior of leds
//#define MY_WITH_LEDS_BLINKING_INVERSE

// Enable inclusion mode
#define MY_INCLUSION_MODE_FEATURE
// Enable Inclusion mode button on gateway
#define MY_INCLUSION_BUTTON_FEATURE

// Inverses behavior of inclusion button (if using external pullup)
#define MY_INCLUSION_BUTTON_EXTERNAL_PULLUP

// Set inclusion mode duration (in seconds)
#define MY_INCLUSION_MODE_DURATION 60 
// Digital pin used for inclusion mode button
#define MY_INCLUSION_MODE_BUTTON_PIN  3 

// Uncomment to override default HW configurations
//#define MY_DEFAULT_ERR_LED_PIN 4  // Error led pin
//#define MY_DEFAULT_RX_LED_PIN  6  // Receive led pin
//#define MY_DEFAULT_TX_LED_PIN  5  // the PCB, on board LED

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

bool promiscuousMode = true;

void setup() { 
  // Setup locally attached sensors
}

void presentation() {
 // Present locally attached sensors 
}

void loop() { 
  // Send locally attached sensor data here 
}

The libraries are untouched and I'm using Arduino IDE 1.6.13 with the AVR Boards version 1.6.15.
Here's what happens to the node when I reset the gateway:

Starting sensor (RRNNA-, 2.0.0)
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=2)
TSM:FPAR
TSP:MSG:SEND 2-2-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-2 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=2)
TSM:UPL
TSP:PING:SEND (dest=0)
TSP:MSG:SEND 2-2-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:READ 0-0-2 s=255,c=3,t=25,pt=1,l=1,sg=0:1
TSP:MSG:PONG RECV (hops=1)
TSP:CHKUPL:OK
TSM:UPL:OK
TSM:READY
TSP:MSG:SEND 2-2-0-0 s=255,c=3,t=11,pt=0,l=25,sg=0,ft=0,st=ok:Temperature/RH Sensor N1 
TSP:MSG:SEND 2-2-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=ok:1.1
TSP:MSG:SEND 2-2-0-0 s=1,c=0,t=6,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 2-2-0-0 s=2,c=0,t=7,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 2-2-0-0 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=ok:0100
!TSP:MSG:SEND 2-2-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=fail:2.0.0
TSP:MSG:SEND 2-2-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,ft=1,st=ok:0
Request registration...
TSP:MSG:SEND 2-2-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=ok:2
TSP:MSG:READ 0-0-2 s=255,c=3,t=27,pt=1,l=1,sg=0:1
Node registration=1
Init complete, id=2, parent=0, distance=1, registration=1
TSP:MSG:SEND 2-2-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=ok:23.40
TSP:MSG:SEND 2-2-0-0 s=2,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=ok:41.47
Time awake: 128ms
TSP:MSG:SEND 2-2-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=ok:23.39
TSP:MSG:SEND 2-2-0-0 s=2,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=ok:41.44
Time awake: 126ms
TSP:MSG:SEND 2-2-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=ok:23.40
TSP:MSG:SEND 2-2-0-0 s=2,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=ok:41.46
Time awake: 128ms
TSP:MSG:SEND 2-2-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=ok:23.40
TSP:MSG:SEND 2-2-0-0 s=2,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=ok:41.45
Time awake: 126ms
TSP:MSG:SEND 2-2-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=ok:23.41
TSP:MSG:SEND 2-2-0-0 s=2,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=ok:41.47
Time awake: 170ms
TSP:MSG:SEND 2-2-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=ok:23.41
TSP:MSG:SEND 2-2-0-0 s=2,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=ok:41.47
Time awake: 168ms
TSP:MSG:SEND 2-2-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=ok:23.39
!TSP:MSG:SEND 2-2-0-0 s=2,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=fail:41.45
Time awake: 300ms
TSP:MSG:SEND 2-2-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=1,st=ok:23.39
TSP:MSG:SEND 2-2-0-0 s=2,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=ok:41.47
Time awake: 147ms
TSP:MSG:SEND 2-2-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=ok:23.40
TSP:MSG:SEND 2-2-0-0 s=2,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=ok:41.47
Time awake: 157ms
TSP:MSG:SEND 2-2-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=ok:23.40
TSP:MSG:SEND 2-2-0-0 s=2,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=ok:41.47
Time awake: 183ms
!TSP:MSG:SEND 2-2-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=fail:23.40
!TSP:MSG:SEND 2-2-0-0 s=2,c=1,t=1,pt=7,l=5,sg=0,ft=1,st=fail:41.45
Time awake: 333ms
!TSP:MSG:SEND 2-2-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=2,st=fail:23.40
!TSP:MSG:SEND 2-2-0-0 s=2,c=1,t=1,pt=7,l=5,sg=0,ft=3,st=fail:41.45
Time awake: 335ms
!TSP:MSG:SEND 2-2-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=4,st=fail:23.39
!TSP:MSG:SEND 2-2-0-0 s=2,c=1,t=1,pt=7,l=5,sg=0,ft=5,st=fail:41.46
Time awake: 335ms
!TSM:UPL FAIL, SNP
TSM:FPAR
TSP:MSG:SEND 2-2-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
!TSP:SEND:TNR
Time awake: 54ms
!TSP:SEND:TNR
!TSP:SEND:TNR
Time awake: 54ms
!TSP:SEND:TNR
!TSP:SEND:TNR
Time awake: 54ms
!TSP:SEND:TNR
!TSP:SEND:TNR
Time awake: 54ms
!TSP:SEND:TNR
!TSP:SEND:TNR
Time awake: 54ms
!TSP:SEND:TNR
!TSP:SEND:TNR
Time awake: 54ms
!TSP:SEND:TNR
!TSP:SEND:TNR
Time awake: 54ms
!TSP:SEND:TNR
!TSP:SEND:TNR

I don't even know what's the meaning TSP and TNR.

Souds great. I took a short pause because believe it or not, I was back to square one with the issues. A couple of days and one Adafruit Feather RFM69 plus one Sparkfun RFM69HCW breakout board later I still have no conclusion to what leads to the problems, at first I thought of bypassing the MySensor's directive and call the RFM69 drivers directly. It worked until it didn't, with no explanation whatsoever.
So I started from a couple of sketches I knew worked and slowly build up the correct configuration that's now working (partly but more on that in a separate topic). The most useful debug tool was an RTL-SDR stick so I could actually hear the nodes whisper
So, it appears that in order to use the 433/868/915 W/HW modules with MySensors, it's best to add theses at the top of your sketches:

// Select the RFM69 radio type
#define MY_RADIO_RFM69
// Enter your model's frequency
#define MY_RFM69_FREQUENCY RF69_433MHZ
// If you're using RFM69HW / RFM69HCW modules, they won't work until this is set.
// Leave it commented for the normal power modules.
#define MY_IS_RFM69HW
// Your network ID
#define MY_RFM69_NETWORKID 100

The library is pretty much preconfigured for RF24 so using the RFM69 modules is possible but with a bit of trial and error until all things are set.

Is the new driver a fork of some other or you're building it from scratch?
One suggestion though: If it's aiming to provide excellent support for the battery powered nodes, it would be great if you'd expose some of the advanced settings that allow faster TX times. I'm currently testing the awake cycle time aiming for the lowest possible values. For instance I chose the fast Si7021 instead of the slooooow DHT22. This one is supposed to have a total converesion time of 22.8ms but the fastest working library is Adafruit's which pulls the maximum resolution values within 50-55ms. But on top of that, the TX time takes another 70ms with the current driver. That means a total of ~125ms (with ack disabled).
125ms isn't bad. But maybe one would come to the conclusion that they'd want to trade range or bandwidth for TX speed (not bitrate). I'm not talking about the bulky 2xAA battery packs or large lithium cells users but the ones who'd put a CR2032 coin battery inside of a door sensor for instance and expect it to last at least a year.

@scalz said:

@mihai-aldea
that's why it's always better to tell which hardware you're using, and logs. If i knew you were using 5v logic, i would have told you it couldn't work, and save time

About promiscuous mode, you can think about it as a sniffer mode.

Great to hear you finally found your answer

Yeah, I know I was a bit of a jackass for not reverting back whatever I was doing and provide you with logs from the MySensors lib. But I used lots of libs, some of them with various tweaks, the test setup was bit complicated and I knew that whatever logs I could see during the initial stages were not very helpful.
And speaking of helpful logs. I would've loved to see more verbose logs. Is there a way to increase the verbosity level?
As for the promisc mode, I know very well that that is, is just that it seemed strange how is it that the node ID's were all messed up.

@executivul said:

RFM69HW can not work with PA disabled, you must use radio.setHighPower(), otherwise unpredictable results may occur.
try spacing them at least 1 meter apart and use radio.setPowerLevel(0) instead.

While RFM69W has only PA0 installed, RFM69HW doesn't have it but has PA1 and PA2. So I'm not sure if there's a problem with enablin PA0 on the HW version but I left it disabled anyway. After trying with the fresh new models, I was too far with my experiments, and drifted a lot from the standard libraries config. So obviously they weren't working. But with with a back to basics approach, I got them to work. I'm not sure what their range is because I haven't had time to make a field test, but the HW's work just fine with all PA's disabled and with a couple of brick walls between.
So guys, thank you very much for your support, but my conclusion is that the first modules weren't working because I was applying them with 5V logic. I will check them and see if they're damaged or work fine with the proper 3.3V.
Since I got them to work, I did found a couple of problems but that's another topic which I'll open as soon as I'll get a consistent conclusion and a replicable scenario.

Well, here's some new developments. I used the Struct_send and Send_receive examples from LPL RFM69 lib.

Struct_send

#define RF_PALEVEL_PA0_OFF
#define RF_PALEVEL_PA1_ON
#define RF_PALEVEL_PA2_OFF

#include <RFM69.h>
#include <SPI.h>
#include <SPIFlash.h>

#define NODEID      99
#define NETWORKID   100
#define GATEWAYID   1
#define FREQUENCY   RF69_433MHZ //Match this with the version of your Moteino! (others: RF69_433MHZ, RF69_868MHZ)
#define KEY         "sampleEncryptKey" //has to be same 16 characters/bytes on all nodes, not more not less!
#define LED         13
#define SERIAL_BAUD 115200
#define ACK_TIME    30  // # of ms to wait for an ack

int TRANSMITPERIOD = 1000; //transmit a packet to gateway so often (in ms)
byte sendSize=0;
boolean requestACK = true;
SPIFlash flash(8, 0xEF30); //EF40 for 16mbit windbond chip
RFM69 radio;

typedef struct {
  int           nodeId; //store this nodeId
  unsigned long uptime; //uptime in ms
  float         temp;   //temperature maybe?
} Payload;
Payload theData;

void setup() {
  Serial.begin(SERIAL_BAUD);
  radio.initialize(FREQUENCY,NODEID,NETWORKID);
  //radio.setHighPower(); //uncomment only for RFM69HW!
  radio.encrypt(KEY);
  char buff[50];
  sprintf(buff, "\nTransmitting at %d Mhz...", FREQUENCY==RF69_433MHZ ? 433 : FREQUENCY==RF69_868MHZ ? 868 : 915);
  Serial.println(buff);
  
  if (flash.initialize())
    Serial.println("SPI Flash Init OK!");
  else
    Serial.println("SPI Flash Init FAIL! (is chip present?)");
}

long lastPeriod = -1;
void loop() {
  //process any serial input
  if (Serial.available() > 0)
  {
    char input = Serial.read();
    if (input >= 48 && input <= 57) //[0,9]
    {
      TRANSMITPERIOD = 100 * (input-48);
      if (TRANSMITPERIOD == 0) TRANSMITPERIOD = 1000;
      Serial.print("\nChanging delay to ");
      Serial.print(TRANSMITPERIOD);
      Serial.println("ms\n");
    }
    
    if (input == 'r') //d=dump register values
      radio.readAllRegs();
    //if (input == 'E') //E=enable encryption
    //  radio.encrypt(KEY);
    //if (input == 'e') //e=disable encryption
    //  radio.encrypt(null);
    
    if (input == 'd') //d=dump flash area
    {
      Serial.println("Flash content:");
      int counter = 0;

      while(counter<=256){
        Serial.print(flash.readByte(counter++), HEX);
        Serial.print('.');
      }
      while(flash.busy());
      Serial.println();
    }
    if (input == 'e')
    {
      Serial.print("Erasing Flash chip ... ");
      flash.chipErase();
      while(flash.busy());
      Serial.println("DONE");
    }
    if (input == 'i')
    {
      Serial.print("DeviceID: ");
      word jedecid = flash.readDeviceId();
      Serial.println(jedecid, HEX);
    }
  }

  //check for any received packets
  if (radio.receiveDone())
  {
    Serial.print('[');Serial.print(radio.SENDERID, DEC);Serial.print("] ");
    for (byte i = 0; i < radio.DATALEN; i++)
      Serial.print((char)radio.DATA[i]);
    Serial.print("   [RX_RSSI:");Serial.print(radio.readRSSI());Serial.print("]");

    if (radio.ACKRequested())
    {
      radio.sendACK();
      Serial.print(" - ACK sent");
      delay(10);
    }
    Blink(LED,5);
    Serial.println();
  }
  
  int currPeriod = millis()/TRANSMITPERIOD;
  if (currPeriod != lastPeriod)
  {
    //fill in the struct with new values
    theData.nodeId = NODEID;
    theData.uptime = millis();
    theData.temp = 91.23; //it's hot!
    
    Serial.print("Sending struct (");
    Serial.print(sizeof(theData));
    Serial.print(" bytes) ... ");
    if (radio.sendWithRetry(GATEWAYID, (const void*)(&theData), sizeof(theData)))
      Serial.print(" ok!");
    else Serial.print(" nothing...");
    Serial.println();
    Blink(LED,3);
    lastPeriod=currPeriod;
  }
}

void Blink(byte PIN, int DELAY_MS)
{
  pinMode(PIN, OUTPUT);
  digitalWrite(PIN,HIGH);
  delay(DELAY_MS);
  digitalWrite(PIN,LOW);
}

Struct_receive

#define RF_PALEVEL_PA0_OFF
#define RF_PALEVEL_PA1_ON
#define RF_PALEVEL_PA2_OFF

#include <RFM69.h>
#include <SPI.h>
#include <SPIFlash.h>

#define NODEID      1
#define NETWORKID   100
#define FREQUENCY   RF69_433MHZ //Match this with the version of your Moteino! (others: RF69_433MHZ, RF69_868MHZ)
#define KEY         "thisIsEncryptKey" //has to be same 16 characters/bytes on all nodes, not more not less!
#define LED         13
#define SERIAL_BAUD 115200
#define ACK_TIME    30  // # of ms to wait for an ack

RFM69 radio;
SPIFlash flash(8, 0xEF30); //EF40 for 16mbit windbond chip
bool promiscuousMode = true; //set to 'true' to sniff all packets on the same network

typedef struct {    
  int           nodeId; //store this nodeId
  unsigned long uptime; //uptime in ms
  float         temp;   //temperature maybe?
} Payload;
Payload theData;

void setup() {
  Serial.begin(SERIAL_BAUD);
  delay(10);
  radio.initialize(FREQUENCY,NODEID,NETWORKID);
  //radio.setHighPower(); //uncomment only for RFM69HW!
  radio.encrypt(KEY);
  radio.promiscuous(promiscuousMode);
  char buff[50];
  sprintf(buff, "\nListening at %d Mhz...", FREQUENCY==RF69_433MHZ ? 433 : FREQUENCY==RF69_868MHZ ? 868 : 915);
  Serial.println(buff);
  if (flash.initialize())
    Serial.println("SPI Flash Init OK!");
  else
    Serial.println("SPI Flash Init FAIL! (is chip present?)");
}

byte ackCount=0;
void loop() {
  //process any serial input
  if (Serial.available() > 0)
  {
    char input = Serial.read();
    if (input == 'r') //d=dump all register values
      radio.readAllRegs();
    if (input == 'E') //E=enable encryption
      radio.encrypt(KEY);
    if (input == 'e') //e=disable encryption
      radio.encrypt(null);
    if (input == 'p')
    {
      promiscuousMode = !promiscuousMode;
      radio.promiscuous(promiscuousMode);
      Serial.print("Promiscuous mode ");Serial.println(promiscuousMode ? "on" : "off");
    }
    
    if (input == 'd') //d=dump flash area
    {
      Serial.println("Flash content:");
      int counter = 0;

      while(counter<=256){
        Serial.print(flash.readByte(counter++), HEX);
        Serial.print('.');
      }
      while(flash.busy());
      Serial.println();
    }
    if (input == 'D')
    {
      Serial.print("Deleting Flash chip content... ");
      flash.chipErase();
      while(flash.busy());
      Serial.println("DONE");
    }
    if (input == 'i')
    {
      Serial.print("DeviceID: ");
      word jedecid = flash.readDeviceId();
      Serial.println(jedecid, HEX);
    }
  }

  if (radio.receiveDone())
  {
    Serial.print('[');Serial.print(radio.SENDERID, DEC);Serial.print("] ");
    Serial.print(" [RX_RSSI:");Serial.print(radio.readRSSI());Serial.print("]");
    if (promiscuousMode)
  {
      Serial.print("to [");Serial.print(radio.TARGETID, DEC);Serial.print("] ");
    }
  
    if (radio.DATALEN != sizeof(Payload))
      Serial.print("Invalid payload received, not matching Payload struct!");
    else
    {
      theData = *(Payload*)radio.DATA; //assume radio.DATA actually contains our struct and not something else
      Serial.print(" nodeId=");
      Serial.print(theData.nodeId);
      Serial.print(" uptime=");
      Serial.print(theData.uptime);
      Serial.print(" temp=");
      Serial.print(theData.temp);
    }
    
    if (radio.ACKRequested())
    {
      byte theNodeID = radio.SENDERID;
      radio.sendACK();
      Serial.print(" - ACK sent.");

      // When a node requests an ACK, respond to the ACK
      // and also send a packet requesting an ACK (every 3rd one only)
      // This way both TX/RX NODE functions are tested on 1 end at the GATEWAY
      if (ackCount++%3==0)
      {
        Serial.print(" Pinging node ");
        Serial.print(theNodeID);
        Serial.print(" - ACK...");
        delay(3); //need this when sending right after reception .. ?
        if (radio.sendWithRetry(theNodeID, "ACK TEST", 8, 0, 50))  // 0 = only 1 attempt, no retries; wait up to 50mS
          Serial.print("ok!");
        else Serial.print("nothing");
      }
    }
    Serial.println();
    Blink(LED,3);
  }
}

void Blink(byte PIN, int DELAY_MS)
{
  pinMode(PIN, OUTPUT);
  digitalWrite(PIN,HIGH);
  delay(DELAY_MS);
  digitalWrite(PIN,LOW);
}

As you noticed both sketches start with

#define RF_PALEVEL_PA0_OFF
#define RF_PALEVEL_PA1_ON
#define RF_PALEVEL_PA2_OFF

so I can play with the PA's.
Also the

  //radio.setHighPower(); //uncomment only for RFM69HW!

is commented out because they appear to hear eachother fine. Well, almost fine.

Here's the Struct_send output:

Transmitting at 433 Mhz...
SPI Flash Init FAIL! (is chip present?)
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
...........

But here's the most interesting output after I changed bool promiscuousMode = false; to bool promiscuousMode = true; I was suddenly able to make them talk to each other even with both PA's disabled and the radio.setHighPower(); commented out.
Here's the Struct_receive output:

Listening at 433 Mhz...
SPI Flash Init FAIL! (is chip present?)
[212]  [RX_RSSI:-68]to [189]  nodeId=10767 uptime=3895142702 temp=ovf
[212]  [RX_RSSI:-66]to [189]  nodeId=10767 uptime=3895142702 temp=ovf
[212]  [RX_RSSI:-66]to [189]  nodeId=10767 uptime=3895142702 temp=ovf
[138]  [RX_RSSI:-66]to [69]  nodeId=25167 uptime=755652493 temp=10.40
[138]  [RX_RSSI:-66]to [69]  nodeId=25167 uptime=755652493 temp=10.40
[138]  [RX_RSSI:-66]to [69]  nodeId=25167 uptime=755652493 temp=10.40
[6]  [RX_RSSI:-66]to [95]  nodeId=28423 uptime=3186857133 temp=-0.00 - ACK sent. Pinging node 6 - ACK...nothing
[6]  [RX_RSSI:-66]to [95]  nodeId=28423 uptime=3186857133 temp=-0.00 - ACK sent.
[211]  [RX_RSSI:-67]to [113]  nodeId=-15141 uptime=657118850 temp=28713.76 - ACK sent.
[211]  [RX_RSSI:-68]to [113]  nodeId=-15141 uptime=657118850 temp=28713.76 - ACK sent. Pinging node 211 - ACK...nothing
[18]  [RX_RSSI:-68]to [211]  nodeId=14750 uptime=987840321 temp=-0.00
[18]  [RX_RSSI:-66]to [211]  nodeId=14750 uptime=987840321 temp=-0.00
[18]  [RX_RSSI:-67]to [211]  nodeId=14750 uptime=987840321 temp=-0.00
[133]  [RX_RSSI:-66]to [167]  nodeId=-16647 uptime=1764550266 temp=ovf
[133]  [RX_RSSI:-67]to [167]  nodeId=-16647 uptime=1764550266 temp=ovf
[133]  [RX_RSSI:-66]to [167]  nodeId=-16647 uptime=1764550266 temp=ovf
[50]  [RX_RSSI:-66]to [109]  nodeId=19370 uptime=3957555244 temp=0.00
[50]  [RX_RSSI:-66]to [109]  nodeId=19370 uptime=3957555244 temp=0.00
[50]  [RX_RSSI:-66]to [109]  nodeId=19370 uptime=3957555244 temp=0.00
[131]  [RX_RSSI:-66]to [229]  nodeId=12568 uptime=2848342087 temp=ovf
[131]  [RX_RSSI:-66]to [229]  nodeId=12568 uptime=2848342087 temp=ovf
[131]  [RX_RSSI:-66]to [229]  nodeId=12568 uptime=2848342087 temp=ovf
[255]  [RX_RSSI:-66]to [168]  nodeId=7355 uptime=659277296 temp=0.00
[255]  [RX_RSSI:-66]to [168]  nodeId=7355 uptime=659277296 temp=0.00
[255]  [RX_RSSI:-67]to [168]  nodeId=7355 uptime=659277296 temp=0.00
[186]  [RX_RSSI:-67]to [20]  nodeId=-17448 uptime=273311279 temp=-13989.21 - ACK sent.
[186]  [RX_RSSI:-68]to [20]  nodeId=-17448 uptime=273311279 temp=-13989.21 - ACK sent.
[186]  [RX_RSSI:-68]to [20]  nodeId=-17448 uptime=273311279 temp=-13989.21 - ACK sent. Pinging node 186 - ACK...nothing
[26]  [RX_RSSI:-68]to [43]  nodeId=2128 uptime=2142532543 temp=ovf
[26]  [RX_RSSI:-67]to [43]  nodeId=2128 uptime=2142532543 temp=ovf
[26]  [RX_RSSI:-67]to [43]  nodeId=2128 uptime=2142532543 temp=ovf
[193]  [RX_RSSI:-67]to [152]  nodeId=32722 uptime=2146611939 temp=-0.00 - ACK sent.
[193]  [RX_RSSI:-68]to [152]  nodeId=32722 uptime=2146611939 temp=-0.00 - ACK sent.
[193]  [RX_RSSI:-67]to [152]  nodeId=32722 uptime=2146611939 temp=-0.00 - ACK sent. Pinging node 193 - ACK...nothing
[128]  [RX_RSSI:-68]to [153]  nodeId=-32702 uptime=4189638721 temp=-130171.57 - ACK sent.
[128]  [RX_RSSI:-67]to [153]  nodeId=-32702 uptime=4189638721 temp=-130171.57 - ACK sent.
[128]  [RX_RSSI:-68]to [153]  nodeId=-32702 uptime=4189638721 temp=-130171.57 - ACK sent. Pinging node 128 - ACK...nothing

Do you noticed the to column? And how the ack destination node is never the same? So it seems to me that the packets are corrupted either at source or at destination. I'm not sure if the sender is mangling it or if the receiver is parsing it wrong. But it's obvious that the one way communication works just fine. The problem is with the "full duplex" communication.

I don't have the skill level of an RF engineer, but being also a licensed ham radio operator, I know a thing or two about RF signals and atennas.
I believe your statements, yet here I am testing a prototype using a radio module that's supposed to beat the RF24 by a mile, but for this to happen I need use dipoles, ground planes, and who knows, maybe design, build and tune some magnetic loop antenna or some antenna tuning circuit for the RFM69 modules to work at 20-30 meters. For God sake, even with an improper length random wire antenna they should be able to work at 20-30m.
There are people reporting good signal at distances of 13km with a bitrate of 55.5kbps. The LowPowerLab sets the default bitrate at 4kbps. That may take the distance to over 20km. But all I managed to squeeze out of my 433MHz HW modules is 3 meters. That can't be right.
I contacted HopeRF and asked them about clarifications. First I need to know if their RFM69HW-V1.3.pdf is compatible with the RFM69HW REV 2.0 board (as depicted on the back of the module). I also contacted the supplier asking if they received any other complaints for those modules.
What kills me is that while everything points to faulty modules, they were bought 6 months apart from the same supplier, they have different frequencies and power output and they behave the same
As for the register levels, luckily I had some 3.3V Arduino Pro Mini to which I hooked a pair of factory sealed modules (to rule out any malfunction due to the improper usage with 5V I/O).
Thanks to Felix's excellent library I was able to pull the complete list of registries:

1 - 10 - 10000
2 - 0 - 0
3 - 2 - 10
4 - 40 - 1000000
5 - 3 - 11
6 - 33 - 110011
7 - 6C - 1101100
8 - 40 - 1000000
9 - 0 - 0
A - 41 - 1000001
B - 40 - 1000000
C - 2 - 10
D - 92 - 10010010
E - F5 - 11110101
F - 20 - 100000
10 - 24 - 100100
11 - 7F - 1111111
12 - 9 - 1001
13 - F - 1111
14 - 40 - 1000000
15 - B0 - 10110000
16 - 7B - 1111011
17 - 9B - 10011011
18 - 8 - 1000
19 - 42 - 1000010
1A - 8A - 10001010
1B - 40 - 1000000
1C - 80 - 10000000
1D - 6 - 110
1E - 10 - 10000
1F - 0 - 0
20 - 0 - 0
21 - 0 - 0
22 - 0 - 0
23 - 0 - 0
24 - D3 - 11010011
25 - 40 - 1000000
26 - 7 - 111
27 - D8 - 11011000
28 - 0 - 0
29 - DC - 11011100
2A - 0 - 0
2B - 0 - 0
2C - 0 - 0
2D - 3 - 11
2E - 88 - 10001000
2F - 2D - 101101
30 - 64 - 1100100
31 - 0 - 0
32 - 0 - 0
33 - 0 - 0
34 - 0 - 0
35 - 0 - 0
36 - 0 - 0
37 - 90 - 10010000
38 - 42 - 1000010
39 - 0 - 0
3A - 0 - 0
3B - 0 - 0
3C - 8F - 10001111
3D - 13 - 10011
3E - 73 - 1110011
3F - 61 - 1100001
40 - 6D - 1101101
41 - 70 - 1110000
42 - 6C - 1101100
43 - 65 - 1100101
44 - 45 - 1000101
45 - 6E - 1101110
46 - 63 - 1100011
47 - 72 - 1110010
48 - 79 - 1111001
49 - 70 - 1110000
4A - 74 - 1110100
4B - 4B - 1001011
4C - 65 - 1100101
4D - 79 - 1111001
4E - 1 - 1
4F - 0 - 0
50 - 13 - 10011
51 - 45 - 1000101
52 - 88 - 10001000
53 - 8 - 1000
54 - 0 - 0
55 - 0 - 0
56 - 1 - 1
57 - 0 - 0
58 - 1B - 11011
59 - 9 - 1001
5A - 55 - 1010101
5B - 80 - 10000000
5C - 70 - 1110000
5D - 33 - 110011
5E - CA - 11001010
5F - 8 - 1000
60 - 0 - 0
61 - F - 1111
62 - 0 - 0
63 - 0 - 0
64 - 0 - 0
65 - F - 1111
66 - 70 - 1110000
67 - 0 - 0
68 - 12 - 10010
69 - 16 - 10110
6A - 19 - 11001
6B - 1C - 11100
6C - 0 - 0
6D - 4 - 100
6E - C - 1100
6F - 30 - 110000
70 - 18 - 11000
71 - 0 - 0
72 - 0 - 0
73 - 0 - 0
74 - 0 - 0
75 - 0 - 0
76 - 0 - 0
77 - 0 - 0
78 - 0 - 0
79 - 0 - 0
7A - 0 - 0
7B - 0 - 0
7C - 0 - 0
7D - 0 - 0
7E - 0 - 0
7F - 0 - 0
80 - D - 1101

I had to use a minor tweak to extend the limit of registries pulled out above the initial limit of 0x4F. They are test registers and internal test registers. Not sure if they're of any help.

@Chester said:

I have had the same issues as you with the RFM69 modules.

First ones that I bought were marked as RFM69HCW 433mhz, and when I put them together as required, I couldn't get range of more than around 40cm. After that, the reception dropped off a cliff. One thing I did note was that the modules looked different from all the images I could see on this site, which led me to ponder whether I just had crummy modules or not. Also, given the size of the antenna, I was a bit loath to continue with 433mhz radios.

so I decided to up and pick up a new batch of radios, and change over to the RFM69HW (without the C), 868mhz. These ones, when I soldered them up, give me range of around 30m through the entire length of the house, through every wall.

So the only thing I could put my effort down to was that I just had a crummy radio module batch first, and a proper set later, so not sure I can put too much more knowledge into things here.

What you're saying makes perfect sense, crappy batches can hit the market sometimes. But what doesn't make any sense in my situation is that I first puchased 5x 868MHz RFM69W modules but as I had other ongoing projects they stayed on shelf for about half an year. Then I considered tinkering with 433MHz RFM69HW to test the longest possible range of RFM69x line.
Anyway, I absolutely need to use bare modules for my sensors so I will order a few from eBay and hopefully those ones will work.

Exactly, I've exhausted all my ideas as well. It must definitely be the hardware. As for your questions, I'm not sure they can even talk at a full 1m distance, more like 0.5m.
I have the custom PCB design ready for production but I don't want to submit it until I do some thorough testing. I looked for alternatives on the local market but I can only find breakout boards and besides their unfeasable cost, they're too bulky to fit inside my sensor cases.
I found that Anarduino sells custom modules with integrated RFM69(H)W (http://www.anarduino.com/miniwireless/) that look exactly like the one I have and the one depicted the guide here: https://www.mysensors.org/build/connect_radio
Adafruit's Feather, as well as the Sparkfun's breakout board are using a different looking module (the same found on eBay or Aliexpress)
Anarduino has an old RFM69 library but I'm struggling with Arduino IDE versions since the latest version throws a bunch of errors when compiling while 1.6.5 works just fine. But the funny thing is that even they recommend using the RadioHead library

Anyway, here's a bunch of pictures but I'm not sure if they're of any help.
http://imgur.com/a/yICkw

So... more tests performed:
I assumed that my moronic rush fried the modules power amps. I didn't carefully read the guide and hooked their I/O pins to a 5V Arduino pins (but connected the VCC pin to the 3.3V rail). So I pulled the last two factory sealed RFM69HW 433MHz I had stashed, soldered them with dupont cables and proper antenna (0.8mm copper single core 17cm long) and hooked one module to a 3.3V Arduino (the gateway to be) and the other one on a breadboard ATmega328 (the basic remote sensor architecture) powered by a 14250 battery.
The exact same thing
The LowPowerLab works for ranges up to 1m, the Radiohead library doesn't report anything on the serial interface and leds I used for basic debug shows that the sensor node sends packets but the gateway doesn't receive them.
So I got to a point where I'm very frustrated because there must be something I'm missing. I am using two module types at different frequency and power output, purchased from a trusted source, six months apart.
However, some further reading lead me to this page:
https://www.andrehessling.de/2015/02/07/figuring-out-the-power-level-settings-of-hoperfs-rfm69-hwhcw-modules/
This guy compiled a very thorough review of the modules in which he's playing with settings by enabling/disabling the radios power amps using writing registers. But I am totally clueless on how can this be done, if the MySensors has the proper settings preconfigured or if they're accessible and if so then where. It's not clear to me either if these registers are persistent across various sketches involving various libraries or if the used library has to have support for them and they need to be declared in every sketch or inside the library. This registry thing is pretty much where my expertise hits a wall
It's really strange that this 1m range is very consistend across a lot of setups I made. Maybe the power amps are disabled and they "hear" eachother while being very close, maybe by some sort of harmonics.

Some guides mention 87mm, others 82mm. As for the helical I will have to test and see. PCB antennas are also an option, but I'd hate to have my nice boxed sensors with wires hanging out.
As for the bad radio modules, that's one other reason I am focusing on the RFM69. I started experimenting with the cheap eBay NRF24L01+ modules, the black ones, only to later find out that about 1 out of 10 fails after sometime and doesn't enter the deep sleep mode, using about 2mA instead of about 60uA, obviously killing the battery after a day or so. I read about one guy who ordered 2000 or so and most of them had the exact same problem.
And since I am using rather expensive CR123 or 14250 batteries I don't want take that chance.
The green NRF24L01+ modules however, worked flawlessly so far but they're a bit too bulky for my projects.

@scalz said:

what if you directly connect a 82mm monopole wire directly on the radio ant pad?

I used a 17cm random wire for the 433MHz modules and 9cm wire for the 868MHz ones. Then coiled up the 17cm wires into a diy helical with 6-7 turns (not sure exctly)

@scalz Many thanks for updating the docs.
I was thinking about testing them with a battery as well but even if the remote sensors may be just fine with battery power, I still need the gateway radio to be fed with a constant 3.3V voltage from either the Arduino's 3.3V rail, or using a an external regulator. And so far neither worked.
I feel like there's something wrong with the radio modules. What ar the odds of those particular modules not to work with MySensors 2.0?

@korttoma: Instead of inserting the #define in the sketch I modified the same entry in MyConfig.h. That's basically the same thing.
Anyway I must confess that at start, it took me some time to realize that That's because there's very little info on the RFM69 setups, almost all documentation revolves around RF24 and ESP8266 and the library and examples are pre-configured for RF24

I haven't heard of countefeit RFM69 modules, but anyway, here are the exact modules, purchased from this exact supplier:
http://www.tme.eu/en/details/rfm69hw-433s2/rf-communication-modules/hope-microelectronics/
http://www.tme.eu/en/details/rfm69w-868s2/rf-communication-modules/hope-microelectronics/

@scalz said:

hmm, looks weird, what is your power supply? do you use dupont cable?
on my side, i already quickly tested 40m with one brickwall, outdoor rfm69cw (same as w) to my indoor rfm69hw GW, with mysensors 2 beta.

Initially I powered them from the Arduino Pro Mini onboard 3.3V voltage regulator which is supposed to handle up to 200mA. I also added capacitors. Then moved the setup to a larger breaboard powered by one of those breadboard power supplies. I powered the radios directly from the breadboard's 3.3V power rail. Also added capacitors.
Please note that each test was performed identically on both sensor node and serial gateway.

The modules are connected to the Arduinos using short dupont cables. It's easier to prototype them by cutting a dupont cable set in two, solder the strip cable ends to the radio boards and connect the dupont pins on the breadboard. One thing worth mentioning is that the 868MHz modules are facing the chip side upwards and the 433MHz down.

Maybe the only thing that's not done 100% by the book is that I chose to connect the radios ground using the farmost GND pin instead of the one opposite the ANT pin. After I soldered them I found some schematics showing a dipole antenna setup using that pin as counterpoise for the antenna. But I assume that all GND pins are connected to the ground plane, so it really doesn't matter.

@gloob said:

Do you mix 433MHz and 868MHz modules?
Sensor and gateway need to have the same type of modul.

Of course I did not mix them, how dumb can I be?
I just happened to have another set which luckily were on a different frequency, as well as being the normal power types (without the "H") to rule out a possible signal saturation.

@FotoFieber said:

@mihai.aldea
Could you please post your sketch?

Have you set

#define MY_IS_RFM69HW 

according to your module type?

No, I haven't. I just changed:

#define MY_RADIO_NRF24
//#define MY_RADIO_RFM69

to

//#define MY_RADIO_NRF24
#define MY_RADIO_RFM69

At some point I did try with:

#define MY_IS_RFM69HW

but no change.

I used the standard sketch, only modifying those two rows.

I recently started experimenting with MySensors 2.0 library and RFM69 modules. I have a couple of RFM69W 868MHz and RFM69HW 433MHz modules. Since I already had the MySensors 1.5 library installed, I tried using that one but found it to be really complicated to use with the RFM69 modules since there is little to no info on how to properly switch from the default RF24 radios to RFM69. And the only bits and pieces I found were also not consistent.
So I moved on to 2.0. The syntax is simpler than 1.5 and I found a little bit more info about using RFM69. I uploaded the sketches and bam!, the sensor was pushing updates to the serial gateway. Then I moved the sensor node to another room. But no RX packets were hitting the gateway. After much trial and error I learned that they only talk to eachother if they're a meter or so.
What I alread did

• Switched the high-power 433MHz RFM69HW with 868MHz RFM69W.
• Used a separate 3.3V power supply to power the radios.
• Used 4.7uF and 47uF capacitors across the radio's power pins on both the gateway and the sensor node.
• Used correct length both wire and helical antennas for both modules types.
  No matter what I did, at least with the 2.0 library they hear eachother at 1m or so. Now I'm rolling back the 1.5 library and sketches and get back with the update.
  I wanted to know if anyone experienced similar issues with the RFM69 modules with the 2.0 library because although I am perfectly happy with the RF24 modules, I'd like the lower fooprint, longer range, RSSI reporting and the encryption of the RFM69 radios.

Hello,

I'm using Vera Edge with a bunch of MySensors based sensors. All went fine until I decided that an EasyIoT should join the network on the same channel while trying to pass some sensor values to others. Anyway, I started to see strange values in the sensors values charts (eg. 1mil Celsius degrees) and started to see sensor properties that should not be there, eg. two nodes with humidity sensors now display their power usage in watts. Other sensors display various battery status values while no battery status should be displayed on the sensors but on the node devices only.
Let's just say that it's going to be really messy add the sensors once again since I have a Cacti instance pulling the sensor values and building charts, so the easiest thing to do would be to able to delete those sensor properties that should not be there. I went through the LuuP requests wiki page but found no reference on how to delete a property field of a given sensors.

Is there a way?