Door Handing Dynamo Help Please

Hi we are trying to schedule / add to a door schedule left and right door swings with in window families.

got as far as automating this but we now need to separate out our windows from the door list.
which we have managed to do as a list. ( the bottom half of the flow)

any ideas or help much appreciated !

how can i convert the end list at the bottom to elements to link back into the top flow ?



First, please remember to add notes for usage of foreign packages, It is almost impossible to find nodes you dont know… However, did I recognized the nodes you used, since it is from the package I maintain :slight_smile:

Your question sounds a bit odd… why is it windows and doors is mixed up as windows?
I will strongly recommend that you keep them separated as doors and windows…

That said, please upload your graph (the dyn file) and I will try helping you. It is rather easy to do the ‘division’ of you windows as doors and windows… even that it is a mess you are doing :slight_smile:

Besides comes the package with two more nodes, since you dont use the face flipping for windows, than use only the node for hand flipping.


Hi erfajo

Yep sorry top package from danedu dynamo.
We are trying to schedule out door swings within window Family
We can get it to work sort of but if we want to filter out any types of window that dont have a door
we get stuck.

have attached the files
thanks for your helpTest Window Handing.rvt|attachment (2.1 MB)
TEST_Window Handing Sample3.dyn (12.5 KB)

Here is a solution, please notice that I have made two imaginary parameters for ‘hinge side’ and ‘opening side’ you have to adjust.

TEST_Window Handing Sample3.dyn (14.3 KB)


WOW Thanks! will give it a go :smile:

What package did you use for the Element.flipped, Element.handflipped,… ? Thx

It is written in the image and the graph as notes… DanEDU Dynamo package maintaind by guess who :slight_smile:



I’ve been trying to develop a Graph using these Nodes. I’m getting ‘Null’ returns from the Nodes in both Revit 2017 and 2018. Can I ask if there any know issues with the Nodes? I have Package 2018.115.0

I’d prefer to use your Nodes, I think, as the Archi_Lab alternative is returning all instances as Reversed even though 4 of them are unaltered, i.e. neither face- nor hand-flipped.

WIP_Set Door ‘Handing’ Instance Parameter v1.dyn (8.2 KB)

I am so sorry… I have made a spelling error in loading the python code.
I search for “ElementElement_FaceFlipped”, and the file is called “Element_FaceFlipped”

please replace this node with the one present in the package folder (DanEDU_Dynamo\dyf).
Element_FaceFlipped.dyf (5.7 KB)

I am working on a larger update of the package, so I will not upload this error correction today

the DanEDU package is now updated (2018.215.0)

1 Like

Hi again

I apologise for this as I do appreciate you posting WIP in your last response.

At the same time, I’ve built the graph as attached in v1 and I couldn’t understand why it should be sorting the doors as it is. It may be that there is something I don’t understand about Door Families and/or handing.

My assumption is:

Door is hinged on R in base condition. It will be R if unchanged OR if hand- AND face-flipped. If it is hand- OR face-flipped only, the door becomes L.

With some further testing (v2), it seems to me that both Nodes are assessing things wrongly (or, as I say, I misunderstand it).

FaceFlipped notes that a door inserted in the ‘wrong’ orientation is face-flipped.This door is inserted in the wall with the ‘exterior’ of the Door Family on the interior side of the Wall. While that is ‘flipped’ in a sense, it behaves more like a rotation would - it is still hinged to the R. Other than that, FaceFlipped correctly notes when Doors have NOT been face-flipped.

HandFlipped had errors in both returns - unchanged Doors reporting as hand-flipped and a hand-flipped Door and one mirrored about its own Centre Left/Right Reference Plane are reporting as not hand-flipped.

I hope this is helpful … if I am mistaken and incorrectly calling these things errors, I apologise and would certainly appreciate clarification.

The Door I used is the standard Concept Door that ships with Revit. I added Parameters to check but have not altered the geometry/orientation of the Door. I did switch on the Room Location Point which seemed to help in the ‘To Room’ part of the schedule. I’m not sure if that is related - I don’t think it changed your Nodes’ performance.

Files available for download here …

DoorTest.rvt (612 KB)

WIP_Set Door ‘Handing’ Instance Parameter v1.dyn (14.6 KB)

WIP_Set Door ‘Handing’ Instance Parameter v2.dyn (6.0 KB)

The flippings are set according to the default families provided by Autodesk.

In the base is the door hinged LEFT and OUT. In Denmark, we always stand on the hinging side looking at the hinges when we want to give information about hinging.

When testing your example I get the result I expected

I have now googled how door hinging is in other countries and that is apparently something we do not agree upon in the world. What I do is the Danish standard. However, strictly written, is it the same we are doing, since those countries that give the opposite information as we would do in Denmark, it is because you look at the handle and not the hinges.

Therefore, to be very correct I went back to my code, which in the boolean node versons is true/fase values in one list, and in the normal version is elements split into a true and a false list)


for element in elements:
    if element.FacingFlipped:


for element in elements:
    if element.HandFlipped == element.FacingFlipped:

That tells me that it is you who have to give the proper input data when setting the parameters for elements being flipped true or false.

1 Like

This is actually an interesting question
I would say from a Danes perspective that what Ideate is doing is wrong!

From a computational perspective, I would say that if the values are false for Handflipped and false for FacingFlipped, then the door would be Left hinged/Right handed and outgoing. In other words, I dont understand what Ideate is doing!?

But that is according to how I think elements should behave :slight_smile:

1 Like

Hello again

Thank you very much. This does appear to answer my question at least … I’ve yet to confirm exactly what standard the contractor will use and was basing mine on the basic IFC enumeration - SINGLE_SWING_RIGHT and SINGLE_SWING_LEFT, found here. There is more detailed information on local variations,including the ‘reverse’ type here.

Thank you especially for pasting your code. This has clarified it. As one comment, may I suggest that the Node title may be slightly misleading in this one respect … your Faceflipped Node will report an Element as Faceflipped or not Faceflipped. But your Handflipped Node reports status influenced by the Faceflipped status. If I understand it correctly (I’m tired!), a Handflipped Element that is not also Faceflipped reports as ‘False’ but is in fact Handflipped. I guess this is perfect for doors in some regions - Denmark and the US (which explains the Archi-Lab confusion for me) - but otherwise a little misleading as far as the Node name is concerned.

Thanks very much for your answers and attention. It’ll be good API practice for me to figure out my own Node!

I have to acknowledge that I have made a mistake, I need to update my code. It is a really bad rookie mistake.

in the HandFlipped case is my code telling if the value is the same, that is not the same as True at all. it simply says they have the same value. In this case that should be false and not true as I have made it. Both the boolean and the element version needs to change to ‘not equal’ as the true value!

HandFlipped will implement the code as shown below.

 for element in elements:
    if element.HandFlipped != element.FacingFlipped:

I will make this update as soon as possible… I still do have a large update to release, so I am afraid that I have to let my wrong code stay for some days. I am so sorry

Thanks a lot for your attention @des.hourihane

the code for flipped elements is updated in the updated DanEDU package (2018.215.0)