Why text-based communication???

[4Project]

Hi all,

Just wonder... What is the reason the communication protocol is text-based?

It's great for debugging and compatability between different vendors, but as I understand there is no such thing as different vendors. Everybody creates and deploys their own devices, so that's probably not the reason.

Leave alone debates how float number should be transmitted in binary format, but if I look on the header itself (before the payload), transmitting it in binary format would save more than 70% of the transmitted data!
That means more data for payload, better power saving for battery based sensors and much more...

Thanks,
Alex

[hek]

Most over-the-air data is transmitted in a binary format from the sensors (i.e. a float is represented by 4 bytes) with the exception of some hvac-states.
The gateway<->controller communication protocol (where low bandwidth is less important) is text based. We've discussed a binary variant but it's still only on the drawing board.

[4Project]

Oh... Apparently I was looking on the Serial Protocol specification, that clearly states that it's describing Gateway and the Controller communication, so that's my bad.

Is there a documentation for the over-the-air messaging beside looking into the code?
I want to make sure it covers all the ideas I had in my mind...

Still have one question regarding the Gateway <--> Controller communication:
The mesasges have only one address (node) ID, meaning there is no way to describe sourse and destination.
Does that mean all the communication is always destined/sourced to/from the controller?
I mean, in KNX all the devices send both source and destination in the telegrams, the switch address the actuator directly.
If I undestand that correctly, in controller-based systems the switch messages are routed to the controller and the controller sends "lights-on" message to the actuator?

Thanks,
Alex

[BulldogLowell]

@4Project said in Why text-based communication???:

Does that mean all the communication is always destined/sourced to/from the controller?

I think that is explained in the network topology.

If you want to send a message node-to-node, you could try to manage it through your gateway or a repeater.

[4Project]

Thanks alot!

Both links clear all my concerns.
Looks like I have all the features I had in mind for my future deployment.

Thanks,
Alex

[4Project]

I was thinking about node-to-node communication a bit more and see few problems with it.
Will appreciate if someone could answer if those are real problems or maybe the implementation covers some of them:

Destination node-id is ok for routing the packets, but it's not enough.
Without child-sensor-id it will not be possible to address a specific port on an actuator.
Is there a way to send child-node-id in the packet?

As I understand, gateways/repeaters use the destination node-id along with their internal routing table to know where to forward the packet to.
If destination node-id is not a gateway id, the packet will be forwarded to the destination node, but will never reach the controller for logging the event. Am I right?
Assuming there is only gateway in the deployment, is there an easy way to push the packet to the controller for node-to-node packets as well?

Even if there is a solution for point 2 issue, the serial protocol don't pass the destination node-id (and destination-child-node-id) to the controller, so the controller won't know if it should answer or only log the event.
Maybe that could be solved by some rules in the controller, just to log the event as with temperature sensor for example...
The rules might be a solution, but without destination-child-id the controller won't be able to log properly events for smart nodes with multiple children since it still don't have that information. The example I can think of is a multi button switch that controls 2 different window shutters that are controlled by single actuator with multiple child-sensor-ids and the switch node decides what shutter should move based on its own logic (light direction for example).

Thanks,
Alex

[Nca78]

Hello @4Project ,
did you read this ? https://www.mysensors.org/download/sensor_api_20

I think it will answer your question for point 1, and probably most of point 3 too...

For point 2, the logic is receiving node will report its new state to controller after receiving a direct message. if you want to make sure the controller gets it then send message to controller and use controller logic to transfer new state to receiving node.

[4Project]

Hi,

I've read it again... now I think I get it better.

Your explanation for point 2 logic makes sense.
Thanks for explaining that.

Regards,
Alex