Announcement

**Moskus** · January 11, 2013, 02:54 PM

Very, very nice! I like it!

I'll use the weekend reading it line by line, making sure I understand it.

First question
"VSPair" and "VGPair" is read as "Value-String Pair" and "Value-Graphics pair?

(If so, then why not call it "ValueStringPair" and "ValueGraphicPair"? It would make it easier to read...

It's stuff like that I'm talking about...)

And thank you to Wade!

**Rick Tinker** · January 11, 2013, 04:58 PM

Originally posted by Moskus View Post

Very, very nice! I like it!

I'll use the weekend reading it line by line, making sure I understand it.

First question
"VSPair" and "VGPair" is read as "Value-String Pair" and "Value-Graphics pair?

(If so, then why not call it "ValueStringPair" and "ValueGraphicPair"? It would make it easier to read...

It's stuff like that I'm talking about...)

And thank you to Wade!

For one thing, dashes are not allowed in variable or procedure names.

Did you ever wonder where the programming language "C" got its name? Programmers do not like to type long variable names - I am better than most because I actually know how to type using more than 2 fingers - but still, variable names are variable depending upon the programmer, and we have thousands that are easily over 9 years old, so it takes a while to clean up that stuff.

**donstephens** · January 11, 2013, 07:41 PM

Nice Tink:

Thanks for the example.

**wetlip** · January 12, 2013, 03:37 AM

i always wondered why hs wasnt shortend to h , know i understand.

1 year ago i was criticized for to long names in programming but the standard is now complete readable understandable meaningful naming in programming.

**Moskus** · January 12, 2013, 04:26 PM

Originally posted by Rick Tinker View Post

Did you ever wonder where the programming language "C" got its name? Programmers do not like to type long variable names - I am better than most because I actually know how to type using more than 2 fingers - but still, variable names are variable depending upon the programmer, and we have thousands that are easily over 9 years old, so it takes a while to clean up that stuff.

It's true that programmer didn't like to use long names (or still don't do it in other languages), but there is a new thing in town, and I bet that you have heard of it:
It's called IntelliSense, and it's built into Visual Studio so you don't even think of it.

I know HomeSeer is "old", it's one of its strengths. And I get that you can't change too much, because it would completely destory backwards compability. But new functionality and variables could easily have been made to comply the .NET guidelines. It is after all a .NET program.

What these APIs idealy should look like is something very similar to the .NET framework itself. Logical, structured, unabreviated names for functions and routines with plenty of comments. And the documentation is pretty good.

But I'll try to shut up about it, even if it will be hard.

I WILL of course use the SDK for all that it's worth, and I WILL convert my exitsting plugins and I do have some ideas for a couple of new ones.

**wetlip** · January 13, 2013, 10:02 AM

adding javascript links to head of homeseer page

seeing all the thermostats png files in this example, i wonder if it is possible for plugin writers to put a reference to an extra javascript file to the head of the page. And add functions to the document ready part in the head of the page. this to implement jQuery to build the thermostat picture par example.

here under is asimple javascript function added to the body of the page,
it would be much easier as this function could be referenced without cutting and pasting the code with append.

PHP Code:


 stb.Append("<script type='text/javascript'>")
            stb.Append(" function radioclick(value1) {")
            stb.Append(" {")
            stb.Append("var id1 = 'Radio' + value1;")
            stb.Append("var rb = document.getElementById(id1);")
            stb.Append("  if ( rb.checked = true ) {")
            'stb.Append(" var td = 'check' + value;")
            stb.Append(" var dtu =document.getElementById('ovstbr1c2');")
            stb.Append(" dtu.html = value1;")
            stb.Append("$.post('/Sample Plugin', id1 +'=checked');")
            stb.Append("}}}")
            stb.Append("</script>")

            stb.Append("<script type='text/javascript'>")




            stb.Append("$(document).ready(function () {")
            stb.Append("$(function () {")
            stb.Append(" $('button[id^=buttonov]').click(function ()")
            stb.Append(" {")
            stb.Append("  $('button[id^=ov1]').click();")
            stb.Append(" });")
            stb.Append(" });")
            stb.Append(" });")

            stb.Append("</script>")

**Rick Tinker** · January 15, 2013, 12:20 PM

Sure there is!

You can put something such as this:

HTML Code:

<script type="text/javascript" src="js/jquery-1.7.js"></script>

(Replace the src path with the path to your JavaScript file)

As the extra_meta parameter to the GetPageHeader call, or you can add it to \HTML\meta.htm which HomeSeer appends the contents of if it exists.

**reidfo** · January 15, 2013, 01:22 PM

I'm interested in learning a little more about parent/child devices.

Code:

dvParent.AssociatedDevice_Add(hs, dvRef)

This makes sense, and I've added it to my code. Is there anything that will change the way parent and child devices are displayed on the device management page? It would be really nice if the child devices were grouped visually underneath the parent. Maybe I'm missing something.

**Rick Tinker** · January 15, 2013, 02:09 PM

Device Information tab will show you related devices, but no, they are not grouped together because that is one of the features of this - the child devices can change their name, location, location2 and they are still linked.

For example, in HS2 I put all of my Z-Wave root devices in one location (Root Devices) so that if upon rare occasion I need to make a change to a node, I know where to find its root. For devices that create Battery child devices, I put them all in one location so I can just view that one location to see if any batteries need replacing. For temperature sensors, they also go in a Temperatures location so at-a-glance, I can see temps around the house - they could also just stay in the room they belong in of course, but if they were slaved together, then the root and battery would be there too.

Linking them is critical though to the new API. You could find each device, get its interface and interfaceInstance properties and device_type, and then use it if you need it, or... You get one of the devices, look up that information, then using the associated device info you either get the parent which then leads you to all the child devices, or if the one you found is the parent then you instantly have access to all of the child devices so your enumeration can end.

So a parent device will have multiple associated devices, but child devices will have 1. For an added measure, there is a "Root" enum for the device types (music, thermostat, security, etc.) that can be used as an added measure to indicate the parent (root) device.

**wetlip** · January 15, 2013, 02:46 PM

Originally posted by reidfo View Post

I'm interested in learning a little more about parent/child devices.

Code:

dvParent.AssociatedDevice_Add(hs, dvRef)

This makes sense, and I've added it to my code. Is there anything that will change the way parent and child devices are displayed on the device management page? It would be really nice if the child devices were grouped visually underneath the parent. Maybe I'm missing something.

parent devices are associated with child devices and vice versa, how does homeseer knows which is the parent ? :

PHP Code:


dv.AssociatedDevice_Add(hs, dvParent.Ref(hs))

**reidfo** · January 15, 2013, 03:02 PM

Originally posted by wetlip View Post

parent devices are associated with child devices and vice versa, how does homeseer knows which is the parent ? :

PHP Code:


dv.AssociatedDevice_Add(hs, dvParent.Ref(hs))

Your plugin will have to make that determination, most likely by the device type and/or subtype. In my case with themostats there is a device type for the thermostat root device. If you're doing something other than thermostats you could use the subtype property to define different types of child devices.

**Rick Tinker** · January 16, 2013, 09:57 AM

From my earlier post...

So a parent device will have multiple associated devices, but child devices will have 1. For an added measure, there is a "Root" enum for the device types (music, thermostat, security, etc.) that can be used as an added measure to indicate the parent (root) device.

**donstephens** · January 16, 2013, 02:49 PM

Not to hijack this thread; I'd love to see you break down triggers and conditions like this excellent example.

**Rick Tinker** · January 16, 2013, 05:46 PM

Originally posted by donstephens View Post

Not to hijack this thread; I'd love to see you break down triggers and conditions like this excellent example.

I think that was the intent when Wade created the sample plug-in "simple" - check that out and see if it helps.

Announcement

Sample Creating a Device

Sample Creating a Device

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment