Replies: 1 comment 5 replies
-
Interesting message finds. Although, I don't think the feature you want is implemented (yet). To identify the message content you need to track them and make sense out of the (hopefully) changing values. You can use the 'decode' command with the slave reply and a given datatype and script this to get the values e.g. for the most likely datatypes, e.g.
Still tedious... but not all datatypes are actually used. Most common ones are uch/d1b (1-byte) and uin/sin/d2c (2-byte) or combine reading and decoding in one line:
This will decode only the last byte (tail -c 4) or the two last bytes (tail -c 6) of the slave reply, respectively. |
Beta Was this translation helpful? Give feedback.
5 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
I'm trying to decode some of the unknown messages sent within my system and could use hints.
Basically, when giving the above mentioned command (ebusctl grab result decode), my system spits out a huge amount of information which drowns me in unnecessary data, and hides the essential stuff. But at the same time the mentioned "decode" feature seems to be quite useful.
Let me give you an example:
when giving "ebusctl grab result all |grep f108b50905540200" i get a list with entries like the following:
f108b50905540200f80a / 050201f80a2d = 126
f108b50905540200fa0a / 050201fa0a2c = 122
f108b50905540200ff0a / 060201ff0ad0f9 = 127
f108b509055402005b0d / 0802015b0d0000c040 = 7959: hmux0 RunDataElectricPowerConsumption
f108b50905540200de08 / 080201de0800005341 = 1242: hmux0 RunDataAirInletTemp
...
From this it's pretty obvious that the essential part of the request is only in the last 2 bytes per message sent by the master. For the last 2 messages, there are entries in the .csv file, for the other 3 there are none.
There is also some structure in the answers from the slave:
Thus, i would need a possibility to narrow down the build-in "decode" function to the relevant parts of the messages. And ideally provide single raw messages, as delivered by "ebusctl grab result" as input.
in the example above:
input: f108b50905540200f80a / 050201f80a2d plus some direction that the decoding should focus on "2d"
output: all possible decoding variants of "2d" based upon the pre-defined data types in ebusd.
Does anybody have an idea how to get that?
Beta Was this translation helpful? Give feedback.
All reactions