<div dir="ltr">Hi Ed,<div><br></div><div>I have had this exact same question before. There is a MR <a href="https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/merge_requests/190">https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/merge_requests/190</a> that does exactly this. I have not made contributions to it so I don't want to take credit for it but I'm quite excited for when it is merged!</div><div><br></div><div>Cheers,</div><div>Jack</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 27, 2021 at 8:21 AM Ed W <<a href="mailto:lists@wildgooses.com">lists@wildgooses.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi, I needed to access details of my modem via Elixir and I have
a future requirement to do similar things via Lua. However, it
seems more than a small hurdle to get access to libqmi from any
scripting languages?<br>
</p>
<p>My first thought was to adapt qmicli, which largely does
everything I need, but to patch the output to be optionally JSON
or similar. However, the coding style of qmicli, doesn't easily
lend itself to this kind of change. The issue is that, at present,
whilst many commands could be adapted, many others generate bits
of string data dynamically in response to nested conditionals,
etc.</p>
<p>So, because it's a potentially pretty large change, how much
interest is there to adapt the qmicli app to instead of generating
direct string output, to instead generate some kind of nested
structure (map), which will then either be kicked out as text
(identical to present), but can also optionally be converted to
something hierarchical and parseable, such as json/xml/toml, etc?</p>
<p><br>
</p>
<p>In the meantime for my elixir library I took a stab at simply
parsing the text which comes out of the current qmicli utility.
It's largely indented into a structure and so (largely), by
counting tabs at the beginning of the line one can fold it back
into some kind of structure that makes it easy to process in a
given scripting language.</p>
<p>However, there isn't absolute consistency in the format of the
output, for example, compare:</p>
<p> /usr/bin/qmicli -p -d /dev/cdc-wdm0 --nas-get-serving-system</p>
<p>and most other commands, eg<br>
</p>
<p> /usr/bin/qmicli -p -d /dev/cdc-wdm0 --nas-get-signal-strength</p>
<p><br>
</p>
<p>The output from nas-get-serving-system is all shown with an extra
level of tab indents (ie indent level starts at 1), whereas most
other commands are left aligned, ie indent level of 0 starts at 0.</p>
<p>Another (minor) challenge is that errors/status messages are not
completely homogeneous, eg a general error in params causes output
to stderr and I think a non zero return code(?), however, status
messages relating to a command where the params are ok shows all
results on stdout, with the qmi data "mixed in" with the status
messages from the utility. eg the first line of most messages, or
the trailer if you add "--client-no-release-cid"</p>
<p>Another curiousity is the output if you call "--client-cid=xx"
with an invalid cid, this spits out an error immediately, but the
app doesn't exit for another 10 seconds with a further timeout
message. (from memory one to stdout, one to stderr)</p>
<p>So not withstanding all of this, I can do the following in my
elixir app (which actually works quite well for my needs):</p>
<p><br>
</p>
<blockquote>
<p>iex> Exqmi.qmicli(nil, "nas-get-serving-system", device:
"/dev/cdc-wdm0")</p>
<p>{:ok, "Successfully got serving system",<br>
%{<br>
"3GPP cell ID" => "283456",<br>
"3GPP daylight saving time adjustment" => {"1", "hours"},<br>
"3GPP location area code" => "65534",<br>
"CS" => "attached",<br>
"Current PLMN" => %{<br>
"Description" => "voda UK",<br>
"MCC" => "234",<br>
"MNC" => "15"<br>
},<br>
"Data service capabilities" => %{"0" => "lte", "_value"
=> "1"},<br>
"Detailed status" => %{<br>
"Capability" => "cs-ps",<br>
"Forbidden" => "no",<br>
"HDR Hybrid" => "no",<br>
"HDR Status" => "none",<br>
"Status" => "available"<br>
},<br>
"Full operator code info" => %{<br>
"MCC" => "234",<br>
"MNC" => "15",<br>
"MNC with PCS digit" => "no"<br>
},<br>
"LTE tracking area code" => "12345",<br>
"PS" => "attached",<br>
"Radio interfaces" => %{"0" => "lte", "_value" =>
"1"},<br>
"Registration state" => "registered",<br>
"Roaming indicators" => %{"0" => {"off", "(lte)"},
"_value" => "1"},<br>
"Roaming status" => "off",<br>
"Selected network" => "3gpp"<br>
}}<br>
</p>
</blockquote>
<p><br>
</p>
<p>Basically the output is really close to being parseable without
too much trouble. However, it feels like a change in how the
messages are generated in the first instance, could lead naturally
to a final output step that is capable of spitting out the result
in a variety of forms. I'm not really familiar with what tools we
already have in glib, but perhaps it already has a structure
(map?) that we can put the messages into at construction time? ie
I'm looking for the smallest change possible, ideally something
that can be automated given the amount of code that would be
touched. <br>
</p>
<p>Any thoughts?</p>
<p><br>
</p>
<p>Ed W<br>
</p>
</div>
_______________________________________________<br>
libqmi-devel mailing list<br>
<a href="mailto:libqmi-devel@lists.freedesktop.org" target="_blank">libqmi-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/libqmi-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/libqmi-devel</a><br>
</blockquote></div>