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

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

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

@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

@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);
}

@isded from what is explained in this page it seems it is based on the Semtech SX1278 :
https://www.makerfabs.com/sx1278-lora-module-433m-10km-ra-02.html

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

tekka007 created this issue in mysensors/MySensors

open Multitransport implementation #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:

1. The way you included the development branch of MySensors in Platformio I believe it takes the "official" MySensors development branch, and I don't konw if the commit by koolru has been merged into that branch.. i believe not.. so it is not using the right code for the STM official core, and could be the origin of your error message. That is the reason I downloaded the library and used a local stored copy from koolru repository. I had also to have installed the official MySensors library (otherwise it gave me compiling errors), as if some library dependencies were missing from koolru branch ¿?.
2. It is true that STM32 core in platformio has both the Roger Clark and Official ststm core. By default it uses the official core. If you want to compile for the Rogre Clark you include the option board_build.core = maple in Platformio.ini.
3. The LowPower library is compiling in the Arduino IDE but gives errors in Platformio with ststm32 core (official).