Object type requirements for base type characterization

A place for developers to discuss development of OSA
Message
Author
Vaughn
Site Admin
Posts: 1432
Joined: Thu May 13, 2010 2:17 pm

Re: Object type requirements for base type characterization

#21 Post by Vaughn » Mon Jul 02, 2012 7:31 am

Automate wrote:
bwoodworth wrote:I think a FAN ON state is a good idea. I will add that and set it to finialized
Thanks,

With this addition http://www.opensourceautomation.com/php ... -t173.html
lets add the new heat or cool setpoint value to the two setpoint change events and the new current temperature to the temperature change event.

The new fields should not impact this as they are only in the event log, and everything should be done by then. The Method queue is what allows these features, and it already has the parameters in it, you just would not see the parameters used in the logs Afterwards.

I got that change in the SVN anyways, just want to make sure we are using them right...


Vaughn

Automate
Posts: 1691
Joined: Sat Dec 11, 2010 1:44 pm
Location: US

Re: Object type requirements for base type characterization

#22 Post by Automate » Mon Jul 02, 2012 7:40 am

Yes, I am just saying, now that the event log can store extra values, thermostat plugins should record the temperature value when they trigger a temperature related event to be logged.

Methods and events are not always related. For instance a caller ID plugin would have an incoming call event but no incoming call method. And if someone changes a thermostat setpoint directly from the thermostat (not through OSA) you would get a setpoint change event without any thermostat method being run.
Last edited by Automate on Mon Jul 02, 2012 7:59 am, edited 2 times in total.

Automate
Posts: 1691
Joined: Sat Dec 11, 2010 1:44 pm
Location: US

Re: Object type requirements for base type characterization

#23 Post by Automate » Mon Jul 02, 2012 7:54 am

The discussion about Base Object Types got me thinking.

Does it make since to have separate "Thermostat Base" and Thermostat" Object Types.

As far as I know all the various thermostat plugins may install their own version of the Thermostat Object Type which may be slightly different from another thermostat plugin type. It would be nice to have a Base Object Type that no plugin install should write into. Any UI would know that the Base Object Type is always standard but any thermostat object could have some extra features in its Thermostat Type that the standardized UI may not support.

User avatar
bwoodworth
Site Admin
Posts: 1563
Joined: Tue May 04, 2010 6:49 am
Location: California

Re: Object type requirements for base type characterization

#24 Post by bwoodworth » Mon Jul 02, 2012 8:20 am

Isn't that what this thread is about? The TERMOSTAT base object type described in the first post is just a model for additional thermostat object types like ZWAVE THERMOSTAT. These additional object types would have the THERMOSTAT base type to used for grouping and would tell any UI that this type will have the necessary states/event/methods/props.
Brian

Automate
Posts: 1691
Joined: Sat Dec 11, 2010 1:44 pm
Location: US

Re: Object type requirements for base type characterization

#25 Post by Automate » Mon Jul 02, 2012 9:25 am

bwoodworth wrote:Isn't that what this thread is about? The TERMOSTAT base object type described in the first post is just a model for additional thermostat object types like ZWAVE THERMOSTAT. These additional object types would have the THERMOSTAT base type to used for grouping and would tell any UI that this type will have the necessary states/event/methods/props.
Yes, but I am also thinking of naming conventions
Should Base objects always include "Base" in their name so that when you are browsing the templates you can tell they are a base object?

From the SVN plugin install.sql files here are how the current thermostat plugins are configured.

Code: Select all

Radio Thermostat types 
  plugin = RADIO THERMOSTAT
  device = RADIO THERMOSTAT DEVICE (does not refer to a base type)
  
RCSTR40 types
  plugin = RCSTR40
  device = THERMOSTAT (base type THERMOSTAT)
 
Aprilaire types
  plugin = APRILAIRETHERMOSTAT
  device = THERMOSTAT (base type THERMOSTAT)

Zwave types
  plugin = ZWAVE
  device = ZWAVE THERMOSTAT (base type THERMOSTAT)
As you can see if THERMOSTAT is the base type, Dan and I will have to modify our plugin device's type names which is not that big of a deal

Also, should plugins always include PLUGIN in their name so you can easily tell which is the device and which is the plugin?

When you are first creating a plugin you may not think about other plugins that may in the future use your same device types. So should every plugin generally create three object types?
* Base Device Type for any device that does not already exist in OSA
* Plugin specific Device Type
* Actual Plugin Type

User avatar
dbemowsk
Posts: 442
Joined: Sun Jan 01, 2012 12:28 pm
Location: Wisconsin
Contact:

Re: Object type requirements for base type characterization

#26 Post by dbemowsk » Mon Jul 02, 2012 6:18 pm

Automate wrote:Yes, but I am also thinking of naming conventions
Should Base objects always include "Base" in their name so that when you are browsing the templates you can tell they are a base object?
Maybe as to not over extend the names of the devices we could use something like I have seen in some peoples coding styles when defining variables, such as these:

Code: Select all

P_RCSTR40 (The plugin)
D_TR40 THERMOSTAT (A device object used by the plugin)
B_THERMOSTAT (The base object type)
OR, what about adding another field such as an object type definition field that would be one of the 3 (PLUGIN, DEVICE or BASE). It could be a simple ENUMerated field. I guess though with that thought, how would you define a control state image, control property label or a place?
Automate wrote:From the SVN plugin install.sql files here are how the current thermostat plugins are configured.

Code: Select all

Radio Thermostat types 
  plugin = RADIO THERMOSTAT
  device = RADIO THERMOSTAT DEVICE (does not refer to a base type)
  
RCSTR40 types
  plugin = RCSTR40
  device = THERMOSTAT (base type THERMOSTAT)
 
Aprilaire types
  plugin = APRILAIRETHERMOSTAT
  device = THERMOSTAT (base type THERMOSTAT)

Zwave types
  plugin = ZWAVE
  device = ZWAVE THERMOSTAT (base type THERMOSTAT)
As you can see if THERMOSTAT is the base type, Dan and I will have to modify our plugin device's type names which is not that big of a deal
Seems like an easy edit for a good cause.
Automate wrote: Also, should plugins always include PLUGIN in their name so you can easily tell which is the device and which is the plugin?
Addressed in my first comment.
Automate wrote: When you are first creating a plugin you may not think about other plugins that may in the future use your same device types.
Are you referring to all object types here or just the base types?
Automate wrote:So should every plugin generally create three object types?
* Base Device Type for any device that does not already exist in OSA
* Plugin specific Device Type
* Actual Plugin Type
I would not necessarily say that every plugin CREATE a base type. I would say that it would be up to the plugin creator to see if a suitable base type exists first. Outside of that I believe that every plugin would use these 3 object types.

Dan B.

User avatar
bwoodworth
Site Admin
Posts: 1563
Joined: Tue May 04, 2010 6:49 am
Location: California

Re: Object type requirements for base type characterization

#27 Post by bwoodworth » Mon Jul 02, 2012 10:55 pm

My vote is that we keep the base object type names like they are in the first post in this thread and have any existing plugins that use the same name for their objects to change them to something more specific. I also think that adding any sort of prefix to the name is a bit ugly and not very readable.
dbemowsk wrote:
Automate wrote:So should every plugin generally create three object types?
* Base Device Type for any device that does not already exist in OSA
* Plugin specific Device Type
* Actual Plugin Type
I would not necessarily say that every plugin CREATE a base type. I would say that it would be up to the plugin creator to see if a suitable base type exists first. Outside of that I believe that every plugin would use these 3 object types.
I agree with Dan on this. Plugin authors should not worry about base types. They should only set their device object types to use existing base types if they already exist. If new devices come out or we decide that there are certain types that are similar enough for a base type we can created it then and plugins can be updated accordingly.
Brian

Automate
Posts: 1691
Joined: Sat Dec 11, 2010 1:44 pm
Location: US

Re: Object type requirements for base type characterization

#28 Post by Automate » Tue Jul 03, 2012 3:39 am

Makes sense, so for my Aprilaire plugin I will change to:

Base Type: THERMOSTAT
Plugin Type: APRILAIRE PLUGIN
Device Type: APRILAIRE THERMOSTAT

What do you think of changing the GUI so when you are creating/modifying an Object instance the Base Object Types do not show up in the Object Type selection drop-down list since users should never be creating instances from a Base Object Type?

User avatar
dbemowsk
Posts: 442
Joined: Sun Jan 01, 2012 12:28 pm
Location: Wisconsin
Contact:

Re: Object type requirements for base type characterization

#29 Post by dbemowsk » Tue Jan 29, 2013 9:57 pm

Can the information from this thread be posted as a sticky or something?

Dan

User avatar
bwoodworth
Site Admin
Posts: 1563
Joined: Tue May 04, 2010 6:49 am
Location: California

Re: Object type requirements for base type characterization

#30 Post by bwoodworth » Tue Jan 29, 2013 11:30 pm

Changed to sticky
Brian

Post Reply