Still not going well for me.

[iotearoa]

Have you tried using 10uf? That fixes the problem for me.
You can use between 4.7 upto 47uf. Most people I've read the 10uf fixes it.

As stipulate at mysensors:

Maybe, Mysensors should really highlight that? :)

[Coffeesnob]

MarcoE- thanks for the tip. I don't have a spare radio but I have another Arduino project I can load which is from another home automation system (DeviceBit) , when load that up I get 100% reliable communication between the two radios so I'm pretty sure its nothing at all to do with hardware.

iotearoa- I am not convinced that the issues is power related. given that the Devicebit method doesn't require a cap and it is using the power from the Arduino. Never the less, i have a 10uf cap i can try.

Having said that clearly given the very low number of responses I must be the only one with this issue. so i think what I'm going to do now is reverse engineer a test communication network using the code from DeviceBit. if I get this to work, then I will post the results here. this may also end up being useful for somebody else because, to be honest, the diagnostics on mysensors are a little bit light on and this makes the exercise a lot frustrating.

[petewill]

@Coffeesnob If you can, you may want to try using two nanos or pro minis before trying to use the Mega. Mega's can be tricky to get right the first time. Also, where are you defining the radio pins for both of the sketches? Did you do it in myconfig.h? If so, did you change it back when you uploaded the nano code?

[Coffeesnob]

@petewill, thanks for the tip. I think you might actually be onto something. But as I don't have any other nano's that's not really an option today. I have order more but they will take at least 3 weeks to get here.

having said that, I have made some important discoveries in the last 24 hours. bottom line I have written a test sketch that runs on both a nano and a Mega and it send messages back and forth between them. This has proven 100% that the issue is not hardware related but it is software related. Now my plan is to write a script that uses the MyConfig.h to get the SPI settings. That way once it's all working with the test sketch you will have a very high probability of it working with Mysensors.

also while I have your attention. I really found your troubleshooting video very very helpful, thanks a lot for doing that. but I wonder do you happen to have or know of a video which shows how to use MYSController. once I get past my current woes I suspect I will need MYSController to resolve other issues.

thanks for your help so far. i really do appreciate it.

[petewill]

@Coffeesnob Yeah, I would order a couple of Nanos (or Pro Minis). They are cheap and are always helpful for troubleshooting.
Here is how I have my devices wired:

*need to configure these pins in the sketch

Here is the code you will need to configure the sketch of the Mega. Make sure to put these lines above the #include <MySensors.h> line.
#define MY_RF24_CE_PIN 49
#define MY_RF24_CS_PIN 53
You should not need to change anything in MyConfig.h if you wire as described above.

The Nano can be wired as described above and no changes need to be made in your sketch or MyConfig.h. This code assumes you are using MySensors 2.x.

I hope that makes sense.

As for a MYSController video, I'm not aware of any out there yet. I have it on my list of videos to make but it's not at the top...

[Coffeesnob]

@petewill, Wow this is EXACTLY what I have been looking for. thanks very very much. I will give it a try.

[Coffeesnob]

@petewill, you sir are a star... this was the information I was missing and it is now working as expected. below is the serial monitor trace from both the Mega and the Uno.

First the Mega

0;255;3;0;9;MCO:BGN:STP
0;255;3;0;9;MCO:BGN:INIT OK,TSP=1
0;255;3;0;9;TSF:MSG:READ,10-10-0,s=255,c=3,t=26,pt=1,l=1,sg=0:2
0;255;3;0;9;TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=27,pt=1,l=1,sg=0,ft=0,st=OK:1
0;255;3;0;9;TSF:MSG:READ,10-10-0,s=1,c=1,t=16,pt=0,l=1,sg=0:1
0;255;3;0;9;MCO:BGN:INIT GW,CP=RNNGA--,VER=2.1.0
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSF:WUR:MS=0
0;255;3;0;9;TSM:INIT:TSP OK
0;255;3;0;9;TSM:INIT:GW MODE
0;255;3;0;9;TSM:READY:ID=0,PAR=0,DIS=0
0;255;3;0;9;MCO:REG:NOT NEEDED

and this is the Uno...
8994 TSF:MSG:SEND,10-10-0-0,s=1,c=1,t=16,pt=0,l=1,sg=0,ft=0,st=OK:1
9000 MCO:SLP:MS=120000,SMS=0,I1=1,M1=1,I2=255,M2=255
9006 MCO:SLP:TPD

I have literally spent hours on this. I think the documentation in terms of getting started needs to be expanded on considerably. I get this is a huge task but if you don't know much about Arduino or know where to look you pretty much screwed.

[mfalkvidd]

@Coffeesnob we try to add as much information as possible in the documentation, without overwhelming users with more information than they can handle. Too much information will make people cringe and go somewhere else.

The Mega is big and relatively expensive. Therefore most people use Nano or Pro Mini. I'm hesitant to add a lot of information for non-common use cases because that information will not be relevant for most users and therefore will just be annoying when people try to create their first sensor.

I have updated the connecting the radio page to include wiring information and the defines for Mega.

Could you list the top 3-5 things that would have helped you the most, and where you would have expected to find that information? That would be great input.

[Coffeesnob]

@mfalkvidd thanks for your reply. I was going to try and contact you about this very thing. If its ok can I PM you will suggestions, I completely get what you’re talking about, I know this problem very well. But there is a way you can provide the information required that is not so in your face which I agree can be an issue.
I would also like to develop a test Sketch that can be used to prove that all the hardware is working independent of anything in the API. This would have made my experience that much easier because I was not actually able to determine where the issue was until I had first proven that it was not the radio or the two different boards I am using (which was suggested in this post as well as in the troubleshooting guide). Are we able to perhaps have a chat via email or something about how to facilitate that?

[mfalkvidd]

@Coffeesnob Great, thanks!
PM is ok if you don't want to discuss it in a forum thread.

[petewill]

@Coffeesnob Sorry for the delayed reply. I was in the mountains the last few days. I'm glad you got it working! There are a lot of different factors at play when designing your own sensors and learning something new can take time but I think you are over the biggest hurdle now.

@mfalkvidd thanks for updating the documentation. You are awesome!

[Coffeesnob]

@petewill, appreciate it. I'm very happy with the outcome, for the most part. However, I now have a new challenger. I am using a relay module and I can happily turn relays on using MYSController but can't seem to figure out how to turn them off. I know you know a little about this product so I wonder if you can point me in the right direction.
I have also connected to my gateway serially using HomeGenie and it can't turn either on or off. but I haven't had time to do any further fault finding there yet.

As soon as I have time, I will provide promised doc. i then need to know where to send them.

[Coffeesnob]

@mfalkvidd, I can post here no problem. but I also want to provide a how-to of sorts that will help newbies like me to rule out anything that is Mysensors related. I just thought this would require me a to PM you

[petewill]

@Coffeesnob said in Still not going well for me.:

I am using a relay module and I can happily turn relays on using MYSController but can't seem to figure out how to turn them off.

Can't you just send a 0 instead of a 1? I don't ever use MYSController for controlling devices. Only for monitoring traffic. All my control is done with Vera. That being said though you should only need to send a 0 to turn off the relay.

[Coffeesnob]

@petewill, yep you would think that would do it... however, it doesn't seem to work. what is interesting is if I send a 1 it also doesn't turn on the relay, only sending an empty message turns it on. I think I might post in the MYSController forum to see if they have any ideas.

[tekka]

@Coffeesnob hmm, can you post your sketch and the debug logs, I assume something must be wrong the way you process incoming messages.

[Coffeesnob]

@tekka, will do. I have had a hardware related issue that is unrelated to this directly. (i bricked my Nano trying to flush the eprom) but it means that until I get this fixed or get new hardware I am not going to be able to do anymore. Im hoping that Im getting close because this is really getting pretty frustrating.

[Coffeesnob]

@mfalkvidd, I have finally had the opportunity to reply to your question from a week back “Could you list the top 3-5 things that would have helped you the most, and where you would have expected to find that information? That would be great input.”
Ok so I think the big thing is there is not a lot of detail in troubleshooting. Clearly the radios are the most problematic part and not being able to get access to how they actually work makes it very frustrating. The table that peterwill provided is very helpful but this also requires you to have some background information.
I understand that you are trying to limit the amount of detail so as not to scare people away but I personally believe that having optional reference material would be extremely helpful. For example a diagram which explains how all the different liberties link together, this would have helped me to determine how the SPI components are setup.
It would have been extremely helpful if in your initial radio setup guide you had a reference to how the SPI components of the radios work. This would be an optional reference that people could look at if they wanted to. At the moment, the way these radios work is very much black magic, and because I am new to the whole Arduino thing I was unable to determine if you are using the standard SPI features of the Arduino or if you had created your own. An example of a reference might be https://www.arduino.cc/en/reference/SPI however it is also important to explain that Mysensors is using its own SPI library, you could (should) go into more detail about how the SPI library is setup from the Mysensors point of view, because if you have to work it out your self this is very chanalgin because there is no common reference to understand how Arduino default SPI relates to mysensors SPI

And finally, something which would make things oh so much easier, is a sample sketch that will just allow you to test the radios, i.e you type the number 1 into the serial monitor on the gateway and you will see a message on the node if the radios are all working. And vice versa. I am willing to take this on as a project as I am already working on it however I would ideally like it to use all the Mysensors library’s. In other words, it should behave like any other sensor network would. But I really need a lot more information to work out how to do this. In the meantime, once I get my radios back up and running again I will post a very quick and dirty version and let you have a look at it.
I hope this all makes sense. I am a huge fan of the work the my sensors team have done here. I want to do what I can to help make it better.

[Coffeesnob]

Ok, so the new hardware has finally arrived and I have been pulling my hair out trying to get it working. It appears like there is something wrong in the way the node and the gateway are setting up. I didn't have this problem a couple of weeks ago but since I have upgraded to v2.1.1 the problem has manifested. I have seen that there are a number of posts that appear to have similar issues but not exactly the same. Perhaps somebody can shed some light.

The setup is still exactly the same as I have described earlier in this post. I have a Mega and a Nano both with NRF24L01, I have a 10uf Cap across the power supplies of both radios, and I am 100% sure that the radios and the Arduinos are all working because I have built a NON Mysensor test sketch to prove this is all fine. Aside from that you can also see from the log transcript below that the units are actually talking. They just don’t seem to be able to complete the negotiation.

So here is what I am seeing. in the log transcript below you can see that the two devices are talking to each other. the Bold text are the messages being sent from the gateway and the normal text is the messages being sent from the Node.

0;255;3;0;9;MCO:BGN:INIT GW,CP=RNNGA--,VER=2.1.1
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSF:WUR:MS=0
0;255;3;0;9;TSM:INIT:TSP OK
0;255;3;0;9;TSM:INIT:GW MODE
0;255;3;0;9;TSM:READY:ID=0,PAR=0,DIS=0
0;255;3;0;9;MCO:REG:NOT NEEDED
0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.1.1
0;255;3;0;9;MCO:BGN:STP
0;255;3;0;9;MCO:BGN:INIT OK,TSP=1

0 MCO:BGN:INIT REPEATER,CP=RNNRA--,VER=2.1.1
3 MCO:BGN:BFR
5 TSM:INIT
6 TSF:WUR:MS=0
12 TSM:INIT:TSP OK
14 TSM:FPAR
16 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:

0;255;3;0;9;TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=255
0;255;3;0;9;TSF:CKU:OK,FCTRL
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0

89 TSF:MSG:READ,0-0-255,s=255,c=3,t=8,pt=1,l=1,sg=0:0
94 TSF:MSG:FPAR OK,ID=0,D=1
2023 TSM:FPAR:OK
2024 TSM:ID
2025 TSM:ID:REQ
2027 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:

0;255;3;0;9;TSF:MSG:READ,255-255-0,s=255,c=3,t=3,pt=0,l=0,sg=0:
255;255;3;0;3;

4035 TSM:ID
4036 TSM:ID:REQ
4038 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:

0;255;3;0;9;TSF:MSG:READ,255-255-0,s=255,c=3,t=3,pt=0,l=0,sg=0:
255;255;3;0;3;

4035 TSM:ID
4036 TSM:ID:REQ
4038 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:

0;255;3;0;9;TSF:MSG:READ,255-255-0,s=255,c=3,t=3,pt=0,l=0,sg=0:
255;255;3;0;3;

4035 TSM:ID
4036 TSM:ID:REQ
4038 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:

0;255;3;0;9;TSF:MSG:READ,255-255-0,s=255,c=3,t=3,pt=0,l=0,sg=0:
255;255;3;0;3;

10066 !TSM:ID:FAIL
10067 TSM:FAIL:CNT=1
10070 TSM:FAIL:PDT

What you can clearly see here is that the initial node setup takes place, the request from the node to the gateway is received by the gateway and it reply’s. the node receives the reply and then it sends its reply, the Gateway receives the reply and then try to send an acknowledgment, but the node never gets the message. I suspect this is because the message being sent from the gateway is incomplete for some reason.

For example the Node sends

4038 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:

The gateway responds with
0;255;3;0;9;TSF:MSG:READ,255-255-0,s=255,c=3,t=3,pt=0,l=0,sg=0:

Which in and of its self doesn’t look exactly right to me, but as I am not the expert in this I am probably wrong.

The gateway then prints 255;255;3;0;3; with nothing else in the line, this looks to me like its trying to send something but the message is empty.

What are your thoughts? @mfalkvidd and @petewill I am hoping you guys can shed some light here.

Thanks in advance.

[hek]

Which controller do you have setup with your gateway to answer the id requests from the node?