[SOLVED] 8MHz Gateway : node not receiving any data

[rene_2k2]

Hello all,

I'm trying to use MySensors with RFM69W, but I have a problem with the node not having its ID assigned.

I'm using Arduino 1.6.5, MySensors 1.5, SerialGateway on a ProMini and various node sketches (last one tested is MockMySensors) from examples on a Atmega328 on a breadboard. I'm using stable 3.3V sources and have put caps between Vcc and Gnd for both node and gateway.

I have tested sketches (gateway and node) from lowpowerlab sketches with the same hardware and it works (gateway receives data from node, ACK ok).
I also have switched Mysensors gateway and node sketches between my 2 physical "nodes" to check that both can emit and receive data, and the result is the same : I see in MYSController (v0.1.2_282) that the node emits its id-request, then the gateway sends an id-response that never seems to be received OR parsed by the node (nothing shows in the serial monitor of the node).
Using a defined ID in node sketch, that looks better : the gateway can see the node and its children sensors and their values. But if the node requires time, the gateway sends it but the node, once more, does not seem to receive/parse anything.

For those of you using RFM69, did you encounter any problem of data not being received by node ? (When using id=AUTO but eeprom not cleared from previous tests, I did not notice the problem. I had to clear eeprom and use id=AUTO or to use time requests to notice that behaviour).
Any clues on what can go wrong ?

[nagelc]

I had an issue that sounds similar with a temperature node. The node would transmit, but could not receive from the gateway. I had connected the RFM69 D100 pin to the Arduino D3 pin instead of the D2 pin. I did not notice because I wired it the same as I had wired the NRF24 version of the node. I don’t think the NRF24 interrupt pin is used in MySensors, but the RFM69 interrupt pin (D100) is.
When I had this issue, it would not work with the Low Power Lab Node and Gateway switches either.
Once I connected D100 to the right pin, it worked fine

[fets]

@rene_2k2 from what I read, the id resquest is manage by the controller not by the serial gateway and I think that MYSController doesn't support this feature. So you have to use a static id (this is what I do).
I experience the same issue with my rfm69 (tested yesteray night for the first time) so I planed to take a closer look this evening but as I see that I'm not alone, may be i'll try to check what nagelc said or take a closer look to the forum.
The suprise is that my gateway receive succesfully message from node but not the other way

[rene_2k2]

Thanks for your answers guys !

@nagelc I think my hardware is OK with DIO0 attached to D2 pin as Node & Gateway sketches from LowPowerLab work (I've just tested once more with ACK enabled and communication is OK in both ways).

@fets You're right : the gateway (at least serial but I think Ethernet too) does not handle ID affectations on its own. However MYSController is a great tool and has an Auto-ID option and also allows you to build whatever message (eg ID response) and to send it immediately or when receiving a message from a node. I see on MYSController's messages tab the ID requests from the node followed by ID responses sent to/by the Gateway (and it loops back to ID-req...).

[fets]

@rene_2k2 what sketch do you use on your node ?
I'm now able to read incoming messages, I had to change mysensor.sleep(xxx) call in loop function by mysensor.wait(xxx).
I hope it helps.

[tekka]

@fets said:

@rene_2k2 from what I read, the id resquest is manage by the controller not by the serial gateway and I think that MYSController doesn't support this feature. So you have to use a static id (this is what I do).

nope, ID requests are handled by MYSController. If the power supply is stable and ID assignments fail, you may try clearing the routing tables (clear gw eeprom)

[rene_2k2]

Hi,

Sorry for late reply, big storm, falling trees, internet/phone cables on the ground...

@fets The sketches I used on my node is MockMySensors from the examples of MySensors V1.5 (adapted for RFM69), this sketch allows me to test sending and receiving messages. I've also tried others such as TimeAwareSensor, but with the same results...
@tekka I've tried clearing eeprom of node and gateway, but does not seems better.

I now have 2 physical nodes like the ones described by @Francois (Arduino Pro Mini & RFM69W connected by jumper wires, see his post ). The strange thing is that when using LowPowerLab node & gw sketches, it looks like no frame is lost (gw receiving each frame sent by node and all ACK responds OK) [even without caps and antennas when nodes are not far away]. whereas when using MySensors (gw & node or even 2 PingPong), they have difficulties to catch each others data.
When using gw & node, gw seems to get node data but node does not get gw data : for TimeAwakeNode, it often needs to send at least 6 time requests before catching the gw response... This behaviour remains unchanged when swapping hardware. Do you know how I can first determine if this is the node not catching data or the gateway not sending data correctly (in MYSController's debug tab, I see the lines of data which are normally sent by the gateway but can I check that this data is really transmitted) ?

@Francois : you have played with RFM69, don't you have any problems of nodes which do not receive reliably data from the gateway ? (I'm using V1.5)

Any idea ?

[Francois]

@rene_2k2 I don't have any issue with any of my nodes that is using the rfm69 radios. I also upgrade all my nodes to ver 1.5. I am using a series gateway and my controller is Domoticz

[rene_2k2]

@Francois : Thanks for the answer.
I'll keep investigating then...

[etrombly]

I just switched over to mysensors, and am having the same issue. Using RFM69's with arduino pro mini's and openhab. The sensor registers with the serial gateway, and receives acks, but the gateway does not send any other messages to the node. I'll try to dig more into it, but since I'm new to mysensors I'm getting familiar with how everything works. Here's the debug info from the gateway:

2015-09-12 19:17:24 - Arduino state updated to 0;0;3;0;9;read: 100-100-0 s=255,c=3,t=11,pt=0,l=5,sg=0:Relay
100;255;3;0;11;Relay
0;0;3;0;9;read: 100-100-0 s=255,c=3,t=12,pt=0,l=3,sg=0:1.0
100;255;3;0;12;1.0
0;0;3;0;9;read: 100-100-0 s=1,c=0,t=3,pt=0,l=0,sg=0:
100;1;0;0;3;

2015-09-12 19:17:43 - KitchenPower received command ON
2015-09-12 19:17:44 - Arduino received command 100;1;1;0;2;1

2015-09-12 19:17:45 - KitchenPower state updated to ON

and the relay node:

send: 100-100-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
sensor started, id=100, parent=0, distance=1
send: 100-100-0-0 s=255,c=3,t=11,pt=0,l=5,sg=0,st=ok:Relay
send: 100-100-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.0
send: 100-100-0-0 s=1,c=0,t=3,pt=0,l=0,sg=0,st=ok:

[etrombly]

Got it figured out. If anyone has this trouble in the future. If you are using a pro mini at 3.3V and 8mhz it isn't compatible with 115200 baud for serial communications. Switch BAUD_RATE to 57600 in MyConfig.h and it will fix the problem. You'll also need to change the baud to match in your demo.items, or whatever your site is called. (for openhab)

[rene_2k2]

@etrombly : thank you so much ! Setting baudrate to 57600 on my gateway seems to resolve the issue.

I had just realized there was a problem with gateway not sending packets thanks to the "WITH_LEDS_BLINKING" option but did not realized that my ProMini did not understand serial input at 115200... The tricky part is that it had no problem with serial output at 115200 and it sometimes even parse and process correctly serial 155200bauds input. However setting lower baudrate seems to work always now !

[etrombly]

@rene_2k2 no problem, it was a really frustrating issue to troubleshoot. I ended up adding some debug prints to serialEvent() in the serialGateway code. Noticed that the first character on a send was fine, then the rest was garbled. A little googling showed what the problem was.

[rene_2k2]

Just updated the subject so that people with the same issue find it easily.