Trying to make sense of Serial display
-
@BulldogLowell said:
Have you read the Serial API?
Ummm, yes, I mentioned "I am OK with the Serial Protocol for the data" but what is all the other stuff? I also mentioned I am writing my own Controller and surely that might have implied that I have been programming for a while as it is not a trivial task. As it happens that "while" is about 40 years. :)
0;0;3;0;9;read: 23-23-0 s=255,c= < This mishmash
3,t=11,pt=0,l=8,sg=0:Humidity< This mishmash
23;255;3;0;11;Humidity< This mishmash
0;0;3;0;9;read: 23-23-0 s=255,c=3,t=12,pt=0,l=3,sg=0:1.0< This mishmash
23;255;3;0;12;1.0 < aaahhhh finally, data!I am sure all that other stuff is important and means something, but where do I read about it? I know I could wade through the .h and .cpp files, but given the description for the Serial Protocol, I hoped (expected) something that similarly explains the "mishmash."
It makes no sense to me to merely discard all that mishmash-data to just get at the Serial-Data portion.
@NotTooTechy said:
but what is all the other stuff? I also mentioned I am writing my own Controller and surely that might have implied that I have been programming for a while as it is not a trivial task. As it happens that "while" is about 40 years.
0;0;3;0;9;read: 23-23-0 s=255,c= < This mishmash
3,t=11,pt=0,l=8,sg=0:Humidity< This mishmash
23;255;3;0;11;Humidity< This mishmash
0;0;3;0;9;read: 23-23-0 s=255,c=3,t=12,pt=0,l=3,sg=0:1.0< This mishmash
23;255;3;0;12;1.0 < aaahhhh finally, data!but, in the API it describes exactly what the "mishmash" is! It contains Node ID's, sensor ID's and other critical data for you to sort the messages... plus the data. ;)
-
@NotTooTechy said:
but what is all the other stuff? I also mentioned I am writing my own Controller and surely that might have implied that I have been programming for a while as it is not a trivial task. As it happens that "while" is about 40 years.
0;0;3;0;9;read: 23-23-0 s=255,c= < This mishmash
3,t=11,pt=0,l=8,sg=0:Humidity< This mishmash
23;255;3;0;11;Humidity< This mishmash
0;0;3;0;9;read: 23-23-0 s=255,c=3,t=12,pt=0,l=3,sg=0:1.0< This mishmash
23;255;3;0;12;1.0 < aaahhhh finally, data!but, in the API it describes exactly what the "mishmash" is! It contains Node ID's, sensor ID's and other critical data for you to sort the messages... plus the data. ;)
@BulldogLowell said:
but, in the API it describes exactly what the "mishmash" is!
Thanks for your patience, but I must be getting too old. I cannot find it.
This page...
http://www.mysensors.org/download/sensor_api_15#the-full-api
As far as I can see does not explain...
0;0;3;0;9;read: 23-23-0 s=1,c=1,t=0,pt=7,l=5,sg=0:69.8
^; ^; ^; ^; ^,,,,,,,,,,,,,,,,,,,,,,,,^,,,,,^,,,,,^,,,,,^,,,,,,,^,,,,,^The things above the Caret ("^") and their values. I can guess at the 23,23,0 as NodeId,NodeID,GatewayID but what is "s=1" etc?
I assume the ":" is a delimiter for the data.I realize this is free stuff, but the documentation does leave a good deal to be desired. Or, maybe it IS just me. :)
It is crazy having half of the cod in plain text and the rest on in Codebender. I understand why it IS in Codebender, but for a documentation page to make a copy of to refer to offline, it is useless.
-
If you actually read the post @mfalkvidd mentioned earlier, you'll find the information you seek.
http://forum.mysensors.org/topic/666/debug-faq-and-how-ask-for-help
-
I think the point here is that you left debug on. I wrote my own controller too (using LabView, serial, VISA) and the only thing I needed (and I suppose you need the same) are the plain messages. I guess your serial output should look like this (I took it from your first message in this thread):
0;0;3;0;14;Gateway startup complete.
23;255;3;0;15;0
23;255;0;0;17;1.5.4
23;255;3;0;6;0
23;255;3;0;11;Humidity
23;255;3;0;12;1.0
23;0;0;0;7;
23;1;0;0;6;
23;1;1;0;0;69.8
23;0;1;0;1;37.0To switch "off" debug, go to Myconfig.h and make a small change:
#define DEBUG
into:
// #define DEBUG
You can put it on again once the serial gateway is up and running to get debug information from the nodes you create.
BR,
Boozz
-
@BulldogLowell said:
but, in the API it describes exactly what the "mishmash" is!
Thanks for your patience, but I must be getting too old. I cannot find it.
This page...
http://www.mysensors.org/download/sensor_api_15#the-full-api
As far as I can see does not explain...
0;0;3;0;9;read: 23-23-0 s=1,c=1,t=0,pt=7,l=5,sg=0:69.8
^; ^; ^; ^; ^,,,,,,,,,,,,,,,,,,,,,,,,^,,,,,^,,,,,^,,,,,^,,,,,,,^,,,,,^The things above the Caret ("^") and their values. I can guess at the 23,23,0 as NodeId,NodeID,GatewayID but what is "s=1" etc?
I assume the ":" is a delimiter for the data.I realize this is free stuff, but the documentation does leave a good deal to be desired. Or, maybe it IS just me. :)
It is crazy having half of the cod in plain text and the rest on in Codebender. I understand why it IS in Codebender, but for a documentation page to make a copy of to refer to offline, it is useless.
@NotTooTechy said:
@BulldogLowell said:
but, in the API it describes exactly what the "mishmash" is!
Thanks for your patience, but I must be getting too old. I cannot find it.
This page...
http://www.mysensors.org/download/sensor_api_15#the-full-api
As far as I can see does not explain...
0;0;3;0;9;read: 23-23-0 s=1,c=1,t=0,pt=7,l=5,sg=0:69.8
^; ^; ^; ^; ^,,,,,,,,,,,,,,,,,,,,,,,,^,,,,,^,,,,,^,,,,,^,,,,,,,^,,,,,^If you look at the serial api, and decode the above string, it will be:
0 -> NodeId (GW)
0 -> ChildSensorID
3 -> Internal message
0 -> no ack
9 -> Debug messageSo it's a debug message that is sent by the GW :) The rest is the payload..
The format of the debug message (payload) could probably have been described better somewhere, but haven't been done yet. (feel free to chip in with documentation :))
-
@NotTooTechy said:
@BulldogLowell said:
but, in the API it describes exactly what the "mishmash" is!
Thanks for your patience, but I must be getting too old. I cannot find it.
This page...
http://www.mysensors.org/download/sensor_api_15#the-full-api
As far as I can see does not explain...
0;0;3;0;9;read: 23-23-0 s=1,c=1,t=0,pt=7,l=5,sg=0:69.8
^; ^; ^; ^; ^,,,,,,,,,,,,,,,,,,,,,,,,^,,,,,^,,,,,^,,,,,^,,,,,,,^,,,,,^If you look at the serial api, and decode the above string, it will be:
0 -> NodeId (GW)
0 -> ChildSensorID
3 -> Internal message
0 -> no ack
9 -> Debug messageSo it's a debug message that is sent by the GW :) The rest is the payload..
The format of the debug message (payload) could probably have been described better somewhere, but haven't been done yet. (feel free to chip in with documentation :))
-
@hek said:
Haha, this must be one of the most confused up threads here :)
But getting better. Thank you all. Now that I see that some of the messages are from the Gateway and not all from the Node it is making some more sense. It would be nice to see some CR and LF in the output, but having employed many programmers over my working life, I understand. ;)
Why does "c = message type" and not "m" for instance? before asking here I was trying to make sense of it without wasting everyone's time and searching files.
@boozz seems to have solved it for me with turn off Debug.
I think that, other than snide comments, we can close this thread from my standpoint. :)
-
In the MySensors protocol, messageType is also called command (for historical reasons I guess?). So c made sense, at least when the debug output was added to the code. There is a link available in the description in the debug faq to the code where a comment saying "The command field (message-type) defines the overall properties of a message" is available.