New Scripting command to replace CAPI

[jon00]

I vote that HS should do whatever Jon needs, so that he .....

This has nothing to do what I need. Most people here are passionate about Homeseer but believe HST have missed a trick with this one. A 32 to 0 vote, posted in the scripting forum is pretty conclusive IMO.

I understand what Rick is saying however even a command that works with 0=Off, 100=On, 1-99=Dim and 0=Off, 255=On, 1-254=Dim (selectable between the two) would be a step in the right direction. This would be ideal for lighting control which would be the main use for most.

[Moskus]

I'm just putting in my 2 cents here, as I find that many people are whining about CAPI. But it seems to me that they are missing the point: It is insanely powerful! You get COMPLETE control over ANY device that implements it (and that should ideally be about every device there is, even your virtual ones).

Now, before beta .90 there wasn't an option to use Linq. And that makes CAPI controls much harder to use compared to hs.Transmit.

I still don't see why HST can't add a simple CAPI-to-Transmit adapter that would suit 99.999997% of all needs. With Linq they could fix this with just a few lines of code. Here's my take:

    Public Sub ControlDevice(ByVal DeviceRef As Integer, ByVal command As String, Optional ByVal dimvalue As Integer = -1)
        command = command.ToLower
        If dimvalue = 0 Then command = "off"
        If dimvalue >= 99 Then command = "on"
        If command = "dim" AndAlso dimvalue = -1 Then dimvalue = 1

        Select Case command
            Case Is = "dim"
                hs.CAPIControlHandler((From c In hs.CAPIGetControl(DeviceRef) Where c.ControlValue = dimvalue).First)
            Case Is = "on", "off"
                hs.CAPIControlHandler((From c In hs.CAPIGetControl(DeviceRef) Where c.Label.ToLower.Contains(command.ToLower)).First)
        End Select
    End Sub

However, it's also possible without Linq

    Public Sub ControlDevice(ByVal DeviceRef As Integer, ByVal command As String, Optional ByVal dimvalue As Integer = -1)
        command = command.ToLower
        If dimvalue = 0 Then command = "off"
        If dimvalue >= 99 Then command = "on"
        If command = "dim" AndAlso dimvalue = -1 Then dimvalue = 1

        Select Case command
            Case Is = "dim"
                For Each CAPIcontrol As HomeSeerAPI.CAPIControl In hs.CAPIGetControl(DeviceRef)
                    If CAPIcontrol.Label.ToLower.Contains("dim") Then
                        Dim DimValueInteger As Integer = CAPIcontrol.Label.ToLower.Replace("dim", "").Replace("%", "").Trim()
                        If DimValueInteger = dimvalue Then
                            hs.CAPIControlHandler(CAPIcontrol)
                            hs.WriteLog("ControlDevice", "Device " & DeviceRef & " is dimmed to " & dimvalue & "%")
                        End If
                    End If
                Next

            Case Is = "on", "off"
                For Each CAPIcontrol As HomeSeerAPI.CAPIControl In hs.CAPIGetControl(DeviceRef)
                    If CAPIcontrol.Label.ToLower = command Then
                        hs.CAPIControlHandler(CAPIcontrol)
                        hs.WriteLog("ControlDevice", "Device " & DeviceRef & " is turned " & command)
                    End If
                Next
        End Select
    End Sub

Linq does make CAPI easier to use. Say I wan to turn a device off using one line, here's how:

hs.CAPIControlHandler((From cc In hs.CAPIGetControl(d) Where cc.Label.ToLower = "off").First)

(I haven't tested it, but if HST implemented it right (and why wouldn't they) it should work. It does in tenScripting).

[ddg]

I'm just putting in my 2 cents here, as I find that many people are whining about CAPI. But it seems to me that they are missing the point: It is insanely powerful! You get COMPLETE control over ANY device that implements it (and that should ideally be about every device there is, even your virtual ones).

Whining?

Well maybe because it was already working perfectly in HS2 and also easy to understand even for the novice user base.
Not everybody is a skilled programmer.

[Moskus]

Whining?

Well maybe because it was already working perfectly in HS2 and also easy to understand even for the novice user base.
Not everybody is a skilled programmer.

Yes, whining!

It wasn't working perfectly in HS2 at all, but it was working somewhat and sometimes. Different protocols where implemented differently, and different plugins required different approaches when scripting. CAPI solves all this by giving us a common interface.


That being said, I believe there still is a point against Rick here. Scripting isn't meant "to be easy", but it is meant to be practical. There are things that just isn't possible with an Event, and could be solved with ONE LINE OF CODE in an immediate script.

Say you want to increase a light by 1%. In HS2 you could just do:

&hs.Transmit "A1", "Ddim", hs.DeviceValue("A1") + 1

That's simple!
And sadly not possible right now...



... or... I guess you could do:

&hs.CAPIControlHandler (From cc In hs.CAPIGetControl(DEVICE_REF) Where cc.ControlValue  = (hs.DeviceValue(DEVICE_REF) + 1)).First

but I wouldn't call that simple at all!

[jon00]

I still don't see why HST can't add a simple CAPI-to-Transmit adapter that would suit 99.999997% of all needs.

That is the whole point of the poll. There is no question about getting rid of CAPI; just providing a simple mechanism to turn devices on, off and dim via a simple script command.

[Rupp]

I'm amazed that someone hasn't written a plugin to do this at this point.

[mrhappy]

I'm amazed that someone hasn't written a plugin to do this at this point.

Why on earth would you write a plugin with hundreds of lines of code to do this? HST advise plugins are only needed for tight integration with the HomeSeer engine. If the main reason behind this is to turn lets say X10 or ZWave devices on/off/dim then I maintain that those plugins should be changed to either support value change callbacks or have a public function that is called in much the same way as execX10/transmit was. The notion of writing a plugin to act as some type of go between that should in theory be a simple process I find is lunacy.

[tenholde]

We need to keep encouraging ALL plugin writers to implement the ControUse interface.


tenholde

[Michael McSharry]

I tool a look at the HS3 SDK (12/9/13) and only hit on ControlUse was in the Document Revision notes indicating that it was added. There may be some description sprinkled around on the message board, but if it is not documented in the SDK then it likely will not get too much use.

[Moskus]

I'm amazed that someone hasn't written a plugin to do this at this point.

Because calling plugin functions are also more complicated than it was...

Don't think I haven't thought about it!

[Phill]

Rick.

Many thanks for spending the time on the script. HS has already stated in the user guide that C# is much faster for Linux / Zee implementation, can you provide the same script in C# please.

Moving forward I'd like to see a library of these kind of tutorial scripts (in vb.net & C# as they same to be the platform preferred languages) which would certainly make my life easier and probably cut down on a lot of questions we see on this forum for us not so skilled programmers who want to use scripting.

All that said. Anything that HS can do to simplify programming in HS3 will only benefit HS and so I support what Jon has raised here.

Thanks

Phill

[tenholde]

I tool a look at the HS3 SDK (12/9/13) and only hit on ControlUse was in the Document Revision notes indicating that it was added. There may be some description sprinkled around on the message board, but if it is not documented in the SDK then it likely will not get too much use.

Rick,

Can you push to get the documentation updated on this?

tenholde

[unibits]

The need for the old ways of doing things.

I am not a script writer or even really knowledgeable with most of this stuff. I rely on the good hearts of many around here to get what I need working. Usually with a little guidance I can fumble my way through this stuff.

I have a simple automation scripts that I use here. Simply put a bunch of exec10 commands to either close a relay, open a relay or update a device status.

It has worked flawlessly for years. The other day the HS2 server died (literally) so I decided to upgrade to HS3. I tried to get the simple things running.

I asked Jon00 again to help me with this. His short answer led me here.

There is no easy way to do this is what I was told.

I understand that we need to move forward with things and that the premise of Homeseer is to get better. The problem I have is that now that it is more complex I wont be able to use it.

I am an electrician and so far my career has not led me to an complex programming. I enjoy automation and the learning that goes with it. The problem I have is now I need to learn an entire new language to simply do simple things. This is over the top in my opinion.

I believe that for the simple things we should work on the "if it aint broke don't fix it" premise.

"Don't trouble trouble till trouble troubles you" seems to fit here.

It appears that the need to be better has clouded what was really important. Users just want simple methods to do things.

Hoping for a simpler way.

Just my 2 cents.

[Rick Tinker]

I am not a script writer or even really knowledgeable with most of this stuff. I rely on the good hearts of many around here to get what I need working. Usually with a little guidance I can fumble my way through this stuff.
(snip)

Most of what you wrote is completely contrary. You did not provide any reason whatsoever for why you started to use a script to control devices in the first place. Sure in HS 1.x you needed to use a script quite often, and in 2.x you still needed to once in a while, but if what you are a proponent of is simplicity, then why in the WORLD are you using a script?!?! To launch a script you have to set up a trigger, so it cannot be that there is a problem with the event triggers, but once you set up the trigger in an event, is there ANYTHING that cannot be done with the device action that you need a script for? The ONLY thing I can think of is to update a device with information downloaded from the internet, but that is usually just to update a string, occasionally a value, but if you are controlling a device, is there any reason to use a script?

If you want simplicity, dump the scripts!

[jon00]

Rick,

I suggested earlier in this thread that providing a command that works with 0=Off, 100=On, 1-99=Dim and 0=Off, 255=On, 1-254=Dim (selectable between the two - integer only) would be useful to control lighting directly as this would cover most bases.

I assume it is HST's reticence in providing this functionality is primarily due to the possible support issues when people try this on something else?