Announcement

Collapse
No announcement yet.

CAPI?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • CAPI?

    Okay... let me start by saying that I've been a LOYAL Homeseer user from very early version 1. I've bought every update, a bunch of plugins, and even just updated my system to HS3 PRO. I'm also a professional software developer, so code doesn't scare me.

    Imagine my shock when I upgraded my very functional and well-loved HS2 PRO system to HS3 PRO a couple of days ago. And every script stopped working.

    No biggie, I thought. Probably just a few deprecated commands or a new DLL import or the like. BOY, WAS I WRONG.

    The simplest and most basic of functions for a home automation system, turning something on, has gone from 1 simple line to a HUGE, poorly-designed "API" with absolutely no backwards compatibility.

    As far as I can tell I can no longer do something as simple as:

    hs.ExecX10 "B2", "On"

    Instead I have to import a new DLL, iterate through control objects, Get special device identifiers to pass into cryptic commands, etc., etc.

    JUST TO TURN ON A LAMP!

    Once a device is in Homeseer it has knowledge of the device capabilities. Or it wouldn't be able to turn the lamp on either, now would it? (Yes, yes, flexible, self-documenting API... next you're going to tell me it's RESTful. Fine, but for the basic devices it's ridiculous...)

    So WHY wouldn't the scripting language extend that simple courtesy to the consumers of the system?

    Not everyone is a professional code jockey. And a lot of us who are don't want to have yet another bizarre API to contend with.

    So Rich? Rupp? What's the deal?

    I'v been a huge advocate of HS for years, bragging about the software and showing off what it could do. But I'm am honestly about 3 seconds from walking away from 10 years of HS and just buying a Vera3 box because it is simple and just works.

    -Scott

  • #2
    I can understand why HS have chosen this path, but I'm not sure I completely agree.

    CAPI has the advantage that it is extremely powerful, and as long as a plugin or device has CAPI controls, you CAN control it using scripts no questions asked!

    As a hobby developer, I find that most useful.



    But with the "CAPI only approach" goes the wonderful thing that is controlling devices with one line scripts. Sometimes I do miss hs.Transmit/Exec or an equivalent, and for on/off/dim-devices it should be fairly easy for HS to add.

    Just something like this:
    Code:
        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 = 100 Then command = "on"
    
            If command = "dim" AndAlso dimvalue = -1 Then
                hs.WriteLog("ControlDevice", "Must specify dim level to dim")
                Exit Sub
            End If
    
            Select Case command
                Case Is = "dim"
                    'DimCAPI(DeviceRef, dimvalue, maximum_offset)
                    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
    ...which can be used like this:
    ControlDevice(244, "on")
    ControlDevice(244, "off")
    ControlDevice(244, "dim", 60)
    HSPro 3.0.0.458, Z-NET with Z-wave plugin 3.0.1.190, RFXCOM + 2x RFXtrx433E, HSTouch, Squeezebox plugin, iTach IP/WF2IR & GC-100-6 with UltraGCIR, BLDenon, NetcamStudio, Jon00s Webpage builder, Harmony Hub plugin, SCSIP (with FreePBX), Arduino plugin, IFTTT, Pushalot plugin, Device History plugin.
    Running on Windows 10 (64) virtualized
    on ESXi (Fujitsu Primergy TX150 S8).
    WinSeer (for Win10) - TextSeer - FitbitSeer - HSPI_MoskusSample

    Are you Norwegian (or Scandinavian) and getting started with HomeSeer? Read the "HomeSeer School"!

    Comment


    • #3
      I can see why HST had to move away from the old commands but I think the transition could have been handled a little better in this respect, if some functions that closely replicate the hs.execX10 function with a single script line work then it does make me wonder why it was not built into HS. The closest I could try and work out to turn on/off a device is something like hs.CAPIControlHandler(hs.CAPIGetSingleControlByUse(3, ePairControlUse._Off)) but working on a virtual device that does not work, it may work on a device generated by another plugin though.
      My Plugins:

      Pushover 3P | DoorBird 3P | Current Cost 3P | Velleman K8055 3P | LAMetric 3P | Garadget 3P | Hive 3P |
      Yeelight 3P | Nanoleaf 3P

      Comment

      Working...
      X