You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So I wanted to seed my parts database based on my order history with Mouser where I get almost everything.
After downloading the orders as xls files I found a csv converter and converted them all to csv.
Then wrote a simple python script that goes through them, and based on the mouser # (supplier part no. - SPN) it gets a proper description from the Mouser search API, not the messed up one in the order data (which has category info prepended).
It also does some basic mapping of Mouser categories to my category tree, and if it can't map it just put it in my "Unknown" category by default.
Then aggregated these into single csv files, about 1k lines each, so wouldn't have to sit and feed Part-DB an endless list of tiny files.
This worked great, although I could only do about 2/3 today as I ran into API usage limits for Mouser. It all pretty much imported cleanly and once their API has cooled down again I'll wrap up the remainder.
One of the issues I ran into is if I import the SPN and set the supplier=Mouser, later when I go to fill it in with info via Part-DB the SPNs clash, and I get two supplier entries, both Mouser. So I imported it all without the SPN or supplier set. It would be really nice if I could provide the supplier and SPN in the files and have Part-DB recognize it and handle it properly. The current model seems to be "create and merge", which is very manual. "Update" might be cleaner: update only that which has changed or been added/removed. Maybe even update automatically in import, but that might tickle API limits easily.
Mouser's API is really flaky. Lost of search responses with an empty list of parts, suggesting nothing was found... retry and it provides the correct answer. Even the borked responses count towards their API limit...
So... not so much in the way of ideas yet... but I'd be curious if there are any ideas for how to manage this? Of course, ideally the order APIs would be used directly (no more annoying xls files to download) - but Mouser doesn't seem to distinguish between reading order data and placing orders so are understandably picky about who they grant this access to.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
So I wanted to seed my parts database based on my order history with Mouser where I get almost everything.
After downloading the orders as xls files I found a csv converter and converted them all to csv.
Then wrote a simple python script that goes through them, and based on the mouser # (supplier part no. - SPN) it gets a proper description from the Mouser search API, not the messed up one in the order data (which has category info prepended).
It also does some basic mapping of Mouser categories to my category tree, and if it can't map it just put it in my "Unknown" category by default.
Then aggregated these into single csv files, about 1k lines each, so wouldn't have to sit and feed Part-DB an endless list of tiny files.
This worked great, although I could only do about 2/3 today as I ran into API usage limits for Mouser. It all pretty much imported cleanly and once their API has cooled down again I'll wrap up the remainder.
One of the issues I ran into is if I import the SPN and set the supplier=Mouser, later when I go to fill it in with info via Part-DB the SPNs clash, and I get two supplier entries, both Mouser. So I imported it all without the SPN or supplier set. It would be really nice if I could provide the supplier and SPN in the files and have Part-DB recognize it and handle it properly. The current model seems to be "create and merge", which is very manual. "Update" might be cleaner: update only that which has changed or been added/removed. Maybe even update automatically in import, but that might tickle API limits easily.
Mouser's API is really flaky. Lost of search responses with an empty list of parts, suggesting nothing was found... retry and it provides the correct answer. Even the borked responses count towards their API limit...
So... not so much in the way of ideas yet... but I'd be curious if there are any ideas for how to manage this? Of course, ideally the order APIs would be used directly (no more annoying xls files to download) - but Mouser doesn't seem to distinguish between reading order data and placing orders so are understandably picky about who they grant this access to.
Beta Was this translation helpful? Give feedback.
All reactions