I have been looking in the forum for some answers but I couldn’t find some from now on.
I have a really basic question haha.
1- I am exporting data from Revit with a stream filtering only the doors in my project (could be any other category).
2- I am importing some of the data of this stream to excel (including ApplicationId).
3- I am modifying some of the door type parameters in excel.
4- I sent the data back with a new commit.
5- I receive this commit to Revit to actualize my doors with the new data I changed in Excel.
6- Nothing changed…
I think this is the most basic workflow using the Revit Connector and the Excel Connector… But I cannot make it work properly… What am I doing wrong ? Do you guys have any idea ?
Should I import all the stream’s data to Excel ? I thought the ApplicationId was enough
Thanks a looooott
I can send screenshots or data if needed.
Thanks for your answer @dimitrie !
I feel bad I didnt read the documentation to the end, you are right it was in
BUUUT haha :
It works perfectly with rooms and built-in paramaters like room names. But I couldnt find a way to modifiy a door type parameter (shared parameter). And I wanted to try with a door instance paramater, but I couldnt find one in the exported data of the doors… Is there a way or not yet ?
One more thing, I know it is a work in progress, but the way the name of the shared type parameters (from the door for example) are displayed in the excel connector is really annoying because it is taking the ID and not the name of it, and then there is no way one can know the name of the parameters one want to add…
We shall log this down and look into it. I suspect it’s more of a pain, hence why we didn’t implement this yet.
Agreed. This is annoyance that we pass down to users; it’s originally coming from the Revit API itself. In the past, we’ve had quite a few issues with duplicate parameter names, so this was - i suspect - a way to avoid that.
We will look into wether there’s a more elegant way to do this. Pointers helpful!
I know that the way they are handled makes your task more and less difficult for each of them, and I guess you want to include all of them. The question is, do you think that in a foreseeable future we could have access to that?
Because I think that if you build a simple, user-friendly and efficient Revit-Excel-Revit workflow, you guys will be the king of the AEC world. (and I can see that we are close to it )
We definitely want this to happen so thanks for all the good feedback!
In theory, all parameters should be supported, Speckle doesn’t differentiate between built-in, shared or project parameters.
If they are instance parameters you can read them and write to them (sending and receiving), if they are type parameters you can only read them (as writing would require editing the family).
For shared and built-in parameters, we need to use their GUIDs/Built-In-Names as their display names are not unique and because they could be in other languages.
If you can’t find some parameters on those doors, I’d be happy to investigate further! Just send me a sample model and I’ll try replicate on my end.
I’m looking into ways to improve exactly this Revit-Excel-Revit flow! If you have any ideas on how it would ideally work, it’d be great to hear them!
Also, would a web app with a tabular interface that allows for a bidirectional link with Revit be an alternative solution?
So I made a few tests and I have some intersting info for you guys.
It looks like for loadable families like Doors or Windows, the stream doesnt grap the simple instance project parameter, but it takes instance family paramaters. (added in the family itself, not in the project).
Same for the type. It grabs the Family Typ Parameter when it was created in the family, and not when it was created in project as Type Project parameter for this category.
That was the first big info.
After that, I can still see some differences between the entire list of parameter available in Revit (Type or Instance) and the list I grab in the stream. But the missing ones are default/built-in paramaters.