I can confirm the solution posted by FarmerEd works for me. I was able to transmit from a Lora32u4 ii (node) to a TTGO Lora32 gateway.
As pointed in his post, the right line was:
#define MY_RFM95_IRQ_NUM digitalPinToInterrupt(7)
instead of #define MY_RFM95_IRQ_NUM MY_RFM95_IRQ_PIN
or #define MY_RFM95_IRQ_NUM 7
Thanks very much again for taking the time to post the solution.
@FarmerEd You are totally right 
.. I have left them so long ago that I forgot that I bought them when I changed from RF69 to LoRa. When i bought them (3 years ago they were a good solution if you want Lora in a pre-built board and don't need the power and price of ESP32 .. I have checked on-line shops for them now but the price advantage seems to have gone.
@FarmerEd Thank you very much for taking the time to post the solution!
At the moment I have dismantled the gateway with RF69 (moved to a LoRa gateway) but I will try to find some time in the following months to test the code.
@NeverDie said in Looks as though ESP-NOW is finally working...:
Anyhow, sleep current for ESP8266 and ESP32, the last time I checked anyway, was still kinda high, but I do wonder what the startup time would be if an ESP module were kept in a totally turned-off state until it was needed. Perhaps the higher transmit speed that is possible with a wifi PHY would allow high power to be used only briefly (~250ms in the example in the video), and so maybe total power consumed from the start of wake-up through the transmission may yet turn out to be a win?
Power consumption in deep sleep is really low if using a barebone ESP32-WROOM or WROVER. I did a project in 2020 before the lockdown using a custom ESP32-WROOM in a Soil Moisture capactive sensor and took some measurements to check the power consumptions in each state. The results were:
Power Consumption
With delay (idle): 39,29 mA in the 3V3 input from FTDI adapter.
In deep sleep: 5,4 uA in the 3V3 input from FTDI adapter.
While transmiting (ESP-NOW protocol) the power spike was huge, an average of 200mA, and I think the peak demand was even higher (400 mA?)
With 600mAh LiFePo4 Batteries, the expected duration is aprox. 5 months. No Regulator needed when using LiFePo4. If using regular LiPo or Li-Ion batteries, careful selection of the regulator is crucial because of the spike while transmiting if the regulator is not capable enough or close to the 3V3 pin of the module, a Brownout is quite probable.
This duration (5 months) is calculated assuming that the processor wakes every 15 min to take a sample of the soil for 2 seconds. If the difference between the measured content and last reported value is less than 5% (aprox. Error of the probe), the value is not sent to the controller (no wifi used). It is estimated that 4 measurements per day are sent. If there is no different in moisture content in a days cycle (every 96 wakeups) the sensor reports the measured value along with voltage. Voltage is sent in every moisture report. It is not considered important to send more frequent updates of voltages, LiFePo4 have a flat discharge curve.
The most impacting measure in extending the battery life in this design was the On-Time of the sensor necessary to stabilize the output (feeding the capacitive soil moisture sensor). It is observed that reducing the On-Time has an impact in the measured output. In the sensor, whenever I woke the sensor from deep-sleep I activate a mosfet to drive the feed to the capacitive soil moisture sensor and wait for 2,4 seconds.. that is the part of the cycle that is more critical to battery life.
The time to transmit the data was on average 80 miliseconds (from ESPNOW initialization to data sent). Here is a dump from the serial monitor to check this duration:
16:21:19.694 > rst:0x5 (DEEPSLEEP_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
16:21:19.694 > configsip: 0, SPIWP:0xee
16:21:19.694 > clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
16:21:19.694 > mode:DIO, clock div:2
16:21:19.694 > load:0x3fff0018,len:4
16:21:19.694 > load:0x3fff001c,len:1044
16:21:19.694 > load:0x40078000,len:8896
16:21:19.694 > load:0x40080400,len:5828
16:21:19.694 > entry 0x400806ac
16:21:19.694 > Boot count: 8
16:21:19.982 > Moisture level (pre): 722.62
16:21:20.853 > Moisture level %: 0.00
16:21:20.853 > Voltage level: 2389.50
16:21:20.853 > Voltage Battery: 3.34
16:21:20.853 > Startig Wifi Now...
16:21:20.853 > Wifi Setup complete.
16:21:20.934 > Send success
There is a possibility to further reduce power consumption. Yo can manipulate pint status and read the ADC while maintaing the main cores in deep sleep by using the low power co-procesor. This coprocesor would check if the value has changed since the last transmission and wake the main processor if it is necessary.
And in relation to ESPNOW and MySensors, I used a TTGO-Lora board with ESP32 and LORA transceiver as the MySensors and ESPNOW gateway. The gateway processed the value from the sensors received by the ESP-NOW "custom" protocol to MySensors... the controller (Openhab) was only aware of sensors atached to the
ESP-NOW Sensor --> TTGO-Lora (Translates from ESP-NOW to MySensor Message) --> Openhab
I did also a proof of concept with a Repeter-translator from ESP-NOW to Mysensors:
ESP-NOW Sensor --> TTGO-Lora (Translates from ESP-NOW to MySensor Message) --> TTGO-Lora (receives MySensor Messages) --> Openhab
The ESP-Now MySensors gateway sketch was not very elegant but worked.
The next step would be using ESPNOW as a new MySensor Protocol... to do it myself I should spent quite some time learning how MySensor Code works.. I have tryed in the past but never have the change to work enough time to understand it fully.
If this transport is supported, I see quite an advante of ESP32 vs NRF5284, both would use the 2,4 GHz band, but ESP32 transmission power is +20dbm (vs +8 dbm for the NRF5284 if I am not mistaken), also, a barebone ESP32-WROOM price is 2 € and is not hard to hand-solder... to that you have to add the components to design a custom board but overall quite competitive.
Pre-production test:
Custom board (first try.. a cable to fix some design errors . 
)
@NeverDie, this could become one of those threads that would gather a wealth of knowledge to understand the multiple solutions in the DIY IoT ecosystem. It could be invaluable for a guy like me that is intermittently in and out of projects as a function of the “spare” time .
I talk about my own experience here. When I built my first MySensors project (10 years ago?) I had no skills in soldering or Arduino programming. After some reading in the howtos I bought some Moteinos with RFM69 (small soldering needed to attach the sensors) and got my first system working with serial gateway and Openhab quite fast. It still works, several temp & humidity nodes and one awning controller.
In the next “in” cycle (some 4 years later) I wanted something “bigger” and designed some custom PCBs with headers to attach ready-made LoRa boards (TTGO ESP32 OLED) in specialized nodes (multi-chamber wine fermentation controller, photovoltaic battery monitor with energy management, irrigation controller, …). Those boards are quite powerful for the price and well supported, but not friendly for battery operated nodes.
Recently we have to install a system to prevent flooding in a basement. We bought a Wifi flooding sensor and a Wifi controllable plug with energy meter that work with the SmartLife App (Tuya IoT cloud). 30 minutes and working reliably.. wow.. so easy. So I agree with @rejoe2, easy and some “no-so-easy” tasks are much readily available than 10 years ago and quite easy to implement for the average joe without the need to invest a lot of hours in creating your own infrastructure.. and also cheaper.
But when you want “special” sensors with more complex logic, if you are lucky and what you want exists, you will most likely have to pay the big price..., or you can build your own, like the MySensors people. So, I have been trying to enter in the next cycle for some time but I think I got too ambitious for my skills and it is taking some time to get to the practical implementation. I wanted to avoid the problems I suffered in the previous cycle with the TTGO (power hungry and poor ADC performance) so I started looking for a ready made board with LoRa and low power and good ADC and good price… and found Heltec LoRa Node 151 with STM32L151 … but there is no Arduino+MySensors support for the MCU… I also explored designing my own custom board based on STM32F1 (BluePill)… got a lot of problems with sleep functions in the tests so I dind't keep on that route… looked at CubeCell and its MySensors support provided by @eiten (ASR650x) still undecided whether it is worth to invest in an MCU from Asrock (future maintainability and ADC performance?).
I started to look outside of the MySensors framework to get those new MCUs working in a more self-sufficient way (not having to wait for new versions of MySensors to support these new boards). Solutions such as RadioDriver library + custom communication protocol + NodeRed decoder to Openhab. Yes, possible, but quite re-inventing the wheel and MySensors is such a well thought protocol…. When you start looking for alternatives you realize the quality work that is behind the project and the good support and community you can find here, so far I have not found an alternative, so I always come back to the forums and MySensors Github pulls to see if anything new is cooking.
What would be great for the next MySensors boost: that HALO multitransport gateway by @scalz , support for ESP-NOW as a transport protocol (just with a bare 3€ ESP32 WROOM module, some passives and external ADC and we could have a node with good 2,4GHz Radio and plenty mcu power), and support for the STM32 official core and SX126x radios (I could be wrong but the STM32WL series seems the sweet spot to me for long range coverage when small ready-made boards appear).
So my 2 cents for this topic translates into: for simple applications (that is what most average people is looking after) ready-made wifi devices exists and are much cheaper and easy to use. And on the other side of the spectrum, more advanced users looking for something “special” want to use some new hardware that is not jet supported... that could explain the decline in post activity in the forums.
@boozz said in CubeCell HAL anyone?:
What does HAL stand for?
Hardware Abstraction Layer. It is a middle piece (sort of translator) in the software where the characteristics of the hardware you are goint to use are defined so the software developers can use the same code for different architectures... and be aware I am very low in the coding chain, so this definition is my pure and ignorant understanding of the concept 
https://github.com/mysensors/MySensors/tree/master/hal/architecture
It is a very interesting board. I would also like to try it for future development. It has gained support in the arduino IDE and Platformio, but I beleive MySensors library is not ready to be used with it (at least I couldn't get it to compile) ... and I wouldn't know where to start to contribute and make it compatible...
@scalz said in Second setup, choosing a radio:
MySensors new driver is RFM69<->RFM95 communication compatible
Indeed this is very interesting!
Do you have any pointer to instructions on how to use this feature?
I am also currently working on my sencond MySensors setup and going the RFM95 route. My first setup was a RFM69, so if I can combine nodes from both without having two different gateways would be very convenient... it could also help in choosing the best hardware for each use case.
After some searching, the only thing I could find was this pull request in MySensors development branch, but I couldn't find any hint about how to make use of it:
https://github.com/mysensors/MySensors/pull/1414
@novicit, nice to hear hospital "repairs" doing well!
I don't have much time either, so, when I find some time in the weekends I try the following step...
A couple of things regarding your comments:
@novicit Using the link you provided I have confirmed that my board is a 128k flash variant (installing STM32CubeProgrammer" and launching its graphical IDE, not tried the command line option).
I have sucessfully compiled the koolru branch with PlatformIO and got the node to send messages go the gateway. What I did:
The platformio.ini file is:
[env:genericSTM32F103CB]
platform = ststm32
board = genericSTM32F103CB
framework = arduino
;board_build.core = maple
monitor_speed = 115200
monitor_filters = time, default
extra_scripts = pre:fix_main.py
lib_extra_dirs = H:\PlatformIO\custom_libraries\
[env:Sensor-Serial-Windows]
upload_port = COM7
monitor_port = COM7
[env:Sensor-Serial-Linux]
; any port that starts with /dev/ttyUSB
upload_port = /dev/ttyUSB*
monitor_port = /dev/ttyUSB*
Start of the compiling process (you can see that the python script is being executed and that the development version of MySensors is selected):
Processing genericSTM32F103CB (platform: ststm32; board: genericSTM32F103CB; framework: arduino)
------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
================================= STM32 FRAMEWORK PATCHER =================================
[INFO] Patching file: C:\Users\xxxxxx\.platformio\packages/framework-arduinoststm32-maple\STM32F1\cores\maple\main.cpp
[INFO] Patching file: C:\Users\xxxxxx\.platformio\packages/framework-arduinoststm32-maple\STM32F4\cores\maple\libmaple\main.cpp
============================================================================================
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/genericSTM32F103CB.html
PLATFORM: ST STM32 6.1.0 > STM32F103CB (20k RAM. 128k Flash)
HARDWARE: STM32F103CBT6 72MHz, 20KB RAM, 128KB Flash
DEBUG: Current (blackmagic) External (blackmagic, jlink, stlink)
PACKAGES:
- framework-arduinoststm32-maple 2.10000.200103 (1.0.0)
- toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 48 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <MySensors> 2.4.0-alpha
| |-- <Wire> 1.0
| |-- <SPI> 1.0
| |-- <EEPROM>
Building in release mode
And the compilation results (I got several warnings regarding SPI but the result is sucessful):
Building .pio\build\genericSTM32F103CB\firmware.bin
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM: [=== ] 26.3% (used 5384 bytes from 20480 bytes)
Flash: [==== ] 38.0% (used 49840 bytes from 131072 bytes)
================================================ [SUCCESS] Took 17.96 seconds ================================================
... @novicit you mention that using the script previously you couldn't get it to work.. check Python install and plugins.. also to debug MySensor messages I used a separate usb to TTL (not STLINK attached to PA9 and PA10 as I explained before).
... and now the next problem... the STM32LowPower.h library (to get the STM32 to deep sleep) is compiling properly in Arduino IDE but does not compile in PlatformIO ... again... 
I still have to try the commits by @KooLru .. (first I have to figure out how to use a commit in a library with the Arduino IDE ) but in the meantime I have found that the compiling problem with PlatformIO, STM32 and MySensors had been already documented in previous posts:
https://forum.mysensors.org/topic/10324/platformio-not-longer-working-with-mysensors/6
That also links to this post:
https://forum.mysensors.org/topic/10193/stm32f103c8-problem-at-compilation/12
That points to the ticket open in the PlatformIO and temporary workaroud (I have to learn to test it):
https://github.com/platformio/platform-ststm32/issues/283#issuecomment-533585597
I have tested the temporary solution in the github ticket and it has compiled for the mapple core. The Plaformio.ini file is:
[env:genericSTM32F103CB]
platform = ststm32
board = genericSTM32F103CB
framework = arduino
board_build.core = maple
extra_scripts = pre:fix_main.py
Before getting it to compile I had to install Python for the OS (in this case I am using Windows 10) and the Python extension for PlatformIO (I chose Microsoft one).
And also, it seems something has changed in the last versions of PlatformIO since solution post in the fix and I had to change the variable name in the Python script PROJECTPACKAGES_DIR by PROJECT_PACKAGES_DIR, so the line in the final line in that scrips is as follows:
STM32_FRAMEWORK_DIR = env['PROJECT_PACKAGES_DIR'] + "/framework-arduinoststm32-maple"
@novicit I can more or less confirm your results. I have used the PH dummy sketch to simulate a value sent to the gateway and it has worked perfectly. Using MySensors development branch the compilation results are:
Sketch uses 47216 bytes (72%) of program storage space. Maximum is 65536 bytes.
Global variables use 5384 bytes (26%) of dynamic memory, leaving 15096 bytes for local variables. Maximum is 20480 bytes.
This results are selecting the variant in the "STMF103C8 (20k RAM, 64k Flash)" of the board in the Arduino IDE tools menu.
However, In the multiple forums I have read about the STM32F103 it seems that regardless of the amount of memory the board you have bought, (64k or 128k) most of them are 128k,... so, you can always try 128k.. or buy 128k variants (STM32F103CB), in which case the compilation results give more headroom for bigger sketches:
Sketch uses 47216 bytes (36%) of program storage space. Maximum is 131072 bytes.
Global variables use 5384 bytes (26%) of dynamic memory, leaving 15096 bytes for local variables. Maximum is 20480 bytes.
I have tried changing the definition to the 128k variant and can confirm that the upload works and that the node works (message received in the gateway)... I don't know if the 64k of sketch are exceeded the code will upload... I believe the upload would have failed if the board does not have that flash memory space.
Find attached the sketch I am using that I can confirm that works... in my setup. I am using a SX1276 LoRa radio.
I used a STLink V2 clone to upload the sketch and a TTL to usb attached to PA9 and PA10 pins to serial print messages. To get Serial.print working (for MySensors connection debug) I had to redirect debug messages to Serial1 port (PA9 and PA10 in STM32 maple core). I believe that Serial corresponds to the on-board usb but mine does't work out of the box and I believe that I would have to upload first a bootloader in order to use it... so I took the short test route and used the TTL to usb instead.
// Enable debug prints to serial monitor
#define MY_DEBUG
// Enable and select radio type attached
//#define MY_RADIO_RF24
//#define MY_RADIO_NRF5_ESB
//#define MY_RADIO_RFM69
#define MY_RADIO_RFM95
#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW125CR45SF128 // Default, medium range
//#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW500CR45SF128 // Fast, short range
//#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW31_25CR48SF512 // Slow, long range
//#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW125CR48SF4096 // Slow, long range
// For RFM95 connections. Following: https://www.thethingsnetwork.org/labs/story/a-cheap-stm32-arduino-node
#define MY_RFM95_IRQ_PIN PA11 // SX1276's IRQ(Interrupt Request)
#define MY_RFM95_IRQ_NUM MY_RFM95_IRQ_PIN
#define MY_RFM95_CS_PIN PA4 // SX1276's CS (NSS)
#define MY_RFM95_RST_PIN PB0 // SX1276's RESET
//#define MY_SOFTSPI
#define MY_SOFT_SPI_SCK_PIN PA5 // SX1276's SCK
#define MY_SOFT_SPI_MISO_PIN PA6 // SX1276's MISnO
#define MY_SOFT_SPI_MOSI_PIN PA7 // SX1276's MOSI
//#define MY_RFM95_POWER_PIN (3) // What is this used for?
#define MY_SERIALDEVICE Serial1 // Force using Serial 1 (RX ->PA9 and TX -> PA10) for MySensor debug messages
// Define a static node address, remove if you want auto address assignment
#define MY_NODE_ID 70
//#define ARDUINO_ARCH_STM32F1
#include <MySensors.h>
#define COMPARE_PH 1 // Send PH only if changed? 1 = Yes 0 = No
const int ledPIN = PC13;
uint32_t SLEEP_TIME = 60000; // Sleep time between reads (in milliseconds)
float lastPH;
bool receivedConfig = false;
bool metric = true;
// Initialize PH message
MyMessage msg(0, V_PH);
void setup()
{
Serial1.begin(115200); //RX->PA9 / TX->PA10
// initialize digital pin PC13 as an outp
pinMode(ledPIN, OUTPUT);
//Setup your PH sensor here (I2C,Serial,Phidget...)
}
float getPH()
{
//query your PH sensor here (I2C,Serial,Phidget...)
float dummy = 7;
return dummy;
}
void presentation()
{
// Send the sketch version information to the gateway and Controller
//sendSketchInfo("PH Sensor", "1.1");
present(0, S_WATER_QUALITY);
}
void loop()
{
float ph = getPH();
Serial1.println("PH: ");Serial1.println(ph);
#if COMPARE_PH == 1
if (lastPH != ph) {
#endif
// Send in the new PH value
send(msg.set(ph, 1));
// Save new PH value for next compare
lastPH = ph;
#if COMPARE_PH == 1
}
#endif
wait(SLEEP_TIME);
}
@monte , @mfalkvidd ... Fantastic!!, is good to know that there there is development to support the official ST Core, for sure it will provide much better future stability with the new hardware from ST.
@novicit said in How to compile MySensors on Platformio for Blue Pill:
@CarloMagno Forgot to mention, in my clean install I created - the directory you described and did not work for me. Instead I just dropped the RogerClark core folder in the regular Arduino hardware folder and it worked. Program Files(x86)\Arduino\hardware\Arduino_STM32-master. The arduino IDE read it fine along with all its native hardware folders.
...It could be because I used the ZIP file to install the Arduino IDE instead of the windows installer... good to point if someone else faces the same problems.
.. still no luck in Platformio.
platformio.ini:
[env:genericSTM32F103CB]
platform = ststm32
board = genericSTM32F103CB
framework = arduino
board_build.core = maple
monitor_speed = 115200
monitor_filters = time, default
[env:Sensor-Serial-Windows]
upload_port = COM7
monitor_port = COM7
[env:Sensor-Serial-Linux]
; any port that starts with /dev/ttyUSB
upload_port = /dev/ttyUSB*
monitor_port = /dev/ttyUSB*
After some warnings regarding definition of SPI2 and not been used, we get to the error when MySensors is included:
Compiling .pio\build\genericSTM32F103CB\lib5ec\MySensors_ID548\MyASM.S.o
Archiving .pio\build\genericSTM32F103CB\lib473\libEEPROM.a
Archiving .pio\build\genericSTM32F103CB\libd15\libSPI.a
Archiving .pio\build\genericSTM32F103CB\lib5ec\libMySensors_ID548.a
Linking .pio\build\genericSTM32F103CB\firmware.elf
.pio\build\genericSTM32F103CB\src\main.cpp.o: In function `premain()':
main.cpp:(.text.startup._Z7premainv+0x0): multiple definition of `premain()'
.pio\build\genericSTM32F103CB\FrameworkArduino\main.cpp.o:main.cpp:(.text.startup._Z7premainv+0x0): first defined here
.pio\build\genericSTM32F103CB\src\main.cpp.o: In function `main':
main.cpp:(.text.startup.main+0x0): multiple definition of `main'
.pio\build\genericSTM32F103CB\FrameworkArduino\main.cpp.o:main.cpp:(.text.startup.main+0x0): first defined here
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\genericSTM32F103CB\firmware.elf] Error 1
================================================ [FAILED] Took 19.66 seconds ================================================
For what I understand of the error... (nothing)... It seems it will take me quite some time to go any further... At least Arduino IDE is working and I can start testing the Radio with that.
I will answer to myself... forcing the architecture in the sketch including this line before MySensors (it should be picked automatically but it seems it's not):
#define ARDUINO_ARCH_STM32F1
#include <MySensors.h>
The error now goes to the hardware definition where indeed it seems it expects to have the maple core:
In file included from C:\Users\xxxxx\Documents\Arduino\libraries\MySensors-development/hal/architecture/STM32F1/MyHwSTM32F1.cpp:20,
from C:\Users\xxxxx\Documents\Arduino\libraries\MySensors-development/MySensors.h:71,
from C:\Users\xxxxx\Documents\Arduino\STM32_MySensors_Test1_v0\STM32_MySensors_Test1_v0.ino:56:
C:\Users\xxxxx\Documents\Arduino\libraries\MySensors-development/hal/architecture/STM32F1/MyHwSTM32F1.h:23:10: fatal error: libmaple/iwdg.h: No such file or directory
23 | #include <libmaple/iwdg.h>
| ^~~~~~~~~~~~~~~~~
compilation terminated.
exit status 1
Error compiling for board Generic STM32F1 series.
I quick search pointed to the Roger Clark github repository (it seems it is the origin of STM32 support in Arduino IDE) https://github.com/rogerclarkmelbourne/Arduino_STM32
I downloaded the zip file with the repository, created a hardware folder in MyDocuments/arduino folder (it did't exist), and decompressed the zip there. The folder structure is as follows:
C:\Users\xxxxx\Documents\Arduino\hardware\Arduino_STM32-master
I closed the Arduino IDE and opened it again so the new boards definition would be available, and in the type of board, under the new group "STM32F1 Boards (STM32duino.com)" I selected the board type "Generic STM32F103C series" and everything compiles OK, (with or without the line #define ARDUINO_ARCH_STM32F1
Now I have to check if following the indication in https://docs.platformio.org/en/latest/platforms/ststm32.html, including the option "board_build.core = maple" in platformio.ini the compilation will force to use the maple core that seems the one working with MySensors.
Well, I have tried the Arduino IDE both with the current stable version of MySensors and with the Development version. In both cases i get a HAL error:
In file included from C:\Users\xxxxx\Documents\Arduino\STM32_MySensors_Test1_v0\STM32_MySensors_Test1_v0.ino:56:
C:\Users\xxxxx\Documents\Arduino\libraries\MySensors-development/MySensors.h:83:2: error: #error Hardware abstraction not defined (unsupported platform)
83 | #error Hardware abstraction not defined (unsupported platform)
| ^~~~~
exit status 1
Error compiling for board Generic STM32F1 series.
Line 56 of the sketch is
#include <MySensors.h>
So it seems it is related to the compatibility of the official STM32 core provided by ST and the MySensors library. I believe I have read somewhere that the successful implementation of MySensors and STM32 was using another core... I have to dig a little bit more about it. Nevertheless. I'd rather use the ST "official" core as it seems it supports a great number of board and is in continuous development, so new boards that appear could be ready to use... (Cube Cell looks really nice but integrates another type of LoRa radio that I believe will require quite more work from MySensors to get it supported).
Hi @novicit ,
I was just trying to test a BluePill adding a LoRa chip (SX1276) as a new type of MySensors node but got blocked in the first step (no compiling when I include MySensors library).
In PlatoformIO I installed the default platform (STSTM32). Sorry I cannot give you a solution,...
Did you get MySensors to compile in the Arduino environment with STM32? (planning to give it a try if it works). Which boards definition?.
If you are interested I could post the compiler output, but I believe is of no use to you since I have not digged much into the issue. I have used ESP32 and ATmega328 variants in the past with MySensors but wanted to give a try to STM32 architecture as it seems quite promissing when dealing with Analog signals (ADC specs), so I am still at the begginin of the journey...
@yveaux Thank you for the replay.
I read that post when I was testing the board but I don't know much about radio protocols and I get a little confused trying to extrapolate the information in that post to MySensors. The boards I have are version v1.2 (printed in the PCB).
What I understood from the post (I could be totally wrong), is that if I want to implement LoRaWan protocol with that board I would need to solder DIO1 and DIO2 to some IO pins (preferably pin5 and pin6 using wire instead of the 1 and 2 that would be the easy ones with the soldering pads). But I believe for radio use with MySensors (no LoRaWan) I don't have to solder DIO1 or DIO2... (Is this assumption right?) as I got the boards talking to each other with the RadioHead library and the pin definitions I posted the sketch.
RadioHead TX test sketch:
// Feather9x_TX
// -*- mode: C++ -*-
// Example sketch showing how to create a simple messaging client (transmitter)
// with the RH_RF95 class. RH_RF95 class does not provide for addressing or
// reliability, so you should only use RH_RF95 if you do not need the higher
// level messaging abilities.
// It is designed to work with the other example Feather9x_RX
#include <SPI.h>
#include <RH_RF95.h>
// for feather32u4
#define RFM95_CS 8
#define RFM95_RST 4
#define RFM95_INT 7
/* for feather m0
#define RFM95_CS 8
#define RFM95_RST 4
#define RFM95_INT 3
*/
/* for shield
#define RFM95_CS 10
#define RFM95_RST 9
#define RFM95_INT 7
*/
/* Feather 32u4 w/wing
#define RFM95_RST 11 // "A"
#define RFM95_CS 10 // "B"
#define RFM95_INT 2 // "SDA" (only SDA/SCL/RX/TX have IRQ!)
*/
/* Feather m0 w/wing
#define RFM95_RST 11 // "A"
#define RFM95_CS 10 // "B"
#define RFM95_INT 6 // "D"
*/
#if defined(ESP8266)
/* for ESP w/featherwing */
#define RFM95_CS 2 // "E"
#define RFM95_RST 16 // "D"
#define RFM95_INT 15 // "B"
#elif defined(ESP32)
/* ESP32 feather w/wing */
#define RFM95_RST 27 // "A"
#define RFM95_CS 33 // "B"
#define RFM95_INT 12 // next to A
#elif defined(NRF52)
/* nRF52832 feather w/wing */
#define RFM95_RST 7 // "A"
#define RFM95_CS 11 // "B"
#define RFM95_INT 31 // "C"
#elif defined(TEENSYDUINO)
/* Teensy 3.x w/wing */
#define RFM95_RST 9 // "A"
#define RFM95_CS 10 // "B"
#define RFM95_INT 4 // "C"
#endif
// Change to 434.0 or other frequency, must match RX's freq!
#define RF95_FREQ 868.0
// Singleton instance of the radio driver
RH_RF95 rf95(RFM95_CS, RFM95_INT);
void setup()
{
pinMode(RFM95_RST, OUTPUT);
digitalWrite(RFM95_RST, HIGH);
Serial.begin(115200);
while (!Serial) {
delay(1);
}
delay(100);
Serial.println("Feather LoRa TX Test!");
// manual reset
digitalWrite(RFM95_RST, LOW);
delay(10);
digitalWrite(RFM95_RST, HIGH);
delay(10);
while (!rf95.init()) {
Serial.println("LoRa radio init failed");
Serial.println("Uncomment '#define SERIAL_DEBUG' in RH_RF95.cpp for detailed debug info");
while (1);
}
Serial.println("LoRa radio init OK!");
// Defaults after init are 434.0MHz, modulation GFSK_Rb250Fd250, +13dbM
if (!rf95.setFrequency(RF95_FREQ)) {
Serial.println("setFrequency failed");
while (1);
}
Serial.print("Set Freq to: "); Serial.println(RF95_FREQ);
// Defaults after init are 434.0MHz, 13dBm, Bw = 125 kHz, Cr = 4/5, Sf = 128chips/symbol, CRC on
// The default transmitter power is 13dBm, using PA_BOOST.
// If you are using RFM95/96/97/98 modules which uses the PA_BOOST transmitter pin, then
// you can set transmitter powers from 5 to 23 dBm:
rf95.setTxPower(23, false);
}
int16_t packetnum = 0; // packet counter, we increment per xmission
void loop()
{
delay(1000); // Wait 1 second between transmits, could also 'sleep' here!
Serial.println("Transmitting..."); // Send a message to rf95_server
char radiopacket[20] = "Hello World # ";
itoa(packetnum++, radiopacket+13, 10);
Serial.print("Sending "); Serial.println(radiopacket);
radiopacket[19] = 0;
Serial.println("Sending...");
delay(10);
rf95.send((uint8_t *)radiopacket, 20);
Serial.println("Waiting for packet to complete...");
delay(10);
rf95.waitPacketSent();
// Now wait for a reply
uint8_t buf[RH_RF95_MAX_MESSAGE_LEN];
uint8_t len = sizeof(buf);
Serial.println("Waiting for reply...");
if (rf95.waitAvailableTimeout(1000))
{
// Should be a reply message for us now
if (rf95.recv(buf, &len))
{
Serial.print("Got reply: ");
Serial.println((char*)buf);
Serial.print("RSSI: ");
Serial.println(rf95.lastRssi(), DEC);
}
else
{
Serial.println("Receive failed");
}
}
else
{
Serial.println("No reply, is there a listener around?");
}
}
RadioHead RX Test Sketch:
// Feather9x_RX
// -*- mode: C++ -*-
// Example sketch showing how to create a simple messaging client (receiver)
// with the RH_RF95 class. RH_RF95 class does not provide for addressing or
// reliability, so you should only use RH_RF95 if you do not need the higher
// level messaging abilities.
// It is designed to work with the other example Feather9x_TX
#include <SPI.h>
#include <RH_RF95.h>
// for Feather32u4 RFM9x
#define RFM95_CS 8
#define RFM95_RST 4
#define RFM95_INT 7
/* for feather m0 RFM9x
#define RFM95_CS 8
#define RFM95_RST 4
#define RFM95_INT 3
*/
/* for shield
#define RFM95_CS 10
#define RFM95_RST 9
#define RFM95_INT 7
*/
/* Feather 32u4 w/wing
#define RFM95_RST 11 // "A"
#define RFM95_CS 10 // "B"
#define RFM95_INT 2 // "SDA" (only SDA/SCL/RX/TX have IRQ!)
*/
/* Feather m0 w/wing
#define RFM95_RST 11 // "A"
#define RFM95_CS 10 // "B"
#define RFM95_INT 6 // "D"
*/
#if defined(ESP8266)
/* for ESP w/featherwing */
#define RFM95_CS 2 // "E"
#define RFM95_RST 16 // "D"
#define RFM95_INT 15 // "B"
#elif defined(ESP32)
/* ESP32 feather w/wing */
#define RFM95_RST 27 // "A"
#define RFM95_CS 33 // "B"
#define RFM95_INT 12 // next to A
#elif defined(NRF52)
/* nRF52832 feather w/wing */
#define RFM95_RST 7 // "A"
#define RFM95_CS 11 // "B"
#define RFM95_INT 31 // "C"
#elif defined(TEENSYDUINO)
/* Teensy 3.x w/wing */
#define RFM95_RST 9 // "A"
#define RFM95_CS 10 // "B"
#define RFM95_INT 4 // "C"
#endif
// Change to 434.0 or other frequency, must match RX's freq!
#define RF95_FREQ 868.0
// Singleton instance of the radio driver
RH_RF95 rf95(RFM95_CS, RFM95_INT);
// Blinky on receipt
#define LED 13
void setup()
{
pinMode(LED, OUTPUT);
pinMode(RFM95_RST, OUTPUT);
digitalWrite(RFM95_RST, HIGH);
Serial.begin(115200);
while (!Serial) {
delay(1);
}
delay(100);
Serial.println("Feather LoRa RX Test!");
// manual reset
digitalWrite(RFM95_RST, LOW);
delay(10);
digitalWrite(RFM95_RST, HIGH);
delay(10);
while (!rf95.init()) {
Serial.println("LoRa radio init failed");
Serial.println("Uncomment '#define SERIAL_DEBUG' in RH_RF95.cpp for detailed debug info");
while (1);
}
Serial.println("LoRa radio init OK!");
// Defaults after init are 434.0MHz, modulation GFSK_Rb250Fd250, +13dbM
if (!rf95.setFrequency(RF95_FREQ)) {
Serial.println("setFrequency failed");
while (1);
}
Serial.print("Set Freq to: "); Serial.println(RF95_FREQ);
// Defaults after init are 434.0MHz, 13dBm, Bw = 125 kHz, Cr = 4/5, Sf = 128chips/symbol, CRC on
// The default transmitter power is 13dBm, using PA_BOOST.
// If you are using RFM95/96/97/98 modules which uses the PA_BOOST transmitter pin, then
// you can set transmitter powers from 5 to 23 dBm:
rf95.setTxPower(23, false);
}
void loop()
{
if (rf95.available())
{
// Should be a message for us now
uint8_t buf[RH_RF95_MAX_MESSAGE_LEN];
uint8_t len = sizeof(buf);
if (rf95.recv(buf, &len))
{
digitalWrite(LED, HIGH);
RH_RF95::printBuffer("Received: ", buf, len);
Serial.print("Got: ");
Serial.println((char*)buf);
Serial.print("RSSI: ");
Serial.println(rf95.lastRssi(), DEC);
// Send a reply
uint8_t data[] = "And hello back to you";
rf95.send(data, sizeof(data));
rf95.waitPacketSent();
Serial.println("Sent a reply");
digitalWrite(LED, LOW);
}
else
{
Serial.println("Receive failed");
}
}
}
The receiver node got the message with this library and without soldering DIO1 and DIO2.
Thanks again for the support!
@mfalkvidd Thank you for the support.
You are right, I forgot to post the logs, and without the logs I can imagine it is impossible to guess what is happening.
Find attached the logs from the Node (Node 10 in this case) taken from the serial output connected to a computer, and the logs from the Gateway taken from the Controller (Openhab) web log viewer to which the gateway is attached through the serial port (Serial gateway):
Node 10 log:
15:04:10.595 -> 7026 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:04:12.610 -> 9027 !TSM:FPAR:NO REPLY
15:04:12.610 -> 9027 TSM:FPAR
15:04:19.600 -> 16029 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:04:21.596 -> 18032 !TSM:FPAR:NO REPLY
15:04:21.596 -> 18032 TSM:FPAR
15:04:28.569 -> 25034 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:04:30.573 -> 27037 !TSM:FPAR:NO REPLY
15:04:30.573 -> 27037 TSM:FPAR
15:04:37.566 -> 34039 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:04:39.577 -> 36042 !TSM:FPAR:FAIL
15:04:39.577 -> 36042 TSM:FAIL:CNT=1
15:04:39.577 -> 36042 TSM:FAIL:DIS
15:04:39.577 -> 36044 TSF:TDI:TSL
15:04:49.559 -> 46045 TSM:FAIL:RE-INIT
15:04:49.606 -> 46045 TSM:INIT
15:04:49.606 -> 46061 TSM:INIT:TSP OK
15:04:49.606 -> 46061 TSM:INIT:STATID=10
15:04:49.606 -> 46063 TSF:SID:OK,ID=10
15:04:49.606 -> 46063 TSM:FPAR
15:04:59.001 -> 53065 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:04:59.001 -> 55068 !TSM:FPAR:NO REPLY
15:04:59.001 -> 55068 TSM:FPAR
15:05:05.576 -> 62070 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:05:07.591 -> 64073 !TSM:FPAR:NO REPLY
15:05:07.591 -> 64073 TSM:FPAR
15:05:14.578 -> 71075 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:05:16.610 -> 73078 !TSM:FPAR:NO REPLY
15:05:16.610 -> 73078 TSM:FPAR
15:05:23.594 -> 80080 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:05:25.614 -> 82083 !TSM:FPAR:FAIL
15:05:25.614 -> 82083 TSM:FAIL:CNT=2
15:05:25.614 -> 82083 TSM:FAIL:DIS
15:05:25.614 -> 82085 TSF:TDI:TSL
15:05:35.568 -> 92086 TSM:FAIL:RE-INIT
15:05:35.568 -> 92086 TSM:INIT
15:05:35.615 -> 92102 TSM:INIT:TSP OK
15:05:35.615 -> 92102 TSM:INIT:STATID=10
15:05:35.615 -> 92104 TSF:SID:OK,ID=10
15:05:35.615 -> 92104 TSM:FPAR
15:05:42.619 -> 99106 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:05:44.626 -> 101109 !TSM:FPAR:NO REPLY
15:05:44.626 -> 101109 TSM:FPAR
15:05:51.590 -> 108111 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:05:53.582 -> 110114 !TSM:FPAR:NO REPLY
15:05:53.582 -> 110114 TSM:FPAR
15:06:00.582 -> 117116 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:06:02.609 -> 119119 !TSM:FPAR:NO REPLY
15:06:02.609 -> 119119 TSM:FPAR
15:06:09.589 -> 126121 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:06:11.592 -> 128126 !TSM:FPAR:FAIL
15:06:11.592 -> 128126 TSM:FAIL:CNT=3
15:06:11.592 -> 128126 TSM:FAIL:DIS
15:06:11.592 -> 128129 TSF:TDI:TSL
15:06:21.571 -> 138131 TSM:FAIL:RE-INIT
15:06:21.607 -> 138131 TSM:INIT
15:06:21.607 -> 138147 TSM:INIT:TSP OK
15:06:21.607 -> 138147 TSM:INIT:STATID=10
15:06:21.607 -> 138149 TSF:SID:OK,ID=10
15:06:21.607 -> 138149 TSM:FPAR
15:06:28.620 -> 145152 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:06:30.594 -> 147156 !TSM:FPAR:NO REPLY
15:06:30.594 -> 147156 TSM:FPAR
15:06:37.610 -> 154157 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:06:39.606 -> 156160 !TSM:FPAR:NO REPLY
15:06:39.606 -> 156160 TSM:FPAR
15:06:46.607 -> 163160 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:06:48.582 -> 165163 !TSM:FPAR:NO REPLY
15:06:48.582 -> 165163 TSM:FPAR
15:06:55.595 -> 172163 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:06:57.580 -> 174166 !TSM:FPAR:FAIL
15:06:57.580 -> 174166 TSM:FAIL:CNT=4
15:06:57.580 -> 174166 TSM:FAIL:DIS
15:06:57.580 -> 174168 TSF:TDI:TSL
15:07:07.588 -> 184170 TSM:FAIL:RE-INIT
15:07:07.588 -> 184170 TSM:INIT
15:07:07.635 -> 184186 TSM:INIT:TSP OK
15:07:07.635 -> 184186 TSM:INIT:STATID=10
15:07:07.635 -> 184188 TSF:SID:OK,ID=10
15:07:07.635 -> 184188 TSM:FPAR
15:07:14.597 -> 191191 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:07:16.606 -> 193196 !TSM:FPAR:NO REPLY
15:07:16.606 -> 193196 TSM:FPAR
15:07:23.598 -> 200196 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:07:25.625 -> 202199 !TSM:FPAR:NO REPLY
15:07:25.625 -> 202199 TSM:FPAR
15:07:32.584 -> 209199 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:07:34.604 -> 211202 !TSM:FPAR:NO REPLY
15:07:34.604 -> 211202 TSM:FPAR
15:07:41.599 -> 218202 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:07:43.611 -> 220205 !TSM:FPAR:FAIL
15:07:43.611 -> 220205 TSM:FAIL:CNT=5
15:07:43.611 -> 220205 TSM:FAIL:DIS
15:07:43.611 -> 220207 TSF:TDI:TSL
15:07:53.620 -> 230209 TSM:FAIL:RE-INIT
15:07:53.620 -> 230209 TSM:INIT
15:07:53.620 -> 230225 TSM:INIT:TSP OK
15:07:53.620 -> 230225 TSM:INIT:STATID=10
15:07:53.620 -> 230227 TSF:SID:OK,ID=10
15:07:53.620 -> 230227 TSM:FPAR
15:08:00.605 -> 237230 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:08:02.590 -> 239233 !TSM:FPAR:NO REPLY
15:08:02.637 -> 239233 TSM:FPAR
15:08:09.599 -> 246233 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:08:11.591 -> 248236 !TSM:FPAR:NO REPLY
15:08:11.591 -> 248236 TSM:FPAR
15:08:18.613 -> 255236 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:08:20.594 -> 257239 !TSM:FPAR:NO REPLY
15:08:20.594 -> 257239 TSM:FPAR
15:08:27.584 -> 264239 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
15:08:29.623 -> 266242 !TSM:FPAR:FAIL
15:08:29.623 -> 266242 TSM:FAIL:CNT=6
15:08:29.623 -> 266242 TSM:FAIL:DIS
15:08:29.623 -> 266244 TSF:TDI:TSL
And the Gateway Log (serial messages received in Openhab):
2019-09-11 15:01:34.805 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2400215 TSM:READY:NWD REQ
2019-09-11 15:01:34.869 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2400266 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
2019-09-11 15:04:05.668 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2551047 TSF:MSG:READ,10-10-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
2019-09-11 15:04:05.671 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2551053 TSF:MSG:BC
2019-09-11 15:04:05.673 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2551058 TSF:MSG:FPAR REQ,ID=10
2019-09-11 15:04:05.676 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2551064 TSF:PNG:SEND,TO=0
2019-09-11 15:04:05.678 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2551070 TSF:CKU:OK
2019-09-11 15:04:05.681 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2551075 TSF:MSG:GWL OK
2019-09-11 15:04:09.578 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2554976 !TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
2019-09-11 15:04:14.652 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2560042 TSF:MSG:READ,10-10-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
2019-09-11 15:04:14.658 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2560049 TSF:MSG:BC
2019-09-11 15:04:14.661 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2560054 TSF:MSG:FPAR REQ,ID=10
2019-09-11 15:04:14.668 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2560060 TSF:CKU:OK,FCTRL
2019-09-11 15:04:14.677 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2560065 TSF:MSG:GWL OK
2019-09-11 15:04:18.292 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2563672 !TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
2019-09-11 15:04:23.658 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2569040 TSF:MSG:READ,10-10-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
2019-09-11 15:04:23.662 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2569046 TSF:MSG:BC
2019-09-11 15:04:23.666 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2569051 TSF:MSG:FPAR REQ,ID=10
2019-09-11 15:04:23.670 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2569057 TSF:CKU:OK,FCTRL
2019-09-11 15:04:23.673 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2569063 TSF:MSG:GWL OK
2019-09-11 15:04:28.133 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2573528 !TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
2019-09-11 15:04:32.646 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2578038 TSF:MSG:READ,10-10-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
2019-09-11 15:04:32.651 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2578044 TSF:MSG:BC
2019-09-11 15:04:32.654 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2578049 TSF:MSG:FPAR REQ,ID=10
2019-09-11 15:04:32.659 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2578055 TSF:CKU:OK,FCTRL
2019-09-11 15:04:32.665 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2578060 TSF:MSG:GWL OK
2019-09-11 15:04:36.990 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2582384 !TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
2019-09-11 15:04:51.662 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2597048 TSF:MSG:READ,10-10-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
2019-09-11 15:04:51.668 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2597054 TSF:MSG:BC
2019-09-11 15:04:51.671 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2597059 TSF:MSG:FPAR REQ,ID=10
2019-09-11 15:04:51.676 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2597065 TSF:PNG:SEND,TO=0
2019-09-11 15:04:51.680 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2597071 TSF:CKU:OK
2019-09-11 15:04:51.687 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2597076 TSF:MSG:GWL OK
2019-09-11 15:04:55.485 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2600884 !TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
2019-09-11 15:05:00.659 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2606046 TSF:MSG:READ,10-10-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
2019-09-11 15:05:00.665 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2606052 TSF:MSG:BC
2019-09-11 15:05:00.671 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2606057 TSF:MSG:FPAR REQ,ID=10
2019-09-11 15:05:00.675 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2606063 TSF:CKU:OK,FCTRL
2019-09-11 15:05:00.679 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2606068 TSF:MSG:GWL OK
2019-09-11 15:05:05.170 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2610572 !TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
2019-09-11 15:05:09.646 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2615043 TSF:MSG:READ,10-10-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
2019-09-11 15:05:09.652 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2615049 TSF:MSG:BC
2019-09-11 15:05:09.656 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2615054 TSF:MSG:FPAR REQ,ID=10
2019-09-11 15:05:09.665 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2615060 TSF:CKU:OK,FCTRL
2019-09-11 15:05:09.668 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2615066 TSF:MSG:GWL OK
2019-09-11 15:05:14.090 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2619492 !TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
2019-09-11 15:05:18.651 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2624041 TSF:MSG:READ,10-10-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
2019-09-11 15:05:18.654 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2624047 TSF:MSG:BC
2019-09-11 15:05:18.658 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2624052 TSF:MSG:FPAR REQ,ID=10
2019-09-11 15:05:18.662 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2624058 TSF:CKU:OK,FCTRL
2019-09-11 15:05:18.670 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2624063 TSF:MSG:GWL OK
2019-09-11 15:05:22.844 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2628248 !TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
2019-09-11 15:05:37.654 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2643051 TSF:MSG:READ,10-10-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
2019-09-11 15:05:37.666 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2643057 TSF:MSG:BC
2019-09-11 15:05:37.683 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2643062 TSF:MSG:FPAR REQ,ID=10
2019-09-11 15:05:37.695 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2643068 TSF:PNG:SEND,TO=0
2019-09-11 15:05:37.702 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2643074 TSF:CKU:OK
2019-09-11 15:05:37.706 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2643078 TSF:MSG:GWL OK
2019-09-11 15:05:41.453 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2646848 !TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
2019-09-11 15:05:46.656 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2652048 TSF:MSG:READ,10-10-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
2019-09-11 15:05:46.665 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2652055 TSF:MSG:BC
2019-09-11 15:05:46.669 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2652060 TSF:MSG:FPAR REQ,ID=10
2019-09-11 15:05:46.673 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2652066 TSF:CKU:OK,FCTRL
2019-09-11 15:05:46.680 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2652071 TSF:MSG:GWL OK
2019-09-11 15:05:51.232 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2656636 !TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
2019-09-11 15:05:55.659 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2661046 TSF:MSG:READ,10-10-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
2019-09-11 15:05:55.663 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2661052 TSF:MSG:BC
2019-09-11 15:05:55.667 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2661057 TSF:MSG:FPAR REQ,ID=10
2019-09-11 15:05:55.671 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2661063 TSF:CKU:OK,FCTRL
2019-09-11 15:05:55.675 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2661069 TSF:MSG:GWL OK
2019-09-11 15:05:59.959 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2665356 !TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
2019-09-11 15:06:04.653 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2670044 TSF:MSG:READ,10-10-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
2019-09-11 15:06:04.657 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2670050 TSF:MSG:BC
2019-09-11 15:06:04.660 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2670055 TSF:MSG:FPAR REQ,ID=10
2019-09-11 15:06:04.664 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2670061 TSF:CKU:OK,FCTRL
2019-09-11 15:06:04.671 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2670066 TSF:MSG:GWL OK
2019-09-11 15:06:08.753 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2674148 !TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
2019-09-11 15:06:23.669 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2689060 TSF:MSG:READ,10-10-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
2019-09-11 15:06:23.676 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2689066 TSF:MSG:BC
2019-09-11 15:06:23.681 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2689071 TSF:MSG:FPAR REQ,ID=10
2019-09-11 15:06:23.685 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2689077 TSF:PNG:SEND,TO=0
2019-09-11 15:06:23.696 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2689082 TSF:CKU:OK
2019-09-11 15:06:23.711 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2689087 TSF:MSG:GWL OK
2019-09-11 15:06:27.381 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2692780 !TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
2019-09-11 15:06:32.656 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2698057 TSF:MSG:READ,10-10-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
2019-09-11 15:06:32.660 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2698064 TSF:MSG:BC
2019-09-11 15:06:32.675 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2698069 TSF:MSG:FPAR REQ,ID=10
2019-09-11 15:06:32.679 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;2698074 TSF:CKU:OK,FCTRL
The logs from the gateway is a little bit more dificult to follow because of the lenght of the messages due to the heading from Openhab preciding the debug messages.
Regarding the <MyConfig.h>, I believe it is because I have used it in the first MySensors implementation I did... some years ago (version 1.4) it was required.. I think.. and I have copied it in this new implementation.
EDIT: The logs received in the Gateway is using the TTGO ESP32 Lora as gateway and Lora32U4 as Node. If I use another Lora32U4 as gateway no messages are received. With the TTGO at least I see that when I power the Node, the Gateway starts receiving messages indicating that there is communication and that the transmission part in the Lora32U4 is working.
I have recently bought 2 units of the board BSFrance Lora32u4 ii and I have been unable to get Mysensors library working with this boards.
The boards seems to be a clone of Adafruit Feather 32u4 RFM95
The board has a SX1276 radio module and the following pinout:
If I set a Serial Gateway (controller is Openhab in RPI3) with one of the boards and the other board as a node there is no message received in the gateway.
The problem seems related to the reception (the transmission seems to work) because if i use as a gateway the board TTGO ESP32 Lora v2.0 I can see in the gateway logs some messages from the Lora32U4 node requesting to engage (Find Parent) and that the gateway replays but in the node the answer is never received.
If I use RadioHead library with sender and receiver sketch with the 2 Lora32U4 boards, the transmission works perfectly in both directions (Transmission and Receptoin), so the hardware seems to be OK and I believe the problem may be with MySensors.
Has anybody have any success with these boards and MySensors.
Gateway Sketch:
/* MySesors Gateway with Lora32U4 II v1.2 board
* Enable debug prints to serial monitor
* Gateway configuration in openhab connected to RPI 3B+ : /dev/ttyUSB0
* disable check in start up
*
* v0:
*/
//Activate debug prints in MySensors library
// Enable and select radio type attached
#define MY_RADIO_RFM95
#define MY_DEBUG
#define MY_DEBUG_VERBOSE_RFM95
//#define MY_DEBUG_VERBOSE_RFM95_REGISTERS
//#define MY_RFM95_ATC_TARGET_RSSI (-70) // target RSSI -70dBm
//#define MY_RFM95_MAX_POWER_LEVEL_DBM (20) // max. TX power 10dBm = 10mW
#define MY_RFM95_FREQUENCY (RFM95_868MHZ)
#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW125CR45SF128
// Enables and select radio type (if attached)
//#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW125CR45SF128 // Default, medium range
//#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW500CR45SF128 // Fast, short range
//#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW31_25CR48SF512 // Slow, long range
//#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW125CR48SF4096 // Slow, long range
// Definitions to improve RFM95 communication
#define RFM95_RETRY_TIMEOUT_MS (5000ul) //!< Timeout for ACK, adjustments needed if modem configuration changed (air time different) in drivers/RFM95/RFM95.h (default: 500ul)
#define MY_TRANSPORT_STATE_TIMEOUT_MS (30*1000ul) //!< 2 changed to RFM95W Ultra long Range enable general state timeout (in ms) in Mytransport.h (default: 2*1000ul)
// For RFM95 connections in LoRA32U4 (Adafruit and BSFrance do not use the standard configuration)
#define MY_RFM95_IRQ_PIN 7
#define MY_RFM95_IRQ_NUM MY_RFM95_IRQ_PIN
//#define MY_RF69_IRQ_NUM 4
#define MY_RFM95_CS_PIN 8
#define MY_RFM95_RST_PIN 4
//#define MY_SOFTSPI
#define MY_SOFT_SPI_SCK_PIN 15
#define MY_SOFT_SPI_MISO_PIN 14
#define MY_SOFT_SPI_MOSI_PIN 16
//#define MY_RFM95_POWER_PIN (3) // What is this used for?
// Enable serial gateway
#define MY_GATEWAY_SERIAL
// Enable inclusion mode
// Set blinking period
#define MY_DEFAULT_LED_BLINK_PERIOD 300
#include <Wire.h> // I2C handling library
// MySensors - Version: 2.3.2-Development (works with ESP32)
#include <MyConfig.h>
#include <MySensors.h>
void setup()
{
static boolean state = HIGH;
static unsigned char count = 0;
// Set console baud rate to monitor
Serial.begin(115200);
while (!Serial && (count < 10) )
{
delay(100); // Wait for serial port to connect with timeout. Needed for native USB
//digitalWrite(LED_BUILTIN, state); LED Pin connected to SDA Pin. Do not use Builtin led in this device
//state = !state;
count++;
}
Wire.begin(); // Start I2C port in case used libraries do not open it
delay(100);
}
void presentation()
{
// Present locally attached sensors here
}
void loop()
{
}
Node Sketch:
/*
* MySesors Node LORA32U4II (adafruit feather equivalent)
*
* v0: 2 simulated child sensors attached to node
*
*/
//Activate debug prints in MySensors library
// Enable and select radio type attached
#define MY_RADIO_RFM95
#define MY_DEBUG
#define MY_DEBUG_VERBOSE_RFM95
//#define MY_DEBUG_VERBOSE_RFM95_REGISTERS
//#define MY_RFM95_ATC_TARGET_RSSI (-70) // target RSSI -70dBm
//#define MY_RFM95_MAX_POWER_LEVEL_DBM (20) // max. TX power 10dBm = 10mW
#define MY_RFM95_FREQUENCY (RFM95_868MHZ)
#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW125CR45SF128
// Enables and select radio type (if attached)
//#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW125CR45SF128 // Default, medium range
//#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW500CR45SF128 // Fast, short range
//#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW31_25CR48SF512 // Slow, long range
//#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW125CR48SF4096 // Slow, long range
// Definitions to improve RFM95 communication
#define RFM95_RETRY_TIMEOUT_MS (5000ul) //!< Timeout for ACK, adjustments needed if modem configuration changed (air time different) in drivers/RFM95/RFM95.h (default: 500ul)
#define MY_TRANSPORT_STATE_TIMEOUT_MS (30*1000ul) //!< 2 changed to RFM95W Ultra long Range enable general state timeout (in ms) in Mytransport.h (default: 2*1000ul)
// For RFM95 connections in LoRA32U4 (Adafruit and BSFrance do not use the standard configuration)
#define MY_RFM95_IRQ_PIN 7
#define MY_RFM95_IRQ_NUM MY_RFM95_IRQ_PIN
//#define MY_RF69_IRQ_NUM 4
#define MY_RFM95_CS_PIN 8
#define MY_RFM95_RST_PIN 4
//#define MY_SOFTSPI
#define MY_SOFT_SPI_SCK_PIN 15
#define MY_SOFT_SPI_MISO_PIN 14
#define MY_SOFT_SPI_MOSI_PIN 16
//#define MY_RFM95_POWER_PIN (3) // What is this used for?
// Define a static node address, remove if you want auto address assignment
#define MY_NODE_ID 10
// Sensor Child ID of the NODE
#define CHILD_ID_BA_Volt_Bateria 0 // Voltaje de Batería
#define CHILD_ID_BA_Volt_Med_Bateria 1 // Voltaje del punto medio de la Batería
// MySensors - Version: 2.3.2-Development (works with ESP32)
#include <MyConfig.h>
#include <MySensors.h>
unsigned long lastmillis;
float BA_Volt_Bateria;
float BA_Volt_Bateria_last=0.0;
float BA_Volt_Med_Bateria;
float BA_Volt_Med_Bateria_last=0.0;
boolean metric = true; // Gateway uses metric system
// MySensors message definition
MyMessage msg_BA_Volt_Bateria(CHILD_ID_BA_Volt_Bateria, V_VOLTAGE);
MyMessage msg_BA_Volt_Med_Bateria(CHILD_ID_BA_Volt_Med_Bateria, V_VOLTAGE);
void setup()
{
static boolean state = HIGH;
static unsigned char count = 0;
// Set console baud rate to monitor
Serial.begin(115200);
while (!Serial && (count < 30) ) {
delay(200); // Wait for serial port to connect with timeout. Needed for native USB
//digitalWrite(LED_BUILTIN, state);
state = !state;
count++;
}
Serial.println("Setup Complete");
delay(100);
}
void presentation()
{
// Send the sketch version information to the gateway and Controller
//sendSketchInfo("LORA32U4II & Node 10", "1.0");
// Register attached sensors
present(CHILD_ID_BA_Volt_Bateria, S_MULTIMETER);
present(CHILD_ID_BA_Volt_Med_Bateria, S_MULTIMETER);
}
void loop() {
// Get current readings for The defined interval POWER_MEASURE_INTERVAL
float counter=1.2;
if (millis()-lastmillis >= 10000) {
// send message
counter=counter*1.2;
BA_Volt_Bateria = counter;
Serial.print("Sending value BA_Volt_Bateria: "); Serial.println(BA_Volt_Bateria);
BA_Volt_Med_Bateria = counter * 0.5;
Serial.print("Sending value BA_Volt_Med_Bateria: "); Serial.println(BA_Volt_Med_Bateria);
send(msg_BA_Volt_Bateria.set(BA_Volt_Bateria,2));
send(msg_BA_Volt_Med_Bateria.set(BA_Volt_Med_Bateria,2));
lastmillis = millis();
}
}
I have used the development version of MySensors because I have TTGO boards with ESP32 processors and those are only supported by the development version, but I have also tried the latest stable version with the same results.
I have also increased the timeouts for the ACK as suggested in the following post, although is quite old:
https://forum.mysensors.org/topic/8813/any-success-story-on-lora-rfm95-module-and-mysensors/9
I have included the configuration in the sketches instead of the library files as can be seen in the sketches. Is this right? or should I do that in the library files?:Mytransport.h and drivers/RFM95/RFM95.h.