PlatformIO and JSON woes…

Yesterday was, for the most part, quite a good day for me.  The weather was bad, so it gave me an excuse to stay inside and play, at least for a couple of hours in the morning.  I’m still slowly working away at implementing a simple, forced-air heat distribution system in the house (our only permanent source of heating is a wood-stove in the lounge/kitchen area, so I’ve added some ducting to take hot air from behind the stove and gently and quietly push it out through a vent in the bedroom).  The latest idea is that I’ll have an ESP8266 with a small screen and a DS18B20 (or similar) in the bedroom which will display the temperature and allow manual on/off override of the fan control via a couple of buttons.

Anyway, I’ve had one of those 2.2″ TFT displays sitting around for ages waiting for me to get going, so early yesterday morning I wire-wrapped it to one of the spare “Yellow Development” boards that I have hanging around and then looked around for something to burn into the ESP as a quick test.  I remembered Squix’s weather station and vaguely recalled seeing a TFT version too, so off I went and grabbed it from his GitHub repository.  After a couple of false starts (what is it with Windows and non-case-sensitivity?!?!) it fired up beautifully and (almost) everything sprung into life (be warned, this application uses a lot of flash memory space to store image files, so you might not be able to fit all of the moon phase .bmp files onto your particular ESP).  The display was impressive enough to divert me into going to the Weather Underground site and signing up for a developer’s API ID, just so that I could play with the application a bit more.

So after duly playing around for a while, I noticed from the comments section on Squix’ page that a couple of people had already added some new features, all of which looked interesting, so off I went to GitHub again and cloned Keith Fowler’s latest and greatest version.  This is where the fun started and my free time went down the plughole (and none of the palaver related below is in any way Keith’s fault, I hasten to add).

I’m using PlatformIO as my build environment (it generally works flawlessly and automatically does neat stuff, like shoehorning everything into memory, or finding your FDTI adapter, without having to be told).  When you need libraries you can just do a word search on, say “DS18B20” and then choose the most suitable looking candidate from the list returned.  Keith’s updated version of the application I was trying to install was looking for “simpleDSTadjust.h”, so I duly typed “simpleDSTadjust” into the library search, got one hit and installed that library.  The next run through produced exactly the same error message as previously, “simpleDSTadjust.h not found”.  Having been bitten once earlier in the morning with a case-mismatch between the #include line and the actual file name (just for refererence, “ArialRoundedMTBold_14.h” as opposed to (ArialRoundedMtBold_14.h”), I went back and scanned the #include and file name with a magnifying glass.  Nope, they’re both the same.  Hmmm….

I quickly looked at the library properties files, library.json and library.properties and discovered a minor typo with the repository URL in the .json file.  A quick check with the spec’ showed that this was a required field, so I corrected it and tried again.  Nope, same error.

Ran the platformio “run” (compile) command again, this time with the -v option.  I got a lot more information on the libraries which it had found, but nothing at all on the missing “simpleDSTadjust.h”.   Next, I went to GitHub and found the repository for simpleDSTadjust.  The most recent changes were to the library.json and library.properties files, but the GitHub diff showed only a single character change in both cases; the version number had changed from 1.0.0 to 1.1.0, unlikely to cause such a problem, I thought.

At this point I was beginning to suspect that maybe there was some sort of bug with PlatformIO that perhaps the length and composition of this particular library’s name was triggering.  On a lets-just-try-it-anyway hunch, I updated my platformio.ini file with a line to change the behaviour of the library dependency finder — lib_ldf_mode = deep+.  That didn’t help at all (so much for hunches!).

Next I removed the simpleDSTadjust library from the PlatformIO local cache (.piolibdeps) using the “lib uninstall” command and then downloaded the GitHub version to the local “lib” directory (normally used for your own, locally created libraries which aren’t available in the global, PlatformIO library system), giving it a different, shorter name.  I  updated both the library .cpp and .h files, as well as the #include lines in the TFT application source, to match the new name.  And …exactly the same.  PlatformIO ignored the newly created library and repeated the boring old “not found” error.  This was starting to get a little tiresome.

Working on the assumption now that the problem lay with the library itself and not, after all, with PlatformIO, I went into the library directory and moved all of the files which seemed to be non-essential into a newly created sub-directory.  The next compile actually worked.  It did fall over on some other errors, but we’d got past simpleDSTadjust.h for the time being.  Okay, what was the actual culprit?  Moving the non-essentials back, one by one, then re-running the compile proved the the library.json file was definitely at fault, but staring at it didn’t yield any obvious clues, so back to the on-line manual pages and the examples to see what a good file should look like (I’ve never knowingly created a .json file, so I definitely classify as a bona-fide novice).  It all looked fairly simple …quoted text, colon delimiters between defined name and data and comma delimiters at the end of data lines, except for the last one.  Okay, squint, squint, squint.  Nope nothing obvious.  Back to the examples — curly braces for multi-field data, comma after the closing curly bracket.  More squinting …and finally an answer; that comma delimiter after the closing curly is missing.  I quickly edited the file to include the errant comma and …Yay!  A working compile.  Finally!

Phew!  A couple of hours of precious free time wasted (but only because I was stupid enough to pursue the issue at hand instead of getting on with the actual project) mainly because there was no error message displayed (or perhaps generated) when parsing of the library.json file failed because of a syntax error.  Anyway, the author of the simpleDSTadjust library (Neptune2)updated the library.json file within a few hours of the issue being raised, so a very big thank you to him/her for that.

Now I suppose that I should buckle down and get back to work on that simple temperature display, now that I’ve proved that the hardware works.  🙂

 

Advertisements

4 thoughts on “PlatformIO and JSON woes…

  1. Hi, interesting idea about moving the warm air from behind the stove. Please ensure that the fan does not interfere with the free air flow to the stove inlet ports as this could adversely affect combustion. Please ensure you install a CO detector in the bedroom as the fan has the potential to move any CO present in the vicinity of the stove into the bedroom.

    Like

  2. Thanks for the tips, Bob. Woodstock Fireview (catalytic) with fresh-air pipe directly to the inlet. The fan is in an enclosed, ducted box in a separate utility space. The inlet (stove side) is a metre and a half above ground level and offset to the side of the stove. The outlet in the bedroom is 15cm above floor level. The fan is a 110CFM (max) unit being run at low speed (and intermittently) to reduce noise. The carbon monoxide alarm is a great idea; any suggestions for a -reliable- unit that won’t break the bank?

    Like

    • Hi, CO is approximately the same density as air so it tends to rise with the heater air. From your description it sounds as if the stove receives its combustion air from outside of the building, however as you mention a cat converter I assume it is flueless. In the UK I recommend either Honeywell or Kidde CO alarms and these cost in the range £20.00 to £30.00. Ideally you should have one in the room where the stove is, and in your application, one in the bedroom. don’t bother buying one with a replaceable battery as the CO sensors have a finite life. Please do not run your system without a CO detector and check it(them) weekly. I would not run the system whilst in bed and you need to ensure there is an adequate source of ventilation in the bedroom.

      Like

  3. […] Previously I mentioned using a modified version of Squix’s Weather Station Colour as a test application for a 2.2″ TFT 240×320 display with an SPI interface.  If you have a Yellow Board hanging around unused, I really would recommend this as a useful application.  My photo doesn’t really do it justice (it is a rainy day here and the light is bad).  The actual display is quite crisp and sharp (even with the protective plastic shipping sheet still attached to the screen). […]

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s