Originally posted by dcorsus
View Post
Announcement
Collapse
No announcement yet.
HS4 Alpha Plugin Development Release
Collapse
This is a sticky topic.
X
X
-
Originally posted by alexbk66 View PostMay 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.
Comment
-
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
Comment
-
Originally posted by dcorsus View PostThinking 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..
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.
Comment
-
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?
Originally posted by dcorsus View Post
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?
Comment
-
Originally posted by rjh View PostOur 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.
Originally posted by rjh View PostMaybe you could use the PED in your devices to store information that is linked to the devices, as opposed to the INI file?
Comment
-
We will not change device refs.
Originally posted by dcorsus View Post
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.
Comment
-
Originally posted by rjh View PostYou 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.
Comment
-
Originally posted by rjh View PostHS4Pro Running on a Raspberry Pi4
67 Z-Wave Nodes, 111 Events, 422 Devices
Z-Wave, UPB, WiFi
Plugins: EasyTrigger, weatherXML, OMNI, Z-Wave, Tuya, Device History
HSTouch Clients: 3 Android, 1 Joggler
Comment
-
Zwave = Z-Stick, 3xHSM100� 7xACT ZDM230, 1xEverspring SM103, 2xACT HomePro ZRP210.
X10 = CM12U, 2xAM12, 1xAW10, 1 x TM13U, 1xMS13, 2xHR10, 2xSS13
Other Hardware = ADI Ocelot + secu16, Global Cache GC100, RFXtrx433, 3 x Foscams.
Plugings = RFXcom, ActiveBackup, Applied Digital Ocelot, BLDeviceMatrix, BLGarbage, BLLAN, Current Cost, Global Cache GC100,HSTouch Android, HSTouch Server, HSTouch Server Unlimited, NetCAM, PowerTrigger, SageWebcamXP, SqueezeBox, X10 CM11A/CM12U.
Scripts = Various
Comment
-
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.
Comment
-
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.
- Likes 2
Comment
-
Originally posted by sirmeili View PostSo, 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.-Larry
A member of "The HA Pioneer Group", MyWebSite
Plugins:
VWS, AB8SS, lrpSpeak, Calendar, Arduino, Harmony, BlueIris, Sprinklers, ZipBackup...
Hardware:
Intel NUC8i7BEH1 running Windows 10 Pro headless, HS3 Pro, Plex running on Synology dual High Availability DS-1815+ NAS (24Tb each), Synology Surveillance Station running on DS-416 Slim (8Tb), Samsung SmartThings, Google Home, Alexa, Hubitat Elevation, ZNET, Ubiquiti UniFi Network, Davis Vantage Pro II Weather Station. Whole house speaker system using a couple of AB8SS switches. Vantage Pro II Weather Station, Rain8Net Sprinklers, Hubitat Elevation, Google Home, Alexa, DSC Security System, Ubiquiti UniFi Network.
- Likes 1
Comment
Comment