DMS Controller Version

[gordonparikh]

This code, used when determining DMS hardware/software make & model, uses the last entry in each array to get the value.

iris/src/us/mn/state/dot/tms/ControllerHelper.java

Lines 116 to 145 in f7a8af6

	/** Get controller setup array data.
	*
	* Finds a value in the "setup" field. The last JSON object in the
	* "arr" array will be found, and the value of "key" returned.
	* If not found, "UNKNOWN" will be returned.
	*/
	static public String getSetup(Controller ctrl, String arr, String key)
	{
	String setup = (ctrl != null) ? ctrl.getSetup() : null;
	if (setup != null) {
	try {
	JSONObject jo = new JSONObject(setup);
	JSONArray ja = jo.optJSONArray(arr);
	if (ja != null && ja.length() > 0) {
	int idx = ja.length() - 1;
	JSONObject o = ja.optJSONObject(idx);
	if (o != null) {
	return o.optString(key,
	"UNKNOWN");
	}
	}
	}
	catch (JSONException e) {
	// malformed JSON
	e.printStackTrace();
	}
	}
	return "UNKNOWN";
	}
	}

I presume the decision to use the last entry is based on devices you have worked with, is that correct? Some of our signs seem to put the values we are most interested in in the first entry instead.

I'm working on dealing with a problem sign where it would be useful to use a modified version of this method (specifically when getting the software version), but I'm not sure of how to reconcile all of this. We could create or adjust this method to implement that functionality, but ideally we would have the software version display in the DMS Properties dialog, in which case we'd want it to work generally for all signs.

I'm going to make it work in our deployment so we can test, but for integrating longer term I'd be interested in discussing this. Do you have any thoughts on how we can handle this kind of variation? Any ideas you have would be greatly appreciated.

Thanks!

[DougLau]

The logic to use the last entry in the table predates the JSON setup field. It may not be necessary now that "hw" and "sw" rows are processed separately. Based on MnDOT's current devices, it looks like using the first entry would produce better version numbers.

It is unfortunate that the 1201 standard doesn't mention any ordering requirements.

The quoted 3-arg getSetup method is only used within OpNtcip for populating SignDetail, and manufacturer-specific checks (isMakeContaining). The version field is populated in ModuleTable.getVersion (103), using the same last entry logic. To get the version from the first entry, the fix should be in this method. Do you want to test this solution?

[DougLau]

See PR #108

[gordonparikh]

I tested this and based on the version number, it should work for what we need. You can go ahead and merge it. Thanks for jumping on it!

We have had issues with Skyline signs not handling fonts in an NTCIP-compliant way. They finally fixed the issue in the firmware recently, but since we have the code to handle the behavior already, we figured we'd leave it in and have a check for firmware version to deal with it. Wyoming was having this issue too, so it could help overall compatibility. I'll clean up/update that code and send a pull request soon.