Suggestion for improvement: change naming of exported/imported files to reduce end-user expectation that files are JSON (Was: bad JSON due to excessive backslashes to escape quotes)

🧰 Built-In Apps and Drivers Built-in Apps
1

The JSON exported from Motion & Mode Lighting apps uses backslashes to escape quotation marks in a way that fails JSON validation. This prevents verifying, reformatting, or editing the JSON file with common tools.

Excerpt of the JSON file with an example of invalid quoting, verbatim as exported from Hubitat:

{"deviceList":null,"multiple":true,"name":"variableDisableOn","type":"enum","value":"[\\"Disable Motion Detector Lighting\\"]"}

Valid JSON:

{"deviceList":null,"multiple":true,"name":"variableDisableOn","type":"enum","value":"[\"Disable Motion Detector Lighting\"]"}

2

The output of this tool is not intended to be manually edited, nor is it guaranteed to be valid JSON, although it is a similar format.

1 Like
3

The exported text is not JSON. And, as @bertabcd1234 says above, attempts to "verify, reformat or edit" are definitely not supported nor intended.

1 Like
4

Fine. It's an arbitrary structured data file.

In that case, the Motion and Mode Lighting App shouldn't create an expectation that the files that are imported/exported are valid JSON by naming the file ".json" on export and shouldn't default to importing files of type "JavaScript Open Notation".

5

After fixing the problem with the double-backslashes, validating, and reformatting the arbitrary structured data file (ASDF, ok?) into more human-readable JSON, I was able to track down 2 issues that were probably causing the multiple java.lang.NullPointerException errors when opening the rules in Mode & Motion Apps....so, even though there's no support for doing anything with the exported ASDF (the JSON that dare not speak it's name), it was quite helpful to have as a diagnostic tool.

I was able to iteratively edit/import JSON files back to Motion & Mode lighting, which led me to find two issues in one rule, causing that rule to fail to open with a NullPointerException:

  1. use of a button device but the button numbers were null
  2. reference to a global hub variable who's name had been changed

Some (but not all) of my other 15 rules that also generated exceptions also used the (renamed) global variable.

6

What version of the hub platform firmware are you running on the system that was throwing the errors? These types of issues are reported and fixed by @bravenel and the rest of the Hubitat team all the time. In your other thread, I recall you were running a quite old version (2.3.6.146) of the hub firmware. Thus, I am curious if you ever upgraded to the latest version and still experienced these issues?

2 Likes
7

I was running 2.3.6.146, though the error first appeared under 2.3.5.152 and was carried along with subsequent updates. Of course, there are almost certainly multiple causes for the 15 rules that all showed NullPointerExceptions.

Community support has been great.

On the other hand, I didn't get any response from anyone at Hubitat to my recent post asking for help resolving errors, nor to a previous report on errors with Motion and Mode lighting (Motion and Mode Lighting Apps error: Cannot get property 'value' on null object), nor to email directly to Hubitat when I lost all devices, apps, and rules in 2023 following a soft reset (you see my reluctance to do a reset?).

Hubitat staff do seem to respond more promptly (often dismissively) to posts labeled as bug reports or feature requests, as shown in this thread.

I upgraded last night (OK, early, early this AM :)). So far, so good.

I want to let it cook for a couple of days before trying to migrate to the C8 Pro.