Set Family Type via dynamo

Hello everyone, I want to override type parameters from an Excel file using Dynamo. The background is that in Revit, when parameters need to be reset to empty, it is not possible; instead, a zero is always left. This becomes problematic as the zero is then displayed in the set label. Specifically, this concerns technical data. For example, if I assign a 230V connection to an element and later want to remove it, a zero remains, and the label displays 0x230V. This is misleading.

The idea was to extract an Excel list from Revit, clear all cells with a zero, and then re-import it into Revit. Since Revit does not allow imports without additional software, I wanted to create a Dynamo script for this. I use the IfcGUID of our families as synchronization parameters. The script runs so far, but in the final step, setting the parameters, Dynamo complains that Element.SetParameterByName expects an argument. I’m a bit stuck and not sure how to bypass this error. Attached is an image of my script. Thank you in advance for your help.

We need the full warning text to provide guidance here. Can you provide it?

Typically that type of error means you are giving it a number when it expects a string, or a null value when it expects an actual data type.

Hi Jacob, thank you for you fast answer. Of cause you can get the hole warning text:

Element.SetParameterByName expects argumenttype(s). (Revit.Elements.Element, string, var). Was retrieved with (string, string, var).

Also I found a logical mistake, the elements now came from the list.filterByBoolMask node. I add a new photo.

The warning is still the same.

The node wants to have an element.
The error says it want´s an element but get´s a string instead.
This is because you are inputting a string instead of an element, so the error makes sense :smiley:

Most likely you want to take the elements from your “all elements of category” node (in the top left)

But it seems there are other issues in your graph too, as the value list is a list of nulls.

2 Likes

Thank you for your response, that makes sense. It is correct that the result list has so many zero entries, as most fields in the table are still empty. They will be filled in the further progress. I have been able to solve the problem now with another tool, so I will address the issue at another time.