@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:
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:
@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:
@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.
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!
Update. Please note that when @kk02067 gave the response directly above it was for Ver 2.0 and referenced a line in that code. It appears that changes leading to Ver 2.1.1 the location has changed and the delay(100) line would not be added at L463 as referenced. In Ver 2.1.1 it is now added between L659 and L660. It will look like this I believe:
L658 _msgTmp.destination = sender;
L659 // send ACK, use transportSendRoute since ACK reply is not internal, i.e. if !transportOK do not reply
ADD delay(100) here!!
L660 (void)transportSendRoute(_msgTmp);
Also, I have not yet used Ver 2.1.1, so don't know if the changes in the latest version might solve the Domoticz relay ack issue I had. This solution solved my problems 100% in Ver 2.0.
@sama, I had similar problems, always with relay nodes. The solution that has worked 100% of the time for me is to add a delay(100) as described by @kk02067 at the end of the forum thread of the same name:
https://forum.mysensors.org/topic/4987/error-sending-switch-command-check-device-hardware
Don't know if this will solve your problem, but worth a try.
@kk02067 , Would you please post specifically where you added the delay(100). I have exactly the same problem as you and would like to be sure the ack gets back to the controller. Thank you!
In other tests and explorations I had noticed that with debug enabled things seemed to work a bit more consistently - but had not tied it to this problem. Unfortunately, debug sacrifices quite a bit of flash which I need for other uses.
I have a dehumidifier in the basement: bought a 12V 1A pump from eBay and installed it to automatically empty the water when it senses water at the top of the bucket. Am using MySensors node to sense water, and turn on the pump when required. (also has DHT-22 attached to monitor humidity.) Am reporting this information back to Domoticz controller. My question: which S_variable, V_variable, and Domoticz device is best to 'count' the number of times the dehumidifier empties?
I am looking to 'count' daily bucket empties, and keep a record of the cumulative empties for the summer. So Domoticz would display daily number in the right of the top banner, and the cumulative number next to the counter icon on the left. I am currently using V_Volume, and S_water in MySensors script, and RFXmeter (set to counter). But this gives me count in 000's. Is there a better set of variables/devices to use? Should the MySensors script transmit just a value of 1 each time, or the cumulative number? Is there a way to reset the cumulative number displayed in Domoticz (RFXmeter)?
I have a number of other nodes I want to set up which will simply count events, report, and track - so I'd like to find the best way to do this. My forum searches got me to this point, but I wonder if there isn't a better way.
Suggestions welcome.
@kr0815 Sorry for not getting back to you sooner. No, I have not come up with a solution for this. Basically I spent much of my free time for a week investigating and working to solve it - within my level of skills - but was unable to isolate the problem. I hope to get back to it when more time allows.
I have seen another forum thread (perhaps yours) that had many of the same problem characteristics as mine. In that thread @hek was involved. Between @hed and @yveaux, that is a lot of talent. The problem is having the problem be repeatable at another installation so it can be identified. In the meantime I installed my standard wired ethernet gateway and have had no problems.
@Yveaux , thank. I was thinking, ... of the 7 nodes I have active, only three have the MYSBootloader on them. These are the same nodes which sent the 'read & forward' packets. This morning before work, I powered up one of the 3 nodes and it immediately tried to download firmware, and that caused the gateway to freeze. (I was still half asleep at the time though.) Do you know if the WiFi Gateway works well with MYSBootloader? Just a thought. Tonight I might change the boot loaders to see what happens.
@Yveaux, Yes I save each sketch separately and was able to check them. Also in the serial monitor snippet above before the 'freeze', you can see the different node ID's. Also, when using the previous 328 gateway all report properly. I think I would get problems if there were duplicate node ID's also on that gateway.
To help, what do I mean when I say 'freeze'. A couple of times the gateway cleared by itself, but after many minutes. And during this period no other nodes were able to report. Other times the red LED for tx, rx, error lights and never goes off. In these cases I had to power down/reset the gateway to recover.
In a couple of other cases, I observed the red led blinking periodically as if it was getting node data, but it had broken the connection with Domoticz (and MYScontroller). In these cases all I had to do was tell Domoticz to settings-hardware-update the mysensors controller. This seemed to cause the gateway to restart, then I could connect again.
But, based on the logs, all problems trigger only after the packets I have shown.
Thanks,
I am trying to set up a ESP8266 gateway using NodeMCU module exactly as in the 'build' instructions. Am using the development branch from Feb 1. It works fine until it gets a "read and forward" packet as shown below in the serial monitor output:
0;255;3;0;9;read: 23-23-0 s=1,c=1,t=0,pt=7,l=5,sg=0:16.5
0;255;3;0;9;read: 23-23-0 s=0,c=1,t=1,pt=7,l=5,sg=0:30.0
0;255;3;0;9;read: 20-20-0 s=1,c=1,t=0,pt=7,l=5,sg=0:-2.6
0;255;3;0;9;read: 20-20-0 s=0,c=1,t=1,pt=7,l=5,sg=0:96.9
0;255;3;0;9;read: 20-20-0 s=255,c=3,t=0,pt=1,l=1,sg=0:188
0;255;3;0;9;read: 22-22-0 s=255,c=3,t=0,pt=1,l=1,sg=0:89
0;255;3;0;9;read and forward: 22-22-255 s=255,c=3,t=7,pt=0,l=0,sg=0
[Gateway freezes here. When it restarts, it prints the next line]
0;255;3;0;9;send: 0-0-22-22 s=255,c=3,t=8,pt=1,l=1,sg=0,st=ok:0
0;255;3;0;9;Client 0 connected
0;255;3;0;9;Client 1 disconnected
0;255;3;0;9;Client 1 connected
0;255;3;0;9;Client 2 disconnected
0;255;3;0;9;Client 2 connected
0;255;3;0;9;Client 2: 0;0;3;0;2;Get Version
0;255;3;0;9;read: 26-26-0 s=255,c=3,t=0,pt=1,l=1,sg=0:102
0;255;3;0;9;read: 20-20-0 s=1,c=1,t=0,pt=7,l=5,sg=0:-2.9
0;255;3;0;9;read: 20-20-0 s=255,c=3,t=0,pt=1,l=1,sg=0:188
0;255;3;0;9;read: 22-22-0 s=255,c=3,t=0,pt=1,l=1,sg=0:90
0;255;3;0;9;read: 26-26-0 s=0,c=1,t=0,pt=7,l=5,sg=0:1.2
Of 7 nodes I have, 3 have sent in these 'read and forward' packets, which 'freeze' the gateway and disconnect both MYScontroller and Domoticz from the server. My question ---- What does the 'read and forward' packet mean? (I don't believe the nodes are repeaters as I used gw.begin(NULL, 22, false).)
The packets appear randomly, from minutes to hours between them. And 90% of the time the gateway freezes requiring a manual restart. I logged for about 2 hours using Serial Monitor, MYScontroller logging, and Domoticz logs. The freeze occurred 7 times in the period.
Also, after logging the data above and removing the WiFi gateway, I put back the previous IBoard 328p ethernet gateway and everything worked fine.
What does the 'read and forward' packet mean? What originates it? Why not a problem with the original gateway. (Also, I believe I had the same problem when I tried WiFi gateway version 1.5, but I did not do all the logging before switching to the development branch.)
Not sure it matters, but below is a list of all the freezes I monitored:
0;255;3;0;9;read and forward: 22-22-255 s=255,c=3,t=7,pt=0,l=0,sg=0
No freeze
0;255;3;0;9;send: 0-0-22-22 s=255,c=3,t=8,pt=1,l=1,sg=0,st=ok:0
0;255;3;0;9;read and forward: 21-21-255 s=255,c=3,t=7,pt=0,l=0,sg=0
Freeze
0;255;3;0;9;send: 0-0-21-21 s=255,c=3,t=8,pt=1,l=1,sg=0,st=ok:0
0;255;3;0;9;read and forward: 23-23-255 s=255,c=3,t=7,pt=0,l=0,sg=0
No freeze, long 4+ minute delay before clearing by itself
0;255;3;0;9;send: 0-0-23-23 s=255,c=3,t=8,pt=1,l=1,sg=0,st=ok:0
0;255;3;0;9;read and forward: 22-22-255 s=255,c=3,t=7,pt=0,l=0,sg=0
No freeze
0;255;3;0;9;send: 0-0-22-22 s=255,c=3,t=8,pt=1,l=1,sg=0,st=ok:0
0;255;3;0;9;read and forward: 22-22-255 s=255,c=3,t=7,pt=0,l=0,sg=0
Freeze
0;255;3;0;9;send: 0-0-22-22 s=255,c=3,t=8,pt=1,l=1,sg=0,st=ok:0
0;255;3;0;9;read and forward: 22-22-255 s=255,c=3,t=7,pt=0,l=0,sg=0
Freeze, Red led for tx,rx,error locked on
0;255;3;0;9;send: 0-0-22-22 s=255,c=3,t=8,pt=1,l=1,sg=0,st=fail:0
0;255;3;0;9;read and forward: 23-23-255 s=255,c=3,t=7,pt=0,l=0,sg=0
Freeze
0;255;3;0;9;send: 0-0-23-23 s=255,c=3,t=8,pt=1,l=1,sg=0,st=ok:0
0;255;3;0;9;read and forward: 22-22-255 s=255,c=3,t=7,pt=0,l=0,sg=0
Freeze
0;255;3;0;9;send: 0-0-22-22 s=255,c=3,t=8,pt=1,l=1,sg=0,st=ok:0
0;255;3;0;9;read and forward: 22-22-255 s=255,c=3,t=7,pt=0,l=0,sg=0
Freeze & I give up
Any helpful comments appreciated.
@Brijesh-Mishra , I see two issues with your photos. 1) the 3.3V regulator is on backwards. If you earlier in this thread someone comments that the regulator needs to be put on backward. The white design on the board is not correct. That was also my experience with the boards I built. The flat side of the regulator should face the two cap's. 2) more importantly, it appears that you used a thermal fuse in the spot where fuse #1 goes. Fuse #1 is supposed to be a 300ma slo blow fuse. If that is what you have there no problem, but it looks like the thermal discussed in the thread. This board does not have a place for the thermal fuse. I would consider this a serious safety issue, but I am not an expert. Hope this helps.
This has been an excellent thread! I am left with one practical question though. How does one safely mount the thermal fuse on the HLK-PM01? Even if the thermal fuse thru hole on the PCB was exactly next to the middle of the HLK-PM01, the lead will still need to run 2+cm to the top of the HLP-PM01, then another 2+cm back down to the PCB. Only the thermal glue holds it in place. It seems it could easily come loose with minimal pressure - and remember it is 110 or 220V! Of course the leads would be protected by electrical tape or shrink tube, but it is still not firmly secured. Plus it is more likely that the leads on both sides would be closer to 3cm, plus the 1 cm for the fuse for a total of ~7cm of high voltage 'leads' not securely tied down to the PCB. I am only a hobbyist, so I am curious to hear others thoughts on this. Also, note that this board (http://forum.mysensors.org/topic/1540/110v-230v-ac-to-mysensors-pcb-board) has great protection, even fuse & varistor on the low voltage side. How would one mount a thermal fuse on the HLK-PM01 without having a 'loose' lead running to the top of the HLK? Or am I over concerned.
@tekka, problem solved! I took a debug log from the node per your suggestion and was surprised to get:
radio init fail
radio init fail
radio init fail
This of course surprised me after it just finished downloading 20kb+. Turns out after I made the first test of OTA which worked fine, my home network automatically synchronized my laptops & desktop. This brought over a copy of myconfig.h which had softspi enabled! (I had been setting up the gateway on a different computer). So when I went to OTA on the second and third nodes it picked up the synched myconfig.h. Ugh, such little strange things that take so much time to find.
@tekka, my apologies for using some of your time. And my Thanks for your great work and sharing with the community!! Hopefully others will avoid similar mistakes by reading this.
@tekka I tried 2 new nodes with static id assigned [gw.begin(incomingMessage, 21, false);] and [gw.begin(NULL, 23, false);] ---- still same frozen response.
10/5/2015 17:18:46 TX 3;255;4;0;3;1400010000000C9486010C94D81A0C94051B0C94AE01
10/5/2015 17:18:46 RX 3;255;4;0;2;140001000000
10/5/2015 17:18:47 INFO BL version=257
10/5/2015 17:18:47 INFO Send FW info to node 3: type=14, version=1, blocks=0x0570, CRC=0xE30B
10/5/2015 17:18:47 TX 3;0;4;0;1;1400010070050BE3
10/5/2015 17:18:47 RX 3;255;4;0;0;1400010070050BE30101
10/5/2015 17:20:32 RX 1;0;1;0;0;19.5
and:
10/5/2015 16:59:29 TX 2;255;4;0;3;1400010000000C9486010C94D11A0C94FE1A0C94AE01
10/5/2015 16:59:29 RX 2;255;4;0;2;140001000000
10/5/2015 16:59:29 INFO BL version=257
10/5/2015 16:59:29 INFO Send FW info to node 2: type=14, version=1, blocks=0x0570, CRC=0x2E9E
10/5/2015 16:59:29 TX 2;0;4;0;1;1400010070059E2E
10/5/2015 16:59:29 RX 2;255;4;0;0;1400010070059E2E0101
10/5/2015 17:00:59 RX 24;1;1;0;0;62.8
Any idea what the nodes are waiting for?
I also reset the gateway to see if it sent anything that cleared the freeze, but no response. Hmmm.
On my 5V minis, the 16mhz crystal is much larger (long silver oval component stamped 16.00) than on 3.3v. At least on mine.
@tekka, In thinking about your question .... As the sketch begins execution after OTA'ing, it then asks for a node id to be issued (even though it has received one from the MysController) - and since I am using an ethernet gateway (& Domoticz) which does not automatically issue a node ID, the pro mini just sits there and waits for a node id? Would it then work if I put in a static node ID, even if it is different than the one issued by Myscontroller? And the node then adopts the static ID. ??
@tekka Thank you for your response. The sketch does not have a static ID - the line is "gw.begin();" So it should receive a node ID. I had MysController set to "AutoID" and it successfully issued the next free ID, which was 2. How would I test further to see why it does not begin execution. (I am using ethernet gateway with authentication, but the configuration is set to 'false', so a node not asking for Atsha response does not get one. Other non-atsha nodes work fine-as shown in the log. Don't know if this would make a difference.)
Looking for help to interpret log data after an OTA update. I am just learning, and successfully OTA'ed a simple DS18B temperature sketch to a node using MysController. Now I am trying to OTA an DHT22 node (the example sketch in 1.5 version, no changes to it.) The firmware OTA seems to go fine, but the Pro Mini never seems to start. Below is the log, I have bolded the log entries I don't understand. As shown, the first bold section comes right after the OTA. The second 16 minutes later is because I pushed the reset button on the pro mini. Any help understanding the log entry is appreciated.
10/5/2015 7:04:01 RX 2;255;4;0;2;820001000200
10/5/2015 7:04:01 TX 2;255;4;0;3;8200010001000C94AE010C94AE010C94ED020C94AE01
10/5/2015 7:04:01 RX 2;255;4;0;2;820001000100
10/5/2015 7:04:01 TX 2;255;4;0;3;8200010000000C9486010C94D11A0C94FE1A0C94AE01
10/5/2015 7:04:01 RX 2;255;4;0;2;820001000000
10/5/2015 7:04:01 INFO BL version=257
10/5/2015 7:04:01 INFO Send FW info to node 2: type=82, version=1, blocks=0x0570, CRC=0x9AEC
10/5/2015 7:04:01 TX 2;0;4;0;1;820001007005EC9A
10/5/2015 7:04:01 RX 2;255;4;0;0;820001007005EC9A0101
10/5/2015 7:07:23 RX 24;1;1;0;0;60.5
10/5/2015 7:07:23 RX 24;2;1;0;1;59
10/5/2015 7:11:41 RX 24;1;1;0;0;60.5
10/5/2015 7:11:41 RX 24;2;1;0;1;59
10/5/2015 7:13:24 RX 23;0;1;0;1;55.7
10/5/2015 7:15:59 RX 24;1;1;0;0;60.5
10/5/2015 7:15:59 RX 24;2;1;0;1;59
10/5/2015 7:18:27 CHILD New child discovered, node id=23, child id=1
10/5/2015 7:18:27 RX 23;1;1;0;0;63.0
10/5/2015 7:18:27 RX 23;0;1;0;1;55.9
10/5/2015 7:20:14 INFO BL version=257
10/5/2015 7:20:14 INFO Send FW info to node 2: type=82, version=1, blocks=0x0570, CRC=0x9AEC
10/5/2015 7:20:14 TX 2;0;4;0;1;820001007005EC9A
10/5/2015 7:20:14 RX 2;255;4;0;0;820001007005EC9A0101
10/5/2015 7:21:50 TX 2;0;3;0;13;0
10/5/2015 7:23:32 RX 23;0;1;0;1;56.0
10/5/2015 7:24:26 RX 24;3;1;0;24;78
I have heard somewhere that zinc-chloride batteries are not suitable for this kind of application. I have also been testing various batteries, all alkaline. Basically I have found you get what you pay for. I tried some local supermarket branded alkaline's and had your result. About 45% they just died. Then I tested a different 'cheap' brand, same result. Upgraded to more expensive brand name and got to ~20% consistently. Then tried top of the line (price wise) brand name - and they have been excellent! I have one node - DS18B20 temperature node in the attic for 6 months - exposed to 0 deg. F to 118 deg. F from winter to summer - and it shows 11% left. Key information is they are AAA, and the BATT_MIN is set to 1.65V! Hope this experience helps.
@Joey-Edelstein , Here is what I did for assembly: Do not begin assembling the board until deciding on what the node is and selecting all parts - not all parts are needed. My first node is a DS18B20 temp sensor. 1) I wanted sockets for the radio and arduino so cut and put in pile of parts to be used. 2) I know I need D3 for the DS18B20, so I cut header for J4. Also need pull up resister for same, so look at the schematic for the board and you see R14 is the pull-up for D3. Put the resister in the pile of parts. 3) I also am battery powering the board, and want to measure it thru A0. So I cut header for J5. Also need a V divider, so looking at the schematic can do that with resisters on R12 & R4. Also need a small capacitor on C6. Put these parts on the pile. Collect all needed parts. Don't need header on J6 for example, not using it. 4) Also soldered the power cap on C2 - did not need the volt regulator supplied in the kit as I am feeding 3.3V directly to J7. Then solder the smallest components first starting with those closest to the center of the board, and moving out. Then the big components such as the sockets, again start at the center of the board and move out. Depending on your application, only use components needed. Look at the schematic. Hope this helps get you started.
@Mrlynx, last Saturday I received the 5 kits ordered from your web site, thanks! Nice simple board, and very flexible for different applications. Have assembled my first sensor using it and works perfectly. Don't miss all the wires it replaces. Although the 805 components are small, I prefer them to thru-hole. Again, thank you, and nice job! Love MySensors and the great community of support.
SUCCESS! Found the reason I could not compile the MQTT Gtwy client.
When I first looked for the PubSubClient library, used google and went to http://knolleary.net/arduino-client-for-mqtt/ which has a link to GitHub for the library. That is the one I used. When @Victor-Klijmeij suggested I look at @ntruchsess suggested changes again - I noticed the line numbers were not the same as mine, but the code was. Bottom line .... I had an old version of PubSubClient. When I used the version @ntruchsess made changes to, it compiled immediately after his suggested changes. The old PubSubClient .cpp file was ~70 lines of code shorter than the current version.
Thank you both again for your help, much appreciated! @ntruchsess, great job, thanks for sharing the code.
@ntruchsess , thank you very much for taking a look, much appreciated.
I deleted PROGMEM as you suggested, resulting in the following:
C:\Active Sync Folder\Home Automation\MySensors active sketch folder\libraries\MQTTclientGateway\MyMQTTClient.cpp: In constructor 'MyMQTTClient::MyMQTTClient(PubSubClient, uint8_t, uint8_t)':
C:\Active Sync Folder\Home Automation\MySensors active sketch folder\libraries\MQTTclientGateway\MyMQTTClient.cpp:116: error: no matching function for call to 'PubSubClient::PubSubClient()'
C:\Active Sync Folder\Home Automation\MySensors active sketch folder\libraries\PubSubClient/PubSubClient.h:59: note: candidates are: PubSubClient::PubSubClient(char*, uint16_t, void ()(char, uint8_t*, unsigned int), Client&)
C:\Active Sync Folder\Home Automation\MySensors active sketch folder\libraries\PubSubClient/PubSubClient.h:58: note: PubSubClient::PubSubClient(uint8_t*, uint16_t, void ()(char, uint8_t*, unsigned int), Client&)
C:\Active Sync Folder\Home Automation\MySensors active sketch folder\libraries\PubSubClient/PubSubClient.h:57: note: PubSubClient::PubSubClient(Client&)
C:\Active Sync Folder\Home Automation\MySensors active sketch folder\libraries\PubSubClient/PubSubClient.h:40: note: PubSubClient::PubSubClient(const PubSubClient&)
Looks to me like the compiler is finding the code ambiguous. For novices like me this is more challenging as the code is fine, just seems to confuse the compiler. I am using Arduino IDE 1.0.6 as you suspected. I am able to compile fine the examples included with pubsubclient, Ethernet, etc. Originally I was using a MAC, so I then tried a Windows pc in case something was there, but same results. Since you are able to compile after removing PROGMEM, I assumed it was part of my setup.
Trial & error is frustrating, but perhaps a way for novices to learn.
I am sure you are busy, so thanks for taking a look!
Forgive what may be a simple question, I am a novice in code but trying
to learn. I am trying to compile the MQTTClientGateway listed in the
first message of this thread.I have downloaded the MQTTClientGateway
code as well as PubSubClient software. I have made absolutely no
changes to any of the code. But when I compile I get the following error:
In file included from /MyMQTTClient.h:17,
from MQTTClientGateway.ino:63:
C:\Arduino\libraries\PubSubClient/PubSubClient.h:68: error: section attribute not allowed for '<anonymous>'
If I can get this to compile clean, I can see if it will work with a
Domoticz setup I already have working on a RPi, with Mosquitto.
I believe the offending line is:
void disconnect();
Since I made no changes, & clearly this compiled by the original
authors, why do I get an error, and how do I fix it?
Any help will be appreciated.
Regards,
PS: below is the full code section
PubSubClient();
PubSubClient(uint8_t , uint16_t, void()(char*,uint8_t*,unsigned int),Client& client);
PubSubClient(uint8_t , uint16_t, void()(char*,uint8_t*,unsigned int),Client& client, Stream&);
PubSubClient(char*, uint16_t, void()(char,uint8_t*,unsigned int),Client& client);
PubSubClient(char*, uint16_t, void()(char,uint8_t*,unsigned int),Client& client, Stream&);
boolean connect(char *);
boolean connect(char *, char *, char *);
boolean connect(char *, char *, uint8_t, uint8_t, char *);
boolean connect(char *, char *, char *, char , uint8_t, uint8_t, char);
void disconnect();
boolean publish(char *, char *);
boolean publish(char *, uint8_t *, unsigned int);