Element.GetParameterValueByName - inconsistent results

[dbaldacchino]

Please see this simple graph (running 0.8.0.950). I am getting inconsistent results for the level names. Notice how some report just the name and others report more information, including the element id of the level. If I make a change to a level, the list changes and the output will shuffle again. This doesn't seem right. I tried it with rooms too, same result. Thanks.

[dbaldacchino]

This doesn't seem to be happening with Levels only. I retrieved the key associated with rooms and areas as you can see below (from a key schedule), yet I'm not getting the expected value. Instead I get "Element" and the ID. When no selection is made for the key value (reported as (none) in Revit), you get "null", which is forcing the node to go in error/warning mode. As a consequence, this data cannot then be written to Excel. Element.Parameters is retrieving the correct data as you can see below. Thanks.

EDIT: For parameter Phase, it is retrieving just the word "Phase" and the ID (similar to the key as explained above). For parameter Design Option, it is retrieving the name but in some random cases, it is reporting the word "DesignOption" and the element ID, similar to Levels. I am also seeing it report "Null" when it should be reporting "Main Model" (for example I have a series of rooms in the Main Model: some report correctly, some report Null).

[dbaldacchino]

Just checked the same graph in 0.7.5 and it does the same (similar) thing. The exception as compared to the above, is that it doesn't throw a warning since instead of "null", the list would report a blank instead. The other difference is that the list was sometimes writing element ids as string values and not as clickable IDs highlighted in green as shown above. The inconsistency with reporting was still there for other parameters though, such as Design Options and Phases. Is this a Revit API problem, or an issue with this node?

[ThorHow]

I have had a similar issue for weeks and coded my own little Python to get correct values - seems to be an issue with numbers.... My Dynamo stays at 0.8.1.1106 on 2015, since I'm currently demo:ing Dynamo for customers, but I tried a newer build a few days ago with the same issue.

The python is just: items = UnwrapElement(IN[0]) parameternamn = IN[1]

elementlist = list() for item in items: elementlist.append(item.LookupParameter(parameternamn).AsString()) OUT = (elementlist))

[cgrammens]

@ThorHow I am trying to use you python work around and I have been getting an error in line 11

SyntaxError: expected an indented block.
I am new to python so I am not entirely sure what I am missing.

[ThorHow]

Python wants it's loops indented, that is, tabbed. So just tab the "elementlist.append..." once and it should work.

But do consider using the normal Sheet.Sheet.Name node instead - it works.

[dbaldacchino]

Simple fix...at the start of line 11, hit tab. That line needs to be indented as it is part of the For loop in line 10.

[dbaldacchino]

@ThorHow I tried the Python script you posted but it doesn't retrieve most parameters. First of all it doesn't like parameter names with a space (errors out). I was looking at the parameters reported through Element.Parameters and using some of those to see if it returned those values but I was only successful getting room names and numbers in my example. Level returns null (and so did Perimeter, etc.). Any idea why? Thanks!

[ThorHow]

Well, it's a dirty hack ;-)

I do ".AsString" - and that one will only work if the parameter's storage type is actually string - a level is stored as an ElementId and will require another bit of magic. Usually you have a bit of a check of the storagetype of the parameter and then alter your code to match - so sorry! My little code is an incomplete little hack which only fix my issue (which was to hide the bug when I demo:ed Dynamo to customers)....

[dbaldacchino]

Ahhh gotcha :) Thanks for the info. I'm still in the novice stages, so this will take me some time to figure out!

[ThorHow]

You a novice? That's a good one ;-)

There must already be a Python snipped around which does the proper job, it's not that hard to do (it's in the sample SDKs and in the very basic C# coding examples at like Tammik's place) but it'd be much nicer if the Dynamo node gets corrected since it's a pretty critical node.....

[dbaldacchino]

When it comes to the Revit API and Python, the description "Noob" is too generous :) I'll keep searching and will find something for sure. In the meantime I'm exploring other ways to get the same data, which is flexing my weak Dynamo muscles, especially when it comes to list management, processing and using more than basic functions.

[ThorHow]

Yes, yes - of course - the famous man whose name can neither be spelled nor pronounced is a noob - sure...

The level of a room is in the API defined from the element - so I actually think the parameter lookup would fail anyway. I use the Clockwork node element.level.

[dbaldacchino]

Here's my current workaround (just forcing myself to write definitions from scratch rather than using custom nodes, just to learn and stretch my brian muscles! Not to mention ease of re-use without having to install packages). I'm simply altering the output of the node:

[monikaprabhu]

Sorry for the inconvenience. I think this might be similar to the issue discussed in forum -http://dynamobim.com/forums/topic/sheet-numbers-and-getparametervaluebyname/ and is already tracked in MAGN- 5870.I'll discuss and request the priority of this fix to be raised as many users are affected by this.

[dbaldacchino]

Thanks, this node is very important to have working right for some basic data management/manipulation in Revit.

[ksobon]

@kronz can we close this? This was resolved in 1.3 and discussed on numerous occasions. Please use BuiltInParameters instead of Parameter Name. Cheers!

[kronz]

Yep! It's way better in 1.3. Thanks

[ParametricMonkey]

Sorry how is this fixed in 1.3? I have the same issue with rooms trying to get their phase. @ksobon are you saying I should be using another node instead...

[ksobon]

I am saying that this is actually "functionality" of Revit API. It let's you select a parameter by name or by builtInparameter name. The former comes with a "risk" of inconsistent results since there are multiple parameters with the same name present in an un-ordered set. That's not a bug, it's just how it works to make it faster. If anything you should be asking for a new node that let's you select by BIP name instead, but that's a different conversation.

[ParametricMonkey]

@ksobon 'Multiple parameters with the same name' - are you saying I have 2 parameters called 'Phase' assigned to the room category?

[ksobon]

Possible, if you can have multiple Category and Level parameters like this:

That's however, not necessarily the issue. The issue is that using that component and expecting consistency is a wrong approach. Use the BIP's instead, and if that doesn't return proper values then we can go from there....

[ParametricMonkey]

@ksobon there is only one phase in BIP but there are 2 categories and 2 levels. How does this happen for a single element? I'm confused.

[ksobon]

Well it stores Level name which returns a string name for that level, and Level Id which returns ElementId for that level in two parameters that have a name "Level", but different BIP pointers. It makes sense if you are hiding one of those from the user anyways. Parameters have a singular storage type so if you want to store a string and element id you need two parameters. But I am just saying that it's possible and these nodes in Dynamo work as intended, but they need to better explain what CAN potentially happen.

[ParametricMonkey]

Sorry I'm still confused. I'm dealing with rooms and their phases. How does this occur - some models works fine, other not? What triggers this?

And how can I fix it? Is it a Dynamo issue or a Revit modelling issue?

[ksobon]

If you do something along these lines:

https://forum.dynamobim.com/t/finding-builtinparameters-for-view-specifically-view-name/15702/11?u=konrad_k_sobon

...and still are having issues then we can narrow it down to something else than faulty Dynamo node.

[dbaldacchino]

So Konrad you're saying that using the BIP is more reliable than using the get parameter by name node, correct?

On Tue, Oct 31, 2017 at 1:32 PM Konrad K Sobon notifications@github.com wrote:

If you do something along these lines:

https://forum.dynamobim.com/t/finding-builtinparameters-for-view-specifically-view-name/15702/11?u=konrad_k_sobon

...and still are having issues then we can narrow it down to something else than faulty Dynamo node.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/DynamoDS/Dynamo/issues/4310#issuecomment-340859821, or mute the thread https://github.com/notifications/unsubscribe-auth/AEcMP_qvzlD76rZSw_Qmuht_jWfmArLCks5sx2fJgaJpZM4EGcB6 .

[ThorHow]

Like Konrad said, some elements have several parameters with the same name - some of those are exposed to the user and some are not. However they are all exposed to the API, and therefore, also Dynamo. Sometimes there are even parameters with the same name, some changeable (read-write) and some not (read-only).

When you use the function ParameterByName a parameter is selected/found and if there are multiple parameters with the same name then one of them is chosen almost by random. Sometimes a read-write, sometimes a read-only, sometimes a phase element with elemenitId and sometimes just the name of a phase and chaos might occur.

The BIP, built-in-parameter, is a way around that - those codes/pointers will directly point to the correct, desired parameter. Such as ParameterByBuilt-in-parameter - there are a few of those functions around in packages.