Announcement

Collapse
No announcement yet.

Single vs Multiple .ini files

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

    Single vs Multiple .ini files

    I have a number of scripts in the script library that place user-configuration definitions in a file homeseer.ini located in the homeseer root directory. Now that homeseer supports .ini I will be moving the definitions into the homeeer\config directory.

    I am polling to see if I should continue to use a single homeseer.ini file, or should I use roughly one .ini file per library post such as Movies.ini, AudreyUtilities.ini, Guest.ini etc.
    0
    Continue to place definitions in homeseer.ini
    0%
    0
    Put definitions in individual files
    0%
    0

    #2
    The third option seems like the only possibility. Put things that are specific to a single script in its own configuration file. Put things that are likely to be of interest to other scripts in a common configuration file. (And in particular, put things that are linked to specific devices into the file for that purpose, using the calls in DeviceProperties.txt as described here, or equivalent.)

    Nucleus Home Automation
    News, support, and updates for Rover, Network Monitor, TimeIcons, and more

    Comment


      #3
      I think that Hunter has a good idea. Maybe we could come up with a consensus what should be in the settings.ini.

      Things like demographics e.g. name, location, zip code, area code ....

      It wouldn't be hard to write a script to enter the information into settings.ini using input boxes.

      Comment


        #4
        Based on Hunter's thought, maybe going to one file wouldn't be so bad afterall. It would just be very important to document with a section header to which scripts those config settings are for. Just a thought...
        HomeSeer 2, HomeSeer 3, Allonis myServer, Amazon Alexa Dots, ELK M1G, ISY 994i, HomeKit, BlueIris, and 6 "4k" Cameras using NVR, and integration between all of these systems. Home Automation since 1980.

        Comment


          #5
          I find it is a whole lot easier to change the variables in the top of the script rather than have to manage 2 files in 2 different locations. Just my 2 cents.

          -Rupp
          ...One Nation Under GOD, Indivisible, With Liberty And Justice For All.
          💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

          Comment


            #6
            A lot of people aren't comfortable with editing scripts, and no one likes the dreaded "error 0 in line 0" that sometimes comes of it.

            However, if Rich actually comes up with the improvements I asked for in the INI commands here, my next project will be to make an ASP that allows anyone to edit the stuff in an INI file. The idea will be that script-writers can call this ASP passing certain parameters that make the ASP only show the fields relevant to that script. (There will also hopefully be some "help file" type explanation of each field, and if I'm feeling very ambitious, some data validation.)

            Since the INI file is always accessed through HomeSeer, never directly, there won't be any problems with caching, and if Rich someday changes where these things are stored (again), this won't break anyone's scripts. Users will be able to configure their preferences in a script easily without playing with an editor, and in fact, without even having to be at the computer where HomeSeer runs.

            I'm just very frustrated that it's taken months for us to even get the missing INI commands, and they're still not quite working, and it's now several weeks and several updates since Rich promised to fix one of the problems and think about the other but no movement again.

            IMO, something like this should have been integrated into the whole "automatic install/update of scripts" mechanism that Rich developed but has still not told us about. Maybe not this, but something to address this need. Communication between us and Rich has, it seems to me, dropped off pretty sharply over the last few months (understandable since HomeSeer is growing and one man can't do everything like he used to be able to, but it's still a shame, especially when it impairs development -- and particularly when it makes it harder for some of us to help shoulder some of the burden).

            Nucleus Home Automation
            News, support, and updates for Rover, Network Monitor, TimeIcons, and more

            Comment


              #7
              Well, here is how I look at it. I can update a script, you can put it in the correct directory and never have to edit anything. Your previous values are still in the ini file.

              I am also making an ini edit page for all of my scripts. Since I am rarely at my server, I can make changes via the web interface. Also by having an editor page, I can make sure that the values are what my script is expecting. If the script needs a 1, 2, 3 4, or 5. I can make a dropdown and then the only values you can select are the ones I allow.

              One other thing I have started doing in all my scripts is to do the GetINI function and test it for blank. If its blank I use SaveINI and set it to a default value. The script continues to run with no errors and you can use the ini editor later to change the default if you want.

              My thought is that everyone needs to make their own ini file. The only time we should use from someone else's ini file is if that file has been placed in public domain. That would mean that anyone can make a change to it and the original author can not take his ini file and go home.

              One thing I think we need to do is come up with a web page where we go to list any ini file that we are going to post out for public use. You would go to the page, see if the name you are wanting to use is being used by someone else. If so, then you need to select a different name for your public post. Otherwise, somewhere down the line we are going to end up with 2 scripts trying to use homeseer.ini or network.ini or includes.ini.

              I think this would be a good idea to do with the include files as well. A web page where we can go to see what functions are already available, and what names are already in use. Not just include file names but function names as well.

              Jeff Farmer

              --
              Jeff Farmer
              HS 3, HSPhone
              My HS3 Plugins: CFHSExtras, Random, Restart, Tracker, WeatherXML, PanaBluRay
              Other Plugins In Use: APCUPSD, BLOnkyo, Device History, EasyTrigger, HSTouch Server, PHLocation2, Pushover, RFXCom, UltraGCIR3, UltraMon3, UltraPioneerAVR3, X10, Z-Wave

              Hardware: GoControl Irrigation Controler, Schlage Lever Lock, Schlage Deadbolt, Way2Call Hi-Phone, RFXCom RFXrec433 Receiver, WGL 800, TI-103, Z-Net, Pioneer 1120, Pioneer 1021, Pioneer LX302, Panasonic BDT-110, Panasonic BDT-210 x2

              Comment


                #8
                Registering your own INI filenames, section names, and field names on a web site is a good idea. Rich could link to it. Anyone up to hosting such a thing?

                Nucleus Home Automation
                News, support, and updates for Rover, Network Monitor, TimeIcons, and more

                Comment


                  #9
                  I will host it if there is enough interest in doing this.

                  Jeff Farmer

                  --
                  Jeff Farmer
                  HS 3, HSPhone
                  My HS3 Plugins: CFHSExtras, Random, Restart, Tracker, WeatherXML, PanaBluRay
                  Other Plugins In Use: APCUPSD, BLOnkyo, Device History, EasyTrigger, HSTouch Server, PHLocation2, Pushover, RFXCom, UltraGCIR3, UltraMon3, UltraPioneerAVR3, X10, Z-Wave

                  Hardware: GoControl Irrigation Controler, Schlage Lever Lock, Schlage Deadbolt, Way2Call Hi-Phone, RFXCom RFXrec433 Receiver, WGL 800, TI-103, Z-Net, Pioneer 1120, Pioneer 1021, Pioneer LX302, Panasonic BDT-110, Panasonic BDT-210 x2

                  Comment

                  Working...
                  X