Using preferences stringType = "paragraph" fails

@nayelyz
Reporting an issue with stringType of ‘paragraph’:

name: test-profile
components:
- id: main
  capabilities:
  - id: waterSensor
    version: 1
  - id: battery
    version: 1
  categories:
  - name: LeakSensor
preferences:
  - name: "paragraphTest"
    title: "Paragraph Test"
    description: "This is a test of the paragraph stringType"
    required: false
    preferenceType: string
    definition:
      stringType: paragraph

This will work and appear correctly in the Settings menu, but after the preferences are saved thru a cycle and restored, the Settings entry will show “null” as the value, and an error is logged on driver init:

[string "datastore.lua"]:37: Data store keys and values must be JSON encodable: userdata: (nil) is of unsupported type userdata

Hi, @csstup!

What do you mean by “restored”?
When you get the infoChanged lifecycle, you save the value, and then…?

Change any other preference (not the paragraph, as it can’t be changed or edited). When the driver reloads thru its init cycle, the error will appear and “null” is now the value of the paragraph preference element.

The datastore doesn’t appear to know what to do with string/paragraph types when reloading the values on init.

Can you provide a snippet of what triggers the issue, please?

This is to understand what’s causing it. I made some tests getting the “paragraph” preference value from the infoChanged lifecycle (this is called when I update another preference), and then, forcing the init lifecycle to trigger by updating the driver. There, I also get the value from device.preferences[id] and I don’t get an error. So, I don’t think the issue is there.
How are you using the datastore to save them?

Also, does your preference definition have different properties than this one?

  - name: "parapgraphSetting"
    title: "parapgraph"
    required: false
    preferenceType: string
    definition:
      stringType: "paragraph"
      default: "Default value for paragraph"

I’ll try and build a minimum set that duplicates the problem. But note that I have NO default value. The paragraph type used to be used in the DTH world to provide infomation to the user in the Settings tab. It wasn’t selectable, it wasn’t to have any value. It was just to view a giant blurb of text from the description field.

So you’d put your information you wanted the user to see in the description field. There was no actual value of the preference, or it was empty.

If you place a default value, then the user has no description field viewable in the Settings tab. Once a value has been set for a preference (default or thru the UI), the description field no longer displays. You’d just get the title, and a value. This defeats the whole purpose of using paragraph.

My sample was just to compare use cases so I could know why I couldn’t replicate the issue. The “default” property is optional but I always tend to initialize values, sorry.
In this case, it is not useful, especially because the description field doesn’t have a character limit like the “default” value (120).