Can't set a yes/no parameter with Dynamo

I’ve been working on a graph to set a yes/no visibility parameter on all doors that are creating in the existing phase to control the graphics of the door swing. It worked in a test project, but seems to fail somewhere when using it on a live project. What’s strange, is that the correct doors are showing in the list at the end, but the parameter is not being set. I am also not getting any warnings.

I tried creating a new project, and copying the same door into it. The graph runs correctly in this new project. The parameter naming is correct, and the correct doors are making it through, so I’m not sure where the issue lies.



Any help would be greatly appreciated!

Thank you!

I am just guessing here.
Try Element.GetParamterByName to retrieve the value by unticked / ticked maybe its just 0 or 1.

1 Like

Thank you for the response! I used your suggestion to verify the set value, and noticed they were all set to 1, even though I knew some of them should not be. I then discovered there was a Project Parameter with the same name added to doors which was being used. I removed that parameter and the it works properly now.

Thanks for your help EzDoesIt!

just curious can you set the parameter with True / False or is it 1 / 0?

Thats why we need SetParameterByGUID @erfajo or a check somehow

Sorry for being late on this one. May i ask why you think I can contribute @Marcel_Rijsmus?

I can see that the issue is solved…

Now where I became aware of the topic I have to say that I dont understand why @kstalkie ends up in the situation as he does. Meaning why having a parameter for existing doors!? This should be able to solve by visibility using the phases.

However, to answer the question by @EzDoesIt. Boolean operations is 0 and 1 where false is the first value, meaning 0, and true is 1. In other words boolean could be used as Yes/No --> True/False --> 1/0

The difference in existing doors and new doors is this

in the family is a boolean switch to make the difference in graphics.

Thanks @Marcel_Rijsmus, that explained a lot :slight_smile:

Is it a dutch thing that you need to show doors differently for existing and new doors? In Denmark would it just be something tagged or halftoned

it must be a dutch thing yes
its in NEN10 which describes how a drawing should be made
with phases you can only toggle the whole family to be visible i think.
Let me explain why we need SetParameterValueByParameterGUID node.
People tend to copy elements from linked files, bringing in the parameters of the object they copied.
Now imagine what happens if the parameters came from a Shared Parameter file setup for IFC export for example. You end up with muliple parameters IFCExportAs because the element copied was made from another SP file (same parameter name, 2 GUIDs). Now i have to make a choice which parameter to fill with a value in the instance properties. Which one do i choose? And how will it affect my IFC file?

First, it is doable to control parameters inside a family using phases… quite easy actually
I have tested it on my “testbed” where I only added “Opening Angle” as an instance parameter to one door family (the four marked in the circle). this is why the “Set Parameter” node fails. It cant find the “Opening Angle” parameter in the other eight doors.

phase.dyn (16.4 KB)

Next… concerning the GUID and redundant parameters… I will try to look into that. I can see the problem, but as you know @Marcel_Rijsmus am I in the middle of a large extension of my package.

1 Like

Most of the time we need to know if an element is existing or new.
Walls and Floors and other system families are important too.

You can get that information, since everything is a parameter value. You cant use it as a formula input/value, but you can change the information about phases into whatever will serve the purpose… in this case an angle value on 30 or 90 degrees :slight_smile:

Doing it this way is much better than having an extra Yes/No parameter the users need to remember to set… this is an error option I would prefer not to be dependent of. I would trust using the phases since this would appear in drawings etc. in a much better way… and best of all… no redundant data :slight_smile:

Hi @erfajo,

The reason for the parameter was to change the symbol of the swing to a straight line, instead of curved. Of course, the phasing can change the graphics to be lighter, but not change the shape of the symbol itself. I am in Canada, this is a common convention.

I demonstrated that you can do anything with phases, also switch between curves and lines… no problem.
It is a much better idea to let phase drive it instead of a yes/no parameter…

I disagree on that.
If you study how phases and phase filters work together in demolition and rebuilding of buildings or parts of buildings in Revit and make sheets of all stages, you will find out.

@Marcel_Rijsmus please notice that @kstalkie has set the phase… if so, then use only that.

having two things which needs to be set is redundant data…


“Phase Created” is not recognized as a parameter in Revit formulas, but perhaps my syntax is wrong. How would you apply this formula?

The Dynamo graph was to remove the need for users to review each door individually. One person can run the graph and it would set everything correctly. In this case, the phase does drive the visibility parameter, it’s just done through Dynamo.

@erfajo, I think we’re trying to accomplish the same thing. I did read what you posted, but the file you attached is corrupt and it wouldn’t open. It looks like you’re using dynamo to set an instance parameter based on phase of an object, which is what i am doing. I thought you were alluding to a method that didn’t require Dynamo.

I called the parameter “Existing Door” so it’s clear to other users what it is for. It serves the same purpose as your “Opening Angle” parameter.

The file is not corrupted, it is made in dynamo 2.0, you should upgrade!

I can figure now that you use the “Existing Door” parameter for turning your line on/off… Sorry but I read this as an extra parameter to be set before something happened graphically in your families. To me it looks like you have three parameters to do the job. It should be doable to do it all with just one parameter…


However, It sure looks like we accomplish the same thing :slight_smile:

Ah, yes 2.0 explains it!

We had to control more than just the angle, our symbols switch to a straight line as well.



Thanks for your help!