Hardware Contributor

@projectMarvin said in Second setup, choosing a radio:

Reading more it seems like OTA for these devices is not supported yet.
@NeverDie @scalz Did you ever get OTA working on these boards?

Nope, not in C, but I did achieve OTA using micropython, uLisp, and Forth, because those 3 are interpreted. However, there may be more information available now on how to do OTA for it in C than there was when I last checked. With C it would require a wireless bootloader. Perhaps one or more of the nRF52 RTOS's would have it by now. It might (?) possibly even be a part of platform.io by now, though I'm doubtful.

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

@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

@Nick-Willis - yes I did, and when I used the new driver everything compiled and the node started, but I got a strange serial log message saying radio = 0 (not radio failed) or something.

@jo34l5 Probbly the biggest knock against ESP's is their sleep power cosumption and, to a lesser degree, a smaller number of GPIO pins on an ESP8266. Even the new ESP32-S2 will consume more power than than a typical mysensors mote. In your case, though, you plan for your nodes to be mains powered, so relative power consumption isn't likely to matter much. There exist quite a large number of mysensors nodes that can run for 10 years or more on a set of batteries, and for a lot of people that's part of their appeal: you can put them just about anywhere. And in terms of range and coverage, nothing beats LoRa for low datarate sensor traffic.

@jo34l5 said in Multiple sensors over wifi?:

Are you aware of a simple, step-by-step guide of sending ANY packet from my arduino over WPA to a specific IP:PORT on my network? Something that is step-by-step (I.e. plug in these wires here, paste this code here). I can't find anything easy for newbies.

Yes, the protocol you probably want is ESP NOW. Here is some step-by-step: https://randomnerdtutorials.com/esp-now-esp8266-nodemcu-arduino-ide/ There is also ESP NOW for for ESP32's, and the new ESP32-S2 reportedly can use WIFI in a much more power efficient way than earlier versions. If I remember correctly, ESP NOW also allows you to use the ESP wifi radio in what might loosely be called a "proprietary mode" for point-to-point communications. i.e. you no longer need to send packets through a wifi router unless you want to, and so the potential exists to save a lot of energy that would otherwise be wasted being a slave to the IEEE 802.11 standards (e.g. constantly pinging the router every 100ms to let it know your node is alive and in-range or else the router will cancel your connection and your node must then go through a slow and lengthy TCP/IP authorization exchange each time it wants to establsih a connection).