Thnx much Hildogjr
I still have Octopart to deal with.
They wont’t activate my account because the script calls out to octopart.com
Caramba.
If you have some python expertise help us to fix the issues before the new release
1 Like
Best of luck with Octopart - they have now removed both of my free API keys which I was using for development work and now want to charge me $25 pm for 1000 queries to access their API (heading up to $200 pm for 25k hits) which seems pretty steep to me. They don’t respond to emails or notify you about APIKey deactivation. The Octopart website has a section on ‘How we make money’ - but there is no mention there about charging for API access. Unfortunately this puts my Kicad2Partkeepr project on the back burner as I can’t do much more work on it without querying the API. Sadly the Altium take over will make any solution depending on individual Octopart registration untenable for most hobbyist level enthusiasts. I will have a look at KiCost to see if there is anything I can help to fix.
I might also look at Ciiva BOM Manager - not sure if anyone has any experience with this and Kicad? This is free for two users and the next tier is $20 which is slightly cheaper than the baseline Octopart API access on its own. But again, owned by Altium …
1 Like
Dear John
We simply refused to go by!
No machinations about electronics part - any part for that matter- that we can deal with manufacturers directly. Even if you are sitting in Timbaktu, you can get ( excepting MAGA restrictions…these days) any part manufactured anywhere in the Globe at any openly competitive price. Period.
I already pointed out in this forum, kicost is very elegant and must not be subject to 1 party holding hostage without any merit to their claims of service.
THAT service is free from the manufacturer. A distributor is a well-honed system who stocks items & we pay a premium for that-- very nominal at that.
Then again, all vendors have an online presence.
This will make the so-vaunted “Supply chain” shenanigans obsolete once our tools become more AI oriented.
So no siree, not going along with anyone trying to push a business model that puts you in a corner.
Hope this clarifies our position.
Senor Hildogjr may wish to speed it up by removing all such predatory inputs. I hope.
BTW: KiCAD is an open software tool, But we contribute to it - as we do for all such efforts.
That is una otra cosa.
robin
Hildogjr:
That is exactly what I am trying to do.
I have to admit my son is an expert in this sort of programming…but helping out that much?
…let us hope…
I will post if hope comes to fruition…asap
The issue is trying to support all the distributors out there means a lot of work keeping up with their changes. The advantage initially of using Octopart was they took care of the changing vendors APIs and they provided their service free to the end user. This was great because all the very limited developers for KiCost (all 2 of them?) only had to keep up with Octopart if they changed their API. (Octopart is like a search engine for electronic parts across different vendors, and showed the comparative pricing between different vendors. No one ever bought any parts directly from Octopart.)
Unfortunately for us the end users, Octopart was acquired by Altium. Altium decided to make the end users pay for the service (at least for API access to their service), I suspect they will provide the Octopart service for free (or part of the service contract) for users of the Altium software. I really wouldn’t expect them to provide this service for free to users of competing software.
1 Like
As an open source project is there enough interest that enough developers would band together and just write code to scrape individual distributors and then aggregate?
1 Like
I think BOM scraping should be open as well- in the sense that info from user’s part “properties” need only be processed and presented in a manner similar to kicost. No need to go overboard about linking with any particular external plugin or site that forces user to compromise his “open” approach…Here “user” knows best what he/she is doing…If they need extra help, it is much better to post here & thousand willing partners will do so.
Now, it is perfectly ok to develop a plugin that works with KiCAD & is based upon honor system of contributions.
This way the integrity of the entire Open approach is maintained and let blossom.
Yes, @SembazuruCDE just 2 active developers, the author @debisme and I.
My expertise is not in web, reason way I was advancing in logic / validation and the different currency implementation.
The scrape module create the big issue when the distributors web page start considere us as an robot (that is true).
Now KiCost is having issues with the GUI in Windows that, even if I finish the new API migration, will delay the release.
1 Like
The new distributors module
accept api_*.py, scrape_*.py and dist_local_*.py. I hope that in the future KiCost will be not dependent of a specific API.
I would state that "good luck with Altium " then!
I do not see how they can beat any manufacturer’s info!
Now can they “buy” out kicost?
nah.
Many worthy .py coders can hack it up…besides, making BOM may become an integral part of KICAD…I am hoping.
There are 1000s competing sch/layout product developers…quite expensive & each has a way to build BOM, including obd++…most elegant & simple is KiCAD…
then what happens?
On top, I would suspect any info from any source other than the original IC/chip/ part whatever…vendor for my use! Neither I would encourage dissemination of such info in our organization.
This has to do with the integrity of the info- nothing against any vendor trying to make a buck on free info.
Finally, if I were a vendor of a part: I would object to a third party making my customer pay for inforthat she would get , uninhibited, free!
It was a surprise to me that Ocopart existed inside kicost…been in the industry 40 yrs …never felt the need for such a service.
It is like buying parts from a third party : unauthorized – would you put that part in your system?
We cannot
KiCost was using Octopart. The only relationship is KiCad is one of many clients of Octopart’s information service.
I’ve directly used Octopart before. It took a lot of the hard work of deciding which vendor to buy parts for price conscious small-run projects. It actually allowed me to decide for a project which parts to buy from Digikey, which parts from Mouser, and which parts from Newark. Not like for my quantities I could buy direct from Vishay or TI…
Sembazuru
Although you make good points, I would say that paying shipping will eat out little differences in pricing here & there.
#2, online buys are very competitive, if not lower than, distis. You can buy 1, sample many( which no one else will ever give you), buy 10 or 100.or 10k!
So not sure how any consolidator will help really.
Much like “travel agents”…gone. You can buy lower priced tickets online…on any airline from anywhere on this Planet.
Pl note this will be my last post on this matter.
KiCost started use Octopart API because we (the author and I) wasn’t able to fix all the scrape module on time for new releases. We was using data from 7 distributors, so it was 7 different scrape modules. Each time that one change the HTML page or coded a new java script for get robots out we had to re-code the correspondent file, it became unproductive for the tool (and just 2 maintenance).
About use direct data for large quantity, I don’t now how to start. The only experience that I had in this case was sent a form for a quote, it wasn’t direct in the web site.
2 Likes
Let me see what we can do to address the issues.
But your work is highly appreciated.
We just have to make sure it can be used without getting tied up with 1 company trying to resell some service when no such service is required.
robin
Hildogjr
Good news is that in a Linux machine, kicost works just as advertised. But not so in w10
we will find out how & why this week.
you did a good job for the plugin. Very useful
-robin
Thanks Robin by the report. I am in my PhD finals now, soon I will return the development.
As far I debugged, it is related with the babel package that I am using now to provide the different currency symbols in the spreadsheet, for currency conversion possibility (and future GUI translation if some one want to).
Linux appear to have already defined some system LANGUAGE variable that is not in Windows. I don’t know if it a Python babel package issue or just some definition that I have to add in Windows though the setup.py.
Some user told me about this workaround:
1 Like
Some alpha code with the new API in the main branch of our GIT https://github.com/xesscorp/KiCost
we appreciate that users send patches to fix the remain issues.
All base functionalities are migrated to the new API.
The developer team wait for users contributions and validation to fix some issues before release it in pip.
Will the newest version of KiCost, to be released on pip, as described above, use Octopart now? If yes, will the user need a paid subscription to Octopart to use their “service?”
Thank you for your hard work!