Polling mode for sensors

[iliak]

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 ?

[hek]

Couldn't the controller just send out the pending (un-transmitted) messages if it receives communication from a node with undelivered messages?

[iliak]

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.

[rvendrame]

I'm new to IOT / MySensors but I have some experience (20+ years) with computer data interfaces

To evaluate Push x Pull we need to think on how real-time and/or reliable we need the final result. I think the answer to this question varies according to the type of sensor (don't forget the actuators) , as well as the result expected by the 'end-user'.

What kind of message could be queued at controller side , targeting a typical temperature sensor (assuming the only thing that node does is cycling measure temp - send data - sleep )?

For actuators (like Dimmers), it makes more sense like hek described (with the comment that only latest message/status matters in this case).

For mixed (sensor+actuator, relay) nodes --- usually they don't sleep, so I believe they fall in the 'actuator' case above.

Maybe I'm missing a situation where the node go to sleep (or temporary down/out of range) and it really needs to receive messages from the controller?

[iliak]

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.'

[hek]

@iliak

Currently It is up to the sketch developer to keep node awake long enough to receive any config messages from controller.

I don't think any of the current controllers push any information when they receive a message from a sleeping node. But it is not a big thing to implement.

But as @rvendrame says, it is quite hard to find any good use case (except for configuration).

[rvendrame]

@iliak, I understand what you mean.

@hek, the gw.request() on node side would not be enough for config messages ? Stills up to sketch developer to program a gw.request from time to time...

The only 'generic' case I can think now: Queueing messages on both node and gateway sides. So in case a receiver (either node or gw) gets temporarily down, messages targeting that receiver would be queued at sender side until the receiver be 'seeing' again.

That could most likely cause the sender run out-of-memory, specially on 2K nodes --- So a hard limit of messages / time must be preset in the header file. Old messages would be discarded first if necessary.

In order hand it would benefit sensors that collect statistical data, usually running on batteries. During a power outage on GW side for example --- Data would still be collected, and transmitted later to controller.

Now I'm thinking that we don't have a time-stamp at the messages So maybe what I wrote it is not so 'beneficial' from statistical point of view...

[lunarok]

Hi,

Will be very interested in the developpment of this subject.
As for the Jeedom controller, I'm waiting the "best" way to do this part.
It can be done to send information/order to a node only when he wakes up as long there is a sign of it.
But my problem is that yes, the sketchs using sleep never care about waiting for unexpecting under send when they are sleeping.

So for me, if you have a way to implement it on the sketch part with the actual protocol untouched, I will be happy to test it (we have already some user expecting a possibility to get an order when their nodes awake)

[hek]

@lunarok

In your sketch you can call:
gw.wait(500)
just before sleep.

This will keep the node wake for half a second while still receive input from controller side.

[X-Ryl669]

@hek The main use case I see (and for me it's a must have) is for power saving. Typically, I've a motion sensor + temp/hum in a single node.
The motion sensor is not active (it's OFF electrically) when the home is not activated.

When I activate the home, the gateway sends all motion sensors' node the order to switch on. But since the nodes are sleeping 99.99% of the time, without a mailbox, these messages would be lost, resulting in the home not activated.

However, if the gateway stores at least one pending message, then, when the node wakes up to send its periodic message, the gateway tells it not to sleep immediately, and sends the pending message back to the node. This, in turns, switches the motion sensor ON.

My sleep time is 8s, so I know that when the home is under alarm, at worst, 8s later the motion sensor is running.

In fact for any actuator (not sensor), this is absolutely required when battery powered.

[hek]

Hi @X-Ryl669 ,

Unfortunately the available memory left in the gateway makes this type of buffering not possible (it must be able to store 254*32 bytes).

To add more gateway functionality we need to step up a notch (hardware vise) or let the controller take care of it.

[X-Ryl669]

Hi @hek ,

I don't get why you would need 254*32 bytes. Actually, only the memory for pending messages are required. When the GW received from a node, it just has to scan in its pending messages list for a matching node, and send the message (then remove from the list).

Because of limited memory constraint, you'll not be able to have a single message per node at a time, but since only few nodes are actuators, I think it should not be an issue.

I've code around doing this, unfortunately not for MySensor (I found your project only recently). I'll try to create a PR for it, if you don't mind.

[andriej]

@hek how about MEGA as a gateway? It has bigger memory available...

[hek]

@X-Ryl669
I'm happy to see what you come up with.

@andriej
There is a ongoing discussion here about creating a gw-device with a little bit more horsepower:
http://forum.mysensors.org/topic/1137/gateway-device

There is also the option of using RPi as combined controller/gateway. @celonunes is making an effort to join the current development branch with the separate Raspberry project.