There's no way to divert a key-value pair to a separate resource file, outside of config.json.
The short term roadmap is to supercede system.device.addDevice (and a whole bunch of other functions) with a single system.config namespace that, broadly, exposes C/R/U/D capabilities for all types of gateway config via a single scripting API. That namespace will include the ability to do the things Phil's concerned about with addDevice.
Sure, but we don't have anything special in that regard either.
But as Paul is saying... basically all these existing scripting functions for adding devices or connections or editing some random property are all headed for deprecation. Would have been nice to have it all done for 8.3.0 but ![]()
![]()
Fair enough.
I am hoping to develop some autodiscovery tools to add to this, my only major roadblock is I have never written in Kotlin, and bmusson wrote this whole thing in Kotlin. I am on my way to learning.
Iām open to PRs in Java, I can handle the conversion if you provide the ābusiness logicā.
While off topic somewhat, I'd like to start tinkering with writing a module for Ignition. I'm a computer science major, but they weren't teaching Java back when I went to school, and haven't done much coding besides writing PLC logic and the scripting in Ignition in many many years. Where would be a good place to start? I have seen Kotlin, Gradle, and Maven thrown around but haven't even started looking at what those are and how they relate to Java. (I haven't programmed anything really major since VB6 was popular....LOL). My next problem though is finding the time to even learn it....been busy with back to back to back projects lately.
I majored in Chemical Engineering and minored in Paper Science lol. As the famous line from Ratatouille says: āAnyone Can Cookā.
My learning strategy is to just FAAFO.
Read and try to understand an existing module, compile it yourself, make some minor changes, then recompile and prove that you can make something happen.
Thereās enough good examples of drivers, script modules, components, etc. that you should be able to find a starting point for whatever you want to accomplish.
Kotlin vs Java? If you donāt know either, but you know Python, Kotlin will probably feel more comfortable. But personally I think thereās great value in learning Java before moving onto Kotlin.
Gradle vs Maven? Donāt worry about it until it matters. Build tools are just a means to an end. I think the simplest way to get started building/signing modules is with IAās Gradle plugin, so probably just use that until you have a reason not to.
I have never been formally trained in any code, never went to university, and am fully self taught.
I had a time a number of months back where I decided to try Java to get into modules, what I found valuable was to take another module I liked that was open source, and started modifying it.
I broke a lot of things, then learnt how to fix them. I still find a lot of things challenging to understand, but then the little things started to make more sense. Also it meant that I could get instant gratification from making a small change to a working code base that then could be fully compiled and run.
The language itself is less of an obstacle than learning the right way to structure a code base, and how to read API docs and extract the information you need.
Also, especially in this forum, there are some very generous and helpful people that seem to really enjoy watching people learning to extend themselves. These people have helped me a lot.
Thanks to both the Norcal-SNMP and Embr-SNMP teams for their efforts to make their SNMP drivers work. I have tested both successfully (read only, v2c) in the office with some of our rapid deployment field equipment where SNMP is the only monitoring weāve got (and very limited at that). The field failure risk is relatively high (esp for power) due to the rapid, limited, compromised and temporary nature of the deployments so hopefully we can monitor, alarm and intervene before failure. It will also enable to log data on the equipmentās performance over time to optimise specs.
Best regards,
Patrick.
Just a heads up, I found a potential bug:
I installed the most recent release (0.3.0) on a Windows server and am testing with a couple of Moxa branded devices using the SNMPv3 driver. I am monitoring the NAT table of the device so I can better document our OT network. I set up a UDT to have access to much more rows than I would need, so that if there was a change I would be able to see it. IE if a row gets added to the table, the additional tags would auto-populate with the values of the NAT table.
When the NAT table gets a new row added, the new values donāt get read in. The values stay with a quality of:
Bad("Bad_NotFound: A requested item was not found or a search operation ended without success.")
This stays until I access the device with an external SNMP tool and walk the table. At that point, the values display in Ignition.
Restarting the module does not fix this issue.
Interesting. I think this points towards this being a Moxa related problem.
Currently reading from the SNMP Agent is handled naively:
- For all the tags scheduled in a group, create the largest GET PDUās possible.
- Send the PDUās.
- If any OIDs in the PDU are rejected, remove them and try again.
This keeps happening until all the bindings have been read or marked as failed.
Notably:
- OIDs are only āblacklistedā for that current scheduled read; the driver does not maintain a list of rejected OIDs.
- The driver only used GET messages, never GETNEXT or GETBULK (which is the more ānormalā way to read entire tables).
So it sounds the Moxa isnāt updating its static (GET-able) address space until it receives a dynamic request (GETNEXT/GETBULK).
Eventually Iād like to add proper table support, which would make the driver behave more like your external SNMP tool.