blog/archive/2016/03/03.rss

   1 <?xml version="1.0" encoding="ISO-8859-1"?>
   2 <rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/'>
   3         <channel>
   4                 <title>Petter Reinholdtsen - Entries from March 2016</title>
   5                 <description>Entries from March 2016</description>
   6                 <link>http://www.hungry.com/~pere/blog/</link>
   7
   8
   9         <item>
  10                 <title>Full battery stats collector is now available in Debian</title>
  11                 <link>http://www.hungry.com/~pere/blog/Full_battery_stats_collector_is_now_available_in_Debian.html</link>
  12                 <guid isPermaLink="true">http://www.hungry.com/~pere/blog/Full_battery_stats_collector_is_now_available_in_Debian.html</guid>
  13                 <pubDate>Wed, 23 Mar 2016 22:10:00 +0100</pubDate>
  14                 <description>&lt;p&gt;Since this morning, the battery-stats package in Debian include an
  15 extended collector that will collect the complete battery history for
  16 later processing and graphing.  The original collector store the
  17 battery level as percentage of last full level, while the new
  18 collector also record battery vendor, model, serial number, design
  19 full level, last full level and current battery level.  This make it
  20 possible to predict the lifetime of the battery as well as visualise
  21 the energy flow when the battery is charging or discharging.&lt;/p&gt;
  22
  23 &lt;p&gt;The new tools are available in &lt;tt&gt;/usr/share/battery-stats/&lt;/tt&gt;
  24 in the version 0.5.1 package in unstable.  Get the new battery level graph
  25 and lifetime prediction by running:
  26
  27 &lt;p&gt;&lt;pre&gt;
  28 /usr/share/battery-stats/battery-stats-graph /var/log/battery-stats.csv
  29 &lt;/pre&gt;&lt;/p&gt;
  30
  31 &lt;p&gt;Or select the &#39;Battery Level Graph&#39; from your application menu.&lt;/p&gt;
  32
  33 &lt;p&gt;The flow in/out of the battery can be seen by running (no menu
  34 entry yet):&lt;/p&gt;
  35
  36 &lt;p&gt;&lt;pre&gt;
  37 /usr/share/battery-stats/battery-stats-graph-flow
  38 &lt;/pre&gt;&lt;/p&gt;
  39
  40 &lt;p&gt;I&#39;m not quite happy with the way the data is visualised, at least
  41 when there are few data points.  The graphs look a bit better with a
  42 few years of data.&lt;/p&gt;
  43
  44 &lt;p&gt;A while back one important feature I use in the battery stats
  45 collector broke in Debian.  The scripts in
  46 &lt;tt&gt;/usr/lib/pm-utils/power.d/&lt;/tt&gt; were no longer executed.  I
  47 suspect it happened when Jessie started using systemd, but I do not
  48 know.  The issue is reported as
  49 &lt;a href=&quot;https://bugs.debian.org/818649&quot;&gt;bug #818649&lt;/a&gt; against
  50 pm-utils.  I managed to work around it by adding an udev rule to call
  51 the collector script every time the power connector is connected and
  52 disconnected.  With this fix in place it was finally time to make a
  53 new release of the package, and get it into Debian.&lt;/p&gt;
  54
  55 &lt;p&gt;If you are interested in how your laptop battery is doing, please
  56 check out the
  57 &lt;a href=&quot;https://tracker.debian.org/pkg/battery-stats&quot;&gt;battery-stats&lt;/a&gt;
  58 in Debian unstable, or rebuild it on Jessie to get it working on
  59 Debian stable. :) The upstream source is available from
  60 &lt;a href=&quot;https://github.com/petterreinholdtsen/battery-stats&quot;&gt;github&lt;/a&gt;.
  61 As always, patches are very welcome.&lt;/p&gt;
  62 </description>
  63         </item>
  64
  65         <item>
  66                 <title>UsingQR - &quot;Electronic&quot; paper invoices using JSON and QR codes</title>
  67                 <link>http://www.hungry.com/~pere/blog/UsingQR____Electronic__paper_invoices_using_JSON_and_QR_codes.html</link>
  68                 <guid isPermaLink="true">http://www.hungry.com/~pere/blog/UsingQR____Electronic__paper_invoices_using_JSON_and_QR_codes.html</guid>
  69                 <pubDate>Sat, 19 Mar 2016 09:40:00 +0100</pubDate>
  70                 <description>&lt;p&gt;Back in 2013 I proposed
  71 &lt;a href=&quot;https://people.skolelinux.org/pere/blog/_Electronic__paper_invoices___using_vCard_in_a_QR_code.html&quot;&gt;a
  72 way to make paper and PDF invoices easier to process electronically by
  73 adding a QR code with the key information about the invoice&lt;/a&gt;.  I
  74 suggested using vCard field definition, to get some standard format
  75 for name and address, but any format would work.  I did not do
  76 anything about the proposal, but hoped someone one day would make
  77 something like it.  It would make it possible to efficiently send
  78 machine readable invoices directly between seller and buyer.&lt;/p&gt;
  79
  80 &lt;p&gt;This was the background when I came across a proposal and
  81 specification from the web based accounting and invoicing supplier
  82 &lt;a href=&quot;http://www.visma.com/&quot;&gt;Visma&lt;/a&gt; in Sweden called
  83 &lt;a href=&quot;http://usingqr.com/&quot;&gt;UsingQR&lt;/a&gt;.  Their PDF invoices contain
  84 a QR code with the key information of the invoice in JSON format.
  85 This is the typical content of a QR code following the UsingQR
  86 specification (based on a real world example, some numbers replaced to
  87 get a more bogus entry).  I&#39;ve reformatted the JSON to make it easier
  88 to read.  Normally this is all on one long line:&lt;/p&gt;
  89
  90 &lt;p&gt;&lt;img src=&quot;https://people.skolelinux.org/pere/blog/images/2016-03-19-qr-invoice.png&quot; align=&quot;right&quot;&gt;&lt;pre&gt;
  91 {
  92  &quot;vh&quot;:500.00,
  93  &quot;vm&quot;:0,
  94  &quot;vl&quot;:0,
  95  &quot;uqr&quot;:1,
  96  &quot;tp&quot;:1,
  97  &quot;nme&quot;:&quot;Din Leverandør&quot;,
  98  &quot;cc&quot;:&quot;NO&quot;,
  99  &quot;cid&quot;:&quot;997912345 MVA&quot;,
 100  &quot;iref&quot;:&quot;12300001&quot;,
 101  &quot;idt&quot;:&quot;20151022&quot;,
 102  &quot;ddt&quot;:&quot;20151105&quot;,
 103  &quot;due&quot;:2500.0000,
 104  &quot;cur&quot;:&quot;NOK&quot;,
 105  &quot;pt&quot;:&quot;BBAN&quot;,
 106  &quot;acc&quot;:&quot;17202612345&quot;,
 107  &quot;bc&quot;:&quot;BIENNOK1&quot;,
 108  &quot;adr&quot;:&quot;0313 OSLO&quot;
 109 }
 110 &lt;/pre&gt;&lt;/p&gt;
 111
 112 &lt;/p&gt;The interpretation of the fields can be found in the
 113 &lt;a href=&quot;http://usingqr.com/wp-content/uploads/2014/06/UsingQR_specification1.pdf&quot;&gt;format
 114 specification&lt;/a&gt; (revision 2 from june 2014).  The format seem to
 115 have most of the information needed to handle accounting and payment
 116 of invoices, at least the fields I have needed so far here in
 117 Norway.&lt;/p&gt;
 118
 119 &lt;p&gt;Unfortunately, the site and document do not mention anything about
 120 the patent, trademark and copyright status of the format and the
 121 specification.  Because of this, I asked the people behind it back in
 122 November to clarify.  Ann-Christine Savlid (ann-christine.savlid (at)
 123 visma.com) replied that Visma had not applied for patent or trademark
 124 protection for this format, and that there were no copyright based
 125 usage limitations for the format.  I urged her to make sure this was
 126 explicitly written on the web pages and in the specification, but
 127 unfortunately this has not happened yet.  So I guess if there is
 128 submarine patents, hidden trademarks or a will to sue for copyright
 129 infringements, those starting to use the UsingQR format might be at
 130 risk, but if this happen there is some legal defense in the fact that
 131 the people behind the format claimed it was safe to do so.  At least
 132 with patents, there is always
 133 &lt;a href=&quot;http://www.paperspecs.com/paper-news/beware-the-qr-code-patent-trap/&quot;&gt;a
 134 chance of getting sued...&lt;/a&gt;&lt;/p&gt;
 135
 136 &lt;p&gt;I also asked if they planned to maintain the format in an
 137 independent standard organization to give others more confidence that
 138 they would participate in the standardization process on equal terms
 139 with Visma, but they had no immediate plans for this.  Their plan was
 140 to work with banks to try to get more users of the format, and
 141 evaluate the way forward if the format proved to be popular.  I hope
 142 they conclude that using an open standard organisation like
 143 &lt;a href=&quot;http://www.ietf.org/&quot;&gt;IETF&lt;/a&gt; is the correct place to
 144 maintain such specification.&lt;/p&gt;
 145
 146 &lt;p&gt;&lt;strong&gt;Update 2016-03-20&lt;/strong&gt;: Via Twitter I became aware of
 147 &lt;a href=&quot;https://news.ycombinator.com/item?id=11319492&quot;&gt;some comments
 148 about this blog post&lt;/a&gt; that had several useful links and references to
 149 similar systems.  In the Czech republic, the Czech Banking Association
 150 standard #26, with short name SPAYD, uses QR codes with payment
 151 information.  More information is available from the Wikipedia page on
 152 &lt;a href=&quot;https://en.wikipedia.org/wiki/Short_Payment_Descriptor&quot;&gt;Short
 153 Payment Descriptor&lt;/a&gt;.  And in Germany, there is a system named
 154 &lt;a href=&quot;http://www.bezahlcode.de/&quot;&gt;BezahlCode&lt;/a&gt;,
 155 (&lt;a href=&quot;http://www.bezahlcode.de/wp-content/uploads/BezahlCode_TechDok.pdf&quot;&gt;specification
 156 v1.8 2013-12-05 available as PDF&lt;/a&gt;), which uses QR codes with
 157 URL-like formatting using &quot;bank:&quot; as the URI schema/protocol to
 158 provide the payment information.  There is also the
 159 &lt;a href=&quot;http://www.ferd-net.de/front_content.php?idcat=231&quot;&gt;ZUGFeRD&lt;/a&gt;
 160 file format that perhaps could be transfered using QR codes, but I am
 161 not sure if it is done already.  Last, in Bolivia there are reports
 162 that tax information since november 2014 need to be printed in QR
 163 format on invoices.  I have not been able to track down a
 164 specification for this format, because of my limited language skill
 165 sets.&lt;/p&gt;
 166 </description>
 167         </item>
 168
 169         <item>
 170                 <title>Making battery measurements a little easier in Debian</title>
 171                 <link>http://www.hungry.com/~pere/blog/Making_battery_measurements_a_little_easier_in_Debian.html</link>
 172                 <guid isPermaLink="true">http://www.hungry.com/~pere/blog/Making_battery_measurements_a_little_easier_in_Debian.html</guid>
 173                 <pubDate>Tue, 15 Mar 2016 15:00:00 +0100</pubDate>
 174                 <description>&lt;p&gt;Back in September, I blogged about
 175 &lt;a href=&quot;https://people.skolelinux.org/pere/blog/The_life_and_death_of_a_laptop_battery.html&quot;&gt;the
 176 system I wrote to collect statistics about my laptop battery&lt;/a&gt;, and
 177 how it showed the decay and death of this battery (now replaced).  I
 178 created a simple deb package to handle the collection and graphing,
 179 but did not want to upload it to Debian as there were already
 180 &lt;a href=&quot;https://tracker.debian.org/pkg/battery-stats&quot;&gt;a battery-stats
 181 package in Debian&lt;/a&gt; that should do the same thing, and I did not see
 182 a point of uploading a competing package when battery-stats could be
 183 fixed instead.  I reported a few bugs about its non-function, and
 184 hoped someone would step in and fix it.  But no-one did.&lt;/p&gt;
 185
 186 &lt;p&gt;I got tired of waiting a few days ago, and took matters in my own
 187 hands.  The end result is that I am now the new upstream developer of
 188 battery stats (&lt;a href=&quot;https://github.com/petterreinholdtsen/battery-stats&quot;&gt;available from github&lt;/a&gt;) and part of the team maintaining
 189 battery-stats in Debian, and the package in Debian unstable is finally
 190 able to collect battery status using the &lt;tt&gt;/sys/class/power_supply/&lt;/tt&gt;
 191 information provided by the Linux kernel.  If you install the
 192 battery-stats package from unstable now, you will be able to get a
 193 graph of the current battery fill level, to get some idea about the
 194 status of the battery.  The source package build and work just fine in
 195 Debian testing and stable (and probably oldstable too, but I have not
 196 tested).  The default graph you get for that system look like this:&lt;/p&gt;
 197
 198 &lt;p align=&quot;center&quot;&gt;&lt;img src=&quot;https://people.skolelinux.org/pere/blog/images/2016-03-15-battery-stats-graph-example.png&quot; width=&quot;70%&quot; align=&quot;center&quot;&gt;&lt;/p&gt;
 199
 200 &lt;p&gt;My plans for the future is to merge my old scripts into the
 201 battery-stats package, as my old scripts collected a lot more details
 202 about the battery.  The scripts are merged into the upstream
 203 battery-stats git repository already, but I am not convinced they work
 204 yet, as I changed a lot of paths along the way.  Will have to test a
 205 bit more before I make a new release.&lt;/p&gt;
 206
 207 &lt;p&gt;I will also consider changing the file format slightly, as I
 208 suspect the way I combine several values into one field might make it
 209 impossible to know the type of the value when using it for processing
 210 and graphing.&lt;/p&gt;
 211
 212 &lt;p&gt;If you would like I would like to keep an close eye on your laptop
 213 battery, check out the battery-stats package in
 214 &lt;a href=&quot;https://tracker.debian.org/pkg/battery-stats&quot;&gt;Debian&lt;/a&gt; and
 215 on
 216 &lt;a href=&quot;https://github.com/petterreinholdtsen/battery-stats&quot;&gt;github&lt;/a&gt;.
 217 I would love some help to improve the system further.&lt;/p&gt;
 218 </description>
 219         </item>
 220
 221         </channel>
 222 </rss>