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