good karma

[hek]

You really don't need to start include mode (that was more to help vera cope with things).
A request for id will have messageType=4, type=5.

What you got was:

Received: from=255, to=255, childId=79, mtype=9, type=0, crc=184, '' 

There actually is no mtype=9. Looks like your header is messed up. Probably due to usage of c-bifields for the header struct (which is assembled/disassembled differently for rpi/arduino compiler). This has been fixed in the upcoming version of the library (were we use normal bit operations to extract the part-8-bit header stuff). A quickfix could be to use full bytes for all header fields (on the arduin/rpi-side).

Or you could have a look at the new development version: https://github.com/mysensors/Arduino/tree/development and make the corresponding changes to RPI code.

If you do the (preferred) later approach, please make sure to create a github pull request so we don't duplicate any work. :)

[aliasdoc]

Thanks Hek, I'll try to port the new development version to RPi and create pull request soon ;).

[aliasdoc]

@hek any idea to port eeprom routing table to raspberry, I think I can use a binary file to this and redefine eeprom_*() functions. What do you think about it ?

[hek]

@aliasdoc
That would be a nice solution! The less we need to re-#define the better.

[aliasdoc]

Ok, now I ported the library to RPI and make tests but the first send command from node is ok, but after it fails
RPI debug:

0;0;4;9;Device startup complete.
0;0;4;8;read: 255-255-255 s=255,c=4,t=7,cr=ec:
0;0;4;8;read: 255-255-255 s=255,c=4,t=7,cr=ec:
0;0;4;8;read: 255-255-0 s=255,c=4,t=3,cr=ec:
0;0;4;8;read: 255-255-0 s=255,c=4,t=3,cr=ec:
0;0;4;8;read: 255-255-0 s=255,c=4,t=3,cr=ec:
0;0;4;8;read: 255-255-0 s=255,c=4,t=3,cr=ec:
0;0;4;8;read: 255-255-0 s=255,c=4,t=3,cr=ec:
0;0;4;8;read: 255-255-0 s=255,c=4,t=3,cr=ec:
0;0;4;8;read: 255-255-0 s=255,c=4,t=3,cr=ec:
0;0;4;8;read: 255-255-0 s=255,c=4,t=3,cr=ec:
0;0;4;8;read: 255-255-0 s=255,c=4,t=3,cr=ec:
0;0;4;8;read: 255-255-0 s=255,c=4,t=3,cr=ec:

and arduino node debug:

send: 255-255-255-255 s=255,c=4,t=7, st=ok:
req node id
send: 255-255-255-0 s=255,c=4,t=3, st=fail:
sensor started, id 255
req node id
send: 255-255-255-0 s=255,c=4,t=3, st=fail:
req node id
send: 255-255-255-0 s=255,c=4,t=3, st=fail:
req node id
send: 255-255-255-0 s=255,c=4,t=3, st=fail:
req node id
send: 255-255-255-0 s=255,c=4,t=3, st=fail:
req node id
send: 255-255-255-0 s=255,c=4,t=3, st=fail:

any idea ?

[hek]

Looks like you get crc-error. cr=ec

Hmm.. guess you'll have to dig into that part to see what could be wrong.

Not sure why the node reports transmission failure... Are you using the same RF24 library version on both ends (you should use the same as Arduino-side).

[aliasdoc]

yes I use the same, this one https://github.com/mysensors/Arduino/tree/development/libraries/RF24/RPi for RPI and this https://github.com/mysensors/Arduino/tree/development/libraries/RF24 for arduino node. In the first call, all is ok but after the I_PING all calls fails :s

[hek]

Good.

Very strange. It's like the RPI radio stops acking... but at the same time it is receiving.. Hmm ..
PING (4,7) is a broadcast message which isn't acked by receiver. But ID_REQUST(4,3) should be acked by RPI.

Try to get crc ok first.

[aliasdoc]

Hi @hek, i check crc8message() function and it appears that thje result is not the same in RPi and arduino ( ?? ) and there are another problem with RF24 drivers, RPi version in the development repo is not the same as arduino version but very similar. The write() function always return false with unicast, I need help with driver, any volunteers ?? :)

[hek]

This is the fork we're using: https://github.com/TMRh20/RF24

Could you create an issue for TMRh20 here:
https://github.com/TMRh20/RF24/issues?state=open