No announcement yet.

A plugin for PluginScripts

  • Filter
  • Time
  • Show
Clear All
new posts

  • A plugin for PluginScripts

    Can anyone see why the following should not work?

    There is a single, multi instance capable plugin, ooh let's call it HSPI_PluginScript.

    It has one configuration parameter - a script name.

    It instantiates ALL possible functions that a plugin can do, but instead of actually doing anything itself it passes the values to the equivalent script function.
    (Just like the PluginFunction routiens it traps these so they don't need to exist.)

    OK, downsides

    1) Probably not as fast.

    But it is HomeAutomation, not weather modelling so how much do I/you care?

    2) Might need to package the parameters

    No worse than having the structs passed by HomeSeer now, just an API after all.

    Upsides -

    1) Simpler to understand. All the boilerplate code that needs to be there is hidden in the only relevant plugin. Only code that is specific/needs to be there is necessary.

    2) Super quick prototyping, edit the script, try it, go again. No edit compile, copy to HS (making sure HS is not active) start HS, etc. etc. - you get my drift. (I've done this many, many, many times [sob!] and it gets very old very quickly.)

    3) Never, ever write plugin again.

    4) Easy access and able to debug/modify 'plugin' code. (Although maybe that is the point...)

    5) Echoing 'Highlander' - there can be only one. With this, ALL plugins are just scripts. HomeSeer itself doesn't see any benefit, but we definitely would. (Actually HS might get some benefit, the plugin code could just be assimilated, making it part of HS proper.)

    Well, anyone see why this isn't a good idea - for a start I'd be able to see what the Z-Wave functions I can call!

    (Just on a personal level I'll be implementing this.)

  • #2
    Regards Bart
    Win7 64Bit on Intel NUCI7 with SSD
    HSPRO 3.
    Devices; 1370 Events; 691

    Jon00 Scripts, JowHue, HSTouch, Plugwise, Z-wave, Ultranetatmo, Ultracam, PHlocation, BLUSBUIRT, MeiHarmony, Buienradar, MEiUnifi Pushover 3P, Random, Nest HSPhone and Blueiris

    Visonic Powermax Alarm System (HS3) Interface:


    • #3
      In relation to 2) just at least, with Visual Studio all you need to do is press play in Visual Studio and your plugin will launch. HS2 was problematic I agree but HS3 is much simpler and quicker.

      I'm struggling with your idea and it sounds like to me that you are advocating basically open sourcing plugins and distributing them as script files? I doubt you will find anyone who for a multitude of different reasons is willing to release their plugins. There may be other issues in that people have split code across different classes and if you had a script then it is going to make no sense because even the API function contains a call to this other class.
      My Plugins:

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


      • #4

        (Like the name by the way.)

        Your first point - twit! Me not you.

        I was copying the exe over and attaching - I had totally ignored that they were exes now. Forgive HUGE stupidity.

        As for Open Sourcing, I admit there is an element of that to it (as I mentioned) - it is annoying to me I can't find out what functions I can call in plugins.

        So I tend to end up writing my own, which takes time and effort.

        But there is the point that people who don't know how Visual Studio works (and I know it is free) might want to try and Scripts are "all" they have.

        Yes, I agree with you about splitting across classes - I have a skeleton plugin that is split so if I don't use it I don't change it.

        (Found the problem with the samples was that they mixed 'their' code with user code, made it diffcult to work out what needed to change - hence I split the user code into classes.)

        So overall, probably a win to you - no wonder you're happy!