2.0 Discussion: Units, sensor types and protocol
-
can we avoid float?
instead of float a multiplied integer can be used
for example 34.6 C temperature can be presented as 346 (no dot)a single float operation increase HEX size significantly
@hek what about idea we discussed to have a network with multiple gateways?
what about adding support for the 2.0 for the nodes be able to have a different BASE address per each gateway?
this way the future network will allows to have 255 sensors per EACH gateway, not per NETWORKYes, configurable base address would be handy if we choose to create an ESP-gateway. It is already supported today but you have to hard code it into MyConfig.h. Would be neat to have this configurable over WiFi.
Using OTA transmitted floats is optional. I haven't looked so deeply on how/if this will be supported yet in the upcoming version.
-
This post is deleted!
-
what benefit is there from encryption vs signing in the MySensors case?
If you have a lock or door sensor do you want others to know when it is opened or closed?
Signing is quite expensive if you look at additional payload size, you need a big counter to prevent replay and a big MAC to prevent attacks. I think that when encrypting things you can do it with the same additional payload and maybe even a less.
-
This post is deleted!
-
Yes, signing, when properly done, is for sure a good begin.
How many bytes are you using for the truncated MAC and nonce?
The AES block size is 128 bytes, so 16 bytes so I do not see why that would not fit.
Encryption is already some kind of authentication is a sense that if you can successfully decode the message you can be sure that the other side knows the shared secret, just like in the cause of your SHA25-HMAC.
-
Would be good to move the last five message into a separate thread...
-
This post is deleted!
-
This post is deleted!
-
There is a solution for multi-gateway that I'm working to port it to the development branch which could use the same radio channel and also to have sensors at gateway node.
-
There is a solution for multi-gateway that I'm working to port it to the development branch which could use the same radio channel and also to have sensors at gateway node.
-
Gateway become normal node, with an id(1-254), like a repeater. Address 0 become like a virtual address which is used when a node wants to send a message to the controller.
This solution will give more redundancy to the network but the same limitations apply, like the max of 254 per network. -
In the case raised by @lunarok, I'm not sure it will fit.
-
Gateway become normal node, with an id(1-254), like a repeater. Address 0 become like a virtual address which is used when a node wants to send a message to the controller.
This solution will give more redundancy to the network but the same limitations apply, like the max of 254 per network.@celonunes said:
Gateway become normal node, with an id(1-254), like a repeater. Address 0 become like a virtual address which is used when a node wants to send a message to the controller.
This solution will give more redundancy to the network but the same limitations apply, like the max of 254 per network.OK. But how this will prevent conflicts on the air between nodes connected to different gateways and having same radio channel and BASE_ADDRESS?
-
Each node will continue to have a unique id in the network.
The controller would have additional work to map nodes to their proper gateway, and this could make the whole idea into something impracticable depending on the controller software.
