Polling mode for sensors

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