Announcement

Collapse
No announcement yet.

Remote Plugin Protocol API

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

    Remote Plugin Protocol API

    --note: I somehow put my first post on this topic in the archive section, apologies for the confusion and duplicate post..

    I'm looking to do some plugin development, but I want to run the plugin remote to the actual HS box. I've seen this being done ( RaspberryIO by Spud ), but I'm hard pressed to find any documentation on the remote protocol.

    Does anyone have a link to, or details on... the remote plugin protocol? I see the 'RaspberryIO' plugin talks to HS over port 10400, so seem any docs would reference that port's use.

    While I've done some VB.net / C# coding, I much prefer more linux friendly languages ( Python, Perl, PHP, Bash, etc ). Thus, I'm looking for protocol on the wire details, not how to start a VB.net / C# project that talks remote.

    Any and all help appreciated!
    LK

    #2
    ok, didn't read question to the end

    Comment


      #3
      The on wire protocol is undocumented and has changed (in fact, I just changed it again about a week ago). It uses a RPC packages called ScS (its on GitHub), you won't be able to directly talk as there are numerous versions in field. The only documented approach is to link to HSCF.dll which is a .NET library. The data on wire after the header is a serialized .NET object, currently using BinaryFormatter but that is also likely to change. In addition there are numerous HS issues which make remote plugins problematic (as an example today there is a single queue for HSEvent notifications, the available quanta is split across all plugs [hopefully this will change soon] so a remote plugin is much more likely to cause that queue to overflow). My suggestion, depending on your goals is to have your code talk to the remote interface (json). If you really need a deeper integration then write a local plugin and then use something like 0MQ to talk to your remote code.

      Comment


        #4
        Thanks for the details bsobel. I was beginning to reach the same conclusions ( based on looking at alexbk66's initial comment and finding the ScS framework ). I've thought about using the MQTT plugin, but that doesn't seem to easily handle the update rate of my current MQTT usage -- so I'd at a minimum need to create a second MQTT service with only changes in state, instead of continuous confirmation of state.

        Ultimately, I'm looking to adapt the 'CoachProxy' device I created for Tiffin Motorhomes to be accessible via Homeseer for easier integration w/ z-wave remotes, sensors, etc.. but this isn't looking to be as easy as I'd hoped.

        I'd like to make a suggestion for a remote API that's documented and easy to code to. Possibly extend the JSON interface to allow remote plugins? Or use websockets?

        Thanks again for the details.
        LK

        Comment

        Working...
        X