The MySensors 1.3 version is soon stable enough to be “released”.
This also means we can start discussing 1.4 protocol changes to make the sensor network even more robust. I am talking about changes on the over-the-air protocol, gw->vera protocol and MySensors C++ API .
I have a few new feature-ideas that might affect all of these and I would really like your input.
Optional “ack” message when sending message between sensors and to gateway. Important sensors like smoke/co2 really need this to confirm that messages has been delivered. Requires small changes to the header. The trick here is how to add this without needing to duplicate all send-methods.
Should we consider sending all payload data as binary instead of ascii values between sensors->gateway->vera. This would reduce payload size, computation power and reduce program size (less conversions).
Encryption. Should be optional per sensor. Requires header changes. This might be a too advanced task for our small MCUs.
It would also be nice to be able to register callback for incoming messages for per child/message types. We could probably also simplify sending of raw digital/analog pin inputs at some sample rate.
The c++ api overall needs a facelift and should have more logical method-names. The goal here is to make it as simple as possible to use. But at the same time it should be very flexible for advanced users.
Sounds good and this might be the best path for node quality monitoring - kill two birds with one stone.
Gets my vote.
Gets my vote. While this may be a challenge, I think security is an imperative to unlock the full potential. When you consider people using MySensors.org for things like opening garage doors, security becomes paramount otherwise its adoption may be relegated to non-sensitive use cases for monitoring.
[[quote=“hek, post:1, topic:180096”]The c++ api overall needs a facelift and should have more logical method-names. The goal here is to make it as simple as possible to use. But at the same time it should be very flexible for advanced users.[/quote]
I agree and perhaps consider different entity abstractions.
Sounds great!
Would this also be implemented on the acuators?
Sometimes the acuators dosen’t get the message and then it would be great with an “ack” function and perhaps a repeat function in the gateway?
Could the protocol be redesigned to include statefull communications, eg like TCP for those with a networking background?
The sending node first completes a three way handshake with the destination node before data transfer begins.
The CRC already implemented ensures the integrity of data transferred.
Acknowledgements would be used after CRC passes.
Once transfer is complete a finish or hangup is sent from the source and acknowledged by the destination closing the conversation.
This adds additional overhead which has its disadvantages, however it would provide guaranteed delivery which is critical for security devices.
Another feature which could feed into Bruce’s reporting is “keep alives” from the gateway to remote nodes. This may not be desirable for battery powered remote nodes though. Having a visual indication in Vera that a sensor is unreachable could help proactively identify and resolve issues.
Just my thoughts as I cannot code but happy to test where possible.
Could the protocol be redesigned to include statefull communications, eg like TCP for those with a networking background?
The sending node first completes a three way handshake with the destination node before data transfer begins.
The CRC already implemented ensures the integrity of data transferred.
Acknowledgements would be used after CRC passes.
Once transfer is complete a finish or hangup is sent from the source and acknowledged by the destination closing the conversation.
This adds additional overhead which has its disadvantages, however it would provide guaranteed delivery which is critical for security devices.
Another feature which could feed into Bruce’s reporting is “keep alives” from the gateway to remote nodes. This may not be desirable for battery powered remote nodes though. Having a visual indication in Vera that a sensor is unreachable could help proactively identify and resolve issues.
Just my thoughts as I cannot code but happy to test where possible.[/quote]
Hi!
We can probably not create a full fledge TCP-like setup over the NRF24L01 radios. There are several problems that has to be taken into account.
Memory (we don’t have space in the limited Arduino memory to buffer/resend messages)
The radio cannot listen while in write mode (so these periods has to be as short as possible)
KISS - Increased complexity will introduce will probably lead to new strange bugs. Building a fully functional TCP-stack over radio is a very complex task.
Small improvement steps is my plan right now. (But I won’t prevent giant leaps if we come up with some revolutionary ideas!)
Also if we keep the core library simple and small we have more space for the actual sketch.
A simpler approach would be be to just add a Sequence count to to messages sent do a device … and repeat the last sequence when the device responds. It’s a trivial part of the TCP/IP protocol.
Then you cam place the burden of dealing with a missed response strictly on the device interrogator.
Best Home Automation shopping experience. Shop at Ezlo!