Read this first - it could SAVE YOU A LOT OF TIME

[mfalkvidd]

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

[mfalkvidd]

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.

[pellusfromtellus]

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

[sundberg84]

@pellusfromtellus - its a typo... mostly I use a 4.7uF but to be honest im not sure which is the "recommended".

[pellusfromtellus]

@sundberg84: Tks for answering! :)

[mfalkvidd]

@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 :)

[Nicklas Starkel]

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

[pjr]

"Error sending command, check device/hardware"

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

[mfalkvidd]

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

[Bogus Exception]

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

[alowhum]

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.

[Anticimex]

@alowhum the security documentation is quite clear on the use of eeprom for encryption keys.

[TRS-80]

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

[ctodor]

@mfalkvidd what if we replace "s" with "sensorId" and so one?

[mfalkvidd]

@ctodor sorry, I don’t understand. Could you describe where the sensorid could be added?