NetXMS Support Forum

I went back to look at this again and continued to have the same issue. 

I checked for error messages in the nxmc.log file as you suggested, and checked again after using the buttons, but saw no errors that looked like they were related to buttons, or launching a browser, or anything. 

Since it had been a while since I had worked on this, and at the time I was doing a number of other things, I decided to go back and double check everything from the beginning.  I checked the Object Tools to ensure they were there and looked correct, and then I removed the buttons from the dashboard, and re-added them.   I then saved, and tried this dashboard under the device, and the buttons worked correctly for the device's context. 

So, this does/did seem to be something wrong with my dashboard or object tools, somehow.    I have no idea what I did, but it does seem to work correctly.   Sorry for the hassle. 

I will dig into this some more.  I used the same Object Tool for the button, as I have used under the node's Tools > Connect  menu.   I can launch HTTP and HTTPS from the Connect menu, but still nothing from the Dashboard.   Not sure why this is happening, or if it's client OS/ client platform specific.  I'm on Windows 7 and Windows 10 for both Client's where I've had this happen, so it's not (client) machine specific for me. 

I'll keep messing with it; For now my work around is just to use the Connect Menu, but having it work in the Dashboard as a button is the end goal. 

No problem Filipp.  Appreciate the response.   

You're correct; I have multiple hierarchies so nodes exist in multiple places (i.e. it might be listed in my physical topology under "Core Routers" but then it might also be listed under Manufacturers > MikroTik... I think this is just for my visual benefit / sorting more than anything else.  I know I tend to over-complicate everything haha). 

Thanks again, and look forward to the fix (noting that B would be my preference, so we don't ever delete a bunch of custom attribute values...like keys/passwords/etc that could be impossible to recover or recreate easily).   

~C

Hmmmm, Ok that's unfortunate.  Is that a difficult limitation to overcome, or something that just needs some time and programming to fix?  (being able to push data into table DCIs from NXSL scripts outside of the Agent, Internal, SNMP)

I'm not sure if a Script Source will work, because that's going to run on a schedule correct?   I was hoping to use Table DCI's to push information into on demand (or, when a script is run manually via an Object Tool); not something that needs to run on a schedule..also, different nodes might need different columns, and the columns might be or might need to be updated at different times.   I guess I can do a "one script does everything" but that could end up being thousands of lines to cover every situation, and the table DCI would likely end up with a large number of tables that are unnecessary also.  I was trying to make this efficient and streamlined by only running smaller scripts as necessary, and only reading/writing into the tables as necessary, as well. 

I might be able to do this under Agent, but some of my scripts work under the Node context and so I guess I would have to somehow pass a node ID to the Agent, so the agent would be able to pull and push information to the Node's table DCI?

Part of what I'm trying to do (or, one of the challenges I'm running into) is that the "perfect" way to do certain things, ends up putting data and values all over the place.  Sometimes it seems Custom Attributes are best/easiest, other times it seems recommended to use Persistent Storage, sometimes Server Side Custom Attributes make the most sense, etc.   It certainly works, but it feels like this can get out of hand quickly with complex scripts and configurations and a large number of nodes.  A lot of things would work great in Persistent Storage, but it is basically a two column list that seems to grow into tens of thousands of items easily if it were to be used by even a few scripts on a large number of nodes. 

I was trying to contain everything random in a table DCI, with the necessary columns (which also take advantage of security permissions which Custom Attributes dont, and are specific to the node (which Persistent Storage is not). 

Are there any other recommendations? 

Thanks!

There seem to be very little info or examples of this...  I'm trying to update some tables and I can't seem to find any solution after trying everything I can think of.   Does anyone have a working example?

    testTable = new Table();
    testTable.addColumn("GUID");
    testTable.addRow();
    testTable.set(0, 0, node.guid);
   
    result = PushDCIData(node, dciId, testTable);

 

hahaha.. wow.... I have never see those options before, but yes, that was the problem.  That's so dumb on my part!  Thank you for pointing this out! 
 

Actually, now my Test DCI has disappeared from the same client as well (but still shows on the other remote client). 



Both of the missing DCIs are broken/not working (expected), and it throws an alarm saying they are unsupported (which, I know and would expect, no issue here).   

But is there something that removes an unsupported DCI from any client which did not create it?   Why would it be accessible on the original client, briefly appear on other clients, and then disappear when it switches to unsupported?

I'm logged into a client remotely (via remote session to another computer), and I have a client running on my local machine.  I'm logged in as the same user account.  

The DCI's are different between the two.  I have tried closing and restarting... I created a test, which appeared in both.  And I can delete the test item from the other machine (the one other than where I created it) and it disappears on both.    I'm not even sure how this could happen.  

Not sure if this has been requested before, but the Dial Gauge is pretty rigid in its configuration with regards to color and values.  

You can only have three color zones, and the color zones have to be, yellow, green, red in that order.   That assumes that something on the left/bottom is bad, something in the top/middle is good, and something far to the right is really bad.   This works fine for things like pressure, RPMs, etc but does not work very well for things like battery voltages where "8" could be just as bad as "15" for a 12V battery where both values need to be in the red.  A battery dial gauge really should be red, orange, green, orange, red.   (or possibly red, orange, green, red)

I think it would be much more useful to allow us to specify the number of color zones, and in which order.  This could be done with a table, kind of like how we can add multiple Dashboard Elements.  You click Add, specify the minimum and maximum values for the range you are creating, and then choose the color.   The item at the top would be the left/bottom color zone on the gauge.  The next item/range would be the next color zone on the gauge, etc  As a sanity check, you could require that the second color zone HAS to start from where the previous zone ends by pre-populating and graying out the field so it cant be changed.  This way, you couldn't overlap the end of color zone 1 with a value of like 11, and then start color zone 2 at 10.     I thought about having the ability to reorder these, but then I think you'd have to give up the sanity check...and that's probably not necessary anyhow since you can adjust the values and colors on each to match your needs.

The Object Tool that I add to the dashboard; I'm trying HTTP and HTTPS buttons.

You said "agent"....  which made me think; does the Dashboard Object Tool require an agent??  Or can it be any node?  The node is online.  The Tool works fine from the Node's  Tools > Connect  menu, so I know that the Tool itself is working ok.  It just doesn't do anything when I add it to the Dashboard as Object Tool buttons. 

I'm not sure what the intended action is when this happens. 

I created a Custom Attribute at the Infrastructure Services Container with no value, and made it inheritable.  
I then set a value on a node (about 3 containers down). 

When I delete the Custom Attribute at the Infrastructure Services Container level, the VALUE of custom attribute on the node is deleted, but the Custom Attribute itself is still there.  

I would have expected:
A)  Deleting a custom attribute would remove it and the value from all child objects.
or
B)  Deleting a custom attribute would remove it from all child objects that have not been defined with a different value.

I would prefer  "B"..... If a custom attribute is removed, I would appreciate it, if it did not delete all values on child objects which are different than the value being deleted (i.e. if something is defined or has a override at a child object DONT delete it).    This could easily wipe out hundreds or thousands of custom defined values which could be nearly impossible to repair.  

But the current behavior I saw (I tested it a few times, a few different ways) was completely unexpected and not what I assume the intention was/is. 

As a side note feature request, there are a number of things in NetXMS which it will catastrophically let you do without warning.   More than once I have accidentally chosen a "delete" option on something, thinking I was removing it from a template, container, etc only to have NetXMS completely deleted the Node.  I realize this is ultimately my fault :-) but sometimes those late 3-4am nights get the best of me and I click without completely processing what is about to happen haha. 

Thanks!

I hate to revive an old post, but I was searching for some better information on this myself.   I noticed that the admin guide screenshots don't even match what's in NetXMS (at least, in 2025 for version 5.2.x) ... so, this is making is pretty difficult haha :-).

Ubiquiti doesn't provide it, but I can probably find it online somewhere; I guess I assumed that was a "standard" MIB of sorts that would already be included by default so I guess that I overlooked that.  :-(

I'm receiving errors when compiling these two related Ubiquiti MIB files.  I did have to correct some issues in the UI-AF-60 MIB downloaded from Ubiquiti to get this far, but I still receive errors (which, seem to be superficial since I see the definitions in the MIB Walk).  Since it seems to work ok, it's not a huge issue other than the fact that the error messages annoy me hahaha, but I thought I'd report it anyhow in case this is part of a larger problem... i.e. my guess is that the NetXMS MIB Compiler is compiling these in the incorrect order or something. 

Or, maybe I'm completely wrong :-)

Templates are GREAT, but, occasionally we realize after the fact there is a "better" way to build something, or we have a new use case that requires us to split DCI's defined in templates into new templates.  
Currently, we can keep historic data by removing the template, but not removing the DCIs however this isn't really ideal since the graphs are wrong anyhow.  
I was thinking it would be pretty nice if a template would automatically merge two DCI's based on identical matching names and other fields.   This could be enabled or disabled somehow in the configuration, just in case someone didn't want this behavior.     I think the DCI's would need to match identically, 100%... as would be the case when you copy or move DCI's between templates. 
If something doesn't match, then they wouldn't merge and a new one would be created.   If that happened accidentally, say for instance if you copied a DCI to a new template and then changed the name and then applied it.... then you could fix this by manually merging the DCI's (after you fixed the name change on the old one), by multi-selecting the two of them, right clicking, and then going to "Actions > Merge" or something like that.  

Merging DCI's manually through the menu would do the same thing as the automatic method; it would check to ensure 100% of the configuration fields were the same, and then move the oldest set of data into the newer DCI.   A warning prompt for Yes/No and brief explanation of what will happen wouldn't be a bad idea either.  
Just for simplicity, you could only merge 2 DCIs at a time.  
I'm sure I could poke around in the database and do this in psql... but I'd rather there be an official NetXMS supported method haha :-)