Mod

@wiredfrank
in your gw sketch, your defines should be like this:

#define MY_RADIO_RFM69
#define MY_RFM69_NEW_DRIVER
#define MY_RFM69_FREQUENCY RFM69_433MHZ // Set your frequency here
#define MY_IS_RFM69HW // Omit if your RFM is not "H"
#define MY_RFM69_IRQ_PIN D1
#define MY_RFM69_IRQ_NUM MY_RFM69_IRQ_PIN
#define MY_RFM69_CS_PIN D8 // NSS. Use MY_RFM69_SPI_CS for older versions (before 2.2.0)

and there is the RFM69_RFM95_ATC_SignalReport.ino sketch for your node, in mysensors examples

/*
 * 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-2019 Sensnology AB
 * Full contributor list: https://github.com/mysensors/MySensors/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.
 *
 *******************************
 *
 * REVISION HISTORY
 * Version 1.0 - tekka
 *
 * DESCRIPTION
 * ATC mode settings and signal report functions, on RFM69 and RFM95 nodes
 *
 */

// Enable debug prints
#define MY_DEBUG

// Enable and select radio type attached

// RFM69
#define MY_RADIO_RFM69
#define MY_RFM69_NEW_DRIVER   // ATC on RFM69 works only with the new driver (not compatible with old=default driver)
#define MY_RFM69_FREQUENCY RFM69_433MHZ
//#define MY_RFM69_ATC_TARGET_RSSI_DBM (-70)  // target RSSI -70dBm
//#define MY_RFM69_MAX_POWER_LEVEL_DBM (10)   // max. TX power 10dBm = 10mW

// RFM95
//#define MY_RADIO_RFM95
//#define MY_RFM95_ATC_TARGET_RSSI_DBM (-70)  // target RSSI -70dBm
//#define MY_RFM95_MAX_POWER_LEVEL_DBM (10)   // max. TX power 10dBm = 10mW

#include <MySensors.h>

// ID of the sensor child
#define CHILD_ID_UPLINK_QUALITY (0)
#define CHILD_ID_TX_LEVEL       (1)
#define CHILD_ID_TX_PERCENT     (2)
#define CHILD_ID_TX_RSSI        (3)
#define CHILD_ID_RX_RSSI        (4)
#define CHILD_ID_TX_SNR         (5)
#define CHILD_ID_RX_SNR         (6)


// Initialize general message
MyMessage msgTxRSSI(CHILD_ID_TX_RSSI, V_CUSTOM);
MyMessage msgRxRSSI(CHILD_ID_RX_RSSI, V_CUSTOM);
MyMessage msgTxSNR(CHILD_ID_TX_SNR, V_CUSTOM);
MyMessage msgRxSNR(CHILD_ID_RX_SNR, V_CUSTOM);
MyMessage msgTxLevel(CHILD_ID_TX_LEVEL, V_CUSTOM);
MyMessage msgTxPercent(CHILD_ID_TX_PERCENT, V_CUSTOM);
MyMessage msgUplinkQuality(CHILD_ID_UPLINK_QUALITY, V_CUSTOM);

void setup()
{
}


void presentation()
{
	// Send the sketch version information to the gateway and controller
	sendSketchInfo("ATC", "1.0");

	// Register all sensors to gw (they will be created as child devices)
	present(CHILD_ID_UPLINK_QUALITY, S_CUSTOM, "UPLINK QUALITY RSSI");
	//present(CHILD_ID_TX_LEVEL, S_CUSTOM, "TX LEVEL DBM");
	//present(CHILD_ID_TX_PERCENT, S_CUSTOM, "TX LEVEL PERCENT");
	//present(CHILD_ID_TX_RSSI, S_CUSTOM, "TX RSSI");
	//present(CHILD_ID_RX_RSSI, S_CUSTOM, "RX RSSI");
	//present(CHILD_ID_TX_SNR, S_CUSTOM, "TX SNR");
	//present(CHILD_ID_RX_SNR, S_CUSTOM, "RX SNR");
}

void loop()
{
	// send messages to GW
	send(msgUplinkQuality.set(transportGetSignalReport(SR_UPLINK_QUALITY)));
	//send(msgTxLevel.set(transportGetSignalReport(SR_TX_POWER_LEVEL)));
	//send(msgTxPercent.set(transportGetSignalReport(SR_TX_POWER_PERCENT)));
	// retrieve RSSI / SNR reports from incoming ACK
	//send(msgTxRSSI.set(transportGetSignalReport(SR_TX_RSSI)));
	//send(msgRxRSSI.set(transportGetSignalReport(SR_RX_RSSI)));
	//send(msgTxSNR.set(transportGetSignalReport(SR_TX_SNR)));
	//send(msgRxSNR.set(transportGetSignalReport(SR_RX_SNR)));
    Serial.print("UPLINK QUALITY RSSI=");
    Serial.println(transportInternalToRSSI(_transportSM.uplinkQualityRSSI)); // UPLINK QUALITY RSSI
Serial.print("TX LEVEL DBM=");    
Serial.println(transportGetTxPowerLevel());  //TX LEVEL DBM
Serial.print("TX LEVEL PERCENT="); 
    Serial.println(transportGetTxPowerPercent());  // TX LEVEL PERCENT
Serial.print("RX RSSI=");
    Serial.println(transportGetReceivingRSSI());  //RX RSSI
Serial.print("TX RSSI=");
    Serial.println(transportGetSendingRSSI());    //TX RSSI

	// wait a bit
	wait(5000);
}

Note: the new rfm driver has compatible communication for rfm69<->rfm95

@Sasquatch
I admit I never checked that, but thought the capa would probably be there.
well, I usually am careful so I add more footprints than needed for flexibilty, just in case

@hlehoux perhaps do you have some arduino mini pro (8mhz 3v) that you could use as a test node and check if you still have same problem (in case this is an IRQ issue..) ?

@Sasquatch
yes rfm modules are nice for long range.
ok. we will re-test OTA+new driver on my new board soon, and will keep you updated

I agree seems OP has setup problem, could be

• H vs non-H define
• IRQ is not triggering for receiving msg
• weak GND counterpoise for antenna,
• power supply. For power I usually use 100uf+0.1uf close to the module. 100uf when it's batt powered (for coincell, I like to have two big capa+0.1uf), else it's possible to use a smaller value like 33-47uf

@electrik
in logs, RFM69:CSMA:RSSI=-104 is the noise floor
and RFM69_TARGET_RSSI_DBM define the rssi you want to have for your node.

so if you have a noise floor of -100, you could adjust your target to -85 or less. But maybe you could get a few retries with -90 target.

rfm69 power level can be adjusted from -18 to +13db. 13db=100% power= 45mA power consumption.

for example, let's say your target is -70, and your power level has been autoadjusted to +5.
then if you set, the target to -80 or less, power level will decrease to maybe -8 or even less, it depends on your environment and your build.
And vice versa, if you set target to -50, ATC will set a higher power level.

ATC is used to auto-adjust radio power level consumption for battery nodes, so they use only energy they need. This also make your rf environment "greener". No nodes sending loud messages if not needed.

Another example, I recently designed a new node. Noise floor here is around -98db.
With a target of -70 if I remember, power level was autoadjusted to +5db.
After adjusting target to -87db, power level has decreased to -11db, which equals to 20% power.
And there are no NACK nor retries.
So this node now requires less energy for sending messages and that will save battery.
This is for an indoor node, 10m distance with 2 brick walls obstacles.

old driver doesn't have ATC management. I've no problem so far with new driver.

I guess H would mean High power version. But to be sure, yuo just have to google for rfm69 pics and you'll see which version you have. Existing versions are : RFM69HW, RFM69W, RFM69HCW, RFM69CW

@Sven-0
Fun to see this old topic again. And also the coincidence, since my visits here have been rare for a long time.
Anyway, I'm running a few slimnodes since the beginning and have both good and bad experiences. In general, the battery lifetime is your least concern. Instead I have had issues with sensors, sensitivity, switch contact corrosion, mechanical robustness, wifi interference, repaeter, gateway, controller, waf, kids, animals, etc, etc.
Regarding this particular PIR slimnode it's very stable, but it is not universal for every situation due to the limited range and missing sinsitivity adjustment. E.g I can't use it too near my basement windows due to the moving cold air. And in my living room I have sun reflections to deal with.
I suggest you start by building a testnode to check if it works for your conditions.
A recent PIR-slimnode battery life example; My hallway one died last week after 33 months and around 6000 trips/month.

@pw44 I would say that raising an alarm or not is the task of the controller, not the sensor. The sensor should only report door status, and the controller combines a number of parameters to decide if the alarm should sound.

@hlehoux
unfortunately, lot of devboards have non-optimized gnd plane for RF, especially for subghz (small or splitted gnd plane by routes..).
Moreover, devboard+dupont cable+external rf module is not ideal.
With rfm69, you should get a nice range.
Though, why on one of your picture, antenna seems shorted to gnd??
Imho I would have chosen something else than esp8266 (esp32??) in your case, but your choice

To check if this is related to your gnd plane and your build is ok, you could also try to hook two straight wires as a dipole antenna to your radio (one to ANA, the other to GND in opposite direction will replace a ground plane). Google for examples, it's simple to try

Welcome to the MySensors community @wiredfrank

The gateway configuration says that you have a rfm69 and a rfm95 radio connected. Is that really the case?

The node is co figured to use a rfm69 with the new driver. The new driver is not compatible with the default driver, so the node should not be able to communicate with the gateway at all.

Note: rfm95 is a LoRa radio, while rfm69 is not.

What do the debug log on the gateway and on the node say?

@skywatch I have never used this feature so I can’t help that much. Based on what I have read in the forums, exactly how you want to use this feature is heavily dependent on the details of each use case so it is impossible to give generic recommendations.

@zboblamont can't you just try it? Nothing will break when powered below 5v, but you would have to apply the pressure somehow