@Dbagioni I don't think that is the case. MySensors is a relatively popular integration, and fits the philosophy of Home Assistant. Also, I just rebuilt from scratch my Home Assistant server (Intel NUC) and it is operating better than my old (5 Years) installation. Very smooth, no problem rebuild. One persons observations.

To close this post out, @bjacobse was correct. After cutting the trace to the IRQ pin of the radio there is no more drain on the D2 pin. Even though the pin was not used by MySensors, the radio apparently still drained current.

Thank You!

@bjacobse Thank you for your comment. I should have looked at that but it has been ~6 years since I paid attention to basic radio connections. :( I am using the MYS11 board from www.sa2avr.se and the schematic shows D2 connected to the IRQ pin of the radio. That could be it. I will test it out.

The "connecting the radio" page of MySensors states: "The IRQ pin is only required to be connected if the MY_RX_MESSAGE_BUFFER_FEATURE is defined in the sketch. I am not using that feature for this node so I might be able to fix it by cutting a trace.

I post my results after testing. Again, great input! Thanks.

@mfalkvidd Please keep us informed on how this goes for you.

A few months ago I also implemented a zigbee network for similar reasons. The nodes are very inexpensive, small, and coin cell powered. I am using these for common applications like temp or motion. That way I can use MySensors nodes for the more custom or complicated applications. So far I have had no problems, actually am surprised at how reliable and fast it is. I have tried to limit the number of different vendors as I understand that can present a problem. I opted to use ZHA (Home Assistant) instead of MQTT, so far works great. Using Sonoff USB 3.0, all other Sonoff zigbee nodes, Sengled bulbs, and Aqara cube, vibration & water detectors. If I run into any problems will also post here.

[Using Home Assistant, Intel NUC, Zwave, MySensors 2.4 & 915, Zigbee, ESP]

I am looking for some input on a problem I have encountered with a battery powered node. Any comments appreciated.

Problem: Bettery powered node is exhausting 2 AA batteries within 5 days due to pin D2 'sinking' ~7ma while sleeping.

Node Description: This is a simple node. It monitors two garage doors for when they open or closed and reports the change to the controller. It sleeps perhaps 95% of the time. The hardware is a standard MySensors pcb with only two components mounted, a pro mini and a nrf24l01 radio. (Plus pin headers.) Pins D2 and D3 are used in "interupt on change mode", one for each garage door. The 'sensors' on the doors are standard magnetic reed switches. They are open when the door is open, and the magnet closes the contact when the door is shut. When shut, the reed switch pulls the respective pin (D2 or D3) to ground. To minimize current draw, the internal pullups on the pins are not used. A 3.3M ohm resistor is pullup for each pin. The software is a sketch created by @anticimex located here https://github.com/iot-playground/Arduino/blob/master/external_libraries/MySensors/examples/BinarySwitchSleepSensor/BinarySwitchSleepSensor.ino. The only changes made are to put in node id and comment out use of the internal piullups.

The node works perfectly. When a door opens or shuts, the interupt awakens the node, it reports the change, and then returns to sleep. The ONLY problem is burning thru batteries.

Investigation: I have put a fluke meter on the node to measure current draw. When pin D3 in in either the pulled up or pulled down position and the node is sleeping the node uses 20micro amps. When pin D2 is in pulled up position and node sleeping, also 20micro amps. But when D2 is in the pulled down position (the garage door is closed) it draws ~6-8ma while sleeping! This draw drains the batteries quickly. I have programmed 4 pro mini's, including one that works fine on another battery powered temp node, and they all perform the same way. I also tried programing the pro minis both with Platformio & Arduino IDE, and there is no difference.

I have no idea why only D2 sinks so much current when the node is sleeping. Any ideas are much appreciated!

@idanronen , I am not an expert but did manage to accomplish what you are doing about a year ago. I can tell you that you are supposed to get two com ports from BMP. Also, where your screen shot says "SW-DP scan failed" means BMP cannot find any 'targets' on the nrf52. You should get back something that looks like this from the scan:
Available Targets:
No. Att Driver
1 ARM Cortex-M
2 Nordic nRF52 Access Port

I performed this operation on ~10 nrf52832 and only one failed the scan. I never found out how to solve it.

Also, your use of the attach command is incorrect. You appear to be trying to attach the com port 13. If the swdp_scan had worked corrrectly, you would then attach the target that shows up in the scan. In my example output, it would be "attach 2" - the nRF52 Access Port.

That adds what I know, hope it helps a bit.

@CarloMagno You are fortunate to have the 128k Blue Pill. I hope mine are also.

Funny, in coding there are always different ways to do things. Working with PlatformIO, I linked to the MySensors development branch in the platform.ini as follows:

[env:bluepill_f103c8]
platform = ststm32
board = bluepill_f103c8
framework = arduino

lib_deps =
  https://github.com/mysensors/MySensors.git#development

lib_ignore =
  ;MySensors standard library
  548

It seemed to work. But I have not yet finished testing.

In your compile on PlatformIO, it makes me wonder if perhaps it used the maple (RogerClark) core instead of STM32. I observe:

1. The STM core also includes the maple core. (https://docs.platformio.org/en/latest/platforms/ststm32.html)
2. Though the .ini file does not have "board_build.core = maple" in it, the compile output has "framework-arduinoststm32-maple 2.10000.200103 (1.0.0)" in the output.
3. The output file size of 50k flash seems large and is comparable to the output I got from my Maple/RogerClark testing. Is it the same size as you got when compiling in the Arduino IDE with STM32 core?
4. The low power library has been written up as not compiling with maple/RogerClark core, but does with STM32 core.
   ==> Just some observations to be confirmed?

In my initial attempts to compile with STM32 core on PlatformIO, it uses the development branch, but I get an error message:
".pio/build/bluepill_f103c8/FrameworkArduinoVariant/PeripheralPins.c' not found, needed by target..."
=> I have not had the time to solve this yet. But, compiler is looking for a file which describe pin map - PeripheralPins.c I am guessing this is similar to MySensors instructions for Nrf5 where two files are in the sketch directory to specify pin assignments. (MyBoardNRF5.cpp and .h)

[Sorry I am not able to make faster progress contributing to this thread. I am a couple weeks out of the hospital and can only sit at my computer for short periods so far. But happy, repairs were successful :) ]

Re: the site to check if Blue Pill is 128k: I believe the "STM32CubeProgrammer" is loaded as part of the STM32 core and does not need to be loaded separately. Should be able to execute those commands without installing anything else.

@CarloMagno I also found the links you refer to. They appear to be "workarounds" rather than truly solving the real problem. I was never able to get the script shown to work. I did get an error free compile with the information in them, but for some reason it appeared to never link the MySensors library. I did not get a splash screen, or any MySensors debug messages.

The tests @monte did seemed to show a significant decrease in flash usage when using the STM32 core. So I also used the @KooLru proposed commits on the same two sketches as before, with promising results (on arduino IDE):

Sketch #1
w/ RogerClarke core Flash used 58k (88%)
w/ @KooLru STM32 core Flash used 41k (61%)

Sketch #2
w/ RogerClarke core Flash used 48k (73%)
w/ @KooLru STM32 core Flash used 30k (45%)

This looks good. I have only tested compile, not yet loaded a Blue Pill with the output.

To use @KooLru proposed commits:

1. must use development branch.
2. create folder MySensors\hal\archetecture\STM32
3. drop @koolru 3 files in above directory. [MyMainSTM32.cpp, MyHwSTM32.h & .cpp]
4. Replace MySensors.h with his version.

@CarloMagno I forgot that most Blue Pills are actually 128k - nice suggestion! I found the following website which shows how to check the flash in a blue pill. [https://www.onetransistor.eu/2020/01/stm32-bluepill-arduino-support.html]

Next Steps:

1. Try @koolru modified development branch with PlatformIO.
2. Live test a program compiled with the modifications in a working MySensors network.

@CarloMagno I have now compiled 2 small test programs, using RogerClarks core. I was very surprised as both used most of the Blue Pill Flash and Memory for very small sketchs.

1. test sketch simple relay off/on used 48k (73%) of flash and 5k (24%) of memory.
2. Sketch with simple LED off/on with 'receive' from controller and rfm69 use 58k flash (88%) and 5.2k (25%) of memory.

I used MySensors current release, & latest Arduino IDE. Have you had similar results in the work you are doing? This would take away the Blue Pill advantage of twice the flash of a pro mini, and make it unusable.

I will dig deeper, and try the @KooLru code above to see if it makes a difference. @monte states that it might not have functionality, but I am not sure what that means as 'core' work is beyond my skill level.

Again, I will assume I am doing something incorrectly as I know others on MySensors forum have used the 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.

@CarloMagno Thank you for putting up your experience and success with the Arduino IDE. It appears we did many of the same steps. I also ran into the HAL error, tried the #define ARDUINO_ARCH..., and failed. Also tried the Roger Clark version and id not get that to run. Today I took an older PC and clean installed the IDE and Roger Clark core as you described and SUCCESS, was able to compile MySensors. There must be something wrong with my configuration on my main PC.

The "official" core is also my preference as it is available on PlatformIO. And there are libraries available for it that may not run on Roger's. For example I have read there is a sleep/low power library for Blue Pill that only runs on the STM32 "official" core (I have not tested that). I might take another try at getting PlatformIO to work with Roger Clarks core but we are getting to the fringes of my technical skills.

In either case, I am very happy to be able to compile MySensors for the Blue Pill. Essentially same cost and size of the Pro Mini, but so much more capable. I have a number of applications it will fit perfectly for.

If I make any progress on PlatformIO, will post here.

@CarloMagno If you are successful to implement MySensors on the Blue Pill, please post your method. Thank you!

I have spent 2 weeks on this and remain unable to compile MySensors for the Blue Pill. I can compile and download programs to the BP on both PlatformIO and Arduino IDE, but as soon as I put #include <mysensors.h> in the code, errors appear. I have found these errors on some forum entries, but a clear step-by-step solution method which works has not yet been posted (that I have found).

I am no expert on coding, so I assume I am missing something.

Hello.
I am trying to change to PlatformIO, which has many advantages over Arduino IDE. I want to compile for the STM32 Blue Pill module but have not been able to get the right configuration. I have found many suggestions but have not gotten any to work. At one point I got a compile, but it ignored the MySensors code.

Can some one please post their working platformio.ini, and are there any detailed instructions anywhere for the exact configuration such as which STM32 library to use?

I have spent days researching and tried things like;
board_build.core = maple
Using a Python script to get rid of multiple main/premain error
Other Platform & Board options. (such as genericSTM, etc)
But cant seem to get the right mix.

Thank you for anyone who can help.

Also, I have been using MySensors for over 5 years: this is a great system, a great website, has great admin, and a fantastic group of contributors. Thank you all very much for MySensors!

++++++++++++++++++++++++++++++++
[ Below is a sample of the various options I have tried in an experimental platformio.ini. None worked.]

;[env:bluepill_f103c8]
;platform = ststm32
;board = bluepill_f103c8
;framework = arduino
;upload_protocol = stlink

; NOTE - Above lines are not acceptable to MySensors on Blue Pill. Must use maple as shown below.

; NOTE - In Platfromio docs, Maple is a different processor
;[env:maple]
;platform = ststm32
;board = maple
;framework = arduino
;upload_protocol = stlink

; NOTE - The below was found when searching the net. It appears an alternative set of ENV entries.
[env:genericSTM32F103C8]
platform = ststm32
board = genericSTM32F103C8
framework = arduino
board_build.core = maple
;lib_extra_dirs = D:\Dropbox\Elektronik\platformio\libraries
;lib_deps = https://github.com/mysensors/MySensors.git#development
upload_protocol = stlink

; Serial Monitor options
monitor_speed = 115200

@sebi,
A couple weeks ago I began exploring deploying E73 modules and had to remove protections. I was successful and now have a working E73 ethernet gateway. Only had ST Link-V2, so I used a "blue pill" I had in inventory to load it with Black Magic Probe. This cleared the protections.

The instructions I followed to load the BMP are step-by-step at https://github.com/TamojitSaha/STM32f103_Black-Magic-Probe

The instructions followed to clear protections with BMP also are step-by-step and worked perfect. They are at https://github.com/AndruPol/nrf52832-recover

In item #4, the program arm-none-eabi-gdb.exe seems to be part of the Arduino tool chain as I found it just by doing a search in file explorer and it was already on my win10 machine. Also, in item #4, (gdb) is the prompt that the program arm-none-eabi-gdb.exe gives. In the first line, change the '/dev/ttyACM0' to your com port. Use 'quit' to exit the program. Also, use 'mon help' to see options.

There are apparently a number of ways to 'recover' the E73, but this worked easily for me, and was step-by-step.

I wanted to make sure this thread is correct. After a day of debugging I found the problem I was having.

My sketch used the following:
request(Data1_ID, V_TEXT, 1); The last variable (1) I believe is used to request an ack from the controller. Using MysController I was able to determine the 1 prevented MySensors from sending the request message somehow. When I changed it to 0, the requests were sent. Not sure if this is a bug, or intended.

Also, I am using the current STABLE version of Domoticz, V3.8153, and it works fine in responding to the requests once I made the change above.

Lastly, at least in the tab I was looking at in MysController, it never showed the response message going back from the controller to the node. Perhaps I did not look in the right place, or that is the way MysController is intended to operate. In either case the response messages were seen by the node.

@Boots33 , thank you for your input. Confirms for me that it is a Domoticz problem. Based on my quick research, Domoticz does not make it very easy to revert to a previous version once updated. Looks like I will have to attempt compiling an archive version, something I have never done before - and a challenge for my skill level. Thanks again!

Back in April I built an LCD node to display data from other sensors, using @AWI “LCD Clock and Text sensor node with new VText” (https://forum.mysensors.org/topic/1957/lcd-clock-and-text-sensor-node-with-new-v_text) as a model. It worked perfectly, requesting data every 4 minutes from the controller using request(Data1_ID, V_TEXT, 1); . I then had to put the project aside for a few months due to other priorities. Now am looking to finish the node and find that it no longer works - it never receives data from Domoticz.

I am confident the sketch works fine. To test, I used MysController to send a message with a temperature and the sketch/node received it and displayed the data correctly. Therefore I logically assume something changed in Domoticz. I believe there was an update to Domoticz around July. I am trying to determine what has happened, especially since I have not seen any other messages in the forum that complain about the “request” no longer working.

My node presents itself, and two S_INFO children, Domoticz properly creates the node and children in the hardware tab under the gateway. The two devices then appear in the Settings -> Devices tab with IDX’s. I use the same LUA script I used months ago to update the new IDX’s, and they update correctly. BUT ….. I notice that under Settings -> Devices the text data updates, but under Hardware tab the Child does not show any data in “values” column.

Shouldn’t the Hardware tab show values for each V-TEXT child? (Especially since the device updates correctly under settings tab.)

Has anyone else seen this?

Thank you for any ideas!

This post describes a method I utilize for logging of long term debug messages. Hopefully it will help others. It is not as useful or elegant as the battery powered sd-card module @sundberg84 is looking at, but it works for my purposes.

I have a @ceech solar board with sensors for temp/hum (HTU21DF), barometer (BMP180), light sensor (BH1750), and a lightning sensor (AS3935). The board is great, all the code works fine. But on a random basis the node will freeze, sometimes in 8 hrs, sometimes 5 days, completely random it appears. So I needed to put debug statements in the code, and find a way to log the debug messages over a period of at least a week. The node wakes every 1 minute to check Baro for weather forecasting, and every 4 mins for all the sensors to report. Additionally, it wakes on interrupt from the lightning sensor. This board is destined to be set up outside powered by a small solar panel, and an 18650 battery. So this has to be solved before sealing it up and mounting in the yard somewhere.

I have a Raspberry PI 2 sitting around so I decided to use it to do the logging. It is connected via a USB port to an FTDI serial module, which in turn is connected to the solar board tx/rx pins. For software, I found a Python program called ‘grabserial’ (github.com/tbird20d/grabserial) which will take serial input from the USB port and write it to a log file.

The Pi is operating in a headless mode, connected via WiFi. So I can put the Pi and solar board anywhere out of the way as long as there is an outlet to power the Pi. I log in via SSH to the Pi.

Using ’grabserial’ requires running the program in background and also to keep it running after I log off the the pi. The command I use is:
nohup ~/grabserial -d /dev/ttyUSB0 -T -o ceechlog -Q &

where:
nohup => allows the program to continue running (not hangup) when I log off the Pi.
-d => The device to listen on. To get which USB port, I ran ls /dev/tty* which lists all devices. Just look for your USB in the list.
-T => Puts a system time stamp on each line of logged data. Valuable!
-o => Tells grabserial the file to output the logging to. In this case I called it ceechlog.
-Q => Instructs grabserial to operate in quiet mode, i.e., don’t copy logging to the terminal.
& => Starts the program running in background.

To confirm the program is running in background, I use ps -A, then look for ‘grabserial’, and its process id. To stop it, just use kill xxxxx, where x is the process id. (I am a linux amateur, I am sure there are cleaner commands, but works for me.)

For the debug statements, In each sketch function, I put Serial.print statements with a number. For example:

void sendTempHum(void)
{
Serial.print(" 9”); //HERE
float humidity = htu.readHumidity();
send(humidityMsg.set(humidity, 0));

Serial.print(" 10"); //HERE
float temperatureHTU = htu.readTemperature();
send(temperatureMsg.set(temperatureHTU, 1));
Serial.println(" 11"); //HERE
}
}

Note that the debug statements in an individual function will print on a single line in the output. The function example above will look like:
9 10 11 The last ‘serial.print in a function is actually a serial.println to get a carriage return. This makes reading the log easier. Don’t forget to a put a blank space before each number so as to separate the #’s on each line. Of course each different function being debugged gets different numbers in the serial.print statements.

Every few days I log in and erase the ceechlog file as it can get quite large. This kills the ‘grabserial’ process, so I just start it up again with the command above. This is not necessary though. It is just housekeeping.

My sketch had 39 different serial.print() statements which track the progress of the program as it executes. After setting this up, my first ‘random’ freeze actually caught the exact line which caused the freeze. I had put serial.print statements on both sides of the offending line.

Hope this is helpful to others trying to find a difficult debug issue.

I just completed a battery-free outdoor node reporting temp/humid based on the information in this thread. Works great, thanks to @NeverDie for his insights. Node is a sensebender micro, RFM69W, 10F supercapacitor, and 5V solar panel. Reporting every 4 minutes it sends temp, humid, supercap %, & solar V. Uses the simple tiny solar charger schematic from @NeverDie shown above.

Results: The supercapacitor cost $2 at Digikey, is about 2/3 the size of a AAA battery, and lasts 40 hours without the solar panel connected. The 40 hours is when the supercapacitor reaches 1.9v as the low end for operating the node. Easily gets through the longer dark winter nights.

The solar panel is from China, Ebay, 110mmx70mm, 5V, 1.25W. The panel works great also. It reaches 4V in the smallest amount of light, and 5.45V (no load) in modest indirect light. In fact, it will fully recharge the supercapacitor in the morning before the sun even rises above the horizon, just from the sky brightening. (From the ~20% overnight discharged state.) It seems to charge a fully empty supercap in ~10 minutes under average light.

Bottom line: no longer walking through 1ft of snow in 10 degrees (F) to get the node, bring it inside, remove water seals, and change the batteries. This is the solution I was looking for.

Also have a 2nd outside node in testing using the Ceech solar board (A great PCB also!), a 18650 battery and the same solar panel. So far the battery has gone 2 months and is at 3.85V without the panel connected. In testing, the solar panel has no problem charging the battery. In fact so much, I am going to add a FET to disconnect the solar panel periodically to allow the battery to cycle some.

This site is excellent, such great talent, thank you all!