Hi,

Try this solution...

Hi,

Send 3 messages one after the other ?

For now, when a sensor sends a message, it doesn't check back for any incoming messages. Further more, the controller is not aware when the sensor is ready to process messages. How can the sensor and the controller can agree on the moment to communicate ?

To give some examples :

• Run time modifications on sleeping sensors : change the sleeping duration, modify planning of the automatic watering system, modify the treshold alert for a motion sensor. Every kind of dynamic changes without rebuilding the sketch.
• When a sensor/controller needs to send informations to a sleeping sensor : like a reboot system every day at midnight,
• More elaborated AI => send the data to the controller and ask what to do.

This is as something like :
Sensor : 'Hey, I'm sensor 12, any news for me ?"
Controller : 'You have 2 messages waiting for you !'
Sensor : 'Ok, I'm ready, you can send them right now.'

Look at the basic temperature sensor example. The sensor sends the data to the controller, but it doesn't ask for pending messages, it just go back to sleep mode again immediatly. If the controller recieve a message from a sensor with pending messages and try to send the pending message immediatly, there's no waranty that the sensor is waiting for or is ready to receive that message.

From what I understand, for now, if the controller sends an ack message and the sensor doesn't send back the ack, it tries again an again indefinitely (some kind of busy loop ?). With this internal message, the sensor ask and wait for the controller to send pending ack messages.

Hi

Currently, sensors need to actively process incoming radio messages via the process() method frequently, otherwise messages are lost... This is the default behavior. A new behavior may be introduced. Messages are stored in the controller and the sensor ask for pending messages. This way the sensor can go in deep sleep mode via the method sleep() without losing any messages.

Two new internal messages are introduced :

• I_SKETCH_POLLING : the sensor send it with a payload value of 1 activates the poll mode, and a value of 0 disables it. This behavior can be changed either at boot time or any time in the lifetime of the sensor. The sensor can request his status with the I_CONFIG message and checks if a flag is set (ie: 'P' for polling mode ?).

• I_SEND_PENDING_MESSAGES : when the message is sent from a sensor, this asks the controller to send the first pending message. No attention is given to the payload. When the message is sent from the controller to the sensor, the payload contains the number of pending messages.

Here's the logical loop when the sensor needs to check for pending messages :

[A] - The sensor sends the internal message I_SEND_PENDING_MESSAGES asking for the controller to send the first pending message (payload is empty).
[B] - The controller sends the first pending message (FIFO) to the sensor if any message is pending, otherwise, if no message are pending, send the internal message I_SEND_PENDING_MESSAGES with a payload of 0.
[C] - The sensor have 2 options, if message received is :

• of any king => process the message and go to step A

• I_SEND_PENDING_MESSAGES => If the message is I_SEND_PENDING_MESSAGES with a payload of 0, then sensor knows now that no messages are pendind and can go back to sleep mode again.

What do you think about this ?

Hi

My question is about moving sensor from one 'MySensors network' (lets call it network A) to another (lets call it network B ), ie: a friend give you one of his sensors from his network. In this scenario, the sensor still use his network A id in the network B. This may cause conflicts with another sensor with the same id in the new network...

A solution would be to give a network some kind of hashcode to compare with a sensor at boot time (in gw.begin()). If hashcodes are different (the one stored in the controller/gateway and the one stored in the sensor), then the sensor need to reinitialize (reset EEPROM and reboot) before any other action. The hashcode may be a string of 8 characters for example.

Add a new sub-type for internal mesage like this :
I_NETWORK_HASHCODE with a value of 15 (?) with the comment "Hashcode used in the network to avoid conflict with others networks".

What do you think about that ?