Happy New Year folks!
As I'm poking around under the hood trying to understand how some things bolt together so I can look at implementing some things I've been thinking about, I've got a few questions about how things work in the device table.
1. What is the purpose of the 'state' field?
2. Is the intention of the 'status' field to show a near-real-time status of the device in question? Typically, what is responsible for updating that field? Based on what's shown in the wiki, it's almost as if each device class or plugin is responsible for updating status. http://wiki.linuxmce.org/index.php/Device_Status
3. As there is a MAC address and an IP address as part of the device's data, would it also not be prudent to have a hostname field as part of the device data? It would make some aspects of managing the LMCE internal network a lot easier if that data were present in the device table, rather than derived and hard coded in external scripts or elsewhere in the database. I'm looking at playing around with the 'workstation' aspect, and it would sure make my life easier if the hostname were there. (Note: there is a "#188 computer name" data point, but that seems like a WINS name field to me, but I could be mistaken).
If the core devs don't see an issue with that, I'll put a feature request ticket in for that schema change. The core devs would be the ones with a full understanding of the possible effects that change would have, so I would think they'd want to handle any change to a core db table like device.
Also, one final question: I manually changed a MD from a MD template to a workstation template in the Device table, and that seems to work. Is that data recorded anywhere else besides the device table?
Thanks for your time, and happy home automation for 2013!
/Mike
To answer your questions, directly:
1. State is a field used to store a global device state. It varies depending on the type of target device...e.g. with lights, it will typically show something like ON/100, meaning the light is on, and at 100% intensity, whereas a thermostat may show: AUTO/COOL/25 indicating that the thermostat is in cool mode, with the temperature set to 25 degrees C. It is exposed as a quick and easy variable specifically for plugin processing.
2. The state field is typically updated by the interface DCE device in question (e.g. ZWave in the case of z-wave enabled thermostats), and is typically used by the plugins (Lighting Plugin, Climate Plugin, whatever), because it is a very easy variable to obtain, without having to traverse the device data (which is also used for device configuration, and can also be used to store state... This actually also implies that said State variable is volatile, whereas device data written by device may be used to store device settings that need to persist.
3. I can understand your point of view, however I would not want to make such a critical addition to the table, as it would require the requisite sql2cpp libraries to also be rebuilt (and thus all most packages in the system). Host names really are superfluous from the point of view for the system, so they were not added as part of the database schema...and honestly, I do not see the utility in adding the field for most users... But this is only my point of view...in the end, he who writes the code, makes the rules...and is also the person who needs to take responsibility when things break.
You will need to study the entire database schema, it is _very_ complex, and the answer to your final question isn't an easy one. I can see you're just starting out, so keep looking at the database tables, and keep asking small, specific questions that we can answer, this way we can help fill in your knowledge, without you getting all spun around.
-Thom
