good karma

[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 :-1:

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