HS4 Alpha Plugin Development Release

[alexbk66]

One of the issues I run into, time and time again, is that my users delete Sonos devices from the HS devices management page which causes irrecoverable inconsistencies with the PI's .ini file.

May be off topic - but I try to minimise use of ini files. Most config information for each device I store in device PED. It's cleaner and more self-contained.

[dcorsus]

May be off topic - but I try to minimise use of ini files. Most config information for each device I store in device PED. It's cleaner and more self-contained.

Agree, I guess I was stuck in coming from HS2 and trying to save as much as possible. Thinking of doing it better in HS4 but for sure means my users will have to reconfigure from scratch or I need to spend even more effort to come up with a DB migration tool. So before I actually go there, need to know whether the HS team is planning on having upgrades from HS3 to HS4, preserving all settings. If not, I can rewrite the whole caboodle and most likely store most of the info in PED objects.

[simplextech]

Not to be negative about the use of PED or the HSD but I went that route originally and on large systems 1k devices or so everything gets very slow and the complaints start. I re-wrote my plugins to use an internal mapping for devices and references because finding them through the normal HS method was too slow and consumed too much CPU

[alexbk66]

Thinking of doing it better in HS4 but for sure means my users will have to reconfigure from scratch or I need to spend even more effort to come up with a DB migration tool..

In every new release I implement migration code, which makes it a bit messy, but transparent for users.

And yeah, it's much cleaner - when plugin starts - I don't read ini configuration, instead I enumerate all devices for the plugin (that's were propsed HS4 function wold be great) - and then read PED for each device type and settings.

[rjh]

You correct in that HS3 plugins continue to work as before so any scripting with HS3 should work with HS4 plugins. An HS4 plugin will probably different enough that they would need to change their scripts anyway. You could accept an "instance"paramter to the plugin function and they would have a minor change to make.

Our plan for the DB is that users will update to a specific version of HS3 before going to HS4. That version will save the DB in the new format so that HS4 can read the info. Our current plan to use JSON for the DB format.

Maybe you could use the PED in your devices to store information that is linked to the devices, as opposed to the INI file?

rjh maybe indeed some ideas are welcome. I realized today that I also have users who script heavily and they use the hs.pluginfunction which is called with an instance and therefore calls the correct method for the correct instance. How do we see this being supported if the instances go away? Does this mean that the people who wrote scripts need to update everything? I guess one answer to my own question is that it will all continue to work as long as the PI is "an HS3 style" PI. Is that correct?

Second questions is about DB migration. Is it the objective of the HS team to provide the capability to start from an HS3 configuration and do an upgrade to HS4 keeping all settings? I need to know so I can decide what I need to think about wrt to my own PI and its config. One of the issues I run into, time and time again, is that my users delete Sonos devices from the HS devices management page which causes irrecoverable inconsistencies with the PI's .ini file. I have been thinking about storing information about the PI into the HS database but that would mean pretty much NO DB migration when going from HS3 to HS4. So what is the intention foreseen by the HS team?

[dcorsus]

Our plan for the DB is that users will update to a specific version of HS3 before going to HS4. That version will save the DB in the new format so that HS4 can read the info. Our current plan to use JSON for the DB format.

Is the plan to keep HS References unchanged? It is these absolute values that also live in my .ini file that screw up things so if the migration tool change those while migrating, I'm in trouble.

Maybe you could use the PED in your devices to store information that is linked to the devices, as opposed to the INI file?

That was my thinking as well, perhaps already start the changes in a version of my HS3 PI but I need to get my head around how to move quite a large amount of key/value items from my .ini file to PED.

[rjh]

We will not change device refs.

Is the plan to keep HS References unchanged? It is these absolute values that also live in my .ini file that screw up things so if the migration tool change those while migrating, I'm in trouble.



That was my thinking as well, perhaps already start the changes in a version of my HS3 PI but I need to get my head around how to move quite a large amount of key/value items from my .ini file to PED.

[dcorsus]

We will not change device refs.

Thanks!!

[dcorsus]

You correct in that HS3 plugins continue to work as before so any scripting with HS3 should work with HS4 plugins. An HS4 plugin will probably different enough that they would need to change their scripts anyway. You could accept an "instance"paramter to the plugin function and they would have a minor change to make.

I was just catching up on reading the SDK documentation and realize that html plugin tags don't have the concept of an instance, it only knows PlugId, Method and it's parameters. Are we here to take ownership of routing the right callback to the right internal instance?

[rjh]

Installer updated to version .18:

https://forums.homeseer.com/forum/de...opment-release

[rmasonjr]

Installer updated to version .18:

https://forums.homeseer.com/forum/de...opment-release

Getting an error on startup:

[enigmatheatre]

Getting an error on startup:

I also get this error. rjh

Greig.

Sent from my SM-G973F using Tapatalk

[rjh]

Check your homeseer folder and make sure the pluginsdk.dll file is not there. It should only exist in \bin\homeseer. Sometimes a vislual studio solution will copy referenced dll files to the output folder. If the pluginsdk.dll file is in the HS folder check the references on any plugin code you are building and make sure none of the references are copying the dll.

I tried the installer in a Windows sandbox it appears to run fine.

I also get this error. rjh

Greig.

Sent from my SM-G973F using Tapatalk

[sirmeili]

So, throwing another, probably unpopular opinion out there. This was released to us too early. There aren't enough details or good examples for people to properly update their plugins and people are getting more frustrated than they need to. I think HST needs to rethink their timeline. I think it's being forced out and that could end in disaster. I think some of the developers who aren't really "developers" will just give up and keep their HS3 plugins which is not what HS wants.

I realize you wanted to/had to make drastic changes, but you should have had a full set of documentation in place before giving people access. That level of documentation can take a good couple of months to properly do.

[lpitman]

So, throwing another, probably unpopular opinion out there. This was released to us too early. There aren't enough details or good examples for people to properly update their plugins and people are getting more frustrated than they need to. I think HST needs to rethink their timeline. I think it's being forced out and that could end in disaster. I think some of the developers who aren't really "developers" will just give up and keep their HS3 plugins which is not what HS wants.

I realize you wanted to/had to make drastic changes, but you should have had a full set of documentation in place before giving people access. That level of documentation can take a good couple of months to properly do.

Really good point!!!