good karma

[sensorsusr]

I'm a Linux newbie, so I won't be able to help out much with the Raspberry Pi gateway development. But I wanted to send some good karma this way because I'm really excited about it, and appreciate all the work you guys are doing.

I'd like to better understand how the Raspberry Pi gateway would work though. These are some of my assumptions.

1. The RPi runs a webserver, and presents all current sensor data as a webpage?

2. RPi also acts as the interactive button provider, so you can actuate Arduino outputs from buttons in the webpage?

3. Will there be data collection and trending? Is that what the cloud based service is? Can I use the RPi to send data to xively or similar services?

4. Is the RPi doing to act as a scene agent? So you can make conditions (if Node 5 PIR sensor senses motion) and take action (activate LED on Node 6 Arduino)?

[hek]

The RPI gateway development will be a two phase thing.

1. In the first phase we will just have a cache-and-forward from the RPI to the cloud-service. All trends and visualization takes place on MySensors web service. The RPI will only run a low footprint database (local backup/cache) and a node-app that keeps a bi-directional web socket open for sensor data and commands back to the RPI. If you also have a Vera it should be able to connect to the RPI (transparent to todays ethernet gateway). The RPI web interface will be minimal. Basically just a single page for entering your API key to the cloud-service and some debug logging. With some beta testers we can now start optimizing data storage and how we store data and how we do realtime processing. Our cloud API will be open for leaving data from other types of sensors and HA systems. Initially we'll offer REST and websocket. The API also opens up for APPs and other goodies.

2. Phase 2 will be much more fun. We're thinking rule engine (with the possibility of pushing rules to RPI that can be executed when offline). Service integration (push notifications, email etc) for server-side rules. We might also offer a more advanced local web interface of the RPI.

[jendrush]

It's great project, and probably all of this forum user know it, but i have question. Can i ask for possible timeline for developement? When could we expect cloud service launch?

[hek]

@jendrush

Timeline... yes, I only wish I knew... This is a project we are all doing on our free time (which varies over time). Giving an estimate might just give false hopes. One thing I know is that everything takes much longer than first anticipated.

But, we'll work as much as we can without losing our families over it

[epierre]

Hello,

I've already made a sensors system interface to cosm in Perl, I could make the same for MySensors since I have all the basic and interface at the same time to some others domotics systems through JSON.

I have already what I need to make the vera (uno+ethernet shield+nrf4L) but not yet enough on the other side(emitter) nor diversity.

Is there a way I could simulate sensors reception, even run some lensors locally (I have humidity, dht11, FC-22-1, TCRT5000...) ? and thus try to emulate both in USB and Ethernet ?

[Yveaux]

@epierre I think you can. Use the serial command API to construct artificial messages as if they were coming from sensor nodes.
Have a simple server socket report them to your domotics interface and you won't notice the difference!

[epierre]

Hello,

Well, I thought I would have to wait for 30 days to have hardware, but I received it under 9 days.... well recommended hardware seller here are worth 5 stars !

Some soldering away and I'll have actual nodes !

Best !

[hek]

9 days is good. It happens sometimes when the post-office gods is in the right mood.

[aliasdoc]

Hi all, i try to use your library in my project with Raspberry Pi as Gateway, I start with your example "piGateway", all starting is done, here debug lines:

Starting Gateway...
Sensor-1Gateway created...
Hej-begin-SPI device = /dev/spidev0.0
SPI speed = 8000000
CE GPIO = 25
STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 = 0x7365727631 0xabcdabc000
RX_ADDR_P2-5 = 0xff 0xe3 0xe4 0xe5
TX_ADDR = 0x7365727631
RX_PW_P0-6 = 0x20 0x20 0x20 0x20 0x20 0x20
EN_AA = 0x3f
EN_RXADDR = 0x3f
RF_CH = 0x4c
RF_SETUP = 0x07
CONFIG = 0x0f
DYNPD/FEATURE = 0x3f 0x04
Data Rate = 1MBPS
Model = nRF24L01+
CRC Length = 16 bits
PA Power = PA_MAX
Radio setup complete-After setupRadio-After openReadingPipe-After startListening-After serial-Begin called

but if I run my arduino with any examples (HumiditySensor, BatteryPoweredSensor, ...) They don't communicate. I double checked wiring, all is OK. Need help thanks.

[jendrush]

@aliasdoc said:

They don't communicate. I double checked wiring, all is OK. Need help thanks.

Do you have a capacitor between power, and ground? I have had same problem, and it helped.

[aliasdoc]

Hi jendrush, yes I have a capacitor of 10uF, transmission is ok with another framework (RF24network).

[aliasdoc]

I have one arduino uno loaded with DallasTemperatureSensor sketch and on rPi running PiGateway example

[Yveaux]

@aliasdoc Do the RX_ADDR_Px and TX_ADDR values match your configuration? If they are then communication seems to work ok.
Some other trivial questions:

• are both radio's on the same channel
• same baudrate
• both use CRC
• have same packet length/use dynamic packet length
• do you run the RPi code as root?

[aliasdoc]

Hi Yveaux and thanks, effectively, config of my arduino is 2MBPS and RPi is 1MBPS, now it communicate but in RPI, I had "Unknown route from GW" error :

Dynamic payload size=7
Received: from=255, to=255, childId=79, mtype=9, type=0, crc=184, ''
Message crc ok.
header.type=0, header.to=255, radioId=0
Unknown route from GW

and from arduino:

Tx: fr=255,to=255,la=255,ne=255,ci=255,mt=4,ty=9,cr=184:
No relay nodes was found. Trying again in 10 seconds.

[Yveaux]

@aliasdoc This one's for Hek

[aliasdoc]

Sorry Yveaux but I don't understand "Hek", what is this ?? thanks

[jendrush]

@aliasdoc Hek is founder/cofounder of mysensors:) I am right?:)

[aliasdoc]

thanks jendrush, i'm so stupid

[hek]

@aliasdoc
It looks like the gateway/controller don't know where to send/route message for node 255.
I haven't really analyzed the RPI code that deeply but it must mimic the EEPROM routing table that the serial/ethernet gateway has (by picking up incomings messages last node.id)... If that is missing then RPI-gw has no clue where to send outgoing messages to nodes.

[gregl]

@aliasdoc said:

Sorry Yveaux but I don't understand "Hek", what is this ?? thanks

Hek is the son of HAL...and the secret sauce who made all this possible....

All Hail Hek!!!

[aliasdoc]

Hi Hek :), thanks for your reply, my RPi is my gateway, i try to make my own "cloud support", for testing, I have 1 RPi running as gateway (with example on github) and 1 sensor running BatteryPowerSensor sketch (original) like this:

(my cloud system) <-------- RPi (as gateway) <------------ arduino sensor (with BatteryPowersensor sketch)

Do I need to start inclusion mode ?? If I understand well, this mode is for automatic ID attribution, is correct ?

And I don't see any EEPROM routing table in serial ethernet examples.

Sorry if my questions are stupid, I try to understand how it works.

[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