<![CDATA[Read this first - it could SAVE YOU A LOT OF TIME]]>People asking questions here on MySensors is generally good at it. But for the newcomers it can be good to have a small guide on how to debug and then some things how to improve your chances of getting help.

Debug

This flowchart shows the most common problems a newcomer may experience. Try to follow the flowchart if you find your problem. Read the most common actions and also read the FAQ below.

0_1454445050795_Debug.jpg

FAQ

#1:1 How do I debug my sensors/gateway?
Add #define MY_DEBUG at top of your sketch. Re-flash the sketch and look in the Serial Monitor (default 115200 bps).

#2:1 Why should I use a capacitor?
The NRF24L01+ is very sensitive to power spikes. A capacitor will most likely help in smoothing these spikes out. Start with a capacitor of 4.7uF across the radio's 3.3V and GND.

#2:2 What does ST:Fail/ST=Fail means?
This means the receiving node or gateway has problems sending ack back to the sending node.
Its probably a hardware issue (power and/or range). Try adding a capacitor (http://www.mysensors.org/build/connect_radio#connecting-a-decoupling-capacitor) to the receiving radio, change powersource, move receiver/sender closer to eachother or build a repeater.

#2:3 I get "Radio init fail/!TSM:INIT:TSP FAIL"
Radio init fail means

  1. Not wired correctly
  2. Not powered correctly
  3. A nrf24, not a nrf24+

Do you have a capacitor between gnd/vcc on the 3.3v radio? This can make difference... Some reading regarding + and not + Nrf modules.
http://forum.mysensors.org/topic/1153/we-are-mostly-using-fake-nrf24l01-s-but-worse-fakes-are-emerging/4
http://forum.mysensors.org/topic/1664/which-are-the-best-nrf24l01-modules/2

#2:4 I only get Find parent in serial log for node
Find parent means the node is trying to find its way to the gateway - and if this repeats it cant.
Its either a range issue or a power issue. You can start by checking the gateway serial log and see if there is any info.
Also, have you added a capacitor on the radios? This is very important since the radio is sensitive to power spikes.

It this doesnt work start with changing the power source and check your wirings / ground connection on the node.
Also you can try to move the node closer to the gateway - if this works and you have some distance between node and gateway you should consider a repeater.

#3:1 My relay isn't working - why?

  • The radio is very power sensitive and it can help adding/changing caps GND/VCC on the radio. 4.7uF is recommended but you can also add higher or lower and even parallel.
  • How you wire the ground from the relay can also make a difference. I have had relays jamming when i ran ground trough the Arduino and not straight to source. Also the opposite that it dint work well if I dint have ground through the Arduino.
  • Range, when you send a on-command there is a ack going back which needs to be ok ("Error sending command, check device/hardware" message in Domoticz). Follow your serial logs in node and gateway to find out if the radio traffic is ok - and put a repeater in between if necessary.
  • Power - I have had Pro Minis that was a little to weak to trigger the relay... :( When the arduino didnt put enough juice out some tries resulted in a unsuccessful relay switch even if the logs told me so. To test this you can upload a sketch doing nothing else but setting the pin to high and low with a delay in between.

Correct log for node (standard relay sketch, node ID = 4) when incoming command from controller.
read: 0-0-4 s=1,c=1,t=2,pt=0,l=1,sg=0:1
send: 4-4-0-0 s=1,c=1,t=2,pt=0,l=1,sg=0,st=ok:1
Incoming change for sensor:1, New status: 1

How to ask for help

  1. Use a meaningful, specific topic header.

  2. Specify your environment:
    Arduino IDE version? OS?
    Which Arduino Library are you running?
    What type of Arduino is your node? Which radio are you using?

  3. Post the code your having problem with and make sure the code is formatted correctly. You can either enclose the source code in 4 "backtick" characters ```` or write 4 spaces first on each line of code.

  4. What is your sensor and gateway debug logs showing? Enable DEBUG in MyConfig.h and look open the Serial Monitor. You can get some hints on how to interpret it here or by using the log parser tool.

  5. How do you power your sensor/gateway? The NRF-radios is very sensitive to power spikes and transients. 90% of communication problems can be resolved by replacing a bad transformer or adding a decoupling capacitor to your radio.

  6. What are the symptoms? Describe the research and diagnostic steps you've done before asking the question. If possible post an example on how to reproduce the problems you've encountered.

For a more comprehensive guide. Have a look here:
http://www.catb.org/esr/faqs/smart-questions.html

Troubleshoot the debug output: use the log parser tool.

(courtesy of @martinhjelmare from this thread)

From the source code in the dev branch: link

s = sensor id
c = message type 0-4: presentation, set, req, internal or stream. See link
t = value type: S_VALUE during presentation or V_VALUE during set/req
pt = payload type: string, byte int, etc. See link
l = message length
sg = signed or unsigned message: 0 or 1 for false or true

0;0;3;0;9 means node 0 , sensor 0, internal message (3), not an ack message (0), log message (9). This means that it's the gateway that prints this info as a log after already having received the message from a node.

At the end you have the payload: 27

Similarly for a sent message: link

General tip

Start small! If you are having problems with your node - exclude everything (make your code as small as possible) in your sketch and only include the MySensors library. Same for the components - only add minimal needed!
Upload and debug through serial line. Does it work? Great - add ONE function (analogread and one sensor for example). Upload and debug through serial. Continue until you find that it does not work anymore. Now you know which part is causing you trouble. This is much better than trying to debug a big sketch with a lot of functions and components that might interfere with each other.

]]>https://forum.mysensors.org/topic/666/read-this-first-it-could-save-you-a-lot-of-timeRSS for NodeTue, 21 Jul 2026 07:50:42 GMTTue, 02 Dec 2014 08:40:20 GMT60<![CDATA[Reply to Read this first - it could SAVE YOU A LOT OF TIME on Sat, 13 Aug 2022 23:59:35 GMT]]>@ctodor sorry, I don’t understand. Could you describe where the sensorid could be added?

]]>https://forum.mysensors.org/post/112816https://forum.mysensors.org/post/112816Sat, 13 Aug 2022 23:59:35 GMT<![CDATA[Reply to Read this first - it could SAVE YOU A LOT OF TIME on Sat, 13 Aug 2022 22:51:10 GMT]]>@mfalkvidd what if we replace "s" with "sensorId" and so one?

]]>https://forum.mysensors.org/post/112815https://forum.mysensors.org/post/112815Sat, 13 Aug 2022 22:51:10 GMT<![CDATA[Reply to Read this first - it could SAVE YOU A LOT OF TIME on Sun, 21 Jun 2020 17:32:10 GMT]]>Like many, I struggled for literally years getting MySensors to work. Recently I tried (yet again) and this time around I began by focussing on an evidence based radio testing method, which for me was the key to success. I humbly cross-link it from here in the hopes that it is helpful to others, because it makes me sad reading how many people have given up trying to get MySensors to work.

Good luck!

And by all means please do not suffer, struggling along in silence. Make a post and try and get some help before frustration mounts too high, and you give up (as I did, many times).

]]>https://forum.mysensors.org/post/106255https://forum.mysensors.org/post/106255Sun, 21 Jun 2020 17:32:10 GMT<![CDATA[Reply to Read this first - it could SAVE YOU A LOT OF TIME on Thu, 10 May 2018 15:49:26 GMT]]>@alowhum the security documentation is quite clear on the use of eeprom for encryption keys.

]]>https://forum.mysensors.org/post/89861https://forum.mysensors.org/post/89861Thu, 10 May 2018 15:49:26 GMT<![CDATA[Reply to Read this first - it could SAVE YOU A LOT OF TIME on Thu, 10 May 2018 15:41:04 GMT]]>Now that encryption is becoming more common, perhaps there can be some tips/flowchart on how to troubleshoot that?

For example, I just discovered that clearing the eeprom (there is a special sketch for that in the examples folder) helps remove old encryption settings.

]]>https://forum.mysensors.org/post/89859https://forum.mysensors.org/post/89859Thu, 10 May 2018 15:41:04 GMT<![CDATA[Reply to Read this first - it could SAVE YOU A LOT OF TIME on Tue, 01 Aug 2017 02:12:42 GMT]]>This is old, but I was looking through it today...
According to the datasheets for voltage regulators and the reports of why there are problems with the nRF, the output, or load side capacitors are for keeping the voltage into the nRF as steady as possible. smaller caps are on the front side of the regulators for noise (faster transient voltages than what you'd see on the nRF draw), like those from other electronics, certain lights, radios, etc. and they are ceramic (or other non-polarized) that are great for this filtering in a small package.
The regulators themselves, like the ones in the Arduinos (if you feed RAW pin) take care of the high frequency stuff, but a bigger capacitor is needed for voltage variations, which a ceramic can't do. This is why electrolytics are used. The problem is, electrolytics are much bigger, and so most regulators have you add them to make them work better. But where would you put a component larger than the MCU's chip? And besides, they are getting smaller all the time.
I've never seen anyone say what value cap is overkill, as each person's setup is different. Some don't power their radios from the MCU's rail at all, and some MCUs can be loaded with servos, etc. that would make their draw on transmit different than yours. The bigger the cap (as long as voltage is a tad over what it will see) the better, when it comes to electrolytics. In fact, you can power your MCU with them!
The only way you can know what will work in your unique situation is with an oscilloscope. It is fast enough to capture any dips in voltage on transmit/power-up, and it can show you any noise and ripple on the input. VOMs are just too slow, and not made to measure small changes in a higher voltage at the speeds you will need to see them.
Since I have a pile of 10uf and 100uf, I start with 10uf by default, and if there is any errors that seem like TX dropout, I'll try 100uf, but a cap in this scenario is only a bandaid making up for an under-powered board, IMHO. With battery size/count restrictions, we don't have any choice, but in AC powered systems we should have a PS beefy enough to allow the radio and all peripherals to go nuts without affecting each other.
If you suspect a supply voltage dropout to the nRF, you'll receive fine. So maybe try taking the other peripherals out one by one, maybe measuring overall current draw, and see if the symptom at some point goes away.
And finally, my opinion is that the radio board is the most suspect piece in the chain. Playing musical parts might save you messing with the caps... :)

]]>https://forum.mysensors.org/post/72704https://forum.mysensors.org/post/72704Tue, 01 Aug 2017 02:12:42 GMT<![CDATA[Reply to Read this first - it could SAVE YOU A LOT OF TIME on Thu, 23 Feb 2017 21:49:46 GMT]]>I have updated the instructions above with references to the new awesome online log parser tool created by @hek. https://www.mysensors.org/build/parser

]]>https://forum.mysensors.org/post/60638https://forum.mysensors.org/post/60638Thu, 23 Feb 2017 21:49:46 GMT<![CDATA[Reply to Read this first - it could SAVE YOU A LOT OF TIME on Mon, 17 Oct 2016 10:49:34 GMT]]>"Error sending command, check device/hardware"

I had oxidized dupont wires between radio and arduino. Good thing to check if your sensors lives outside!

]]>https://forum.mysensors.org/post/50412https://forum.mysensors.org/post/50412Mon, 17 Oct 2016 10:49:34 GMT<![CDATA[Reply to Read this first - it could SAVE YOU A LOT OF TIME on Wed, 21 Sep 2016 15:04:36 GMT]]>I just checked my sensors and I'm using 470µF.
Shows to go you really should check what you grab from a bag of capacitors ;)

]]>https://forum.mysensors.org/post/48195https://forum.mysensors.org/post/48195Wed, 21 Sep 2016 15:04:36 GMT<![CDATA[Reply to Read this first - it could SAVE YOU A LOT OF TIME on Wed, 14 Sep 2016 09:35:32 GMT]]>@pellusfromtellus thanks for noticing. I've updated the connect radio page, hopefully it is a bit clearer now.

@sundberg84 nice profile picture. Great to get a face for you :)

]]>https://forum.mysensors.org/post/47658https://forum.mysensors.org/post/47658Wed, 14 Sep 2016 09:35:32 GMT<![CDATA[Reply to Read this first - it could SAVE YOU A LOT OF TIME on Wed, 14 Sep 2016 06:07:19 GMT]]>@sundberg84: Tks for answering! :)

]]>https://forum.mysensors.org/post/47641https://forum.mysensors.org/post/47641Wed, 14 Sep 2016 06:07:19 GMT<![CDATA[Reply to Read this first - it could SAVE YOU A LOT OF TIME on Wed, 14 Sep 2016 06:05:30 GMT]]>@pellusfromtellus - its a typo... mostly I use a 4.7uF but to be honest im not sure which is the "recommended".

]]>https://forum.mysensors.org/post/47640https://forum.mysensors.org/post/47640Wed, 14 Sep 2016 06:05:30 GMT<![CDATA[Reply to Read this first - it could SAVE YOU A LOT OF TIME on Wed, 14 Sep 2016 05:48:28 GMT]]>Hi!

Thanks for Your troubleshooting guide. For a newbie (like me) it's really appreciated! :)

A newbie question: Why do You use a 4.7 µF capasitor and on the page for connecting the radio (https://www.mysensors.org/build/connect_radio) they use a 47µF capasitor (10 times bigger)?

/Pellus

]]>https://forum.mysensors.org/post/47638https://forum.mysensors.org/post/47638Wed, 14 Sep 2016 05:48:28 GMT<![CDATA[Reply to Read this first - it could SAVE YOU A LOT OF TIME on Tue, 02 Jan 2018 18:58:00 GMT]]>For reading debug output for MySensors 2.0 (starts with TSP/TSM), see this great post by @tekka and the doxygen documentation at https://www.mysensors.org/apidocs-beta/group__MyTransportgrp.html#details

EDIT: Or even better, use the awesome online log parser tool.

]]>https://forum.mysensors.org/post/43373https://forum.mysensors.org/post/43373Tue, 02 Jan 2018 18:58:00 GMT<![CDATA[Reply to Read this first - it could SAVE YOU A LOT OF TIME on Mon, 29 Feb 2016 22:27:44 GMT]]>Troubleshoot the debug output

(courtesy of @martinhjelmare from this thread)

From the source code in the dev branch: link

s = sensor id
c = message type 0-4: presentation, set, req, internal or stream. See link
t = value type: S_VALUE during presentation or V_VALUE during set/req
pt = payload type: string, byte int, etc. See link
l = message length
sg = signed or unsigned message: 0 or 1 for false or true

0;0;3;0;9 means node 0 , sensor 0, internal message (3), not an ack message (0), log message (9). This means that it's the gateway that prints this info as a log after already having received the message from a node.

At the end you have the payload: 27

Similarly for a sent message: link

]]>https://forum.mysensors.org/post/33000https://forum.mysensors.org/post/33000Mon, 29 Feb 2016 22:27:44 GMT<![CDATA[Reply to Read this first - it could SAVE YOU A LOT OF TIME on Sat, 20 Feb 2016 15:09:49 GMT]]>Hi Everyone,

I made a quick video to share some of the things I've learned when troubleshooting issues. I’m not an expert and this is by no means an all-inclusive troubleshooting guide but hopefully it will give you some tips that will help you get to the root of the problem you’re experiencing.

https://youtu.be/vehinrWbxpw

]]>https://forum.mysensors.org/post/32115https://forum.mysensors.org/post/32115Sat, 20 Feb 2016 15:09:49 GMT