Topics created by tante ju

@tante-ju Sorry for the late reply, I have been away for a few days with work. While I am sure there will be more than one way to achieve your goal I have given a brief outline of the way i did it below. If all you want to do is request data from another node it should not need any more steps than @Sasquatch has listed above. Lets say we have node A with an id of 1 we also have node B with an id of 2 and it has a binary sensor with a child id of 3 Node A wants to know the the status of the binary sensor on node B So in your code on node A you will issue the request to query child id 3 on node 2 request( 3, V_STATUS, 2); The gateway will rout this directly to node B where you will need to have code to deal with the request in the receive(); function. In it's simplest form you could have something like this below. void receive(const MyMessage &message) { if (message.type == V_STATUS) { if (message.getCommand() == C_REQ){ // message is request // put code here to be executed when the message is from a request // most likely you will call a function that will get the requested // data and return it to node A. If you are expecting requests for more than 1 // sensor you can use message.sensor to test which sensor the request is for } else { // message is from gateway,process the message as per normal // put code here to be executed when the message is from gateway } } } in the scenario above node B only expects requests from node A or commands from the gateway so it is easy to check what has arrived. If the message is a request we can execute code to get the required data and send it back. if it is a command (C_SET) from the gateway then it will fall through to the else part of the statement and be available as per normal. To send back the Data you will need to use a node to node message. this can be done on the fly, the format is shown below /* Node to Node message format. * * * * * * : Id of sending : message : Destination : Destination : Payload * * : sensor : Type : sensor Id : Node Id : */ send(MyMessage(sendingSensorId, V_STATUS).setSensor(sensorId).setDestination(nodeId).set(true)); //send message to desitination node So using our example you would have. (As we are not trying to actually switch any sensors on node A we can leave out the setSensor() part of the message) send(MyMessage(3, V_STATUS).setDestination(1).set(true)); Being a binary sensor the payload would be set to either true or false. Now we have sent the data all that is left to do is catch it in the recieve part of node A. One way to do this is simply to test for where the message has come from, if it is from the gateway (node 0) or in our case node 2. void receive(const MyMessage &message) { if (message.type == V_STATUS) { if (message.sender == 0) { // check if message is from gateway (node 0) // put code here for normal gateway messages } else { // message is not from gateway so check to see if it is from node B if (message.sender == 2 ){ Put code here to deal with returning request } } } }

This is an issue with the HW SPI port in the atmega328. If configured as an input, the master spi port will turn into a slave, if SS pin is low. Atmega328p datasheet, section 19.3.2: When the SPI is configured as a Master (MSTR in SPCR is set), the user can determine the direction of the SS pin. If SS is configured as an output, the pin is a general output pin which does not affect the SPI system. Typically, the pin will be driving the SS pin of the SPI Slave. If SS is configured as an input, it must be held high to ensure Master SPI operation. If the SS pin is driven low by peripheral circuitry when the SPI is configured as a Master with the SS pin defined as an input, the SPI system interprets this as another master selecting the SPI as a slave and starting to send data to it. To avoid bus contention, the SPI system takes the following actions: The MSTR bit in SPCR is cleared and the SPI system becomes a Slave. As a result of the SPI becoming a Slave, the MOSI and SCK pins become inputs. The SPIF Flag in SPSR is set, and if the SPI interrupt is enabled, and the I-bit in SREG is set, the interrupt routine will be executed. Thus, when interrupt-driven SPI transmission is used in Master mode, and there exists a possibility that SS is driven low, the interrupt should always check that the MSTR bit is still set. If the MSTR bit has been cleared by a slave select, it must be set by the user to re-enable SPI Master mode.