Recurring problem: my library update from github does not show up on PlatformIO

I see other people having the same problem, but no solution yet, other than to post here…

I registered my library PlatformIO Registry several days ago, and after integrating a pull request from @ivankravets regarding the manifest it showed up here. Great!

I did several releases on the lib since then, >= 3 days ago.
See here: Releases · joba-1/Joba_Tsl2561 · GitHub
These updates on github are not reflected in the library manager:

pio lib show 2869
#ID: 2869
Arduino Library for ams (taos) luminance chip Tsl2561 with autogain

Version: 2.0.1, released Thu Feb 15 18:23:47 2018

d668ce8da7, released Sun Feb 11 00:34:05 2018
2.0.1, released Thu Feb 15 18:23:47 2018

Maybe it is related to the weird first version tag? I don’t mind it being removed.
Would be great if there is a notification with some kind of error log to the lib owner in such cases.

Not in a hurry though, just want a great tool get even better :slight_smile:

Just got a little more weird:

Versions listed on PlatformIO still end at 2.0.1, but Manifest page already has it correct:

“name”: “Joba_Tsl2561”,
“version”: “2.0.4”,


Sorry, we found a bug in our Library Crawler which “froze” updates queue :frowning:
Now all should work.

Thanks - it worked :slight_smile:

Please can you update Mysensors (ID 548). Version is shown as 2.2.0 but in fact it’s 2.2.0-rc2 and not final release.
And if you can add developement branch.
Thank you

That was the issue with the library maintainers. They forgot to update version. The source files of the library were actual. Nevertheless, I’ve just updated that library. Now all manifests are up to date.

Same problem with this library: it does not update.
But file is set, and the owner published a release.

What can i do to get this library updated on platformio registry?

author=Lewis He
maintainer=Lewis He <>
sentence=Arduino library for X-Power AXP202 chip
paragraph=Arduino library for X-Power AXP202 chip. Tested with ESP32

Responded to here:

Hi, it seems I have the same problem.
I registered my library PlatformIO Registry (version 1.0.5).
The following updates ( newest version 1.1.1) were not adopted although the new version ist maintained in the manifest:

  "name": "LCD/LED library",
  "version": "1.1.1",
  "keywords": "hd44780, ks0066, max7221, lcd, led, display",
  "description": "Display library for HD44780 kompatible displays",
    "type": "git",
    "url": ""

Can you please take a look waht the problem is.
Thanks in advance.

Two things that jump out:

  • the library.json in the 1.1.1 tag points to a 1.1.0 release - maybe it’s confused with the mismatch? Which could also explain why 1.1.0 isn’t showing in the release history on the PIO registry.
  • it’s possible the tag should be v1.1.1 - although a re-read of the documtation suggests both forms are acceptable, so maybe it is just the first point, or the PIO Library Crawler needs a kick to liven it up.

Try changing the version number to 1.1.2, and ensuring that version of library.json is tagged 1.1.2, and then wait 24-48 hours to see if the change goes through. The PlatformIO Library Registry is showing the current library.json manifest, so it is at least seeing that properly.

1 Like

Hi pfeerick,
thanks for your reply. I have update the release to 1.1.2 and library.json is also tagged with 1.1.2.
Now I wait for 48 hours…

1 Like

Now it works well, thanks a lot.

1 Like

Fantastic, looks like the crawler just got confused with the tag/version mismatch. :slight_smile: It’s easily done… still working out this git stuff myself at times… just found out the other day that I don’t need to merge branches (I use a master/develop two branch system) when using tags, meaning I don’t get the extra merge commitsnow … I can just tag the final commit for a version, and then merge that tag across…

1 Like

Thats interesting, can you explain it a little more detailed (I am new at github :wink: ).

That would require I remember what I did :wink:

Basically, for elapsedMillis, I have two branches … develop and master. I only release new versions on the master branch, and the develop branch is where anything cues up in the meantime. It’s not a model particularly needed for this library, but it lets me practice with git and github on methodologies that would suit larger or more multi-developer projects.

What I didn’t like about this was the fact it seemed you needed to merge back and forward… i.e. have a look at the commit logs for platform-atmelavr as one example. Stuff happens in develop, then gets merged to master, and then master gets merged back into develop. I thought there had to be a better way. I then realised when in the develop branch, and you’re tagging a commit as the final commit for a release (i.e. v1.0.5), you can push that tag to another branch… i.e. master… and no merge commits, nada. And since master is really a snapshot in time of develop, there’s no need for the merge back.

That’s the theory for now, unless someone says that doing it this way will cause me headaches or grief in the future. :wink: :laughing:

btw, the git reference material on tagging is surprisingly readable…

Thanks for the detailed description, I will try it soon.
And thanks for the link, indeed I had problems with tags/releases and your link helped to understand that better.

1 Like