2.0 Discussion: Units, sensor types and protocol
-
I am working on a security protocol, and have posted my take on things in the security thread. I will weigh in on this thread once I have verified my design, but so far, only two new message types should be needed, one to request security capabilities and once for capabilities and a nonce. I do not think software based security is a suitable solution due to memory constraints so I am going for a hardware based solution with a pre-shared key. I will publish more concrete examples once I have verified them.
-
Hi,
Is there any move on the V2 ? Can we see the actual status and what it is going to look like ?
Going to a V2 for the Jeedom controller, will like to see it coming with mySensors v2 changes.
Precisly will like to have a status about :- reboot of node without needing a special bootloader (inside the lib will be the best)
- sending libversion from presentation including for gateway (this is include for nodes, I don't know for gateway)
- possible of sending V_type used during presentation, no need to wait to send data
- possible of sending a short desc name for each sensors created (can be helpfull when you create many sensors with same type and the difference is not only the order)
- possible to send the power source of node, I don't know inside battery or else. This will be very helpful with battery/plug or battery/solar source for exemple. So we can know how much the battery is full but also if the sensor is actually on battery.
- getConfig to be used for any paramteres instead of units, like this the node can request parameters from the conrtoler (think about a global sketch for a switch that can talk to a relay node, by the controller side you set which node it's controling)
Can we have a wiki page maybe with an actual status of where is the V2 ? And is there a dev version we can try ?
-
Hi,
Is there any move on the V2 ? Can we see the actual status and what it is going to look like ?
Going to a V2 for the Jeedom controller, will like to see it coming with mySensors v2 changes.
Precisly will like to have a status about :- reboot of node without needing a special bootloader (inside the lib will be the best)
- sending libversion from presentation including for gateway (this is include for nodes, I don't know for gateway)
- possible of sending V_type used during presentation, no need to wait to send data
- possible of sending a short desc name for each sensors created (can be helpfull when you create many sensors with same type and the difference is not only the order)
- possible to send the power source of node, I don't know inside battery or else. This will be very helpful with battery/plug or battery/solar source for exemple. So we can know how much the battery is full but also if the sensor is actually on battery.
- getConfig to be used for any paramteres instead of units, like this the node can request parameters from the conrtoler (think about a global sketch for a switch that can talk to a relay node, by the controller side you set which node it's controling)
Can we have a wiki page maybe with an actual status of where is the V2 ? And is there a dev version we can try ?
@lunarok said:
Hi,
Is there any move on the V2 ? Can we see the actual status and what it is going to look like ?
There has been some delays due to workload. But i hope to finish it eventually. :)
- reboot of node without needing a special bootloader (inside the lib will be the best)
Not sure it is possible to reboot an arduino without watchdog enabled (anyone knows any tricks?).
- sending libversion from presentation including for gateway (this is include for nodes, I don't know for gateway)
Yep, possible to get version from gateway today.
- possible of sending V_type used during presentation, no need to wait to send data
There will be a different setup.
- possible of sending a short desc name for each sensors created (can be helpfull when you create many sensors with same type and the difference is not only the order)
Good idea! I'll take that into consideration.
- possible to send the power source of node, I don't know inside battery or else. This will be very helpful with battery/plug or battery/solar source for exemple. So we can know how much the battery is full but also if the sensor is actually on battery.
Thats also a good idea. I'll have to think about how it could be incorporated.
- getConfig to be used for any paramteres instead of units, like this the node can request parameters from the conrtoler (think about a global sketch for a switch that can talk to a relay node, by the controller side you set which node it's controling)
Config/settings will be a bit different as well.
Can we have a wiki page maybe with an actual status of where is the V2 ? And is there a dev version we can try ?
Hmm.. my github account (henrikekblad) will contain the source until I feel it's worth trying out by the community. But there is a part of it I'm waiting for a c++ guru at work helping out with (advanced c++ templating which is a bit over my level of c++ knowledge). Those will hopefully make callbacks (incoming messages) usage awesome.
The plan is the gateway will be able to accept/push json objects instead of the semicolon separated parameters, Much depends on how memory demanding it becomes.
-
@lunarok said:
Hi,
Is there any move on the V2 ? Can we see the actual status and what it is going to look like ?
There has been some delays due to workload. But i hope to finish it eventually. :)
- reboot of node without needing a special bootloader (inside the lib will be the best)
Not sure it is possible to reboot an arduino without watchdog enabled (anyone knows any tricks?).
- sending libversion from presentation including for gateway (this is include for nodes, I don't know for gateway)
Yep, possible to get version from gateway today.
- possible of sending V_type used during presentation, no need to wait to send data
There will be a different setup.
- possible of sending a short desc name for each sensors created (can be helpfull when you create many sensors with same type and the difference is not only the order)
Good idea! I'll take that into consideration.
- possible to send the power source of node, I don't know inside battery or else. This will be very helpful with battery/plug or battery/solar source for exemple. So we can know how much the battery is full but also if the sensor is actually on battery.
Thats also a good idea. I'll have to think about how it could be incorporated.
- getConfig to be used for any paramteres instead of units, like this the node can request parameters from the conrtoler (think about a global sketch for a switch that can talk to a relay node, by the controller side you set which node it's controling)
Config/settings will be a bit different as well.
Can we have a wiki page maybe with an actual status of where is the V2 ? And is there a dev version we can try ?
Hmm.. my github account (henrikekblad) will contain the source until I feel it's worth trying out by the community. But there is a part of it I'm waiting for a c++ guru at work helping out with (advanced c++ templating which is a bit over my level of c++ knowledge). Those will hopefully make callbacks (incoming messages) usage awesome.
The plan is the gateway will be able to accept/push json objects instead of the semicolon separated parameters, Much depends on how memory demanding it becomes.
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 NETWORKsense and drive
-
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.
