RFM69 new driver delay

[mickecarlsson]

@pepson said in RFM69 new driver delay:

And tell me how you have connected Gateway to RPI3? By ethernet or by serial ? Because i see in your building Gateway that you dont use parameter ETHERNET on port 5003

I use Ethernet to connect to my Domoticz.
The reason that you don't see my configuration for ETHERNET or PORT is because they are default when you configure.
If you look at the file Makefile.inc you will see the build options. In my case the file looks like this:

SOC=BCM2837
CPPFLAGS=-march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -DMY_RADIO_RFM69 -DMY_RFM69_NEW_DRIVER -DMY_GATEWAY_LINUX -DMY_DEBUG -DLINUX_SPI_BCM -DLINUX_ARCH_RASPBERRYPI -DMY_RFM69_FREQUENCY=RFM69_868MHZ -DMY_IS_RFM69HW 
LDFLAGS=-pthread 
PREFIX=/usr/local
CC=gcc
CXX=g++
BUILDDIR=build
BINDIR=bin
GATEWAY_DIR=/usr/local/bin
INIT_SYSTEM=systemd
SPI_DRIVER=BCM

So in my case I have these defines:
MY_RADIO_RFM69
MY_RFM69_NEW_DRIVER
MY_GATEWAY_LINUX
MY_DEBUG
LINUX_SPI_BCM
LINUX_ARCH_RASPBERRYPI
MY_RFM69_FREQUENCY=RFM69_868MHZ
MY_IS_RFM69HW

[pepson]

@mickecarlsson
You dont have issue becuase temp/hum send data from time to time every defined time.
My sketch with relay also looks that works ok.
But problem is on sketch with relay to control covers. WHen cover roll node send still data and it is problem...
This is my opinion.

[pepson]

@mickecarlsson said in RFM69 new driver delay:

MY_RADIO_RFM69 -DMY_RFM69_NEW_DRIVER -DMY_GATEWAY_LINUX -DMY_DEBUG -DLINUX_SPI_BCM -DLINUX_ARCH_RASPBERRYPI -DMY_RFM69_FREQUENCY=RFM69_868MHZ -DMY_IS_RFM69HW
LDFLAGS=-pthread

Tell me you have BME280 this :
https://www.aliexpress.com/item/3In1-BME280-GY-BME280-Digital-Sensor-SPI-I2C-Humidity-Temperature-and-Barometric-Pressure-Sensor-Module-1/32847825408.html?spm=2114.search0104.3.1.6d76301deOqjBT&ws_ab_test=searchweb0_0,searchweb201602_3_10152_10151_10065_10344_10068_5722815_10342_10343_10340_5722915_10341_5722615_10696_10084_10083_10618_10304_10307_10820_10301_10821_5722715_10843_10059_306_100031_10103_10624_10623_10622_5722515_10621_10620,searchweb201603_1,ppcSwitch_5&algo_expid=8f90a51c-aded-4f24-a909-68e32bf05b4b-0&algo_pvid=8f90a51c-aded-4f24-a909-68e32bf05b4b&priceBeautifyAB=0

My defined is the same:

SOC=BCM2837
CPPFLAGS=-march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -DMY_RADIO_RFM69 -DMY_RFM69_NEW_DRIVER -DMY_GATEWAY_LINUX -DMY_DEBUG -DLINUX_SPI_BCM -DLINUX_ARCH_RASPBERRYPI -DMY_DEFAULT_TX_LED_PIN=18 -DMY_DEFAULT_RX_LED_PIN=16 -DMY_DEFAULT_ERR_LED_PIN=12 -DMY_PORT=5003 -DMY_IS_RFM69HW -DMY_RFM69_FREQUENCY=RFM69_868MHZ 
LDFLAGS=-pthread 
PREFIX=/usr/local
CC=gcc
CXX=g++
BUILDDIR=build
BINDIR=bin
GATEWAY_DIR=/usr/local/bin
INIT_SYSTEM=systemd
SPI_DRIVER=BCM

[scalz]

@pepson
just to know, when you get this issue, do you send to one shutter only? (because i see you're sending each %, each 200ms). Well we have already did a stress test in the past, one packet each 50-70ms with a dozen of nodes and it worked but that was with a local unoffcial lib, and not with rpi as gw.
I don't remember if buffer has been implemented in regular branch, for rfm69 (but I think so). And it should work like you said it works with 2.2
We'll be able retry some stress tests, unfortunately not on rpi as gw (not using this setup), I'm not sure but maybe only marceloaqno may be using rpi with rfm69 (not sure), and we're a very few rfm69 users. Let us check if it's a general problem or rpi as gw only.
Sorry for disturbance ;)

[pepson]

@scalz
Hmmm
I am not advanced user. This sketch i found on github from other user. I can change sometinh in sketch to test it ? Can you help me what change in sketch to test ?

[scalz]

@pepson
no idea if it will help you, but what i meant is sending less msg .
I think i recognize some parts of this sketch, not sure :)

So, in your sketch, here you can see it sends at each %

  if (isMoving) 
  {
    unsigned long _now = millis();
    if (_now - lastLevelTime >= timeOneLevel * 1000) {
      if (directionUpDown == DIRECTION_UP) {
        currentShutterLevel += 1;
      } else {
        currentShutterLevel -= 1;
      }
      currentShutterLevel = constrain(currentShutterLevel, 0, 100);
      #ifdef MY_DEBUG
      Serial.println(String(requestedShutterLevel));
      Serial.println(String(currentShutterLevel));
      #endif
      lastLevelTime = millis();
      send(msgPercentage.set(currentShutterLevel));

try to change this last line, by:

if (currentShutterLevel % 5 == 0) send(msgPercentage.set(currentShutterLevel)); // change 5 by 10 if you want to send each 10% for example

no worry about shutter level update in controller, because when it will stop it will send its level (with sendstate in shutterhalt).
As your settings in top of sketch is 20sec for a complete roll, then it should send each second instead of 200ms previously (except if you did some calibration), and if i'm not wrong, I quickly read it!

[pepson]

@scalz

Sorry but i dont know what line chage with this your line

if (currentShutterLevel % 5 == 0) send(msgPercentage.set(currentShutterLevel)); // change 5 by 10 if you want to send each 10% for example```

[scalz]

@pepson
I extracted a part of your sketch above. change the last line of the extract

[pepson]

@scalz

Should looks like this ?

if (isMoving) 
  {
    unsigned long _now = millis();
    if (_now - lastLevelTime >= timeOneLevel * 1000) {
      if (directionUpDown == DIRECTION_UP) {
        currentShutterLevel += 1;
      } else {
        currentShutterLevel -= 1;
      }
      currentShutterLevel = constrain(currentShutterLevel, 0, 100);
      #ifdef MY_DEBUG
      Serial.println(String(requestedShutterLevel));
      Serial.println(String(currentShutterLevel));
      #endif
      lastLevelTime = millis();
      if (currentShutterLevel % 5 == 0) send(msgPercentage.set(currentShutterLevel)); // change 5 by 10 if you want to send each 10% for example```

[pepson]

Ok tested as show in previus post. And the same problem. Maybe a little better. But maybe no...
On 2.2.0 is a very very better.