💬 Serial Protocol - 2.x
-
Thank you for the comments about the protocol. We have started to look at a new binary protocol for the future, and I think that your input is valuable.
However this will break compatibility completely, so we have to get plugin developers on board as well, when we are confident enough about the base layout of the protocol. As they have to be ready with support for a new protocol from day 1, when we release it.
(the protocol draft is on a Google document, can't remember the link right now, but perhaps @hek has it in his favorites :))
@tbowmo I made some related comments some while back when 2.0 was being developed, but then I disappeared from MySensors for many months (life does that). So I understand that it's too late for changes to that, and I am only planting seeds for the future, accepting that many will not sprout soon, or ever. The current spec is already a good effort.
The comments about more specific documentation can still be implemented, tho.
Perhaps I can help with comments on the binary protocol. The problem is that it has to map nearly 1:1 into the serial protocol, right? Or not?
I continue to be impressed with the quality of this community.
-
As the binary protocol is breaking things anyways, we could break it so it becomes right :) So it doesn't have to map 1:1 with the old protocol.
I think that we had the ASCII protocol so much in the heads, when we started looking at a future (binary) protocol it was made 1:1.. But it's not finalized at all yet, so it's still very open for comments :)
-
Is there any chances that binary protocol will support sending of multiple sensor values per one message?
I'm talking about nodes that (for example) sending several binary switch sensor values with 1-byte value. Even if one set/req message contains 5 fields (5 bytes, currently Sensor id, Var type, Ack-thing (request ack / is ack), Payload type (integer, float, string, binary), Payload) it's possible to pack at least 4-5 results into single 32-byte message. This will reduce the load on the radio network 5 times. Also this will reduce gateway's load. It's also possible to remove duplicating fields and further reduce protocol.
For example, some of my nodes sending 5 temperatures from ds18b20 sensors. Packing all 5 temps into single message (2 bytes for temp and 1 byte for sensor id) will reduce traffic 5 times.
Packing/unpacking can be done at gateway side.
-
the protocol spec is still in very early draft.. That said, I would really like to keep things as simple as possible on the node side, in order to conserve flash / ram space as much as possible..
But let's see, it might be a year before we have something ready.. And it will probably be mysensors 3.0 that will get the new protocol, as it will probably break compatibility in every way possible :D
-
the protocol spec is still in very early draft.. That said, I would really like to keep things as simple as possible on the node side, in order to conserve flash / ram space as much as possible..
But let's see, it might be a year before we have something ready.. And it will probably be mysensors 3.0 that will get the new protocol, as it will probably break compatibility in every way possible :D
@tbowmo I agree with keeping things simple to implement, particularly on the Node & Gateway side. And it doesn't hurt that this would likely also keep things simpler to implement on the Controller side (ie: simpler plug-ins/adapters/drivers to write, which is a positive even when resources are not so tight.).
We might be able to nevertheless implement some kind of multi-value packet concept tho. I added a comment to the 3.0 doc about a simple and low overhead way to allow homogeneous arrays. That might or might not be worthwhile.
Robosensors's use case would involve some kind of tagged sub-unit approach, with multiple id/value pairs, yet another concept worth considering.
-
Regarding V_POSITION and using semi-colons inside the payload, that will in my view break the API message structure. At least home assistant/pymysensors will not work with this. I'll build for and recommend users of that controller to use comma instead of semi-colon to split info inside the payload for V_POSITION.
-
This is just what I've been looking for. I do however have a suggestion. I'm building a solar heater (water) for my shop and need to keep track of at least 3 temps (solar panel, storage tank, and inside shop), 1 water pressure and 1 water flow meter (for solar panel Pump) . There doesn't seem to be V_ or S_ variables for direct water pressure or flow. Would you please add something for them.
-
@mfalkvidd said:
@musthafa is there a reason S_BINARY can't be used for those cases?
Thanks. Didn't look at it. Solved my problem.
-
Where can I find the structure for the payload of the internal command I_LOG_MESSAGE ? e.g. payload "TSF:MSG:SEND,211-0-220-220,s=211,c=1,t=23,pt=2,l=2,sg=0,ft=0,st=OK:69"
I know I'm sending a value from node 211 to node 220 with the value 69. What does c=1, t=23, pt=2, l=2, sg=0,ft=0 mean? -
Where can I find the structure for the payload of the internal command I_LOG_MESSAGE ? e.g. payload "TSF:MSG:SEND,211-0-220-220,s=211,c=1,t=23,pt=2,l=2,sg=0,ft=0,st=OK:69"
I know I'm sending a value from node 211 to node 220 with the value 69. What does c=1, t=23, pt=2, l=2, sg=0,ft=0 mean? -
-
how can I handle sendheartbeat() messages in my controller? What payload will be sent? 1 or 0, True or False...?
ps I´m using openhab
@siod said in 💬 Serial Protocol - 2.x:
how can I handle sendheartbeat() messages in my controller? What payload will be sent? 1 or 0, True or False...?
ps I´m using openhab
I just tested this using a Serial gateway.
Sending
sendHeartbeat()from node displays this on my Serial gateway:... 214;255;3;0;22;73 214;255;3;0;22;108 214;255;3;0;22;143 ...3=internal message
0=nack
22=I_HEARTBEAT_RESPONSEIn MyTransport.cpp I found
uint32_t transportGetHeartbeat(void) { return transportTimeInState(); } --- uint32_t transportTimeInState(void) { return hwMillis() - _transportSM.stateEnter; }So the payload is some elapsed time in milliseconds.
-
@siod said in 💬 Serial Protocol - 2.x:
how can I handle sendheartbeat() messages in my controller? What payload will be sent? 1 or 0, True or False...?
ps I´m using openhab
I just tested this using a Serial gateway.
Sending
sendHeartbeat()from node displays this on my Serial gateway:... 214;255;3;0;22;73 214;255;3;0;22;108 214;255;3;0;22;143 ...3=internal message
0=nack
22=I_HEARTBEAT_RESPONSEIn MyTransport.cpp I found
uint32_t transportGetHeartbeat(void) { return transportTimeInState(); } --- uint32_t transportTimeInState(void) { return hwMillis() - _transportSM.stateEnter; }So the payload is some elapsed time in milliseconds.
@gvorster Thank you for explanation!
One more thing: I wanted to implement a sendHeartbeat() into a Repeater node (which should never sleep!), where should I put this function and how? When putting it just into the loop it is of course spamming my gateway with heartbeat messages...Is it possible anyway?
