I don't see anything in the documentation. Maybe it's there or maybe I'm bad at searching. Either way, we have the option of saving data in the state or data. For example, we can:
state.somevar = somevalue
and to retrieve simply
state.somevar
or we can
device.updateDataValue("somevar", "somevalue")
and to retrieve
device.getDataValue("somevar")
What are the differences? Using state seems to keep the datatype of the variable so there is no casting or converting when it comes out. Should we always use state? What types of things should go in the "Data"?
For example, if a fan was 3 speed versus 4 speed where would that be stored? Are there fans that can only have 3 speeds or 4 speeds? I've typically seen that most fans just use rheostats and can be almost any speed accurately. Or are there some that are really just limited to 3 or 4 speeds?
But to get away from the example again, what is the guideline?
It's been a while since I asked this and I have at least partially answered my own question so I will put my findings here.
For the most part I put information that defines the device in the "data" values. This would include the MSR, manufacturer, model, firmware version, etc. In general things that do not change or change very infrequently. All of the data that I would consider important to deciding which driver to use, for example, might be stored in "data".
Another guideline that I follow for myself is that I typically do not put anything in "data" that can't be dealt with easily as a String. All data going into and out of the "data" values are Strings. Even if I have a list of capabilities that doesn't change I will store it in the state just so that I don't have to parse it into and out of a map to work with it. Variables stored in state retain their data types where as data stored in "data" are converted to Strings.
These guidelines seem to be working well for me without any problems (as far as I can tell).
You can't. Apps, including Rule Machine, can only access device attributes (or events), which are things you find under "Current States." If you habe something in state or "Device Data" thst you want to be consumed by apps, then t should probably be a device event instead. If it's a parent app (one that created such a device), then you have more options, so this is mostly just applicable to "regular"/other apps, but I assume that is what you're talking about.
I mean, you can. But if you ask me, I don't think it's likely. Most apps work by responding to events, which would be attributes you see under "Current States" on the device page. If you have a driver that puts something under "Device Data" or state that an app might want to consume, it should probably be an event instead. If this is a custom driver, you can re-work that to do so (not so much with a stock driver, of course, unless you write/use another).
You might be able to access device data with a custom app. I don't recall exactly which methods are available to arbitrary apps and not just parent/child relationships (but this wouldn't include RM or webCoRE as-is). I know you cannot access state except in these special cases. In all of these cases, it would simply access to the value, not a "subscription" like you can get with device events (things under "Current States" on the device page)--which is crucial for most apps in that they generally want to respond to changes.
Is this related to your RGBW controller you've mentioned in another thread? If so, I think a custom device driver is the best way to go about this--but you'll have to find, port, or create one. There is an open SmartThings DTH you can probably port with minor changes, a community-created Hubitat driver (not the built-in one, though the guy who wrote it is now staff--and this one has likely been abandoned), and possibly others you could use as a starting point if writing one from the ground up is not your thing.
Without too much background myself, I see the state variables as something you may need to or want to keep private to the device and related apps, whereas attributes are things that you want to make available externally in things like Dashboards or Maker API. An example for some of the drivers I have written is the security token often required when connecting to a cloud-based service. I don't want this made available for other drivers or applications to access.
A minor point for my example of a security token is that they can sometimes be quite large, as I have found, so can push the 1024 character limit.
But if you ask me, I don't think it's likely. Most apps work by responding to events, which would be attributes you see under "Current States" on the device page. If you have a driver that puts something under "Device Data" or 
