<link>http://people.skolelinux.org/pere/blog/</link>
+ <item>
+ <title>Full battery stats collector is now available in Debian</title>
+ <link>http://people.skolelinux.org/pere/blog/Full_battery_stats_collector_is_now_available_in_Debian.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Full_battery_stats_collector_is_now_available_in_Debian.html</guid>
+ <pubDate>Wed, 23 Mar 2016 22:10:00 +0100</pubDate>
+ <description><p>Since this morning, the battery-stats package in Debian include an
+extended collector that will collect the complete battery history for
+later processing and graphing. The original collector store the
+battery level as percentage of last full level, while the new
+collector also record battery vendor, model, serial number, design
+full level, last full level and current battery level. This make it
+possible to predict the lifetime of the battery as well as visualise
+the energy flow when the battery is charging or discharging.</p>
+
+<p>The new tools are available in <tt>/usr/share/battery-stats/</tt>
+in the version 0.5.1 package in unstable. Get the new battery level graph
+and lifetime prediction by running:
+
+<p><pre>
+/usr/share/battery-stats/battery-stats-graph /var/log/battery-stats.csv
+</pre></p>
+
+<p>Or select the 'Battery Level Graph' from your application menu.</p>
+
+<p>The flow in/out of the battery can be seen by running (no menu
+entry yet):</p>
+
+<p><pre>
+/usr/share/battery-stats/battery-stats-graph-flow
+</pre></p>
+
+<p>I'm not quite happy with the way the data is visualised, at least
+when there are few data points. The graphs look a bit better with a
+few years of data.</p>
+
+<p>A while back one important feature I use in the battery stats
+collector broke in Debian. The scripts in
+<tt>/usr/lib/pm-utils/power.d/</tt> were no longer executed. I
+suspect it happened when Jessie started using systemd, but I do not
+know. The issue is reported as
+<a href="https://bugs.debian.org/818649">bug #818649</a> against
+pm-utils. I managed to work around it by adding an udev rule to call
+the collector script every time the power connector is connected and
+disconnected. With this fix in place it was finally time to make a
+new release of the package, and get it into Debian.</p>
+
+<p>If you are interested in how your laptop battery is doing, please
+check out the
+<a href="https://tracker.debian.org/pkg/battery-stats">battery-stats</a>
+in Debian unstable, or rebuild it on Jessie to get it working on
+Debian stable. :) The upstream source is available from
+<a href="https://github.com/petterreinholdtsen/battery-stats">github</a>.
+As always, patches are very welcome.</p>
+</description>
+ </item>
+
<item>
<title>UsingQR - "Electronic" paper invoices using JSON and QR codes</title>
<link>http://people.skolelinux.org/pere/blog/UsingQR____Electronic__paper_invoices_using_JSON_and_QR_codes.html</link>
This is the typical content of a QR code following the UsingQR
specification (based on a real world example, some numbers replaced to
get a more bogus entry). I've reformatted the JSON to make it easier
-to read. Normally this is all on one long line:
+to read. Normally this is all on one long line:</p>
<p><img src="http://people.skolelinux.org/pere/blog/images/2016-03-19-qr-invoice.png" align="right"><pre>
{
the people behind the format claimed it was safe to do so. At least
with patents, there is always
<a href="http://www.paperspecs.com/paper-news/beware-the-qr-code-patent-trap/">a
-chance of getting sued...</a>
+chance of getting sued...</a></p>
<p>I also asked if they planned to maintain the format in an
independent standard organization to give others more confidence that
they conclude that using an open standard organisation like
<a href="http://www.ietf.org/">IETF</a> is the correct place to
maintain such specification.</p>
+
+<p><strong>Update 2016-03-20</strong>: Via Twitter I became aware of
+<a href="https://news.ycombinator.com/item?id=11319492">some comments
+about this blog post</a> that had several useful links and references to
+similar systems. In the Czech republic, the Czech Banking Association
+standard #26, with short name SPAYD, uses QR codes with payment
+information. More information is available from the Wikipedia page on
+<a href="https://en.wikipedia.org/wiki/Short_Payment_Descriptor">Short
+Payment Descriptor</a>. And in Germany, there is a system named
+<a href="http://www.bezahlcode.de/">BezahlCode</a>,
+(<a href="http://www.bezahlcode.de/wp-content/uploads/BezahlCode_TechDok.pdf">specification
+v1.8 2013-12-05 available as PDF</a>), which uses QR codes with
+URL-like formatting using "bank:" as the URI schema/protocol to
+provide the payment information. There is also the
+<a href="http://www.ferd-net.de/front_content.php?idcat=231">ZUGFeRD</a>
+file format that perhaps could be transfered using QR codes, but I am
+not sure if it is done already. Last, in Bolivia there are reports
+that tax information since november 2014 need to be printed in QR
+format on invoices. I have not been able to track down a
+specification for this format, because of my limited language skill
+sets.</p>
</description>
</item>
projects / homepage.git / blobdiff