As I understand your question, the process is:
1. create new thing (initially disabled).
2. desire to read/update a property on the disabled thing without enabling it.
3. enable the thing (via CustomEnableThing).
4. do stuff with the thing (maybe including changing properties).
5. disable thing (via CustomDisableThing).
6. go to (2).
You could have a DataTable where you store info about what properties need to change.
So, (2.update) above becomes, 'update DataTable with info about what properties to change'.
Then, in the CustomEnableThing service (3), you check the table for changes (also deleting the record), enable the thing and apply the changes.
For reading the properties while the thing is disabled, you can have another table.
So, (2.read) becomes, 'if thing is enabled, read from thing; otherwise, read from table'.
And, in (5), CustomDisableThing will also update the table before disabling the thing.
You might also modify how the thing is initially created to also set up the table with the correct properties.
You can use the same table for both offline-reading and offline-updating, and then in CustomEnableThing, you'd have to compare what's on the thing with what's in the table. Anything that differs should be updates on the table while the thing was disabled.
Alternatively, you can have GenericThings with subscriptions on the disabled things AnyDataChange Events, and just store a copy of the properties there. I think you'll get log messages due to subscriptions to disabled things, but you can probably ignore these. You can also update properties on the GenericThing, and then with a subscription to the ThingStart Event, you can assign the changes to the disabled thing when it wakes up. This will double how many entities are involved, whereas the DataTable solution above is just one or two new Entities (and one or two new DataShapes). the GenericThing solution is also harder to maintain because of assigning the subscriptions (I don't know whether you can programmatically set up subscriptions).
