Host issue/question

I have a simple definition that pushes the Host Type Name into a shared parameter of a Curtain Panel. And it owrks like a charm.








Of course i wouldn’t be bothering you if i didnt have any problem :slight_smile: If i use a Basic Wall as a Curtain Panel then it fails to register the value. Which make sense since walls don’t have host.

So… im open to any suggestion :slight_smile:



Had a similar issue recently - you’ll need to add the same project parameter to the Walls category in your model.

Daniel, I was in a bit of a rush yesterday, but had a bit of time to think ybout your problem this morning. My earlier suggestion actually won’t solve your problem as things are a little more complicated. When you use wall elements as curtain panels, Revit actually stores two elements: a curtain panel placeholder and the actual wall element that appears in the panel schedule. When you collect curtain panels in Dynamo by category you will, however, receive the placeholder element - which means that any parameter values you update in those elements will not appear in your panel schedule. :frowning:

I had the same issue on a recent project and eventually managed to solve it with a custom Python script. At the time, I thought that this was too special a case to include that functionality in Clockwork, but seeing that others are struggling with this as well I have added a node called CurtainPanel.HostPanel to the package - just install the latest version. The graph below shows you how to integrate it in your workflow. You’ll also need Konrad Sobon’s highly useful package that has a really cool node called Combine by Pattern - wish I would have thought of that one…


Finally got some time to test… unfortunately i only had 2016 handy but i got some weird results. Some panels(even though not walls) either got the wrong parameter or got none at all. I will try on 2015 asap. now I’m off to bed… damn its 3:43 in the morning lol

Screen Shot 2015-04-25 at 3.41.07 AM

Tested under 2015 and i get a similar result

Screen Shot 2015-04-26 at 8.18.09 AM

Interesting - can you share your file?

Of course :slight_smile:
Here’s a link:


BTW you’re in Munich right?

I’ll have a look tomorrow. And no, I’m in Aachen (C’est Aix-la-Chapelle en français…).

Okay, so I had a look at this and it seems that the element collection is the root of the problem (which is rather strange BTW). In my workflow I had used a different method of collecting the panels (because at the time we only needed the panels that were hosted in a certain type of curtain wall) so I never noticed this. I have modified the curtain panel collection process in your graph accordingly and the Host-Type parameter is now filled correctly.

What I am doing differently here is that I am starting with a collection of wall instances which I then filter down to those walls that are actual curtain walls. If you’re also interested in panels hosted in curtain systems or glazed roofs you would have to add collectors for those entities to the graph, of course. Subsequently, I am using a node called Element.Panels which I made recently because the built-in CurtainPanel.ByElement node that should do the same is broken ( That gives me a list of panels for each host which I can then flatten and apply to the rest of the original graph. (Except for Combine by Pattern, all custom nodes are from package Clockwork)


Of course it works like a charm :slight_smile:

Thanks a lot for your help… again

way up north then :slight_smile: I was in Stuttgart yesterday

While it worked fine in my test file it failed on some panels in a real project. They look fairly standard to me of course :slight_smile:

Email me if you want to have access to the file because this one is much more sensitive and… Germany :slight_smile:


No host

Found out why they we’re not being picked up. They are actually Curtain Walls nested in a Panel…

Daniel, Sorry to hear you had a problem to begin with, but your first screenshot was the answer to over an hour of searching / trying to solve a problem I had.