Polling mode for sensors
-
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.
-
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?
-
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.' -
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.'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).
-
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.'@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...
-
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)
-
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)
-
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).
@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.
-
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.
-
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.
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.
-
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
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-deviceThere 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.
